$30 off During Our Annual Pro Sale. View Details »

Segment Routing入門

Segment Routing入門

Segment Routing入門用資料

Wataru MISHIMA

November 29, 2021
Tweet

More Decks by Wataru MISHIMA

Other Decks in Technology

Transcript

  1. © NTT Communications Corporation All Rights Reserved.
    Segment Routing⼊⾨
    2022/1/13
    イノベーションセンター 三島 航

    View Slide

  2. © NTT Communications Corporation All Rights Reserved. 2
    ● 閉域網のルーティング技術について
    ○ TE(Traffic Engineering)
    ○ VPN(Virtual Private Network)
    ○ Service Function Chaining
    ● Segment Routing
    ○ Segment Routingの概要
    ■ SRの仕組み(Segmentとは、SRの転送⽅法)
    ■ SR Policy
    ○ SRのデータプレーン
    ■ SR-MPLS、SRv6
    ○ SRのコントロールプレーン
    ■ IS-IS/OSPF拡張
    ● Flex-Algo
    ■ MP-BGP
    ■ SR PCE
    ○ SR関連の応⽤技術
    ■ Fast ReRoute、TI-LFA
    ■ EPE
    画像︓http://www.segment-routing.net/
    ⽬次

    View Slide

  3. © NTT Communications Corporation All Rights Reserved. 3
    ● TE(Traffic Engineering)
    ○ 帯域確保、遅延最⼩化、冗⻑化等
    ○ Segment Routingが⽣まれた背景としてわかりやすい
    ● VPN(Virtual Private Network)
    ○ 顧客のネットワーク同⼠を接続、
    ○ オフィス間・DC間などの拠点間通信、外部から社内ネットワークへのアクセス等
    ● Service Function Chaining
    ○ TEの⼀種。ある通信に特定のNetwork Functionを挟み込む
    ○ 通信への付加価値適⽤
    CGN Firewall Optimizer DPI
    Dst.
    Service Chain B
    Service Chain A
    B
    A
    Customer A
    Customer B
    Customer A
    Customer B
    VPN A
    VPN B
    TE Path B
    TE Path A
    ※閉域網: インターネットから分離されたネットワーク
    ※SRは閉域網のみで使われる技術ではないが、基本を学ぶため閉域網の事例で紹介
    A D
    B
    C
    X
    Z
    Y
    閉域網のルーティング技術について

    View Slide

  4. © NTT Communications Corporation All Rights Reserved. 4
    ● 閉域網の位置・役割による呼称
    ○ CE (Customer Edge) : 閉域網のユーザ側ルータ
    ○ PE (Provider Edge) : CEを収容する閉域網のエッジルータ
    ○ P (Provider) : 閉域網内に存在するコアルータ
    ● 閉域網の⼊出や送受信による呼称
    ○ Ingress / Egress : 閉域網の⼊り⼝: Ingress、出⼝: Egress
    ○ Headend / Tailend : 閉域網の送信元: Headend、終端部: Tailend
    ● BGP的な役割による呼称
    ○ ASBR (AS Border Router) : ASの境界部に位置するルータ。対向とeBGPで経路を交換
    domain
    PE/ASBR
    P
    CE PE ASBR
    Autonomous System
    Ingress Egress
    Tailend
    Headend
    Egress Peer
    AS
    Customer
    CEはPEと異なるASとして設計可能
    ルータの役割と呼称

    View Slide

  5. © NTT Communications Corporation All Rights Reserved. 5
    TE(Traffic Engineering)

    View Slide

  6. © NTT Communications Corporation All Rights Reserved. 6
    ● 経路表による宛先IPアドレスベースでの転送
    ○ 各ルータのポリシーに基づいた最短経路を経路表に格納
    ○ 宛先を元に送出先を決定
    A D
    B
    C
    X
    Z
    Aの経路表
    宛先 送出先
    X X
    Y Y
    B B
    C C
    D B
    Z B
    Y
    Bの経路表
    宛先 送出先
    X A
    Y A
    A A
    C C
    D D
    Z D
    Dの経路表
    宛先 送出先
    X B
    Y B
    A B
    B B
    C C
    Z Z
    P.6からP.11までは下記の浅間さん資料の流れを参考にしています
    https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    ⼀般的なIPによる転送

    View Slide

  7. © NTT Communications Corporation All Rights Reserved. 7
    ● 送信元やプロトコル種別など、宛先以外の要素で転送したい︕
    ○ ⾳声通信は低遅延、動画は低ジッタ、ウェブは広帯域...
    ○ 送信元Xさんはお⾦をたくさん払っているので品質の良い通信...
    ○ 特定の送信元以外の通信は、セキュリティ機器を複数経由させたい...
    ○ → 実現できれば、ネットワークに付加価値を提供可能
    ● 宛先ベースの経路表だけでは実現不可能
    A D
    B
    C
    X
    Z
    Aの経路表
    宛先 送出先
    X X
    Y Y
    B B
    C C
    D B
    Z B?C?
    Y
    遅延優先︖
    帯域優先
    P.6からP.11までは下記の浅間さん資料の流れを参考にしています
    https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    より⾼度な経路制御の要求

    View Slide

  8. © NTT Communications Corporation All Rights Reserved. 8
    ● Policy-Based Routing
    ○ ポリシーに基づいた転送を⾏うための仕組み
    ○ 経路表ではなく、ポリシーを記述したルートマップに基づき転送
    ○ 送信元アドレス・プロトコル・ポート・インターフェース等の条件と、該当したパケットの
    処理をルートマップに定義、転送を実施
    A D
    B
    C
    X
    Z
    Y
    遅延優先
    帯域優先
    Aのルートマップ
    match set
    宛先 送信元 動作 転送先
    Z X permit B
    Z Y permit C
    P.6からP.11までは下記の浅間さん資料の流れを参考にしています
    https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    案1: PBR

    View Slide

  9. © NTT Communications Corporation All Rights Reserved. 9
    ● MPLS(Multi-layer Protocol Label Switching)
    ○ パケットに⼊れたMPLSヘッダ(Shimヘッダ)内のラベル情報を利⽤し転送
    ○ MPLS TableをExact Matchで参照し転送
    ○ ラベルにPush / Swap / Popいずれかの操作をしながらスイッチング
    ■ Push: ラベル追加
    ■ Swap: ラベル交換
    ■ Pop: ラベル除去
    A D
    B
    C
    X
    Z
    Y
    MPLS domain
    BのMPLS Table
    Label Action Next
    3 Pop -
    6 Swap “5” D
    AのMPLS Table
    Label Action Next
    1 Pop -
    2 Swap “6” B
    3 Swap “5” C
    4 Swap “3” B
    5 Swap “4” C
    6 Pop X
    7 Pop Y
    2 Payload
    Shim
    DのMPLS Table
    Label Action Next
    2 Pop -
    5 Pop Z
    CのMPLS Table
    Label Action Next
    4 Pop -
    5 Swap “5” D
    3 Payload
    P.6からP.11までは下記の浅間さん資料の流れを参考にしています
    https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    案2: MPLS

    View Slide

  10. © NTT Communications Corporation All Rights Reserved. 10
    ● OpenFlow
    ○ SDN(Software Defined Networking)の実現⼿法の⼀つ
    ○ 転送を担うOpenFlowスイッチを、ポリシーを管理するOpenFlowコントローラで制御
    ■ スイッチはFlow Tableに無いパケットが⼊ってきた際にコントローラへ確認
    ■ コントローラは各スイッチのFlow Tableを更新すると共に転送⽅法を指⽰
    A D
    B
    C
    X
    Z
    Y
    Packet In
    Flow Mod
    Packet Out
    AのFlow Table
    Rule Action
    宛先 送信元 動作 対象
    Z X 転送 B
    Z Y 転送 C
    Controller
    P.6からP.11までは下記の浅間さん資料の流れを参考にしています
    https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    案3: OpenFlow

    View Slide

  11. © NTT Communications Corporation All Rights Reserved. 11
    1. 中間ノードのステート増加
    ○ ポート番号 / Interface / ホストアドレスなど細かい単位での制御︖
    2. 新たな経路追加/削除時のステート追加(伝搬)
    ○ 経路追加の度に、中間のノード全ての経路表を更新する︖(シグナリング)
    A D
    B
    C
    X
    Z
    Y
    match set
    宛先 送信元 動作 転送先
    Z X permit B
    Z Y permit C
    D X permit B
    D Y permit C
    C X permit B
    C Y permit C
    B X permit B
    B Y permit C
    X X permit X
    Y Y permit Y
    制御対象の数に伴い
    テーブルが肥⼤化
    P.6からP.11までは下記の浅間さん資料の流れを参考にしています
    https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    従来の経路制御技術が抱える課題

    View Slide

  12. © NTT Communications Corporation All Rights Reserved. 12
    ● 案1〜3の⼿法では、制御対象の数だけ中間ノードが転送ルールを保持
    ● 中間ノードのステート増加
    ○ 柔軟な経路制御を実現するためのルール増加
    ■ 宛先ポートやプロトコルなど、より細かい条件での経路制御の要求
    ■ 課⾦に基づいた送信元Prefixごとの経路制御の要求
    ○ 中間ノードが分散して保持する発⾏済みルールの管理
    A D
    B
    C
    X
    Z
    Y
    match set
    宛先 送信元 動作 転送先
    Z X permit B
    Z Y permit C
    D X permit B
    D Y permit C
    C X permit B
    C Y permit C
    B X permit B
    B Y permit C
    X X permit X
    Y Y permit Y
    中間ノードであるB/C/Dも
    同様にStateが増加
    従来の経路制御技術が抱える課題 - 中間ノードのステート増加

    View Slide

  13. © NTT Communications Corporation All Rights Reserved. 13
    ● 中間にステートが必要 = 新たな経路追加/削除の度、中間ノードの操作が必要
    ○ 中間ノードの経路を更新し、新たな経路を⽣成する処理をシグナリングと呼ぶ
    ● IGPの他にシグナリング専⽤プロトコルの管理・運⽤が必要
    ○ 管理・運⽤の煩雑化や学習コストの増加
    → 中間ノードのステート増加と、煩雑なプロトコルがスケーラビリティの課題に
    A D
    B
    C
    X
    Z
    Y
    従来の経路制御技術が抱える課題 - 経路追加/削除時の伝搬

    View Slide

  14. © NTT Communications Corporation All Rights Reserved. 14
    Segment Routing

    View Slide

  15. © NTT Communications Corporation All Rights Reserved. 15
    ● SR(Segment Routing)
    ○ 次世代の経路制御技術
    ■ RFC8402で標準化: https://datatracker.ietf.org/doc/html/rfc8402
    ● 3つの特徴
    ○ Scalable: ソースルーティングのパラダイム
    ■ 中間ノードの持つステートを削減
    ○ Simple: シンプルなプロトコル構成
    ■ データプレーンはMPLS or IPv6
    ■ コントロールプレーンは既存IGP or EGPを拡張し使⽤
    ■ シグナリングプロトコルが不要
    ○ Seamless deployment: 既存データプレーンとの親和性
    ■ SR-MPLSでは既存のMPLS関連技術を利⽤可能
    ■ SRv6は既存IPv6網を⼟管として使⽤可能 画像︓http://www.segment-routing.net/
    → 従来の経路制御技術が抱える、ステート増加とシグナリングによるスケーラビリティの課題を解決
    Segment Routingの概要

    View Slide

  16. © NTT Communications Corporation All Rights Reserved. 16
    ● 送信元で経路を指定し、転送を⾏うルーティングパラダイム
    ○ パケット⾃⾝が経路情報をもち、それに基づいて転送(= 経路を中間ノードで管理しない)
    ○ 経路指定の⼿法に合わせ、ストリクト/ルーズの2種類が存在
    ● ストリクトソースルーティング
    ○ 宛先までに経由するノード/リンクを全て指定する⼿法
    ○ 主なユースケース︓帯域保証
    ● ルーズソースルーティング
    ○ 宛先と経由すべきノードのみを指定し、その間の経路は厳格に指定しない⼿法
    ○ 主なユースケース︓サービスチェイニング
    A D
    B
    C
    X
    Z
    Y
    Z Payload
    D
    B
    Z Payload
    C
    Loose Source Routing
    Strict Source Routing
    ソースルーティング

    View Slide

  17. © NTT Communications Corporation All Rights Reserved. 17
    ● SRでの転送対象、処理を指⽰するものをSegmentと呼ぶ
    ○ 各ノードはSegment ID(SID)で指⽰された処理を⾏いながらパケットを転送
    ○ SR domainで⼀意なGlobal Segmentと、ノード内で⼀意なLocal Segmentが存在
    ● Segmentの例
    ○ Node Segment: 特定のノードを⽰す。Global Segment
    ■ Prefixに紐づくSegment をPrefix Segmentと呼ぶ。Node SegmentはノードのLoopbackに紐づくPrefix Segment
    ○ Adjacency Segment: 隣接関係を⽰す。Local Segment
    ○ Binding Segment: 任意のポリシーに紐付けて使うSegment。⼀般的にLocal Segment
    SR domain
    SID 処理
    10 X
    11 Y
    2 B
    3 C
    4 B
    12 B
    101 X
    102 Y
    103 B
    104 C
    A D
    B
    C
    X
    Z
    Y
    Node SID
    Adjacency SID
    Payload
    12
    4
    103
    Segment List
    1
    10
    11
    12
    1
    2
    3
    4
    101
    102
    103
    104
    HeadendであるXがencapし、Segment ListでX→A→B→D→Zと
    通るよう指定された例
    2段⽬はAdjacency SIDである103を指定されているため、
    確実にA-Bのリンクを通る
    Adjacency SIDはStrict Source Routingをしたい時やMulti-Path区間で
    リンクを指定する時に、
    Node SIDはLoose Source Routingをしたい時に⽤いる
    AのSID Table
    Segment

    View Slide

  18. © NTT Communications Corporation All Rights Reserved. 18
    1. SR domainの送信元がパケットにSR Headerを付与
    ○ SR Header…SRに関する情報を格納するヘッダ
    ○ 経路をSR Header中のSegment Listで指定
    2. 中間ノードはSegment Listの先頭を経路表から参照し転送
    3. 最終的な宛先ノードがSR Headerを除去
    SR domain
    A D
    B
    C
    X
    Z
    Y
    Payload
    12
    4
    103
    Segment List
    1
    10
    11
    12
    1
    2
    3
    4
    101
    102
    103
    104
    1. HeadendであるXが、受信したパケットに
    Segment Listの含まれたSR Headerを付与
    2. パケットを受け取ったAは
    SID Tableを参照し転送
    3. SR Headerが除去され、
    SR domainから出る
    Payload
    SID 処理
    10 X
    11 Y
    2 B
    3 C
    4 B
    12 B
    101 X
    102 Y
    103 B
    104 C
    AのSID Table
    SRの転送例

    View Slide

  19. © NTT Communications Corporation All Rights Reserved. 19
    ● SRにおける転送⼿法を指定するポリシー
    ○ 例: ノードAとBを経由する、帯域X bps以上/遅延X ms未満、SFCなど
    ○ SR Policyをインスタンス化したものがセグメントリスト
    ● 各SR Policyは Binding SID(BSID)と結び付けられる
    ○ HeadendはSR Policyに基づきセグメントリストをつけてパケットを送出
    ○ ⾃らが処理すべきBSIDを受け取ったノードはそれに紐づくSR Policyを処理
    ■ 他のSegment listをつける、SRHを外して他プロトコルのトンネルに繋ぐなど
    BSIDに対応する新たなSegment Listを付与する例
    画像: https://y-network.jp/2020/07/31/segment-routing-024/
    BSIDに対応する他プロトコルのトンネルに繋ぐ例
    画像: http://cisco-inspire.jp/issues/0024/closeup3.html
    SR Policy

    View Slide

  20. © NTT Communications Corporation All Rights Reserved. 20
    ● あるネットワーク上に仮想ネットワークを作成する概念
    ○ 物理的なNW構造に囚われない⼀連の通信・経路制御を実現するために利⽤
    ○ 上位層をOverlay Network・下位層をUnderlay Networkと呼ぶ
    ■ Underlayは物理構成を管理
    ■ OverlayはUnderlayの構成を気にせず構成・転送
    Overlay
    Underlay
    A D
    B
    C
    X
    Z
    Y
    A D
    B
    C
    X
    Z
    Y
    例1: IPv4+OSPF
    例2: IPv6+IS-IS
    例1: MPLS+RSVP-TE
    例2: SRv6+IS-IS
    オーバレイネットワーク

    View Slide

  21. © NTT Communications Corporation All Rights Reserved. 21
    データプレーン / コントロールプレーン

    View Slide

  22. © NTT Communications Corporation All Rights Reserved. 22
    ● ネットワークの持つ機能を役割ごとに分離し扱う概念
    ○ データプレーン︓転送機能
    ○ コントロールプレーン︓経路共有。SR的にはさらに3種類の役割が考えられる
    ■ Control Plane (LinkState): オーバレイの構築(Node SIDとTE情報の共有)
    ■ Control Plane (VPN): オーバレイ上のVPNの構築(VPN経路とVPNラベルの共有)
    ■ Control Plane (Policy): ポリシーの適⽤(Segment Listの作成と配布)
    PE P
    Control Plane (VPN)
    Data Plane
    役割︓オーバーレイ上のVPNの構築
    (BGP Prefix-SIDの広告)
    プロトコル︓BGP(VPNv4/VPNv6/EVPN等)
    役割︓パケットの転送
    プロトコル︓MPLS, IPv6
    PE
    SID・TE情報の共有
    パケットの転送
    Control Plane
    (LinkState)
    Control Plane (Policy) PCE
    役割︓経路の設定(Segement Listの作成と配布)
    プロトコル︓BGP-LS(トポロジ吸い上げ)
    PCEP(SegmentListの適⽤)
    ポリシーの適⽤
    VPNの構築
    役割︓オーバーレイの構築
    (Node SID/Adjacency SIDの伝搬)
    プロトコル︓IS-IS, OSPF, BGP-LS(Multi-AS等の場合)
    データプレーン / コントロールプレーン

    View Slide

  23. © NTT Communications Corporation All Rights Reserved. 23
    ● 役割: データの転送
    ○ パケットにSegment Listをつけて送出
    ○ SID Tableを元にデータを転送
    ● 利⽤するプロトコルにより、SRv6とSR-MPLSに⼤別
    ○ SRv6ならSegment Listは拡張ヘッダ内、SID TableはIPv6の経路表
    ○ SR-MPLSならSegment ListはShimヘッダ(ラベル)のスタック、SID TableはMPLS Table
    Data Plane MPLS or IPv6(パケットの転送)
    SRのデータプレーン

    View Slide

  24. © NTT Communications Corporation All Rights Reserved. 24
    ● 役割: SR domain内でのSIDの共有
    ○ SR domain内の他ノードに⾃らの持つSIDを伝達
    ■ 他ノードのNode SIDを学習し、SID Tableに格納
    ○ SID伝搬にはUnderlayと共通のIGP(OSPF/IS-IS)を利⽤可能
    ■ IS-IS, OSPF共にSR⽤の拡張を利⽤
    ● SR-MPLSでは拡張が実装されていないと使えない
    ● TE metricやFlex-Algoの定義などもIGP拡張で共有(後述)
    ■ IGPを利⽤するため、トポロジ変更時の収束はUnderlayと同時になる
    Control Plane
    (LinkState)
    IS-IS (SID・TE情報の共有)
    SRのコントロールプレーン(LinkState)

    View Slide

  25. © NTT Communications Corporation All Rights Reserved. 25
    ● 転送に必要なSID情報の伝搬
    ○ 既存のIS-IS / OSPFやBGP-LSを拡張して利⽤される
    ■ IGPではIS-ISが実装状況の良い傾向
    ○ ⼀般的に、アンダーレイと同じルーティングプロトコルで広告
    SR domain
    AのSID Table
    SID 処理
    10 X
    11 Y
    2 B
    3 C
    4 B
    12 B
    101 X
    102 Y
    103 B
    104 C
    A D
    B
    C
    X
    Z
    Y
    10
    11
    12
    1
    2
    3
    4
    101
    102
    103
    104
    経路広告
    宛先 送出先
    X X
    Y Y
    B B
    C C
    D B
    Z B
    Aの経路表
    (Underlay)
    SRのコントロールプレーン(LinkState)の流れ

    View Slide

  26. © NTT Communications Corporation All Rights Reserved. 26
    1. SR domainの送信元がパケットにSR Headerを付与
    ○ SR Header…SRに関する情報を格納するヘッダ
    ○ 経路をSR Header中のSegment Listで指定
    2. 中間ノードはSegment Listの先頭を経路表から参照し転送
    3. 最終的な宛先ノードがSR Headerを除去
    SR domain
    AのSID Table
    SID 処理
    10 X
    11 Y
    2 B
    3 C
    4 B
    12 B
    101 X
    102 Y
    103 B
    104 C
    A D
    B
    C
    X
    Z
    Y
    Payload
    12
    4
    103
    Segment List
    1
    10
    11
    12
    1
    2
    3
    4
    101
    102
    103
    104
    HeadendであるXが、受信したパケットに
    Segment Listの含まれたSR Headerを付与
    (再掲)SRのデータプレーンの流れ

    View Slide

  27. © NTT Communications Corporation All Rights Reserved. 27
    SRのデータプレーン
    SR-MPLSとSRv6

    View Slide

  28. © NTT Communications Corporation All Rights Reserved. 28
    ● MPLS(Multi-layer Protocol Label Switching)
    ○ パケットに20bitのMPLSラベルが含まれた32bitのMPLSヘッダ(Shimヘッダ)を付与し、
    Exact Matchな転送を⾏う技術
    ■ MPLSで作成する経路をLSP(Label Switched Path)、MPLSルータをLSR(Label Switch Router)と呼ぶ
    ○ パケットを受け取ったLSRは、MPLS Tableを参照し次のいずれかの処理を実施
    ■ PUSH… Shimヘッダ(MPLSラベル)を追加する
    ■ POP… Shimヘッダ(ラベル)を減らす
    ■ SWAP… 先頭ラベルを別のラベルに変更する
    A D
    B
    C
    X
    Z
    Y
    MPLS domain
    BのMPLS Table
    Label Action Next
    3 Pop -
    6 Swap “5” D
    AのMPLS Table
    Label Action Next
    1 Pop -
    2 Swap “6” B
    3 Swap “5” C
    4 Swap “3” B
    5 Swap “4” C
    6 Pop X
    7 Pop Y
    2 Payload
    Shim
    DのMPLS Table
    Label Action Next
    2 Pop -
    5 Pop Z
    CのMPLS Table
    Label Action Next
    4 Pop -
    5 Swap “5” D
    3 Payload
    右図は従来のMPLSによる転送。基本的にはShimヘッダは複数つけない
    PUSH → SWAP, SWAP... → POP
    ラスト1HopはShimヘッダごと外すことで
    Egressノードの負荷を下げることも可能
    PHP(Penultimate Hop Popping) と呼ぶ
    PUSH 2
    SWAP 6
    SWAP 5
    POP
    SWAP 5
    SWAP 5
    PUSH 3
    POP
    MPLS

    View Slide

  29. © NTT Communications Corporation All Rights Reserved. 29
    ● L2ヘッダとL3ヘッダの間にMPLS Shimヘッダを付与
    ○ 俗にレイヤ2.8(2.5)と呼ばれる
    ■ ドメイン (AS等) は超えないがドメイン内のネットワークは超える、L2とL3の中間の動き
    ○ Shimヘッダ内は4領域に分かれる
    ■ Label: MPLSラベル。20bit (約100万) の領域が存在
    ■ EXP: 予約領域。QoS制御などに利⽤可能
    ■ S: Shimヘッダが多段構成かどうかの判定フラグ。0なら次もShim、1ならL3ヘッダが続く
    ■ TTL: ループ防⽌⽤。IPヘッダのTTLと関連づけたりつけなかったりする
    Layer 2 header MPLS Shim header (32bits) Layer 3 header L3 Payload
    MPLS Shim header (32bits)
    Label (20bits)
    EXP
    (3bits)
    S
    (1bits)
    TTL
    (8bits)
    Shimヘッダは任意の数つけられる
    MPLSのフレームフォーマット

    View Slide

  30. © NTT Communications Corporation All Rights Reserved. 30
    ● データプレーンにMPLSを利⽤したSegment Routing
    ○ ShimヘッダのスタックをSegment List、MPLS TableをSID Tableとして⽤いる
    A D
    B
    C
    X
    Z
    Y
    SR domain
    BのSID Table(⼀部)
    Label Action Next
    6 Swap “5” D
    12 Payload
    Shim
    DのMPLS Table(⼀部)
    Label Action Next
    12 Pop Z
    CのSID Table(⼀部)
    Label Action Next
    12
    Swap
    “12”
    D
    12 Payload
    SRのPHPを特にPSP(Penultimate
    Segment Pop of the SRH)と呼ぶ
    10
    11
    12
    3
    4
    1
    AのSID Table
    ・隣接するNode SIDやAdjacency SIDは全てPop処理
    ・隣接していないNode SIDは同じラベルへのSwap処理
    2段以上のSegment Listの場合は、Headendが多段Pushする
    2
    3
    2
    Label Action Next
    10 Pop X
    11 Pop Y
    2 Pop B
    3 Pop C
    4 Swap “4” B
    12 Swap “12” B
    101 Pop X
    102 Pop Y
    103 Pop B
    104 Pop C
    SR-MPLS

    View Slide

  31. © NTT Communications Corporation All Rights Reserved. 31
    ● MPLSは先頭ラベルを⾒て次の転送先を決めるため、あるノードの受け取る
    先頭ラベルは次のノードを⽰す
    ○ あるノードのNode SIDはその⼿前のノードが処理する
    ○ 各ノードが⾃らのNode SID(Locator/Function)を処理するSRv6の処理とは異なる
    A D
    B
    C
    X
    Z
    Y
    SR domain
    12 Payload
    Shim
    12 Payload
    10
    11
    12
    2
    3
    4
    1
    2
    3
    12 Payload
    12 Payload
    AのSID Table(⼀部)
    2 や 3 はBやCのNode SIDだが、
    ⼀つ⼿前に位置するAがPop処理をする。
    BやCは⾃らのNode SIDを受け取らない
    ラベルスイッチングに伴うSR-MPLS固有の挙動
    Label Action Next
    10 Pop X
    11 Pop Y
    2 Pop B
    3 Pop C
    … … …

    View Slide

  32. © NTT Communications Corporation All Rights Reserved. 32
    ● 各ルータの利⽤するGlobal SIDの範囲
    ○ SRGBはあるSR domainの中で統⼀することが推奨される
    ○ 同様に、あるノード内でのLocal SIDの範囲をSRLB(SR Local Block)と呼ぶ
    ● SR-MPLSでは、SRGBのベースにindexを⾜した値をNode SIDとして扱う
    ○ SRGBはSegment Routing全体の概念だが、特にSR-MPLSでは重要となる
    ■ MPLS VPNやRSVP-TEなど、ルータ内で別のMPLSラベルとして使われる範囲と分ける必要がある
    ○ 機種ごとにデフォルトの領域が異なるため、マルチベンダ環境では事前に統⼀することを推奨
    ■ 隣接ルータとSRGBが異なる場合でも、IGPで広告されるSRGB情報を元に接続可能(次ページ)
    Node 1
    SRGB: 16000-23999
    index: 1
    Node 2
    SRGB: 16000-23999
    index: 2
    Node 3
    SRGB: 16000-23999
    index: 3
    Label Action Next
    16002 POP Node 2
    16003 SWAP 16003 Node 2
    ... ... ...
    SR domain
    16001 16002 16003
    Node 1のSID Table(⼀部)
    Label Action Next
    16001 POP Node 1
    16003 POP Node 3
    ... ... ...
    Node 2のSID Table(⼀部)
    16003 Payload Payload
    Pop
    Prefix: Z.Z.Z.Z
    Index: 3
    Node 3のIndex
    Prefix: Z.Z.Z.Z
    Index: 3
    Node 3のIndex
    SRGB: 16000
    Range: 8000
    Node 2のSRGB
    IGP(ISISやOSPF)
    SRGB: 16000
    Range: 8000
    Node 3のSRGB
    SRGB(SR Global Block)

    View Slide

  33. © NTT Communications Corporation All Rights Reserved. 33
    ● SRGBは運⽤上合わせることが推奨されているが、必須では無い
    ○ IGPで広告される情報をベースに各ノードがSID TableのOutgoing Labelを調整し相互接続
    ○ SID Tableの作成⽅法:
    Node 1
    SRGB: 16000-23999
    index: 1
    Node 2
    SRGB: 800000-804095
    index: 2
    Node 3
    SRGB: 16000-23999
    index: 3
    Label Action Next
    16002 POP Node 2
    16003 SWAP 800003 Node 2
    ... ... ...
    SR domain
    16001 16002 16003
    Node 1のSID Table(⼀部)
    Label Action Next
    800001 POP Node 1
    800003 POP Node 3
    ... ... ...
    Node 2のSID Table(⼀部)
    800003 Payload Payload
    Pop
    Prefix: Z.Z.Z.Z
    Index: 3
    Node 3のIndex
    Prefix: Z.Z.Z.Z
    Index: 3
    Node 3のIndex
    SRGB: 800000
    Range: 4096
    Node 2のSRGB
    SRGB: 16000
    Range: 8000
    Node 3のSRGB
    Node 2のSRGBは800000〜だが、
    Node 1では16002として学習
    Node 3のNode SIDは、
    16003から800003の
    SWAPとなっている
    1. ⾃らのSRGBの基準値に、IGPで広告された隣接ルータのIndexを⾜したSIDを学習
    2. SRGBの基準値とSRGB Sizeで隣接ノードのSRGBを認識
    3. 隣接ノードへのSWAPルールを作成する際、隣接ノードのSRGBを⽤いてOutgoing labelを設定
    ○ 同じNode SIDのルールであっても、違うラベルにSWAPすることとなる
    4. SRGBは異なっていても動作するが、IndexはSR domain内でのGlobal Uniqueに設計する必要あり
    (参考)SRGBが異なる場合の挙動

    View Slide

  34. © NTT Communications Corporation All Rights Reserved. 34
    ● 専⽤のIPv6拡張ヘッダを⽤いSegment Routingを⾏う⼿法
    ○ データプレーンにIPv6パケットを使⽤
    ■ SRv6に対応していないネットワークを、そのまま⼟管として利⽤可能
    ■ SIDはIPv6アドレスの形式
    ○ SRv6 Functionによる⾼い拡張性
    ■ RFC8986: https://datatracker.ietf.org/doc/html/rfc8986
    ○ SRヘッダの付与⽅式は Encapsulation と Insert の2種類
    ■ ただしInsertモードはRFC8200違反のため、RFC8986とは別ドラフトで議論中
    ● https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-insertion/
    IPv6 Header
    IPv6 Extension Header
    (SR Header)
    Payload
    IPv6 Header
    Encapsulationモード: 扱う対象がIPv6でなくても使⽤可能 Insertモード: IPv6パケットであることが必須だが、
    ヘッダによるオーバーヘッドを削減できる
    Payload
    IPv6 Header
    Encapsulation
    IPv6 Extension Header
    (SR Header)
    Payload
    IPv6 Header
    Payload
    IPv6 Header
    Insert SRH
    SRv6

    View Slide

  35. © NTT Communications Corporation All Rights Reserved. 35
    ● IPv6アドレスの128bit空間をLocator、Function、Argumentに分割して使⽤
    ○ それぞれのフィールドは可変⻑、またArgumentはなくても良い
    ○ Locator… 転送先を⽰すフィールド
    ○ Function… 転送時の処理を⽰すフィールド
    ○ Argument… Functionに与える引数(任意)
    Locator Function Argument (任意)
    例: fd00 : 0000 : 0000 : 0000 : 0000 : 0000 : 0000 : 0000
    ⼀般的にはLocatorは64bitで設計されることが多い
    SRv6のSID構造

    View Slide

  36. © NTT Communications Corporation All Rights Reserved. 36
    ● 拡張ヘッダとしてSR Headerが付く
    ○ 拡張ヘッダはRouting headerの形式を踏襲
    ○ Routing Type: SRv6のSRHであれば4
    ○ Segment Left: Segment Listの先頭を⽰すポインタ
    ■ Segment Leftの初期値はSegment Listの段数
    ■ end処理のたびに-1され、最終的に0になる
    ○ Segment List: Segmentの配列
    ■ Segment Leftを配列の添字とするため、配列の末尾がListの
    先頭要素、配列の先頭が末尾の要素となる
    ○ Optional TLV
    ■ HMACなどで利⽤
    ● IPv6 Headerの宛先アドレスは、End処理の度に
    Segment Listの先頭要素で上書きされる(後述)
    ○ 宛先アドレスでのIPv6 Forwardingを可能にする処理
    出典: https://datatracker.ietf.org/doc/html/rfc8754
    IPv6 Header (NH: 43) IPv6 Extension Header (SRv6 Header) Payload
    Inner Header (IPv4/IPv6)
    SRv6のパケットフォーマット

    View Slide

  37. © NTT Communications Corporation All Rights Reserved. 37
    SR domain
    ● SRv6に関連するノードには3種類の役割が存在する
    ○ SR Source Node: SRv6の送信元となるHeadendノード
    ○ Transit Node: IPv6を転送するノード。SRv6⾮対応でも良い
    ○ SR Segment Endpoint Node: Segmentを処理するノード
    ■ SRv6パケットのDestination AddressをLocal Segment、あるいはInterface Addressとして持つ
    Node 1
    Locator: fd00:0:0:1::/64
    Node 2
    Locator: fd00:0:0:2::/64
    Node 3
    Locator: fd00:0:0:3::/64
    (SR Source Node) (Transit Node) (SR Segment Endpoint Node)
    IPv6 Forwarding End.DT6
    H.Encaps
    (SR Source Node) (SR Segment Endpoint Node) (SR Segment Endpoint Node)
    End End.DT6
    H.Encaps
    Node 2のEnd、Node 3のEnd.DT6の2段でSegment Listを付与した例
    [fd00:0:0:2::1, fd00:0:0:3::6:a]
    Node 3のEnd.DT6のみでSegment Listを付与した例
    [fd00:0:0:3::6:a]
    SRv6関連ノードの種別

    View Slide

  38. © NTT Communications Corporation All Rights Reserved. 38
    ● ⾃らがDestinationであるPacketを受信したノード(Endpoint)はSRHを処理
    ○ EndpointはLocal SID Tableを参照しFunctionを処理(後述)
    ■ 例えばEndは、Segment Leftを1つ減らしDestination IP Addressを次の先頭要素に変更して転送
    ○ EndpointではないノードはSRHを処理せず、通常のIPv6 Forwardingを実施
    Node 1
    Locator: fd00:0:0:1::/64
    Node 2
    Locator: fd00:0:0:2::/64
    Node 4
    Locator: fd00:0:0:4::/64
    SR domain
    IPv6 Extension Header
    (SR Header)
    Node 3
    Locator: fd00:0:0:3::/64
    IPv6 Header
    End IPv6 Forwarding End.DT6
    H.Encaps
    (SR Source Node) (SR Segment Endpoint Node) (Transit Node) (SR Segment Endpoint Node)
    Next Header: 43
    Source IP address: fd00:0:0:1::1
    Destination IP address: fd00:0:0:2::1
    Payload
    IPv6 Header
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Last Entry: 1 Flags Tag
    Next Header:
    41
    Hdr Ext Len: 6 Routing Type: 4 SL: 1
    Next Header: 43
    Source IP address: fd00:0:0:1::1
    Destination IP address: fd00:0:0:4::6:a
    Payload
    IPv6 Header
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Last Entry: 1 Flags Tag
    Next Header:
    41
    Hdr Ext Len: 6 Routing Type: 4 SL: 0
    Next Header: 43
    Source IP address: fd00:0:0:1::1
    Destination IP address: fd00:0:0:4::6:a
    Payload
    IPv6 Header
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Last Entry: 1 Flags Tag
    Next Header:
    41
    Hdr Ext Len: 6 Routing Type: 4 SL: 0
    SRv6による転送

    View Slide

  39. © NTT Communications Corporation All Rights Reserved. 39
    ● SRv6⾮対応ノードもTransit専⽤のノードとして扱える
    ○ SRv6⾮対応な既存IPv6ネットワーク等を⼟管として利⽤可能
    ○ 前提として、Locator単位の経路広告は必要
    Node 1
    Locator: fd00:0:0:1::/64
    Node 2
    Locator: fd00:0:0:2::/64
    Node 4
    Locator: fd00:0:0:4::/64
    SR domain
    IPv6 Extension Header
    (SR Header)
    SRv6非対応Node
    IPv6 Header
    End IPv6 Forwarding End.DT6
    H.Encaps
    (SR Source Node) (SR Segment Endpoint Node) (Transit Node) (SR Segment Endpoint Node)
    Next Header: 43
    Source IP address: fd00:0:0:1::1
    Destination IP address: fd00:0:0:2::1
    Payload
    IPv6 Header
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Last Entry: 1 Flags Tag
    Next Header:
    41
    Hdr Ext Len: 6 Routing Type: 4 SL: 1
    Next Header: 43
    Source IP address: fd00:0:0:1::1
    Destination IP address: fd00:0:0:4::6:a
    Payload
    IPv6 Header
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Last Entry: 1 Flags Tag
    Next Header:
    41
    Hdr Ext Len: 6 Routing Type: 4 SL: 0
    Next Header: 43
    Source IP address: fd00:0:0:1::1
    Destination IP address: fd00:0:0:4::6:a
    Payload
    IPv6 Header
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Last Entry: 1 Flags Tag
    Next Header:
    41
    Hdr Ext Len: 6 Routing Type: 4 SL: 0
    SRv6⾮対応ノードが存在する場合の処理

    View Slide

  40. © NTT Communications Corporation All Rights Reserved. 40
    ● Endpoint以外のノードはLocator部分のみをFIBで処理
    ● EndpointはLocal SID TableでFunctionを処理
    Node 1
    Locator: fd00:0:0:1::/64
    Node 2
    Locator: fd00:0:0:2::/64
    Node 4
    Locator: fd00:0:0:4::/64
    SR domain
    Node 3
    Locator: fd00:0:0:3::/64
    End IPv6 Forwarding End.DT6
    H.Encaps
    (SR Source Node) (SR Segment Endpoint Node) (Transit Node) (SR Segment Endpoint Node)
    IPv6 Extension Header
    (太字が先頭要素)
    宛先 送出先
    fd00:0:0:1::/64 en0
    fd00:0:0:3::/64 en1
    fd00:0:0:4::/64 en1
    Node 2のFIB(⼀部)
    en0
    en1 en0
    en1 en0
    en1
    宛先 送出先
    fd00:0:0:1::/64 en0
    fd00:0:0:2::/64 en0
    fd00:0:0:4::/64 en1
    Node 3のFIB(⼀部)
    宛先 送出先
    fd00:0:0:1::/64 en0
    fd00:0:0:3::/64 en0
    fd00:0:0:4::/64 en0
    Node 4のFIB(⼀部)
    SID Action
    fd00:0:0:2::/128 End
    Node 2のLocal SID Table
    SID Action
    fd00:0:0:2::/128 End
    Node 3のLocal SID Table
    SID Action
    fd00:0:0:4::/128 End
    fd00:0:0:4::6:a/128 End.DT6 VRF-a
    Node 4のLocal SID Table
    VRF-a
    IPv6 Header(宛先のみ)
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Destination Address: fd00:0:0:2::1
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Destination Address: fd00:0:0:4::6:a
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00:0:0:4::6:a
    Destination Address: fd00:0:0:4::6:a
    Locator / Local SIDの処理

    View Slide

  41. © NTT Communications Corporation All Rights Reserved. 41
    ● SR Policy Headend Behaviors。Headend(SR Source Node)の処理
    ○ Headend⾃⾝が⾃ら⾏う処理なので、SIDリストにSIDを⼊れて送るものではない
    ■ (実装によっては内部でH.Encaps等を⽰すSIDを使ってるかも)
    ○ 以前はTransitの略称でT.xxxxと⾔う名前だった
    ○ H.Encaps: EncapsulationモードでSRv6ヘッダをつける
    ■ IPv4/IPv6どちらにも使えるが、v6の場合IPv6ヘッダが⼆重になってしまう
    ○ H.Insert: InsertモードでSRv6ヘッダをつける
    ■ IPv4パケットには使えない。RFC8200違反のため、RFC8986とは別ドラフトで議論中
    IPv6 Header
    IPv6 Extension Header
    (SRv6 Header)
    Payload
    IPv6 Header
    Encapsulationモード: 扱う対象がIPv6でなくても使⽤可能 Insertモード: IPv6パケットであることが必須だが、
    ヘッダによるオーバーヘッドを削減できる
    Payload
    IPv6 Header
    Encapsulation
    IPv6 Extension Header
    (SRv6 Header)
    Payload
    IPv6 Header
    Payload
    IPv6 Header
    Insert SRH
    代表的なWell-known Behaviors(Headend)

    View Slide

  42. © NTT Communications Corporation All Rights Reserved. 42
    ● Endpoint Behaviors: SR Segment Endpoint Nodeの処理
    ○ 基本的にはSIDリストに⼊れて送るSID
    ○ End: SIDリストを参照し、⼀つ進めて転送
    ■ SR-MPLSのNode SIDに⼀番近い
    ○ End.DX4, End.DX6: Decapsulation and IPv4/6 Cross-Connect
    ■ Decapを⾏い、IPv4/IPv6で転送する。Per-CE L3VPN
    ○ End.DT4, End.DT6: Decapsulation and Specific IPv4/6 Table Lookup
    ■ Decapを⾏い、特定のVRFをLookupする。per-VRF L3VPN
    ○ End.DX2: Decapsulation and L2 Cross-Connect
    ■ Decapを⾏い、特定のL2インターフェースに送る。L2VPN
    ○ End.AM: Endpoint to SR-unaware APP via masquerading
    ■ Service Function Chainingを⽬的とし、SRv6⾮対応なNodeを救うためのFunction
    1. SRv6ヘッダのDestinationを最終的なアドレスに書き換えて⾮対応Nodeに送出
    2. 戻ってきたパケットのDestinationを再びNexthopに書き換え、Endの処理を実施
    ○ End.B6.Encaps: Endpoint Bound to an SRv6 Policy with Encapsulation
    ■ SRv6をEncapsulationするBinding Segment(SR-MPLSをEncapするならEnd.BM)
    代表的なWell-known Behaviors(Endpoint)

    View Slide

  43. © NTT Communications Corporation All Rights Reserved. 43
    ● 基本的に可変⻑かつ⾃由(ただし⼀部の実装はLocator⻑が固定)
    ○ (例)Cisco: Locatorは64bit、うち上位40bitをSID block、下位24bitをNode IDとして利⽤
    ● 階層的に設計することに利点あり︖(拠点間通信やSRv6⾮対応網の利⽤など)
    ○ 例えば AS Prefix : 拠点ID : Algo ID : index のように設計するべきと考える
    ○ Function部分も管理がしやすいようID設計を⾏う
    ○ ただしSIDはLocatorを元に⾃動⽣成する実装も多く、Functionを任意の値にできない場合も
    ■ (例)VPNv6によるEnd.DT6の⾃動払い出し
    2001:db8:180:1:1:4:1:a
    拠点ID(拠点1)
    Flex-Algo ID (128)
    Algo内のindex Function Sub-ID
    Function ID パラメータ1
    SID設計の例。2001:db8::/32 を利⽤し設計を実施
    例では255拠点で、拠点ごとに65535ノードが収容可能になる
    LocatorはASの持つPrefixや⾮SR網のアドレスブロック、
    Function/ArgumentはSRv6の⽤途と相談して設計する
    パラメータ2
    (補⾜)SRv6のSID設計案

    View Slide

  44. © NTT Communications Corporation All Rights Reserved. 44
    ● BSIDを使えば、SR-MPLSもSRv6 Functionと似たことができる︖
    → 現状ではできない。理由は以下2点
    ● 1. Exact Matchの制約
    ○ SRv6のSIDはLocator/Function/Argumentに分かれており、Functionと効率的な転送が両⽴できる
    ■ Functionを処理するノード以外はLocator部だけを学習する。Function単位のFIB installは不要
    ○ SR-MPLSのLabelではそうは⾏かない。BSIDの数だけ経路を持つ必要がある
    ● 2. Programmability
    ○ SRv6ではFunctionはユーザが⾃由に定義することができる設計になっている
    ○ ⼀⽅SR-MPLSのBSIDは現状⾃由Programすることは想定されておらず、
    ルータの実装で決まった形のSR Policyにのみ対応している
    SRv6
    Node
    fd00:0:0:1::2 Payload
    fd00:0:0:1::3 Payload
    fd00:0:0:1::1 Payload
    SR-MPLS
    Node
    24002 Payload
    24003 Payload
    24001 Payload
    Label
    fd00:0:0:1::/64
    SID Table(⼀部) Label
    24001
    24002
    24003
    SID Table(⼀部)
    Endpointとなるノード以外はSID
    TableにLocaterのみ保持
    SRv6 Functionに相当するBSIDを処
    理するノード以外も、全てのノードが
    SID Tableに持つ必要あり
    このBSIDはGlobal SIDとなる
    (補⾜)Binding SegmentとSRv6 Function(1/2)

    View Slide

  45. © NTT Communications Corporation All Rights Reserved. 45
    ● 例として、SRv6ではGlobal Segmentな⾃作Functionを⽤意し、Argumentを
    書き換えながら連鎖的に計算するような使い⽅もできる
    ○ 参考: SRv6で8パズルを解いてみる(https://qiita.com/jiazio/items/15b41f1345089a1887af)
    ○ もちろんBSIDでも計算結果に対応したSIDへSWAPすることはできるかもしれない。
    ただしその場合は前述の2つの制約が厳しい。
    ■ 計算後のBSIDまでExact Matchできるよう学習済みでないとその先で転送ができない
    ■ 機器にProgrammabilityがない
    SRv6
    Node
    fd00:0:0:1::2:100 Payload
    SR-MPLS
    Node
    24002 Payload 24XXX? Payload
    Exact MatchなSR-MPLSのSIDは柔
    軟な利⽤が不可能
    計算結果に応じたSIDを事前に全パタ
    ーン発⾏してGlobal SIDとして他ノード
    全てに展開する...︖
    fd00:0:0:1::2:200 Payload
    Locatorによる効率的な転送と
    Argumentの活⽤により柔軟なSID利
    ⽤が可能
    機器のProgrammabilityが活発に議論されている
    欲しい機能に応じて専⽤のFunctionを実装するのはSRv6
    の代表的なユースケース
    Exact Matchの制約が⼤きく、SRv6 Functionのような
    Programmabilityはあまり検討されていない
    (補⾜)Binding SegmentとSRv6 Function(2/2)

    View Slide

  46. © NTT Communications Corporation All Rights Reserved. 46
    ● SR-MPLS側の利点
    ○ SR-MPLSの⽅が先に実装が始まっているため、SRv6に⽐べ実装状況が良い
    ■ MPLS-VPNなど、MPLSの既存アーキテクチャもそのまま活⽤できる
    ○ SRv6に⽐べSIDサイズが⼩さい(SRv6 128bitに対しSR-MPLSは32bit)
    ● SRv6側の利点
    ○ 128bitのSIDを活かして様々な動作を⾏うSRv6 Functionの存在、⾼い拡張性
    ○ SRv6に対応していない網も、IPv6さえ対応していれば⼟管として使⽤可能
    ■ 仮に間にインターネットが挟まっていても、IPv6さえあれば転送可能
    SR-MPLSとSRv6の⽐較

    View Slide

  47. © NTT Communications Corporation All Rights Reserved. 47
    SRのコントロールプレーン

    View Slide

  48. © NTT Communications Corporation All Rights Reserved. 48
    ● 役割: SR domain内でのSIDの共有
    ○ SR domain内の他ノードに⾃らの持つSIDを伝達
    ■ 他ノードのNode SIDを学習し、SID Tableに格納
    ○ SID伝搬にはUnderlayと共通のIGP(OSPF/IS-IS)を利⽤可能
    ■ IS-IS, OSPF共にSR⽤の拡張を利⽤
    ● SR-MPLSでは拡張が実装されていないと使えない
    ● TE metricやFlex-Algoの定義などもIGP拡張で共有(後述)
    ■ IGPを利⽤するため、トポロジ変更時の収束はUnderlayと同時になる
    Control Plane
    (LinkState)
    IS-IS (SID・TE情報の共有)
    SRのコントロールプレーン(SID共有部分・再掲)

    View Slide

  49. © NTT Communications Corporation All Rights Reserved. 49
    C-Plane3種、SRでの役割をもう⼀声
    PE
    P
    PE
    P
    PE
    P
    PE
    P
    PE
    P
    PE
    P
    Control Plane (VPN)
    Control Plane
    (LinkState)
    Control Plane (Policy)
    PCE
    PCEP (発⾏した
    セグメントリストの共有)
    BGP-LS (パス計算のための
    トポロジ/TE情報の共有)
    BGP (VPNの構築)
    IS-IS (SID・TE情報の共有)
    役割︓経路の設定(Segement Listの作成と配布)
    - BGP-LSによりトポロジ情報を吸い上げる
    - PCEが持つポリシーをもとに、セグメントリストを構築
    - PCEPにより、作成したセグメントリストをPEに配布
    → 動作の結果、PEがセグメントリストを得る。Pには影響しない
    役割︓オーバーレイ上のVPNの構築
    - L3VPN(per-VRF/per-CE)やL2VPNに対応したVPNラベル
    (BGP Prefix-SID)を作成
    - BGPにより対向のPEにL3VPN(per-VRF/per-CE)やL2VPNの情報を広告
    → 動作の結果、VPNを貼りたいPE同⼠が、VPN経路やそのラベルを取得
    役割︓オーバーレイの構築
    - 各ノードがindexからNode SIDを、隣接関係からAdjacency SIDを作成
    - IGPにより網内(IGP domain = SR domain内)の全ノードに
    Node SID / Adjacency SIDを広告
    - 上記を受け取ったノードは、受け取ったNode SIDをSID Tableに格納
    → 動作の結果、SID Tableができる
    = Segment Listで指定された際に転送する為の下準備ができる

    View Slide

  50. © NTT Communications Corporation All Rights Reserved. 50
    ● 役割: SIDと各種TEパラメータの共有
    ○ SR domain内でNode/Adjacency SIDやSRGB、TE Metric/帯域/遅延等の定義を広告
    ○ SR関連の情報を含めるように既存IGPを拡張し利⽤
    ■ SR-MPLSではNode SIDの広告にIGP拡張が必須
    ■ SRv6でもFlex-AlgoなどをIGP拡張により実現
    ● IS-IS Extension for Segment Routing
    ○ https://datatracker.ietf.org/doc/html/rfc8667
    ○ SR-MPLS⽤のTLV/sub-TLVを定義
    ■ IS-IS TLV Codepoints: https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
    ■ SRv6⽤の追加拡張も議論中: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions
    ● OSPF Extension for Segment Routing
    ○ OSPFv2: https://datatracker.ietf.org/doc/html/rfc8665
    ○ OSPFv3: https://datatracker.ietf.org/doc/html/rfc8666
    ■ SR-MPLS⽤のOpaque-Typeを定義
    ■ SRv6⽤の追加拡張も議論中: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions
    SRのIGP

    View Slide

  51. © NTT Communications Corporation All Rights Reserved. 51
    ● 太字部分がSR⽤に追加されたTLV/Sub-TLV
    ● Sub-TLVs for Types 22, 23, 25, 141, 222, and 223
    ○ Adj-SIDの広告。TLV-22: Extended IS reachability等、Neighbor Information 系のTLVに付与
    ■ Sub-TLV 31: Adjacency Segment Identifier(Adj-SID)
    ■ Sub-TLV 32: Adjacency Segment Identifier(LAN-Adj-SID)
    ● Sub-TLVs for Types 135, 235, 236, and 237
    ○ Prefix-SIDの広告。TLV-135: Extended IP reachability等、Prefix Reachability系のTLVに付与
    ■ Sub-TLV 3: Prefix Segment Identifier(Prefix-SID)
    (参考)RFC8667 IS-IS Extension for Segment Routing (1/2)

    View Slide

  52. © NTT Communications Corporation All Rights Reserved. 52
    ● 太字部分がSR⽤に追加されたTLV/Sub-TLV
    ● Sub-TLVs for Type 242(Router Capability)
    ○ SR-MPLSの対応やSRGBなど、SRに関する全体的な設定を広告
    ■ Sub-TLV 2: SR-Capability SR-MPLSのIPv4/v6対応やSRGBの広告
    ■ Sub-TLV 19: SR-Algorithm IGP Algorithm Typeの広告。0: SPF、1: Strict SPF
    ● Flex-Algo(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo): 128-255
    ■ Sub-TLV 22: SR Local Block SRLB(Adj-SID等、Local SIDの範囲)を広告
    ■ Sub-TLV 24: SRMS Preference SR Mapping Server(RFC8661)のPreference値
    ● TLV 149: SID/Label Binding TLV
    ● TLV 150: Multi-Topology SID/Label Binding TLV
    ○ SRMSでマッピングしたPrefix SIDを広告
    (参考)RFC8667 IS-IS Extension for Segment Routing (2/2)

    View Slide

  53. © NTT Communications Corporation All Rights Reserved. 53
    ● LSA Type9/10/11: Opaque LSA(RFC7684, RFC7770)を利⽤し広告
    ● Opaque Type 4: OSPFv2 Router Information
    ○ Type 8: SR-Algorithm IGP Algorithm Typeの広告。0: SPF、1: Strict SPF
    ○ Type 9: SID/Label Range SRGBの広告
    ○ Type 14: SR Local Block SRLB(Adj-SID等、Local SIDの範囲)を広告
    ○ Type 15: SRMS Preference SR Mapping Server(RFC8661)のPreference値
    ● Opaque Type 7: OSPFv2 Extended Prefix Opaque LSA
    ○ Type 2: OSPF Extended Prefix Range TLV
    ■ Type 1: SID/Label Sub-TLV
    ■ Type 2: Prefix-SID Sub-TLV
    ● Opaque Type 8: OSPFv2 Extended Link Opaque LSA
    ○ Type1 : OSPFv2 Extended Link TLV
    ■ Type 1: SID/Label Sub-TLV
    ■ Type 2: Adj-SID Sub-TLV
    ■ Type 3: LAN Adj-SID/Label Sub-TLV
    (参考)RFC8665 OSPF Extension for Segment Routing

    View Slide

  54. © NTT Communications Corporation All Rights Reserved. 54
    ● Router Information Opaque LSA(RFC7770)とExtended LSAで広告
    ○ https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.txt
    ● LSA Type 12 OSPFv3 Router Information Opaque LSA
    ○ 前ページのOSPFv2 Opaque Type 4: OSPFv2 Router InformationのTLVと同じ
    ● Extended LSA(RFC8362)
    ○ 下記のExtended LSAのTLVとしてSR関連の情報を付与
    ■ E-Intra-Area-Prefix-LSA,
    ■ E-Inter-Area-Prefix-LSA
    ■ E-AS-External-LSA
    ■ E-Type-7-LSA
    ○ Type 9: OSPFv3 Extended Prefix Range TLV
    ■ Type 4: Prefix-SID sub-TLV
    ■ Type 5: Adj-SID sub-TLV
    ■ Type 6: LAN Adj-SID sub-TLV
    ■ Type 7: SID/Label sub-TLV
    (参考)RFC8666 OSPFv3 Extension for Segment Routing

    View Slide

  55. © NTT Communications Corporation All Rights Reserved. 55
    ● IGPの経路計算を柔軟に実現するため、経路計算⾯を仮想化・多重化する技術
    ○ draft: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo
    ○ 分けたAlgorithmごとにトポロジを持ち、AlgoごとのMetric/制約で経路計算を実施
    ■ Algoごとに固有のトポロジ、Metricで最短経路を決定
    ■ あるAlgoのSIDを指定すると、そのトポロジ内で転送が⾏われる
    ○ QoS保証、Affinity制約が⾃然に実現できる
    ■ デメリットとして、SID Tableのエントリ数は増減する
    ■ QoS保証をしつつルーズソースルーティングをする、などということが可能
    画像: https://y-network.jp/2020/09/29/segment-routing-042/ 画像: https://www.segment-routing.net/images/sr-igp-flex-algo-rev4b-km1.pdf
    Flex-Algorithm(Flex-Algo)

    View Slide

  56. © NTT Communications Corporation All Rights Reserved. 56
    ● 意図に基づいてネットワーキングを実現する概念
    ○ 運⽤者が事前に定義した状態になるようネットワークを構築する
    ○ 例: 障害が起きても、常に帯域X bpsを満たすようリルートされる経路
    ○ 例: IGPコストではなく、常に遅延最⼩になるような経路
    画像: https://blogs.cisco.com/networking/improving-networks-with-ai
    Intent-based Networking

    View Slide

  57. © NTT Communications Corporation All Rights Reserved. 57
    ● ⼀つのNWを、複数の仮想NWに分割・多重化する技術
    ○ リソースの共通化と、NWの分離を同時に実現
    ○ 利⽤者ごとの分離、冗⻑パスの分離、通信品質のMetric分けなど
    物理NW
    (Underlay)
    スライスB
    スライスA
    ネットワークスライシング

    View Slide

  58. © NTT Communications Corporation All Rights Reserved. 58
    ● IS-IS/OSPF共に https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo で提案中
    ○ 基本的にはFAD(Flex-Algorithm Definition)とColor(Administrative-group)の2点で広告
    ○ 柔軟な計算を実現するため、様々なパラメータを利⽤
    ■ Affinity制約: bitmapなColor。Include(any/all), Excludeなどが選択可能
    ■ Metric: IGP Metric・TE Metric・DelayなどAlgorithmごとに設定可能
    ■ Disjoint Path: SRLG(Shared Risk Link Group)を考慮した冗⻑パスの有効利⽤
    A D
    B
    C
    SR domain
    A D
    B
    C
    A D
    B
    C
    Algorithm 129: Exclude GREEN
    TE Metric、
    Algorithm 128 Exclude RED
    IGP Metric
    A D
    C
    Algorithm 130: include-all Blue
    IGP Metric
    100, 10
    10, 100
    10, 10
    100, 10
    10, 100
    Metric: IGP, TE
    Color
    Legend
    10
    10
    10
    100
    100
    10
    10
    10 10
    10
    Flex-Algo⽤のIGP拡張

    View Slide

  59. © NTT Communications Corporation All Rights Reserved. 59
    ● 各ルータがリンクにColorを設定、IGPで広告
    ○ Administrative-groupやExtended Administrative group(RFC7308)をbitmapとして使⽤
    ■ Administrative-group: 4byte空間
    ■ Extended Administrative group: 4byteの倍数。先頭4byteはAdmin-groupと⼀致
    ○ Admin-group、Extended Admin-group共にLegacyなものとASLAで再定義されたものが存在
    ■ ASLA(Application-Specific Link Attribute): RFC8919、8920
    ■ Flex-AlgoではASLAの使⽤を想定
    ● ASLAのSABM(Standard Application Identifier Bit Mask)で3bit⽬を⽴て、Flex-Algoでの利⽤を明⽰
    ● IS-ISの場合、ASLAのL-Flagを⽴てることでLegacyなAdmin-groupを使⽤可能
    00000000 00000000 00000000 00001001
    bit-position 0と3が有効になったAdministrative-groupの例
    網の運⽤者がbit-position 0はRED、1はGREENなどと定義し利⽤する
    Flex-Algo⽤のColor

    View Slide

  60. © NTT Communications Corporation All Rights Reserved. 60
    ● TLV-242 Router Capability
    ○ Type 19: SR-Algorithm Algorithmに対応する番号(128-255)を含める(RFC8667)
    ○ Type 26: IS-IS FAD sub-TLV Metric-Type、Calculation-Type、Priorityを広告
    ■ Type 1: IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV
    ■ Type 2: IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV
    ■ Type 3: IS-IS Flexible Algorithm Include-ALL Admin Group Sub-TLV
    ■ Type 4: IS-IS FAD Flags Sub-TLV
    ■ Type 5: IS-IS Flexible Algorithm Exclude SRLG Sub-TLV
    ● SRLG Value(RFC5307)を格納し、Algoの計算から除外したいSRLG(FAESRLG)を指定
    ● Sub-TLV 16 Application-Specific Link Attributes(RFC8919)
    ○ TLV-22: Extended IS reachability等、Neighbor Information系のTLV(23/25/141/222/223)に付与
    ○ Sub-Sub-TLV-3 Administrative Group
    ○ Sub-Sub-TLV-14 Extended Administrative Group
    ● TLV-3 Administrative-group(RFC5305)
    ● TLV-14 Extended Administrative-group(RFC7308)
    ○ Legacy実装。どちらもL-Flagが有効な場合のみ評価
    (参考)Flex-Algo⽤のIGP(IS-IS)

    View Slide

  61. © NTT Communications Corporation All Rights Reserved. 61
    ● Router Information(OSPFv2: LSA Type 9/10/11、OSPFv3: LSA Type 12)
    ○ Type 8 SR-Algorithm Algorithmに対応する番号(128-255)を含める
    ○ Type 16 OSPF Flexible Algorithm Definition TLV
    ■ Metric-Type、Calculation-Type、Priorityを定義。下記のTLVを付与可能
    ■ Type 1: OSPF Flexible Algorithm Exclude Admin Group Sub-TLV
    ■ Type 2: OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV
    ■ Type 3: OSPF Flexible Algorithm Include-ALL Admin Group Sub-TLV
    ■ Type 4: OSPF FAD Flags Sub-TLV
    ■ Type 5: OSPF Flexible Algorithm Exclude SRLG Sub-TLV
    ■ SRLG Value(RFC4203)を格納し、Algoの計算から除外したいSRLG(FAESRLG)を指定
    ● OSPF Application-Specific Link Attributes
    ○ OSPFv2 Extended Link TLVやOSPFv3 Extended-LSA Sub-TLVとして広告される
    ■ OSPFv2: TLV 19: Administrative Group、TLV 20: Extended Administrative Group
    ■ OSPFv3: TLV 20: Administrative Group、TLV 21: Extended Administrative Group
    (参考)Flex-Algo⽤のIGP(OSPF)

    View Slide

  62. © NTT Communications Corporation All Rights Reserved. 62
    ● SR(Segment Routing)
    ○ ソースルーティングのパラダイムとシグナリング不要なプロトコル構成
    ○ 従来の経路制御技術が抱えるステート増加とシグナリングによるスケーラビリティの課題を解決
    ● 2種類のデータプレーン
    ○ SR-MPLS: MPLSラベルを利⽤したSR
    ○ SRv6: IPv6の拡張ヘッダを利⽤したSR
    ● 既存のIGPを活⽤
    ○ C-Plane(LinkState): Node SIDの配布。IS-ISやOSPFを拡張し実現︕
    ○ より柔軟な経路計算のため、IGP拡張によるFlex-Algoのような仕組みも
    ここまでのまとめ(TE)

    View Slide

  63. © NTT Communications Corporation All Rights Reserved. 63
    VPN(Virtual Private Network)

    View Slide

  64. © NTT Communications Corporation All Rights Reserved. 64
    ● VPN (Virtual Private Network)
    ○ ネットワーク上に仮想的な専⽤回線を構築する技術
    ○ 主な⽤途: 企業NW、DCなどの拠点間通信、外部から社内ネットワークのアクセス
    Customer A
    Customer B
    Customer A
    Customer B
    VPN A
    VPN B
    何らかのネットワーク
    VPNとは

    View Slide

  65. © NTT Communications Corporation All Rights Reserved. 65
    ● インターネットVPN
    ○ インターネット上に仮想回線を構築するVPN
    ○ トンネリング・暗号化により機密性を担保
    ○ 主な技術...L2TP/IPSec、SSL-VPN
    ● IP-VPN
    ○ 通信事業者等の運⽤する閉域網を利⽤し構築するL3VPN
    ○ 主な技術...MPLS-VPN
    ● 広域イーサネット
    ○ 通信事業者等の運⽤する閉域網を利⽤し構築するL2VPN
    ○ 主な技術... VPLS
    VPNの種別(インターネットVPNとIP-VPN)

    View Slide

  66. © NTT Communications Corporation All Rights Reserved. 66
    ● L2VPN
    ○ 端点同⼠をL2で接続するVPN
    ■ 通信はInterface等のL2情報で識別
    ■ Customer同⼠はフラットなL2網
    ■ 間に⼤きなL2スイッチがあるイメージ
    ● L3VPN
    ○ 端点同⼠をL3で接続するVPN
    ■ 通信はVRF/CE等のL3情報で識別
    ■ Customer同⼠は別のL2網、L3で接続
    ■ 間に⼤きなルータがあるイメージ
    MAC-VRF
    A
    MAC-VRF
    B
    MAC-VRF
    A
    MAC-VRF
    B
    VPN網
    Customer
    A
    Customer
    B
    Customer
    A
    Customer
    B
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    VRF
    default
    VRF
    A
    VRF
    B
    VRF
    A
    VRF
    B
    VRF
    default
    VPN網
    Customer
    A
    Customer
    B
    Customer
    A
    Customer
    B
    192.168.0.0/24 192.168.0.0/24
    192.168.0.0/24 192.168.0.0/24
    Interface A Interface A
    Interface B Interface B
    L2VPNとL3VPN

    View Slide

  67. © NTT Communications Corporation All Rights Reserved. 67
    ● L3VPNの実現⼿法による区別
    ● per-VRF VPN
    ○ VRFで識別するL3VPN
    ○ PEはVPNラベルに紐づくVRFの経路表を参照
    ● per-CE VPN
    ○ 接続するCEで識別するL3VPN
    ○ PEはVPNラベルに紐づくCEへと送出
    VPN網
    Customer
    A
    Customer
    B
    Customer
    A
    Customer
    B
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    VPN網
    Customer
    A
    Customer
    B
    Customer
    A
    Customer
    B
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    VRF
    default
    VRF
    A
    VRF
    B
    VRF
    A
    VRF
    B
    VRF
    default
    per-VRF VPNとper-CE VPN

    View Slide

  68. © NTT Communications Corporation All Rights Reserved. 68
    ● VRF (Virtual Routing and Forwarding)
    ○ ルータのL2/L3仮想化技術
    ■ ルーティング機能とフォワーディング機能の双⽅を仮想化
    ○ 1つのルータ上に複数の独⽴したルーティングインスタンスを⽣成
    ■ ルーティングインスタンスごとに経路表/Mac Tableを保有
    VPN網
    Customer A
    Customer B
    Customer A
    Customer B
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    Customer A
    の経路表
    Customer A
    の経路表
    Customer B
    の経路表
    VPN網の
    経路表
    VPN網の
    経路表
    VRF B VRF default VRF B
    VRF default
    Customer B
    の経路表
    VRF A VRF A
    VRF

    View Slide

  69. © NTT Communications Corporation All Rights Reserved. 69
    AS65000
    ● Route-Distinguisher (RD)
    ○ ルータ内部で複数のVRFを扱う際、VRFごとに経路を識別するための識別⼦
    ○ 2byte:2byteの形式で慣例的に、AS番号:VRFごとの番号 の形式で表すことが多い
    ■ あるノードの異なるVRFに同じ経路が存在していても、RD+Prefixの組み合わせで識別可能
    VPN網
    Customer A
    Customer B
    Customer A
    Customer B
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    Customer A
    の経路表
    Customer B
    の経路表
    Customer A
    の経路表
    Customer B
    の経路表
    VPN網の
    経路表
    VPN網の
    経路表
    R02
    R01
    VRF A
    RD: 65000:100 VRF default
    VRF A
    RD: 65000:100
    VRF B
    RD: 65000:200
    VRF default VRF B
    RD: 65000:200
    Prefix: 192.168.0.0, RD: 65000:100
    Prefix: 192.168.0.0, RD: 65000:200
    R01のBGPテーブル
    Prefix: 192.168.1.0, RD: 65000:100
    Prefix: 192.168.1.0, RD: 65000:200
    R02のBGPテーブル
    RD付き経路を学習
    Route-Distinguisher

    View Slide

  70. © NTT Communications Corporation All Rights Reserved. 70
    AS65000
    ● Route-Target (RT)
    ○ 経路広告時に、相⼿に経路を識別してもらうために使⽤する識別⼦
    ○ 各ルータは、受信した経路のRTを参照し格納先のVRFを決定するimportルールを定義
    ■ ⼀般的には、経路につけるRTは対応するVRFのRDと同じ値にすることが多い
    ■ BGP UPDATEを受信したルータは、import設定に従ってRTに対応するVRFに格納
    VPN網
    Customer A
    Customer B
    Customer A
    Customer B
    Customer A
    の経路表
    Customer B
    の経路表
    Customer A
    の経路表
    Customer B
    の経路表
    VPN網の
    経路表
    VPN網の
    経路表
    Prefix: 192.168.0.0, RD: 65000:100
    Prefix: 192.168.0.0, RD: 65000:200
    R01のBGPテーブル
    Prefix: 192.168.1.0, RD: 65000:100
    Prefix: 192.168.1.0, RD: 65000:200
    Prefix: 192.168.1.0, RD: 65000:100
    R02のBGPテーブル
    R02
    R01
    BGP UPDATE
    VRF A
    RD: 65000:100
    Export RT: 65000:100
    VRF A
    RD: 65000:100
    Import RT: 65000:100
    VRF B
    RD: 65000:200
    Export RT: 65000:200
    VRF default VRF B
    RD: 65000:200
    Import RT:
    65000:200
    RT: 65000:100
    Prefix:192.168.0.0/24
    ②受信側はimportルールに従い
    RTに対応するVRFに格納
    ①送信側は、相⼿に格納して欲しい
    VRFを⽰すRTをつけUPDATEを広告
    VRF default
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    Route-Target

    View Slide

  71. 71
    MPLS ShimヘッダがついているならばMPLS領域が、
    Shimヘッダがなく、IPヘッダがついていればIP領域が参照される
    (参考)⼀般的なルータの構造
    Router
    VRF (Virtual Routing and Forwarding)
    役割: L2/L3機能の仮想化。L2のMAC TableやL3のIP Table、L2.8のMPLS TableはVRFごとに⽣成される(実装による)
    LSDB
    IS-IS daemon BGP daemon
    BGP Table
    Connected / Static Route
    MPLS領域
    TCAM (Ternary Content Addressable Memory) IPv4領域
    IPv6領域
    show isis database show bgp
    BGPで学習したVRF経路
    (VPNラベルをencapするように
    インストールされる)
    BGPで学習したVPNラベル
    (BGP Prefix SID)
    ISISで学習した経路
    ISISで学習したラベル
    (Node SID)
    Shimヘッダにこのラベルが⼊ってきたら
    この動作をして、MACヘッダに
    このMACアドレスをつけてこのIFから送る
    IPヘッダのdst addrにこれがあったら
    この宛先に、MACヘッダにこのMACアドレス
    をつけてこのIFから送る
    HW処理⽤のメモリ。
    実際に⼊ってきたパケットはこれで処理する
    ConnectedやStatic Routeなどは直接RIBに⼊る
    junosだとset routing-options rib inet6.0 static route
    するからわかりやすいかも
    LIB
    (Label Information
    base)
    RIB
    (Routing Information
    base)
    LFIB
    (Label FIB)
    FIB
    (Forwarding
    Information base)
    MPLS Table IP Table
    ベストパスのみ
    ただし、SR-MPLSでは
    ベストパス以外存在
    しない気がする
    ベストパスのみ
    MAC address Table
    RIB/LIB: CPU処理で⽤いる経路表
    各種のルーティングプロトコルで
    選択されたベストパス / Static Route
    などの経路情報は全てここに載る
    各プロトコルのベストパスを
    Administrative Distance値で⽐較し、
    最終的なベストパスを決定する
    FIB/LFIB: ⾼速化のため、HW処理で
    ⽤いる、ベストパスのみが含まれた
    テーブル。RIB/LIBから⽣成される
    ARPで学習する
    Data Plane
    Control Plane
    © NTT Communications Corporation All Rights Reserved.

    View Slide

  72. © NTT Communications Corporation All Rights Reserved. 72
    ● ネットワークの持つ機能を役割ごとに分離し扱う概念
    ○ データプレーン︓転送機能
    ○ コントロールプレーン︓経路共有。SR的にはさらに3種類の役割が考えられる
    ■ Control Plane (LinkState): オーバレイの構築(Node SIDとTE情報の共有)
    ■ Control Plane (VPN): オーバレイ上のVPNの構築(VPN経路とVPNラベルの共有)
    ■ Control Plane (Policy): ポリシーの適⽤(Segment Listの作成と配布)
    PE P
    Control Plane (VPN)
    Data Plane
    役割︓オーバーレイ上のVPNの構築
    (BGP Prefix-SIDの広告)
    プロトコル︓BGP(VPNv4/VPNv6/EVPN等)
    役割︓パケットの転送
    プロトコル︓MPLS, IPv6
    PE
    SID・TE情報の共有
    パケットの転送
    Control Plane
    (LinkState)
    Control Plane (Policy) PCE
    役割︓経路の設定(Segement Listの作成と配布)
    プロトコル︓BGP-LS(トポロジ吸い上げ)
    PCEP(SegmentListの適⽤)
    ポリシーの適⽤
    VPNの構築
    役割︓オーバーレイの構築
    (Node SID/Adjacency SIDの伝搬)
    プロトコル︓IS-IS, OSPF, BGP-LS(Multi-AS等の場合)
    データプレーン / コントロールプレーン(再掲)

    View Slide

  73. © NTT Communications Corporation All Rights Reserved. 73
    ● SR-MPLSは既存のMPLS-VPNを利⽤可能
    ○ L2VPN/L3VPN共にコントロールプレーンにMP-BGPを利⽤(後述)
    ● L2VPN: EVPN
    ○ VPNラベルとEVPN NLRIを広告
    ■ EVPN NLRI Typeにより様々な情報を広告
    ● Type1: Multihoming⽤情報
    ● Type2: MAC/IP
    ● Type3/4: BUM転送⽤の情報
    ● L3VPN: VPNv4/VPNv6
    ○ VPNラベルとVPN Prefixの組み合わせを広告
    ■ VPNラベルはper-VRFやper-CEに⽣成
    VPN網
    Customer
    A
    Customer
    B
    Customer
    A
    Customer
    B
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    VRF
    default
    VRF
    A
    VRF
    B
    VRF
    A
    VRF
    B
    VRF
    default
    VPN網
    Customer
    A
    Customer
    B
    Customer
    A
    Customer
    B
    192.168.0.0/24 192.168.0.0/24
    192.168.0.0/24 192.168.0.0/24
    Interface A Interface A
    Interface B Interface B
    MPLS-VPN(コントロールプレーン)

    View Slide

  74. © NTT Communications Corporation All Rights Reserved. 74
    MPLS-VPN(データプレーン)
    ● L2VPN/L3VPN共に識別のためVPNラベルを利⽤する
    ○ MPLSではLabel、SRv6ではEnd.DTやEnd.DX系のFunctionが相当
    Customer A
    Customer B
    Customer A
    Customer B
    SR domain
    Customer Aの
    経路表
    Customer B
    の経路表
    VRF A
    RD: 65000:100
    VRF B
    RD: 65000:200
    Customer A
    の経路表
    Customer B
    の経路表
    VRF A
    RD: 65000:100
    VRF B
    RD: 65000:200
    Node 2
    Node 3
    24001 Payload
    16004
    HeadendはVPNラベルとTEラベルを付与して転送
    24001 Payload
    TailendはVPNラベルに従いL2/L3を識別
    (例はper-VRFなL3VPN)
    VPNラベル
    TEラベル
    Node 1 Node 4

    View Slide

  75. © NTT Communications Corporation All Rights Reserved. 75
    ● EVPN (Ether-VPN)
    ○ MP-BGPを利⽤したL2VPNの実現⽅式。RFC7432, 7623等で提案
    ○ EVPN Virtual Instance (EVI)と呼ばれるインスタンスごとに識別
    ○ 特徴︓
    ■ データプレーンを問わない実装。柔軟にネットワーク設計が可能
    ■ 拠点間トラフィックが不要なMACアドレス学習
    ● EVIとMAC-VRFが1:1で対応し、BGPを経由して学習
    Control Plane (VPN)
    Data Plane
    MP-BGP (EVPN)によるMACアドレス伝搬
    MPLS(RFC7432), PBB (RFC7623), VXLAN(RFC8365)等による転送
    EVI EVI
    EVIをD-planeの経路と紐付けて利⽤する
    Router Router
    EVPN

    View Slide

  76. © NTT Communications Corporation All Rights Reserved. 76
    ● OverlayプロトコルのTransport部分の作成
    ○ この部分のプロトコルはEVPNとは関係なく、なんでも良い
    ■ SR-MPLS/SRv6: IGPによるSID配布&SR Policy(Segment List)設定
    ■ 従来のMPLS:LDPによるラベル配布&RSVP-TEによるシグナリング
    ■ その他VXLAN、PBBなど
    Customer A
    Customer B
    Customer A
    Customer B
    C-Plane (VPN)
    D-Plane
    C-Plane
    (LinkState)
    Node 1 Node 4
    Node 2
    Node 3
    Transportの確保
    (ID広告・TE Pathの構築など)
    EVPNによるL2VPN(コントロールプレーン動作: LinkState)

    View Slide

  77. © NTT Communications Corporation All Rights Reserved. 77
    ● MP-BGPによるMAC address Tableの共有
    ○ MP-BGPにより、Path attribute Type14 (AFI25, Sub-AFI70)でEVPN情報を伝搬
    ○ EVIごとにMac-Addr Tableを共有
    Customer A
    Customer B
    Customer A
    Customer B
    C-Plane (VPN)
    D-Plane
    C-Plane
    (LinkState)
    Node 1 Node 4
    Node 2
    Node 3
    MP-BGP (EVPN)によるMACアドレス伝搬
    EVI A
    EVI B
    EVI A
    EVI B
    EVPNによるL2VPN(コントロールプレーン動作: VPN)

    View Slide

  78. © NTT Communications Corporation All Rights Reserved. 78
    ● EVIに紐づいたOverlay Transportを利⽤し転送
    ○ これまでのコントロールプレーン動作の結果により、EVIとOverlay Transportが紐づく
    ○ EVIに対応するを経路を選択し転送を実施
    Customer A
    Customer B
    Customer A
    Customer B
    C-Plane (VPN)
    D-Plane
    C-Plane
    (LinkState)
    Node 1 Node 4
    Node 2
    Node 3
    EVI A
    EVI B
    EVI A
    EVI B
    SR domain
    EVPNによるL2VPN(データプレーン動作)

    View Slide

  79. © NTT Communications Corporation All Rights Reserved. 79
    ● 各VRFが持つ経路のPrefixと対応するVPNラベルを広告
    ○ MPLSやSR等、何らかのD-planeと紐付けて⽤いる
    Customer A
    Customer B
    Customer A
    Customer B
    C-Plane (VPN)
    D-Plane
    C-Plane
    (LinkState)
    Node 2
    Node 3
    MP-BGP (VPNv4/VPNv6)によるPrefix広告
    Customer Aの
    経路表
    Customer B
    の経路表
    VRF A
    VRF B
    Customer A
    の経路表
    Customer B
    の経路表
    VRF A
    VRF B
    Node 1 Node 4
    VPNv4/VPNv6(コントロールプレーン動作: VPN)

    View Slide

  80. © NTT Communications Corporation All Rights Reserved. 80
    ● L2/L3VPNを実現するWell-known Fuctnionが提案済み
    ○ 対象となるFunctionは、DecapsulationのDが名前に含まれる
    出典: Segment Routing チュートリアル 鎌⽥ 徹平・⽵⽥ 直哉 (シスコシステムズ合同会社) https://www.janog.gr.jp/meeting/janog40/program/sr
    SRv6によるVPN(データプレーン)

    View Slide

  81. © NTT Communications Corporation All Rights Reserved. 81
    ● SRヘッダを除去&指定されたL2 Interfaceへ送出
    ○ L2VPNを実現するWell-known Fuctnion
    Customer A
    Customer B
    Customer A
    Customer B
    SR domain
    ① Node 1はSRv6のヘッダをつけ転送
    (Node 2のEndとNode 4 en0のEnd.DX2を付与)
    ③ Node 4は VRF defaultでEnd.DX2を実施
    拡張ヘッダを外し、en0から送出
    ④ Customer Aへ到着
    L2VPNに成功
    IPv6 Extension Headerのみ抜粋
    (太字が先頭要素)
    IPv6 Extension Headerのみ抜粋
    (太字が先頭要素)
    ② Node 2はEnd処理を実施
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00::4:0:2:0:0
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00::4:0:2:0:0
    en0
    en1
    Locator:
    fd00:0:0:1::/64N
    ode 1
    Locator:
    fd00:0:0:4::/64
    Node 4
    Locator:
    fd00:0:0:2::/64
    Node 2
    Locator:
    fd00:0:0:3::/64
    Node 3
    SRv6によるL2VPN(End.DX2)

    View Slide

  82. © NTT Communications Corporation All Rights Reserved. 82
    ● SRヘッダを除去&指定されたVRF TableをLookupし転送
    ○ per-VRF L3VPNを実現するFunction
    Customer Aの
    経路表
    Customer B
    の経路表
    VRF A
    RD: 65000:100
    VRF B
    RD: 65000:200
    Customer A
    の経路表
    Customer B
    の経路表
    VRF A
    RD: 65000:100
    VRF B
    RD: 65000:200
    Customer A
    Customer B
    Customer A
    Customer B
    Locator:
    fd00:0:0:2::/64
    Node 2
    Locator:
    fd00:0:0:3::/64
    Node 3
    ① Node 1はSRv6のヘッダをつけ転送
    (Node 2のEndとNode 4 VRF SRv6のEnd.DT6を付与)
    ③ Node 4は VRF defaultでEnd.DT6を実施
    拡張ヘッダを外し、VRF AをLookup
    ④ VRF Aの通りにCustomer Aへ送出
    per-VRF L3VPNに成功
    SR domain
    IPv6 Extension Headerのみ抜粋
    (太字が先頭要素)
    IPv6 Extension Headerのみ抜粋
    (太字が先頭要素)
    VPN網の
    経路表
    VRF default
    VPN網の
    経路表
    VRF default
    Locator:
    fd00:0:0:1::/64N
    ode 1
    Locator:
    fd00:0:0:4::/64
    Node 4
    ② Node 2はEnd処理を実施
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00::4:0:6:0:a
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00::4:0:6:0:a
    SRv6によるVPN(End.DT4, End.DT6)

    View Slide

  83. © NTT Communications Corporation All Rights Reserved. 83
    ● SRヘッダを除去&指定されたNexthopへ送出
    ○ per-CE VPNを実現するWell-known Fuctnion
    Customer A
    Customer B
    Customer A
    Customer B
    Locator:
    fd00:0:0:1::/64N
    ode 1
    Locator:
    fd00:0:0:4::/64
    Node 4
    Locator:
    fd00:0:0:2::/64
    Node 2
    Locator:
    fd00:0:0:3::/64
    Node 3
    CE 4
    CE 3
    CE 2
    CE 1
    IPv6 Extension Headerのみ抜粋
    (太字が先頭要素)
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00::4:1:6:0:a
    IPv6 Extension Headerのみ抜粋
    (太字が先頭要素)
    Segment List [1]: fd00:0:0:2::1
    Segment List [0]: fd00::4:1:6:0:a
    ① Node 1はSRv6のヘッダをつけ転送
    (Node 2のEndとNode 4でCE3を⽰すEnd.DX6を付与)
    ③ Node 4は VRF defaultでEnd.DX6を実施
    拡張ヘッダを外し、CE3へ送出
    ④ Customer AのCE3に到着
    per-CE L3VPNに成功
    ② Node 2はEnd処理を実施
    SR domain
    SRv6によるVPN(End.DX4, End.DX6)

    View Slide

  84. © NTT Communications Corporation All Rights Reserved. 84
    ● VPN: インターネット上に仮想的な専⽤線を⽤意する技術
    ○ 端点の接続レイヤによりL2VPNとL3VPNが存在
    ● SR-MPLSに関連するVPN: MPLS-VPNの仕組みを活⽤
    ● SRv6のVPN: SRv6 Functionで実現
    ● C-Plane(VPN): EVPN・VPNv4/VPNv6
    ここまでのまとめ(VPN)

    View Slide

  85. © NTT Communications Corporation All Rights Reserved. 85
    VPNで⽤いられるプロトコル(MP-BGP)

    View Slide

  86. © NTT Communications Corporation All Rights Reserved. 86
    ● MP-BGP (Multi Protocol BGP)
    ○ 本来IPv4 unicastしか送れなかったBGPを、他のプロトコル情報を送れるように拡張
    ■ IPv6情報が扱えるのもこの拡張による
    ○ BGP Path Attribute Type14, 15, 16により、各プロトコルの情報を広告
    ■ 特にAttribute Type14や15に含まれるAddress Familyの概念が重要
    ● VPNに限らず、現代のルーティングに携わるならMP-BGPは必修︕
    ○ 様々な情報をPath AttributeとNLRI Address Familyで伝える概念を理解、活⽤しよう︕
    Multi Protocol BGP (MP-BGP)

    View Slide

  87. © NTT Communications Corporation All Rights Reserved. 87
    ● Type 14: Multiprotocol Reachable NLRI
    ○ 到達可能経路。下記の3つの情報が含まれる
    ■ Address Family (プロトコル種別。AFIとSub-AFIからなる), Next Hop, NLRI (経路情報)
    ● Type 15: Multiprotocol Unreachable NLRI
    ○ 無効な経路。受け取ったルータは該当経路を削除する。下記の3つの情報が含まれる
    ■ Address Family, Unfeasible Routes Length(Withdraw Rulesの⻑さ), Withdraw Rules(削除対象の経路)
    ● Type 16: Extended Communities
    ○ BGP Communityの拡張版
    ■ 2byte:2byteのフィールドなBGP Communityに対し、4byte:2byteや2byte:4byteのフィールドを使⽤可能
    ■ VRFのRoute TargetやColor、RedistibuteされたOSPFのDomain ID(同⼀エリアを識別するID)などを伝搬可能
    Attribute Type 14/15/16

    View Slide

  88. © NTT Communications Corporation All Rights Reserved. 88
    BGPパス属性(Path Attribute)
    ● 主に以下のような属性があり、ベストパス選択の際に使⽤される
    ● SRをやるなら⾚い2つが特に重要
    Type Code Path Attribute Attribute Type コメント
    1 ORIGIN Well-Known mandatory
    2 AS_PATH Well-Known mandatory
    3 NEXT_HOP Well-Known mandatory
    4 MULTI_EXIT_DISC Optional non-transitive
    5 LOCAL_PREF Well-Known discretionary よく使う。例えばMulti-Exitな構成でのASBRの選択とか
    6 ATOMIC_AGGREGATE Well-Known discretionary
    7 AGGREGATOR Optional transitive
    8 COMMUNITY Optional transitive
    9 ORIGINATOR_ID Optional non-transitive
    10 CLUSTER_LIST Optional non-transitive
    14 MP_REACH_NLRI Optional non-transitive 様々な種類の経路の広告。Address Familyで識別する
    15 MP_UNREACH_NLRI Optional non-transitive
    16 EXTENDED_COMMUNITIES Optional transitive Route-Targetの広告、Colorの広告

    View Slide

  89. © NTT Communications Corporation All Rights Reserved. 89
    (参考)パス属性の種類(Attribute Type)
    ● パス属性は識別・伝搬の扱いにより4つに分類
    Attribute Type 意味
    Well-known mandatory 全BGPルータで識別(処理)する必要あり、全てのUPDATEに含まれる
    Well-known discretionary 全BGPルータで識別(処理)する必要あり、UPDATEに含まれるかは任意
    Optional transitive 識別(処理)するかどうかはBGPルータの任意
    ただし識別できない場合でも、ネイバーに対してこのパス属性をつけたまま伝搬させる
    Optional non-transitive 識別(処理)するかどうかはBGPルータの任意
    識別できない場合、ネイバーに対してこのパス属性を伝搬しない

    View Slide

  90. © NTT Communications Corporation All Rights Reserved. 90
    AFIとSub-AFI
    ● AFI (Address Family Information)
    ○ https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
    Sub-AFI Description
    1 Unicast
    2 Multicast
    70 BGP EVPNs
    71 BGP-LS
    128 MPLS-labeled VPN address
    AFI Description
    1 IPv4
    2 IPv6
    25 AFI for L2VPN information
    16388 BGP-LS
    ● Sub-AFI
    ○ https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml
    例︓AFI: 1, Sub-AFI: 1 = IPv4 Unicast
    AFI: 1, Sub-AFI: 128 = L3VPN IPv4 Unicast
    AFI: 25, Sub-AFI: 70 = L2VPN EVPN

    View Slide

  91. © NTT Communications Corporation All Rights Reserved. 91
    Customer B
    Customer A
    VPNv4 / VPNv6
    ● MP-BGPを利⽤したL3VPN技術(RFC4346 / RFC4659)
    ○ AFI: 1 or 2、SAFI: 128
    ○ VPN Prefix/Route-Targetと対応するVPN Labelを広告
    ○ SRv6対応: https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services
    AS65000
    VPN網
    Customer A
    Customer B
    Customer A
    の経路表
    Customer B
    の経路表
    Customer A
    の経路表
    Customer B
    の経路表
    VPN網の
    経路表
    VPN網の
    経路表
    Prefix: 192.168.0.0, RD: 65000:100
    Prefix: 192.168.0.0, RD: 65000:200
    R01のBGPテーブル
    Prefix: 192.168.1.0, RD: 65000:100
    Prefix: 192.168.1.0, RD: 65000:200
    Prefix: 192.168.1.0, RD: 65000:100
    R02のBGPテーブル
    R02
    R01
    BGP UPDATE
    VRF A
    RD: 65000:100
    Export RT: 65000:100
    VRF A
    RD: 65000:100
    Import RT: 65000:100
    VRF B
    RD: 65000:200
    Export RT: 65000:200
    VRF default VRF B
    RD: 65000:200
    Import RT:
    65000:200
    RT: 65000:100
    Prefix:192.168.0.0/24
    ②受信側はimportルールに従い
    RTに対応するVRFに格納
    ①送信側は、相⼿に格納して欲しい
    VRFを⽰すRTをつけUPDATEを広告
    VRF default
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24

    View Slide

  92. © NTT Communications Corporation All Rights Reserved. 92
    EVPN
    ● MP-BGPを利⽤したL2VPN技術(RFC7432)
    ○ AFI: 25、SAFI: 70
    ○ VPNラベルとEVPN NLRIを広告
    ■ Route-Type 1: Multihoming⽤情報
    ■ Route-Type 2: MAC/IP
    ■ Route-Type 3/4: BUM転送⽤の情報
    ■ Route-Type 5: L3VPN(RFC9136)
    ○ SRv6対応: https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services
    Control Plane (VPN)
    Data Plane
    MP-BGP (EVPN)によるMACアドレス伝搬
    MPLS(RFC7432), PBB (RFC7623), VXLAN(RFC8365)等による転送
    EVI EVI
    EVIをD-planeの経路と紐付けて利⽤する
    Router Router

    View Slide

  93. © NTT Communications Corporation All Rights Reserved. 93
    BGP-LS
    BGP-LS(BGP Link State)
    ● MP-BGPを利⽤したLink State共有技術(RFC7752)
    ○ AFI: 16388、SAFI: 71
    ○ IGPで収集したLink-StateやTE情報などをBGPで配信
    ■ OSPF/IS-ISどちらのLink Stateにも対応
    ■ PCE等のコントローラへのLink State配布や、マルチAS環境でIGPを超えたLink-State共有などを実現
    LSDB/TED
    IS-IS / OSPF
    daemon
    BGP
    daemon
    LinkState
    の収集
    TEDの
    Export
    Router
    TED
    Link Stateの共有先
    (PCE等のコントローラ・
    他IGPドメインのルータ等)
    BGP
    daemon
    受信した
    LinkState
    IGPで収集したLink State情報や、付随するTE情報を格納したデータベースをTED(Traffic Engineering Database)と呼ぶ
    IGPのLSDBとまとめて⼀つのDBとして実装されることが多い。下記はJunosの例
    https://www.juniper.net/documentation/jp/ja/software/junos/bgp/topics/topic-map/link-state-distribution-using-bgp.html
    MP-BGPでLinkstateを広告
    (AFI 16388, SAFI 71/72)

    View Slide

  94. © NTT Communications Corporation All Rights Reserved. 94
    (参考)BGP-LU(BGP Labelled Unicast)
    ● MPLSラベルをIPv4/v6のprefixと共に伝達する技術(RFC8277)
    ○ AFI: 1 or 2、SAFI: 4
    ○ BGP経由でラベルを伝達することでMulti-ASなMPLSのLSPを作成できる
    ○ RFC8669でSR向けに拡張
    ■ 異なるASのSIDを学習可能
    画像: https://www.noction.com/blog/bgp-labeled-unicast-bgp-lu
    わかりやすい説明: https://y-network.jp/2020/07/15/segment-routing-011/#toc2

    View Slide

  95. © NTT Communications Corporation All Rights Reserved. 95
    AS65000
    Color Extended Community
    ● BGPで広告する経路にColorをつける概念
    ○ IP Unicast経路やVPN経路など、任意の経路に付与可能
    ○ ColorベースでのTEなどに利⽤
    Customer A
    Customer B
    Customer A
    Customer B
    Node 2
    Node 3
    MP-BGP (VPNv6)によるPrefix伝搬
    RT: 65000:100
    Prefix:192.168.1.0/24
    Color: 100
    Customer A
    の経路表
    Customer B
    の経路表
    Customer A
    の経路表
    Customer B
    の経路表
    VRF A
    RD: 65000:100
    Import RT: 65000:100
    VRF A
    RD: 65000:100
    Export RT: 65000:100
    VRF B
    RD: 65000:200
    Import RT: 65000:200
    VRF B
    RD: 65000:200
    Export RT: 65000:200
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    Node1は受信した経路に対し、
    事前に定義されたper-ColorなTEポリシーを適⽤
    Node 1 Node 4
    通常、ポリシーはEndpointベースに定義する
    IPv4/v6 Dual StackにUnderlayを構成した場合は
    CO bitを設定することではEndpointに関わらずポリシーを適⽤可能
    SR domain

    View Slide

  96. © NTT Communications Corporation All Rights Reserved. 96
    Customer B
    Customer A
    AS65000
    ● Route-Target (RT)
    ○ 経路広告時に、相⼿に経路を識別してもらうために使⽤する識別⼦
    ○ 各ルータは、受信した経路のRTを参照し格納先のVRFを決定するimportルールを定義
    ■ ⼀般的には、経路につけるRTは対応するVRFのRDと同じ値にすることが多い
    ■ BGP UPDATEを受信したルータは、import設定に従ってRTに対応するVRFに格納
    VPN網
    Customer A
    Customer B
    Customer A
    の経路表
    Customer B
    の経路表
    Customer A
    の経路表
    Customer B
    の経路表
    VPN網の
    経路表
    VPN網の
    経路表
    Prefix: 192.168.0.0, RD: 65000:100
    Prefix: 192.168.0.0, RD: 65000:200
    R01のBGPテーブル
    Prefix: 192.168.1.0, RD: 65000:100
    Prefix: 192.168.1.0, RD: 65000:200
    Prefix: 192.168.1.0, RD: 65000:100
    R02のBGPテーブル
    R02
    R01
    BGP UPDATE
    VRF A
    RD: 65000:100
    Export RT: 65000:100
    VRF A
    RD: 65000:100
    Import RT: 65000:100
    VRF B
    RD: 65000:200
    Export RT: 65000:200
    VRF default VRF B
    RD: 65000:200
    Import RT:
    65000:200
    RT: 65000:100
    Prefix:192.168.0.0/24
    ②受信側はimportルールに従い
    RTに対応するVRFに格納
    ①送信側は、相⼿に格納して欲しい
    VRFを⽰すRTをつけUPDATEを広告
    VRF default
    192.168.0.0/24 192.168.1.0/24
    192.168.0.0/24 192.168.1.0/24
    Route-Target(再掲)

    View Slide

  97. © NTT Communications Corporation All Rights Reserved. 97
    ● IPv4以外の情報も送れるように拡張されたBGP
    ○ Path Attributeと、NLRIに紐づくAFI/Sub-AFIで様々な情報を共有
    ○ 今までに出たVPNv4/VPNv6やEVPN、BGP-LSなどもMP-BGPで送信される
    ● VPNに限らず、現代のルーティングに携わるならMP-BGPは必修︕
    ○ 様々な情報をPath AttributeとNLRI Address Familyで伝える概念を理解し、活⽤しよう︕
    ここまでのまとめ(MP-BGP)

    View Slide

  98. © NTT Communications Corporation All Rights Reserved. 98
    SR PCE

    View Slide

  99. © NTT Communications Corporation All Rights Reserved. 99
    ● ネットワークの持つ機能を役割ごとに分離し扱う概念
    ○ データプレーン︓転送機能
    ○ コントロールプレーン︓経路共有。SR的にはさらに3種類の役割が考えられる
    ■ Control Plane (LinkState): オーバレイの構築(Node SIDとTE情報の共有)
    ■ Control Plane (VPN): オーバレイ上のVPNの構築(VPN経路とVPNラベルの共有)
    ■ Control Plane (Policy): ポリシーの適⽤(Segment Listの作成と配布)
    PE P
    Control Plane (VPN)
    Data Plane
    役割︓オーバーレイ上のVPNの構築
    (BGP Prefix-SIDの広告)
    プロトコル︓BGP(VPNv4/VPNv6/EVPN等)
    役割︓パケットの転送
    プロトコル︓MPLS, IPv6
    PE
    SID・TE情報の共有
    パケットの転送
    Control Plane
    (LinkState)
    Control Plane (Policy) PCE
    役割︓経路の設定(Segement Listの作成と配布)
    プロトコル︓BGP-LS(トポロジ吸い上げ)
    PCEP(SegmentListの適⽤)
    ポリシーの適⽤
    VPNの構築
    役割︓オーバーレイの構築
    (Node SID/Adjacency SIDの伝搬)
    プロトコル︓IS-IS, OSPF, BGP-LS(Multi-AS等の場合)
    データプレーン / コントロールプレーン(再掲)

    View Slide

  100. © NTT Communications Corporation All Rights Reserved. 100
    ● PCE(Path Computation Element)
    ○ 中央集権的にMPLS等の経路計算を実⾏するノード。RFC5540、8231、8664などで提案
    ■ 複雑なポリシーの適⽤や経路計算、発⾏済みのLSP管理などを実現
    ■ 遅延、トラフィック分散、Affinity制約などの複雑なTEの実現、SDN的なアプローチ
    ■ BGPを収容するノードとして、ルートリフレクタと相乗りさせることも可能
    ■ 経路を受け取るノードはPCC(Path Computation Client)と呼ぶ
    ● 図的には分かれているが、PCEとPCCは同じノードにもできる
    Router
    (PCC)
    Router
    Router
    (PCC)
    PCE
    LinkStateの共有 Path情報の伝達
    Path情報(MPLSではLSP)の計算
    経路⽣成時の処理
    トポロジ変更時の処理
    (BGP Triggered Update)
    PCE

    View Slide

  101. © NTT Communications Corporation All Rights Reserved. 101
    ● SR PCEの動作は⼤きく2段階に分かれる
    ○ それぞれの段階では⽤いるプロトコルも異なる
    ○ トポロジ 情報の収集を⾏う段階(BGP-LS)
    ○ 経路計算結果を⾏う段階(PCEP & PCE内部での経路計算)
    C-Plane (Policy)
    SR PCEの動作
    C-Plane (VPN)
    D-Plane
    C-Plane
    (LinkState)
    PCE
    PCC
    TED Policy
    TEDへのLinkState伝達
    (BGP-LS)
    トポロジ/TE情報共有処理
    トポロジ変更時の
    BGP-LS Triggered Update
    Segment List発⾏処理
    オンデマンドなSegment List要求
    CSPFによるSegment Listの計算
    経路計算
    結果
    (PCEP)
    経路計算
    要求
    (PCEP)

    View Slide

  102. © NTT Communications Corporation All Rights Reserved. 102
    ● TED(Traffic Engineering Database)︓トポロジ情報を格納するデータベース
    ○ LSDBから⽣成される。リンク/ノードやSID等の他、TE metricや遅延も⼊る
    ● PCEP(PCE Communication Protocol)︓PCE-PCC間を接続するプロトコル
    ● CSPF(Constrained SPF)︓制約付きShortest Path First
    ○ Policyに基づき、帯域や遅延優先、Disjoint-path等の制約を満たす経路を計算
    C-Plane (Policy)
    SR PCEの⽤語
    PCE
    PCC
    TED Policy
    トポロジ/TE情報共有処理
    トポロジ変更時の
    BGP-LS Triggered Update
    Segment List発⾏処理
    オンデマンドなSegment List要求
    CSPFによるSegment Listの計算
    C-Plane (VPN)
    D-Plane
    C-Plane
    (LinkState)
    PolicyはPCC側が持ち、
    PCReqに⼊れてリクエストする設計もある
    TEDへのLinkState伝達
    (BGP-LS)
    経路計算
    結果
    (PCEP)
    経路計算
    要求
    (PCEP)

    View Slide

  103. © NTT Communications Corporation All Rights Reserved. 103
    ● PCE Communication Protocol
    ○ RFC5440で提案された、PCE-PCC間を接続するプロトコル
    ■ TCP port 4189を利⽤
    ■ MPLS/RSVP-TE環境のPCEに向け考案された
    PCEP
    画像: https://www.slideshare.net/TakuyaMiyasaka/pce-mplssdn
    PCE PCE

    View Slide

  104. © NTT Communications Corporation All Rights Reserved. 104
    ● 発⾏済みのパスを管理するかどうかで⼆種類に分類
    ● Stateless PCE: 発⾏済みのLSP/Segment Listを管理しないPCE
    ○ PCReqに対応した経路を発⾏し、PCRepを返すだけ
    ● Stateful PCE: 発⾏済みのLSP/Segment Listを管理するPCE
    ○ 経路変更などが⽣じた際、PCE側からPCCに能動的に経路変更が可能(能動性の有無によりActiveとPassiveに分類)
    ○ 既存のLSPの報告(PCRpt)、既存LSPの経路変更(PCUpd)、新規LSPの確⽴(PCInitiate)
    ○ ポータル等と組み合わせ、発⾏済みLSPの可視化等が可能
    Stateless PCEとStateful PCE
    画像: https://www.slideshare.net/TakuyaMiyasaka/pce-mplssdn
    PCE

    View Slide

  105. © NTT Communications Corporation All Rights Reserved. 105
    (参考)SRの帯域保証について
    ● SRのIGP機能だけではRSVP-TEのような帯域保証はできない
    ○ 帯域を確保するシグナリングプロトコルを利⽤しないため
    ● Stateful PCE機能を備えたコントローラを⽤いることで可能となる
    ○ 既存Segment Listの情報を管理することで帯域を管理
    ○ Telemetry等と組み合わせた機器情報管理と相性
    ● PCEを使わない場合の帯域保証も提案
    ○ SRでもRSVP-TEのような仕組みを使う
    ■ https://datatracker.ietf.org/doc/html/rfc8403

    View Slide

  106. © NTT Communications Corporation All Rights Reserved. 106
    ● 中央集権的に経路計算を実⾏するノード
    ○ 複雑なポリシーの適⽤や経路計算、発⾏済みのLSP管理などを実現
    ○ 遅延、トラフィック分散、Affinity制約などの複雑なTEの実現、SDN的なアプローチ
    ○ Stateful PCEによる発⾏済みのパスの管理や、可視化との相性、マルチドメインの集中管理
    ● → 集中的な網の管理や複雑な経路計算などに威⼒を発揮
    Router
    (PCC)
    Router
    Router
    (PCC)
    PCE
    LinkStateの共有 Path情報の伝達
    Path情報(MPLSではLSP)の計算
    経路⽣成時の処理
    トポロジ変更時の処理
    (BGP Triggered Update)
    ここまでのまとめ(PCE)

    View Slide

  107. © NTT Communications Corporation All Rights Reserved. 107
    SR関連の応⽤技術

    View Slide

  108. © NTT Communications Corporation All Rights Reserved. 108
    FRR / TI-LFA
    ● FRR(Fast Reroute)
    ○ Backup-Pathを⽤意し、障害時に50ms未満のLocal Repairを実現
    ● TI-LFA(Topology-Independent Loop-Free Alternate)
    ○ FRRの実現⼿法の⼀つ。トポロジを問わずループフリーなBackup-Pathを⽣成
    ■ Qノード、Pノードを選出し、P→Qノードを通るよう迂回路を⽣成
    ■ IGPでSID込みのトポロジ共有をするSRとの親和性
    画像: https://www.netone.co.jp/knowledge-center/blog-column/knowledge_takumi_121/

    View Slide

  109. © NTT Communications Corporation All Rights Reserved. 109
    Service Function Chaining
    ● Service Function Chaining
    ○ TEの応⽤技術の⼀つ
    ■ https://datatracker.ietf.org/doc/html/rfc7665
    ○ NW上の機能を特定の順番でつなぎ、サービスとして提供する技術
    ■ ある通信に付加価値を提供することが可能
    ○ ⽇本語ではサービスチェイニングと呼ぶことが多い
    CGN Firewall Optimizer DPI
    Dst.
    Service Chain B
    Service Chain A
    Customer A Customer B

    View Slide

  110. © NTT Communications Corporation All Rights Reserved. 110
    SRv6 SFC Proxy
    ● SRv6⾮対応なNetwork Functionを利⽤するための技術
    ○ SFF(Service Function Forwarder): Fucntionにパケットを転送、戻りパケットを受信するノード
    ○ SR Proxy: SRv6⾮対応なノードに対しパケットを転送、戻りパケットをSRv6に再送信するノード
    ■ SRv6ではSFFと機能を兼ねる設計が可能
    ● SRv6ではEnd.A系のFunctionによりProxyを実現
    ○ https://datatracker.ietf.org/doc/draft-ietf-spring-sr-service-programming/
    ■ SR-Unaware対応のため、Static / Dynamic / Masquerading の3⽅式が提案
    PE 1
    SR domain
    SFF /
    SR Proxy
    PE 2
    Function
    End.AM
    1. Segment Leftを1つ進め(End)
    Destination AddressをSegment List [0](末尾)で上書き
    3. Destination AddressをSegment List [Segment Left]
    (本来の先頭要素)で上書き、SRv6による転送を再開
    2. Network Functionは正しく最終的なDestinationが
    指定されたIPv6パケットを受け取る(拡張ヘッダは無視)

    View Slide

  111. © NTT Communications Corporation All Rights Reserved. 111
    ● EPE (Egress Peer Engineering)
    ○ 対向ASへの経路が複数ある場合にそのどちらかを選択するための技術
    ● SRでのEPE
    ○ https://datatracker.ietf.org/doc/html/rfc9086
    ○ Peer Adj SID / Peer Node SIDで対向を識別
    EPE
    SR domain
    PE/ASBR1
    P1 ASBR β
    AS β
    AS α
    PE1
    PE/ASBR2
    P2 ASBR γ
    AS γ
    24001 Payload
    Segment List
    Label Action Next
    24000 POP ASBR β
    24001 POP ASBR γ
    ... ... ...
    PE/ASBR 1のSID Table(⼀部)
    eBGP Peerごとに発⾏された
    EPE Peer Adj SIDで処理
    EPEでASBR γ に送出
    ASBR γ を⽰すEPEラベルを
    付与し送信

    View Slide

  112. © NTT Communications Corporation All Rights Reserved. 112
    ● Multi-ASにTEをする場合、下記の3種類が重要となる
    a. AS内のTE(SR-TE)
    ■ Multi-ASなTEメニューのため、より効率的かつ柔軟なTEをしたくなる
    ■ TE Metric/遅延ベースなFlex-Algo等との組み合わせ、IGP MetricのOverride...
    b. ASBR(Egress)の選択
    c. Egress Peerの選択
    ■ 同⼀Prefixに対して複数の経路を持ちたい → RR環境ではBGP add-pathなども必要
    (補⾜)Egress/Egress Peer周りのTEについて
    SR domain
    PE/ASBR1
    P1 ASBR β1
    AS β
    AS α
    PE1
    PE/ASBR2
    P2 / RR ASBR β2

    View Slide

  113. © NTT Communications Corporation All Rights Reserved. 113
    (参考)SR OAM
    ● SR Operation, Administration, and Maintenance
    ○ SR網の運⽤、管理、保守を⾏うための技術群
    ■ https://datatracker.ietf.org/doc/html/rfc8403
    ■ https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-oam-requirement
    ○ MPLS LSP Ping/Tracerouteなどが含まれる
    ○ 疎通性の確認や障害検知など
    画像: https://www.cisco.com/c/ja_jp/td/docs/iosxr/ncs560/segment-routing/70x/b-segment-routing-cg-70x-ncs560/b-segment-routing-cg-70x-ncs560_chapter_01010.html

    View Slide

  114. © NTT Communications Corporation All Rights Reserved. 114
    (参考)Performance Measurement
    ● LSPの接続性や遅延などを計測
    ○ https://datatracker.ietf.org/doc/html/draft-gandhi-spring-stamp-srpm
    ● TWAMP(Two-Way Active Measurement Protocol)
    ○ https://datatracker.ietf.org/doc/html/rfc5357
    ○ タイムスタンプ付きのUDPパケットを利⽤し、遅延を計測するためのプロトコル
    ■ 通常のTWAMPの他に、Client-Serverを省略したTWAMP Lightも存在
    ■ 計測⼿法にはOne-way / Two-way / Loopbackの3種が存在
    ○ 計測結果はIGP / BGP-LSに載せて広告可能
    ■ Flex-Algoとの組み合わせ、Delay MetricのIGP計算スライスを作成するなど
    ● P2P遅延とE2E遅延
    ○ P2P遅延: ある区間の遅延を計測する⼿法。IGPで集め、Metricとして利⽤
    ○ E2E遅延: ある経路の遅延を計測する⼿法。定義済みのSR Policyの評価など

    View Slide

  115. © NTT Communications Corporation All Rights Reserved. 115
    (参考)SRv6のSID圧縮
    ● SID空間を効率的に使いたい要求
    ● 現在SRv6 SID Compression Design Teamを中⼼に議論中
    ○ https://datatracker.ietf.org/doc/html/draft-ietf-spring-compression-analysis
    ○ https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update
    ○ 圧縮率、SRv6 SIDやSRHの互換性、テーブル、C-Planeなどに差異

    View Slide

  116. © NTT Communications Corporation All Rights Reserved. 116
    ● ASごとのリソース分離によるスケーラビリティ向上・新規ユースケースの創出
    ○ 分散と集中のバランスを考慮したデザインが重要
    ■ Inter-AS Option、AS間のTEメニュー提供⽅法(RT/Color/BSID/EPE)など
    ■ スケーラビリティと理想的なE2E TEのトレードオフ
    ■ 既存網同⼠の相互接続によるサービス連携、リソースの有効活⽤
    ■ SR-MPLS-SRv6 Interworkなど、新たな価値の提供
    ● NTT Comの取り組み: https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf
    (参考)Multi-AS Segment Routing
    SR domain
    PE/ASBR1
    P1 PE/ASBR3
    AS β
    AS α
    PE1
    PE/ASBR2
    P2 PE/ASBR4
    SR domain
    P3
    P/SFF1
    PE2
    Function

    View Slide

  117. © NTT Communications Corporation All Rights Reserved. 117
    ● 企業間/AS間連携、Inter-DCなL2/L3VPN
    ○ 複数の網を接続し、CustomerにL2/L3VPNを提供
    ● 5G Core/Access/MECの接続
    ○ 機能ごとのNW分離。SRのスライシングやFunctionはモバイルと好相性
    ● Service Function Chainingの提供
    ○ Public Cloud等の他ASと連携し、⼀連のサービスを提供
    画像: https://pc.nanog.org/static/published/meetings/NANOG73/1659/20180626_Moyer_Segment_Routing_For_v1.pdf
    (参考)Multi-AS SRのユースケースの例

    View Slide

  118. © NTT Communications Corporation All Rights Reserved. 118
    それぞれ⼀度読んでおくことをお勧めします
    ● MPLSなど閉域網の技術全般:
    ○ 閉域網接続の技術⼊⾨
    ■ https://www.slideshare.net/MasayukiKobayashi/ss-60985808
    ● SR全般:
    ○ SRv6⼊⾨
    ■ https://enog.jp/wordpress/wp-content/uploads/2018/12/ENOG55_asama.pdf
    ○ SRv6〜ネットワークプログラマビリティの実現〜
    ■ https://www.nic.ad.jp/ja/materials/iw/2019/proceedings/s04/s4-miyasaka.pdf
    ○ Segment Routing | ゆるふわネットワーク:
    ■ SR関連技術の概念をIOS-XRのコンフィグつきで解説
    ■ https://y-network.jp/category/segment-routing/
    ● PCE:
    ○ PCE 〜MPLSネットワークのSDN化を本気で実現する"唯⼀の"⽅法
    ■ https://www.slideshare.net/TakuyaMiyasaka/pce-mplssdn
    参考資料

    View Slide

  119. © NTT Communications Corporation All Rights Reserved.

    View Slide