Segment Routing入門

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

View Slide

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

View Slide

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

View Slide

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

View Slide

TE（Traffic Engineering）

View Slide

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

View Slide

● 送信元やプロトコル種別など、宛先以外の要素で転送したい︕
○ ⾳声通信は低遅延、動画は低ジッタ、ウェブは広帯域...
○ 送信元Xさんはお⾦をたくさん払っているので品質の良い通信...
○ 特定の送信元以外の通信は、セキュリティ機器を複数経由させたい...
○ → 実現できれば、ネットワークに付加価値を提供可能
● 宛先ベースの経路表だけでは実現不可能
A D
B
C
X
Z
Aの経路表
宛先送出先
X X
Y Y
B B
C C
D B
Z B?C?
Y
遅延優先︖
帯域優先
より⾼度な経路制御の要求

View Slide

● Policy-Based Routing
○ ポリシーに基づいた転送を⾏うための仕組み
○ 経路表ではなく、ポリシーを記述したルートマップに基づき転送
○ 送信元アドレス・プロトコル・ポート・インターフェース等の条件と、該当したパケットの
処理をルートマップに定義、転送を実施
A D
B
C
X
Z
Y
遅延優先
帯域優先
Aのルートマップ
match set
宛先送信元動作転送先
Z X permit B
Z Y permit C
案1: PBR

View Slide

● 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
案2: MPLS

View Slide

● 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
案3: OpenFlow

View Slide

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
制御対象の数に伴い
テーブルが肥⼤化
従来の経路制御技術が抱える課題

View Slide

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

View Slide

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

View Slide

Segment Routing

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

データプレーン / コントロールプレーン

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

SRのデータプレーン
SR-MPLSとSRv6

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

● 各ルータの利⽤する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
... ... ...
16003 Payload Payload
Pop
Prefix: Z.Z.Z.Z
Index: 3
Node 3のIndex
Prefix: Z.Z.Z.Z
Index: 3
Node 3のIndex
SRGB: 16000
Range: 8000
Node 2のSRGB
IGP（ISISやOSPF）
SRGB: 16000
Range: 8000
Node 3のSRGB
SRGB（SR Global Block）

View Slide

● 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
Label Action Next
800001 POP Node 1
800003 POP Node 3
... ... ...
800003 Payload Payload
Pop
Prefix: Z.Z.Z.Z
Index: 3
Node 3のIndex
Prefix: Z.Z.Z.Z
Index: 3
Node 3のIndex
SRGB: 800000
Range: 4096
Node 2のSRGB
SRGB: 16000
Range: 8000
Node 3のSRGB
Node 2のSRGBは800000〜だが、
Node 1では16002として学習
Node 3のNode SIDは、
16003から800003の
SWAPとなっている
1. ⾃らのSRGBの基準値に、IGPで広告された隣接ルータのIndexを⾜したSIDを学習
2. SRGBの基準値とSRGB Sizeで隣接ノードのSRGBを認識
3. 隣接ノードへのSWAPルールを作成する際、隣接ノードのSRGBを⽤いてOutgoing labelを設定
○ 同じNode SIDのルールであっても、違うラベルにSWAPすることとなる
4. SRGBは異なっていても動作するが、IndexはSR domain内でのGlobal Uniqueに設計する必要あり
（参考）SRGBが異なる場合の挙動

View Slide

● 専⽤の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
(SR Header)
Payload
IPv6 Header
Payload
IPv6 Header
Insert SRH
SRv6

View Slide

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

View Slide

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

View Slide

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

View Slide

● ⾃らが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
(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
Destination IP address: fd00:0:0:4::6:a
Payload
IPv6 Header
Next Header:
41
Next Header: 43
Payload
IPv6 Header
Next Header:
41
SRv6による転送

View Slide

● 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
(SR Header)
SRv6非対応Node
IPv6 Header
H.Encaps
Next Header: 43
Destination IP address: fd00:0:0:2::1
Payload
IPv6 Header
Next Header:
41
Next Header: 43
Payload
IPv6 Header
Next Header:
41
Next Header: 43
Payload
IPv6 Header
Next Header:
41
SRv6⾮対応ノードが存在する場合の処理

View Slide

● 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
H.Encaps
（太字が先頭要素）
宛先送出先
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
宛先送出先
fd00:0:0:1::/64 en0
fd00:0:0:3::/64 en0
fd00:0:0:4::/64 en0
SID Action
fd00:0:0:2::/128 End
Node 2のLocal SID Table
SID Action
fd00:0:0:2::/128 End
SID Action
fd00:0:0:4::/128 End
fd00:0:0:4::6:a/128 End.DT6 VRF-a
VRF-a
IPv6 Header（宛先のみ）
Destination Address: fd00:0:0:2::1
Destination Address: fd00:0:0:4::6:a
Destination Address: fd00:0:0:4::6:a
Locator / Local SIDの処理

View Slide

● 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
(SRv6 Header)
Payload
IPv6 Header
Encapsulationモード: 扱う対象がIPv6でなくても使⽤可能 Insertモード: IPv6パケットであることが必須だが、
ヘッダによるオーバーヘッドを削減できる
Payload
IPv6 Header
Encapsulation
(SRv6 Header)
Payload
IPv6 Header
Payload
IPv6 Header
Insert SRH
代表的なWell-known Behaviors（Headend）

View Slide

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

View Slide

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

View Slide

● 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
SR-MPLS
Node
24002 Payload
24003 Payload
24001 Payload
Label
fd00:0:0:1::/64
SID Table（⼀部） Label
24001
24002
24003
SID Table（⼀部）
Endpointとなるノード以外はSID
TableにLocaterのみ保持
SRv6 Functionに相当するBSIDを処
理するノード以外も、全てのノードが
SID Tableに持つ必要あり
このBSIDはGlobal SIDとなる
（補⾜）Binding SegmentとSRv6 Function（1/2）

View Slide

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

View Slide

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

View Slide

SRのコントロールプレーン

View Slide

● 役割: 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)
SRのコントロールプレーン（SID共有部分・再掲）

View Slide

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の構築)
- BGP-LSによりトポロジ情報を吸い上げる
- PCEが持つポリシーをもとに、セグメントリストを構築
- PCEPにより、作成したセグメントリストをPEに配布
→ 動作の結果、PEがセグメントリストを得る。Pには影響しない
- L3VPN（per-VRF/per-CE）やL2VPNに対応したVPNラベル
（BGP Prefix-SID）を作成
- BGPにより対向のPEにL3VPN（per-VRF/per-CE）やL2VPNの情報を広告
→ 動作の結果、VPNを貼りたいPE同⼠が、VPN経路やそのラベルを取得
- 各ノードがindexからNode SIDを、隣接関係からAdjacency SIDを作成
- IGPにより網内（IGP domain = SR domain内）の全ノードに
Node SID / Adjacency SIDを広告
- 上記を受け取ったノードは、受け取ったNode SIDをSID Tableに格納
→ 動作の結果、SID Tableができる
= Segment Listで指定された際に転送する為の下準備ができる

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

VPN（Virtual Private Network）

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
RD付き経路を学習
Route-Distinguisher

View Slide

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
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
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
VRF default VRF B
RD: 65000:200
Import RT:
65000:200
RT: 65000:100
Prefix:192.168.0.0/24
②受信側はimportルールに従い
RTに対応するVRFに格納
①送信側は、相⼿に格納して欲しい
VRFを⽰すRTをつけUPDATEを広告
VRF default
192.168.0.0/24 192.168.1.0/24
192.168.0.0/24 192.168.1.0/24
Route-Target

View Slide

71
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

View Slide

PE P
Control Plane (VPN)
Data Plane
PE
Control Plane
(LinkState)
VPNの構築
データプレーン / コントロールプレーン（再掲）

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

● 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
EVI A
EVI B
EVI A
EVI B
EVPNによるL2VPN（コントロールプレーン動作: VPN）

View Slide

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

View Slide

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

View Slide

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

View Slide

● 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のみ抜粋
② Node 2はEnd処理を実施
Segment List [0]: fd00::4:0:2:0:0
Segment List [0]: fd00::4:0:2:0:0
en0
en1
Locator:
fd00:0:0:1::/64N
ode 1
Locator:
fd00:0:0:4::/64
Node 4
Locator:
fd00:0:0:2::/64
Node 2
Locator:
fd00:0:0:3::/64
Node 3
SRv6によるL2VPN（End.DX2）

View Slide

● 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 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
VPN網の
経路表
VRF default
VPN網の
経路表
VRF default
Locator:
fd00:0:0:1::/64N
ode 1
Locator:
fd00:0:0:4::/64
Node 4
Segment List [0]: fd00::4:0:6:0:a
SRv6によるVPN（End.DT4, End.DT6）

View Slide

● 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
（Node 2のEndとNode 4でCE3を⽰すEnd.DX6を付与）
③ Node 4は VRF defaultでEnd.DX6を実施
拡張ヘッダを外し、CE3へ送出
④ Customer AのCE3に到着
per-CE L3VPNに成功
SR domain
SRv6によるVPN（End.DX4, End.DX6）

View Slide

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

View Slide

VPNで⽤いられるプロトコル（MP-BGP）

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
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
R01
BGP UPDATE
VRF A
RD: 65000:100
VRF A
RD: 65000:100
VRF B
RD: 65000:200
VRF default VRF B
RD: 65000:200
Import RT:
65000:200
RT: 65000:100
Prefix:192.168.0.0/24
VRF default
192.168.0.0/24 192.168.1.0/24
192.168.0.0/24 192.168.1.0/24

View Slide

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
MPLS(RFC7432), PBB (RFC7623), VXLAN(RFC8365)等による転送
EVI EVI
EVIをD-planeの経路と紐付けて利⽤する
Router Router

View Slide

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

View Slide

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

View Slide

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
VRF A
RD: 65000:100
VRF B
RD: 65000:200
VRF B
RD: 65000:200
192.168.0.0/24 192.168.1.0/24
192.168.0.0/24 192.168.1.0/24
Node1は受信した経路に対し、
事前に定義されたper-ColorなTEポリシーを適⽤
Node 1 Node 4
通常、ポリシーはEndpointベースに定義する
IPv4/v6 Dual StackにUnderlayを構成した場合は
CO bitを設定することではEndpointに関わらずポリシーを適⽤可能
SR domain

View Slide

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
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
R01
BGP UPDATE
VRF A
RD: 65000:100
VRF A
RD: 65000:100
VRF B
RD: 65000:200
VRF default VRF B
RD: 65000:200
Import RT:
65000:200
RT: 65000:100
Prefix:192.168.0.0/24
VRF default
192.168.0.0/24 192.168.1.0/24
192.168.0.0/24 192.168.1.0/24
Route-Target（再掲）

View Slide

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

View Slide

SR PCE

View Slide

PE P
Control Plane (VPN)
Data Plane
PE
Control Plane
(LinkState)
VPNの構築
データプレーン / コントロールプレーン（再掲）

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

SR関連の応⽤技術

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

Segment Routing入門

Segment Routing入門

Wataru MISHIMA

More Decks by Wataru MISHIMA

Other Decks in Technology

Featured

Transcript