Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

© 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/ ⽬次

Slide 3

Slide 3 text

© 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 閉域網のルーティング技術について

Slide 4

Slide 4 text

© 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として設計可能 ルータの役割と呼称

Slide 5

Slide 5 text

© NTT Communications Corporation All Rights Reserved. 5 TE（Traffic Engineering）

Slide 6

Slide 6 text

© 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による転送

Slide 7

Slide 7 text

© 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 より⾼度な経路制御の要求

Slide 8

Slide 8 text

© 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

Slide 9

Slide 9 text

© 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

Slide 10

Slide 10 text

© 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

Slide 11

Slide 11 text

© 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 従来の経路制御技術が抱える課題

Slide 12

Slide 12 text

© 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が増加 従来の経路制御技術が抱える課題 - 中間ノードのステート増加

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© NTT Communications Corporation All Rights Reserved. 14 Segment Routing

Slide 15

Slide 15 text

© 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の概要

Slide 16

Slide 16 text

© 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 ソースルーティング

Slide 17

Slide 17 text

© 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

Slide 18

Slide 18 text

© 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の転送例

Slide 19

Slide 19 text

© 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

Slide 20

Slide 20 text

© 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 オーバレイネットワーク

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

© 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等の場合） データプレーン / コントロールプレーン

Slide 23

Slide 23 text

© 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のデータプレーン

Slide 24

Slide 24 text

© 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）

Slide 25

Slide 25 text

© 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）の流れ

Slide 26

Slide 26 text

© 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のデータプレーンの流れ

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

© 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

Slide 29

Slide 29 text

© 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のフレームフォーマット

Slide 30

Slide 30 text

© 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

Slide 31

Slide 31 text

© 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 … … …

Slide 32

Slide 32 text

© 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）

Slide 33

Slide 33 text

© 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が異なる場合の挙動

Slide 34

Slide 34 text

© 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

Slide 35

Slide 35 text

© 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構造

Slide 36

Slide 36 text

© 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のパケットフォーマット

Slide 37

Slide 37 text

© 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関連ノードの種別

Slide 38

Slide 38 text

© 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による転送

Slide 39

Slide 39 text

© 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⾮対応ノードが存在する場合の処理

Slide 40

Slide 40 text

© 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の処理

Slide 41

Slide 41 text

© 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）

Slide 42

Slide 42 text

© 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）

Slide 43

Slide 43 text

© 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設計案

Slide 44

Slide 44 text

© 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）

Slide 45

Slide 45 text

© 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）

Slide 46

Slide 46 text

© 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の⽐較

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

© 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共有部分・再掲）

Slide 49

Slide 49 text

© 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で指定された際に転送する為の下準備ができる

Slide 50

Slide 50 text

© 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

Slide 51

Slide 51 text

© 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）

Slide 52

Slide 52 text

© 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）

Slide 53

Slide 53 text

© 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

Slide 54

Slide 54 text

© 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

Slide 55

Slide 55 text

© 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）

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

© 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拡張

Slide 59

Slide 59 text

© 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

Slide 60

Slide 60 text

© 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）

Slide 61

Slide 61 text

© 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）

Slide 62

Slide 62 text

© 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）

Slide 63

Slide 63 text

© NTT Communications Corporation All Rights Reserved. 63 VPN（Virtual Private Network）

Slide 64

Slide 64 text

© 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とは

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

© 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

Slide 67

Slide 67 text

© 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

Slide 68

Slide 68 text

© 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

Slide 69

Slide 69 text

© 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

Slide 70

Slide 70 text

© 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

Slide 71

Slide 71 text

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.

Slide 72

Slide 72 text

© 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等の場合） データプレーン / コントロールプレーン（再掲）

Slide 73

Slide 73 text

© 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（コントロールプレーン）

Slide 74

Slide 74 text

© 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

Slide 75

Slide 75 text

© 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

Slide 76

Slide 76 text

© 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）

Slide 77

Slide 77 text

© 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）

Slide 78

Slide 78 text

© 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（データプレーン動作）

Slide 79

Slide 79 text

© 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）

Slide 80

Slide 80 text

© 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（データプレーン）

Slide 81

Slide 81 text

© 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）

Slide 82

Slide 82 text

© 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）

Slide 83

Slide 83 text

© 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）

Slide 84

Slide 84 text

© 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）

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

© 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)

Slide 87

Slide 87 text

© 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

Slide 88

Slide 88 text

© 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の広告

Slide 89

Slide 89 text

© 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ルータの任意 識別できない場合、ネイバーに対してこのパス属性を伝搬しない

Slide 90

Slide 90 text

© 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

Slide 91

Slide 91 text

© 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

Slide 92

Slide 92 text

© 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

Slide 93

Slide 93 text

© 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）

Slide 94

Slide 94 text

© 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

Slide 95

Slide 95 text

© 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

Slide 96

Slide 96 text

© 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（再掲）

Slide 97

Slide 97 text

© 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）

Slide 98

Slide 98 text

© NTT Communications Corporation All Rights Reserved. 98 SR PCE

Slide 99

Slide 99 text

© 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等の場合） データプレーン / コントロールプレーン（再掲）

Slide 100

Slide 100 text

© 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

Slide 101

Slide 101 text

© 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)

Slide 102

Slide 102 text

© 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)

Slide 103

Slide 103 text

© 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

Slide 104

Slide 104 text

© 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

Slide 105

Slide 105 text

© 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

Slide 106

Slide 106 text

© 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）

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

© 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/

Slide 109

Slide 109 text

© 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

Slide 110

Slide 110 text

© 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パケットを受け取る（拡張ヘッダは無視）

Slide 111

Slide 111 text

© 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ラベルを 付与し送信

Slide 112

Slide 112 text

© 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

Slide 113

Slide 113 text

© 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

Slide 114

Slide 114 text

© 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の評価など

Slide 115

Slide 115 text

© 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などに差異

Slide 116

Slide 116 text

© 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

Slide 117

Slide 117 text

© 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のユースケースの例

Slide 118

Slide 118 text

© 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 参考資料

Slide 119

Slide 119 text

© NTT Communications Corporation All Rights Reserved.