Segment Routing入門

Segment Routing入門用資料

Transcript

1. © NTT Communications Corporation All Rights Reserved. Segment Routing⼊⾨ 2022/1/13 イノベーションセンター 三島 航
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/ ⽬次
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 閉域網のルーティング技術について
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として設計可能 ルータの役割と呼称
5. © NTT Communications Corporation All Rights Reserved. 5 TE（Traffic Engineering）
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による転送
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 より⾼度な経路制御の要求
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
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
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
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 従来の経路制御技術が抱える課題
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が増加 従来の経路制御技術が抱える課題 - 中間ノードのステート増加
13. © NTT Communications Corporation All Rights Reserved. 13 • 中間にステートが必要 = 新たな経路追加/削除の度、中間ノードの操作が必要 ◦ 中間ノードの経路を更新し、新たな経路を⽣成する処理をシグナリングと呼ぶ • IGPの他にシグナリング専⽤プロトコルの管理・運⽤が必要 ◦ 管理・運⽤の煩雑化や学習コストの増加 → 中間ノードのステート増加と、煩雑なプロトコルがスケーラビリティの課題に A D B C X Z Y 従来の経路制御技術が抱える課題 - 経路追加/削除時の伝搬
14. © NTT Communications Corporation All Rights Reserved. 14 Segment Routing
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の概要
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 ソースルーティング
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
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の転送例
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
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 オーバレイネットワーク
21. © NTT Communications Corporation All Rights Reserved. 21 データプレーン / コントロールプレーン
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等の場合） データプレーン / コントロールプレーン
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のデータプレーン
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）
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）の流れ
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のデータプレーンの流れ
27. © NTT Communications Corporation All Rights Reserved. 27 SRのデータプレーン SR-MPLSとSRv6
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
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のフレームフォーマット
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
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 … … …
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）
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が異なる場合の挙動
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
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構造
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のパケットフォーマット
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関連ノードの種別
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による転送
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⾮対応ノードが存在する場合の処理
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の処理
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）
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）
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設計案
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）
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）
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の⽐較
47. © NTT Communications Corporation All Rights Reserved. 47 SRのコントロールプレーン
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共有部分・再掲）
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で指定された際に転送する為の下準備ができる
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
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）
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）
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
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
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）
56. © NTT Communications Corporation All Rights Reserved. 56 • 意図に基づいてネットワーキングを実現する概念 ◦ 運⽤者が事前に定義した状態になるようネットワークを構築する ◦ 例: 障害が起きても、常に帯域X bpsを満たすようリルートされる経路 ◦ 例: IGPコストではなく、常に遅延最⼩になるような経路 画像: https://blogs.cisco.com/networking/improving-networks-with-ai Intent-based Networking
57. © NTT Communications Corporation All Rights Reserved. 57 • ⼀つのNWを、複数の仮想NWに分割・多重化する技術 ◦ リソースの共通化と、NWの分離を同時に実現 ◦ 利⽤者ごとの分離、冗⻑パスの分離、通信品質のMetric分けなど 物理NW （Underlay） スライスB スライスA ネットワークスライシング
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拡張
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
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）
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）
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）
63. © NTT Communications Corporation All Rights Reserved. 63 VPN（Virtual Private Network）
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とは
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）
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
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
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
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
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
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.
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等の場合） データプレーン / コントロールプレーン（再掲）
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（コントロールプレーン）
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
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
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）
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）
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（データプレーン動作）
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）
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（データプレーン）
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）
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）
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）
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）
85. © NTT Communications Corporation All Rights Reserved. 85 VPNで⽤いられるプロトコル（MP-BGP）
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)
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
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の広告
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ルータの任意 識別できない場合、ネイバーに対してこのパス属性を伝搬しない
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
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
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
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）
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
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
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（再掲）
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）
98. © NTT Communications Corporation All Rights Reserved. 98 SR PCE
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等の場合） データプレーン / コントロールプレーン（再掲）
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
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)
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)
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
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
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
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）
107. © NTT Communications Corporation All Rights Reserved. 107 SR関連の応⽤技術
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/
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
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パケットを受け取る（拡張ヘッダは無視）
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ラベルを 付与し送信
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
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
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の評価など
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などに差異
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
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のユースケースの例
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 参考資料
119. © NTT Communications Corporation All Rights Reserved.