2021/12/3
マルチAS/マルチドメインなSegment Routingの実現
イノベーションセンター 三島 航
© NTT Communications Corporation All Rights Reserved.
⽬次
● マルチAS/マルチドメインなSegment Routing
○
背景: NTT ComのSR活⽤事例と課題
○
新たな要求とユースケース
○
Multi-AS SRについて
■
E2E TEとスケーラビリティのバランス（集中と分散）
● SR-MPLS/SRv6相互接続
○
SR-MPLS
CE
Service Function Chainingの活⽤
● Future Work
○
PCEの活⽤
○
VPN/TEのセルフマネージ化
○
より⾼度なTEの実現
○
SRv6のさらなる活⽤
© NTT Communications Corporation All Rights Reserved.
CE
PE
PE
P
Network
Function
PE/ASBR
SFC
Proxy
PE/ASBR
P
SRv6
PE
CE
CE
Interw ork
ASBR
PE/ASBR
P
SR-MPLS
PE
PE/ASBR
PE/ASBR
P
PE
CE
SR-MPLS
2
マルチAS/マルチドメインなSegment Routing
NTT ComのSR活⽤事例と課題
© NTT Communications Corporation All Rights Reserved.
3
作りたいネットワーク
● マルチAS/マルチドメインなSegment Routing
○
なぜ必要か、どう作るかを説明して⾏きます
AS
SR-MPLS domain
Customer
CE
PE
Network
Function
Customer
P
PE
CE
Customer
PE/ASBR
CE
Inter-AS
MPLS
SFC
Proxy
PE/ASBR
PE
Customer
CE
Customer
PE
P
SRv6 domain
AS
© NTT Communications Corporation All Rights Reserved.
Interwork
ASBR
PE/ASBR
Inter-AS
MPLS
P
SR-MPLS domain
AS
PE/ASBR
PE/ASBR
Inter-AS
MPLS
P
PE
CE
SR-MPLS domain
AS
4
Multi-AS SR-MPLSについて
● まずはMulti-AS SR-MPLSから︕
AS
SR-MPLS domain
Customer
CE
PE
Network
Function
Customer
P
PE
CE
Customer
PE/ASBR
CE
Inter-AS
MPLS
SFC
Proxy
PE/ASBR
PE
Customer
CE
Customer
PE
P
SRv6 domain
AS
© NTT Communications Corporation All Rights Reserved.
Interwork
ASBR
PE/ASBR
Inter-AS
MPLS
P
SR-MPLS domain
AS
PE/ASBR
PE/ASBR
Inter-AS
MPLS
P
PE
CE
SR-MPLS domain
AS
5
NTT ComとSegment Routing（2018〜）
● SR-MPLSを活⽤した全社的な商⽤インフラを構築・運⽤中
○
Customerごとにスライスを提供
○
SR網のみでのL2VPN / L3VPN提供
■
○
要件と当時の実装状況を考慮し、SR-MPLS + MP-BGP（VPNv4/v6、EVPN）を選定
過去の対外発表
■
SR-MPLSの導⼊事例と今後の展望について（MPLS JAPAN 2019）
●
■
ユーザによるセルフマネージ可能なネットワークサービス運⽤システムの事例（ONIC 2019）
●
■
https://mpls.jp/2019/presentations/MPLS-Japan2019_NTTcom.pdf
https://onic.jp/_cms/wp-content/uploads/2019/11/onic2019_tajima.pdf
マルチベンダASかつマルチベンダにおけるSR-MPLS TEの実現（MPLS JAPAN 2021）
●
© NTT Communications Corporation All Rights Reserved.
https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf
6
実現したいこと（2021〜）
● SR-MPLSをより⼤規模に構成したい︕
○
例として下記のようなユースケースを検討中
○
複数拠点に跨がるSR-MPLS網の⼤規模展開
○
複数の運⽤者の持つネットワークの相互接続
■
（参考）Docomo・NTT Com・NTTコムウェアの組織統合
●
○
https://www.nttdocomo.co.jp/info/news_release/2021/10/25_00.html
複数の機能を持つネットワーク同⼠の接続
■
コア網・アクセス網・データセンタなど
© NTT Communications Corporation All Rights Reserved.
7
Single-AS構成で⽣じる課題
1. Global Unique空間の共有
○
⽤途や管理者ごとにレベル/エリアの分割は可能だが、IP空間は共有する必要あり
○
SIDのindexも単⼀のSR domainでUniqueに管理、NW同⼠が密結合になる
2. ある設定や障害の影響範囲が全体に及ぶ
○
フラットな単⼀ネットワーク設計はスケーラビリティの⾜枷となる
Single-AS
⽤途 α のNW
⽤途 β のNW
障害情報の伝搬
P1
16002
PE/ASBR1
16004
PE/ASBR3
16006
SR domain
P3
16008
PE1
16001
PE2
16010
P2
16003
© NTT Communications Corporation All Rights Reserved.
PE/ASBR2
16005
PE/ASBR4
16007
P/SFF1
16009
IP addr / SIDはSR domainでGlobal Uniqueに設計しなければならない
8
提案: Multi-AS Segment Routing
● マルチASにネットワークを設計、各ASでSRを利⽤し相互接続
○
ASごとのリソース分離によるスケーラビリティ向上・新規ユースケースの創出︕
■
既存網同⼠の相互接続によるサービス連携、リソースの有効活⽤
■
SR domainの範囲、LSDBの共有⽅法、TEの実現⽅法などで形態が実現可能
■
SR-MPLS-SRv6 Interworkなど、新たな価値の提供
障害影響もAS内に閉じる
AS α
AS β
SR domain
P1
16002
PE/ASBR1
16004
Inter-AS
MPLS
SR domain
PE/ASBR3
16001
P3
16003
PE1
16001
PE2
16005
P2
16003
© NTT Communications Corporation All Rights Reserved.
PE/ASBR2
16005
PE/ASBR4
16002
P/SFF1
16004
UnderlayをASごとに隠蔽、IP addr / SIDはSR domainを⾃由に設計︕
9
Multi-AS SRのユースケースの例
● 企業間/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
© NTT Communications Corporation All Rights Reserved.
10
Inter-AS Option
● Multi-AS MPLS-VPNでは複数の接続オプションが提案済（RFC4364）
実現⽅式により、Option A, B, Cの3種に分類
○
■
Option AとBを組み合わせたOption D(AB)も提案
それぞれのOptionにPros/Consが存在
○
以降のページで、下記のトポロジをそれぞれのInter-AS Optionで繋ぐ例を紹介
AS α
Customers
PE1
© NTT Communications Corporation All Rights Reserved.
AS β
P1
PE/ASBR1
PE/ASBR2
P2
Customers
PE2
11
Inter-AS Option A
● AS間をCustomerごとのサブインターフェースで分割する⼿法
最もシンプルな⼿法
○
■
リモートASとはCEと同様の構成で接続
■
AS間は単純なIPパケットで転送
スケーラビリティは低い
○
■
AS間にCustomerの数だけサブインターフェースと経路共有（eBGP/IGP/Static Route等）が必要
AS α
SR domain
iBGP
PE1
16001
P1
16002
PUSH
TE label
VPN label
16003
24001
PE/ASBR1
16003
POP
Subinterface
per-VRF
POP
© NTT Communications Corporation All Rights Reserved.
24001
Payload
SR domain
iBGP
PE/ASBR2
16001
P2
16002
PUSH
VPN label
Payload
AS β
eBGP per-VRF
Payload
PE2
16003
POP
TE label
VPN label
16003
24002
POP
VPN label
Payload
24002
Payload
12
Inter-AS Option B
● ASBR間でVPN経路を広告、VPNラベルのSWAPでAS間を接続する⽅式
○
ASBRはVRFに紐づくインターフェースを持たないため、経路のRIB Installが不要
○
AS間は単⼀のインターフェースで接続可能
○
ASBR間もMPLS-VPNで接続。AS内のVPNとSWAPし、⼀連のVPNを構築
○
→ ASを分離し、疎結合に接続することでスケーラビリティの確保が可能
AS α
AS β
Inter-AS
MPLS domain
SR domain
Next-hop self
iBGP
PE1
16001
P1
16002
PUSH
TE label
VPN label
16003
24001
© NTT Communications Corporation All Rights Reserved.
24001
P2
16002
SWAP & PUSH
VPN label
Payload
iBGP
PE/ASBR2
16001
SWAP
VPN label
Payload
eBGP
PE/ASBR1
16003
POP
SR domain
24002
Payload
TE label
VPN label
16003
24002
PE2
16003
POP
POP
VPN label
Payload
24002
Payload
13
Inter-AS Option C
● フラットなdomainを構築しE2Eの到達性を担保
○
ASBR間でIGPとBGP-LS or BGP-LUでAS間の到達性を確保
○
RR間でVPN情報を交換。Option A, Option Bと異なり、ASBRにはVRFが不要
○
→ ASを超えた柔軟な経路制御が可能だが、複数のASを密結合に設計する必要あり
■
Global Unique空間の共有（Node SIDなど）
eBGP (VPN)
AS α
AS β
SR domain
iBGP
iBGP
eBGP（LinkState）
IGP
PE1
16001
PUSH
TE label
VPN label
16006
24002
IGP
P1/RR
16002
SWAP
Payload
© NTT Communications Corporation All Rights Reserved.
PE/ASBR1
16003
PE/ASBR2
16004
SWAP
TE label
VPN label
16006
24002
Payload
IGP
SWAP
TE label
VPN label
16006
24002
Payload
P2/RR
16005
IGP
POP
TE label
VPN label
16006
24002
PE2
16006
POP
VPN label
Payload
IP addr / SIDはASを超えたSR domainでGlobal Uniqueに設計
24002
Payload
14
Inter-AS Option D（AB）
● Option Aの抱えるスケーラビリティの課題を⼀部改善する⼿法
データ転送とeBGPセッション⽤のリンクを分割
○
■
Option Aと同様に、AS間はCustomerごとのサブインターフェースで分割しデータを転送
■
Option Bと同様に、Global VRFの単⼀BGPセッションで接続
→ BGPセッション数は削減。サブインターフェースによるスケーラビリティの制限は残る
○
AS α
AS β
SR domain
iBGP
PE1
16001
TE label
VPN label
16003
24001
PE/ASBR1
16003
POP
PE/ASBR2
16001
POP
© NTT Communications Corporation All Rights Reserved.
24001
Payload
P2
16002
PUSH
VPN label
Payload
iBGP
Global VRF for eBGP /
Subinterface per-VRF
P1
16002
PUSH
SR domain
eBGP
Payload
PE2
16003
POP
TE label
VPN label
16003
24002
POP
VPN label
Payload
24002
Payload
15
Inter-AS Optionの特徴と技術選定
● スケーラビリティの向上、Underlayの隠蔽が⽬的 = Option Bを選定
○
Option A: AS間に⼤量のサブインターフェースとBGPセッションが必要
○
Option B: ASごとに分離しつつ、AS間は単⼀のBGPセッションで実現可能
○
Option C: 柔軟な経路制御は可能だが、ASごとの情報分離が不可能
○
Option D(AB): BGPセッションの課題は改善されているが、サブインターフェースは⼤量に必要
● Option Cと異なり、Option BではE2Eでの真に最適なTEは難しい
○
LSDBがASごとに分離しているため、あるASのPEだけで最適経路を計算できない
○
→ Intent-basedなTEポリシーの接続により解決︕（次章で解説）
© NTT Communications Corporation All Rights Reserved.
16
Inter-AS Option BによるL3VPN（VPNv4/VPNv6）
● ASBRはAS内とAS間のVPNラベルを相互にSWAPしてVPNを接続
○
TEラベルはASごとにPUSH
○
3AS以上でも正しく接続可能なことを検証済︕
○
Route-Targetは慣例的にAS番号を埋め込むため⼯夫が必要
■
AS間で書き換え or 相互接続⽤のRTを利⽤
AS α
AS β
Inter-AS
MPLS domain
SR domain
Next-hop self
iBGP
PE1
16001
P1
16002
PUSH
TE label
VPN label
16003
24001
© NTT Communications Corporation All Rights Reserved.
24001
P2
16002
SWAP & PUSH
VPN label
Payload
iBGP
PE/ASBR2
16001
SWAP
VPN label
Payload
eBGP
PE/ASBR1
16003
POP
SR domain
24002
Payload
TE label
VPN label
16003
24002
PE2
16003
POP
POP
VPN label
Payload
Node SIDはAS内でUniqueであれば良い。横のASを気にせず設計可能
24002
Payload
17
Inter-AS Option BによるL2VPN（EVPN）
● 基本的な動作はL3VPNと同様
● 各ベンダ機能実装中の段階
Type-2経路（MAC Advertisement）に限られるなど制約あり
○
AS α
AS β
Inter-AS
MPLS domain
SR domain
Next-hop self
iBGP
PE1
16001
P1
16002
PUSH
TE label
VPN label
16003
24001
© NTT Communications Corporation All Rights Reserved.
24001
P2
16002
SWAP & PUSH
VPN label
Payload
iBGP
PE/ASBR2
16001
SWAP
VPN label
Payload
eBGP
PE/ASBR1
16003
POP
SR domain
24002
Payload
TE label
VPN label
16003
24002
PE2
16003
POP
POP
VPN label
Payload
24002
Payload
18
Multi-AS SR（VPN）のまとめ
● ASごとにSRドメインを分離し、Option BでVPN実装
○
Global Uniqueな情報（SID/IGP情報）を分離、スケーラビリティを確保︕
● AS間の接続の⾃由度も確保
○
AS間の繋がりはSRに依存しない、MPLS-VPNでVPN経路を交換するだけの疎結合
○
トランジットASを挟み、3AS以上での検証にも成功︕
IGP空間はASごとに閉じる。横のASに内部的な設定変更/障害影響を与えない
AS α
AS β
SR domain
PE1
16001
P1
16002
© NTT Communications Corporation All Rights Reserved.
Inter-AS
MPLS
PE/ASBR1
16003
PE/ASBR2
16001
AS γ
SR domain
P2
16002
Inter-AS
MPLS
PE2
16003
PE/ASBR2
16001
Node SIDはAS内でUniqueであれば良い。横のASを気にせず設計可能
SR domain
P2
16002
PE2
16003
19
Multi-AS SR - Traffic Engineering
© NTT Communications Corporation All Rights Reserved.
20
Inter-AS Option BのLSDBによるTEの限界
● Option BではPEがASを超えた最適経路を計算できない
○
SR domain/IGP情報をASごとに分離するため
○
Option-CであればIGP情報が混ざるため、PEが最適経路を計算可能
○
TE情報の集中と分散設計
PE1はAS α内のLinkStateしか持たないため、AS α内部のTEパスしか計算できない
AS β内部のTEはASBR3やASBR4のポリシーに依存する
AS α
AS β
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
Inter-AS
MPLS domain
SR domain
P1
16002
PE/ASBR1
16004
PE/ASBR3
16001
P3
16003
P2
16003
PE/ASBR2
16005
PE/ASBR4
16002
POP16004
P4
PE2
16005
21
Multi-AS構成におけるTE
● Multi-ASでのユースケースを満たすようなTEとは︖
○
この通信を帯域 X bps以上 / 遅延 X ms未満 で送りたい / 冗⻑系のうち1系をメインに送りたい
○
→ ある意図（Intent）に基づいたTEが構築できればOK
■
送信元PEでE2Eの最適経路計算を⾏う代わり、ASごとにIntentを満たす部分最適経路を構築し接続
■
ASごとのIntentは他ASへTEメニューとして提供
Intent情報を事前に共有、⼀連のTEを実現
Intentに基づく部分最適なTE α
Intentに基づく部分最適なTE β
AS α
AS β
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
Inter-AS
MPLS domain
SR domain
P1
16002
PE/ASBR1
16004
PE/ASBR3
16001
P3
16003
P2
16003
PE/ASBR2
16005
PE/ASBR4
16002
POP16004
P4
PE2
16005
22
（参考）Intent-based Networking
● 意図に基づいてネットワーキングを実現する概念
○
○
○
運⽤者が事前に定義した状態になるようネットワークを構築する
例: 障害が起きても、常に帯域X bpsを満たすようリルートされる経路
例: IGPコストではなく、常に遅延最⼩になるような経路
画像: https://blogs.cisco.com/networking/improving-networks-with-ai
© NTT Communications Corporation All Rights Reserved.
23
TEメニューの実現
● BGP Color Extended Communityを利⽤
○
○
TEメニュー（Intent）に対応するColorを定義、伝搬
Colorの値はTE区間 = SR domainに隠蔽
■
AS間では相互流通⽤のColorに変換、ASごとに値を変換しながら伝達
● 下記は極端な例だが、全区間でColorを変換している
Color = 300に紐づく
最短遅延パスを割当
iBGP
AS αのルールで
Color = 300に変換
Color: 300
eBGP
相互流通ルールの
Color = 1000に変換
Color: 1000
iBGP
Color: 200
AS α
AS β
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
最短遅延のIntentを指定したい
経路にColor = 200を付与
Inter-AS
MPLS domain
SR domain
P1
16002
PE/ASBR1
16004
PE/ASBR3
16001
P3
16003
P2
16003
PE/ASBR2
16005
PE/ASBR4
16002
POP16004
P4
PE2
16005
24
SR domain内でのTE実現⼿法の例
● TEには複数の⼿法が存在。管理のしやすさを考慮し⼿法を検討
●
Headend（PE/ASBR）がIntentを満たすように
TailendまでのSIDを積む⽅式（Explicit-Path/CSPF）
○ IntentはSegment ListとしてInstance化される
Explicit-Path 1: 16002/16005
Explicit-Path 2: 16002/16003/16005
Explicit-Path 3: 16003/16005
●
Intentを満たすFlex-Algoを定義し転送を⾏う⽅式
○ IntentはAlgorithmとしてInstance化される
Algorithm 128: exclude-all RED, IGP Metric
Algorithm 129: exclude-all RED, TE Metric
Algorithm 130: exclude-all GREEN, IGP Metric
AS α
AS α
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
P1
16002
P2
16003
PE/ASBR1
16004
PE/ASBR2
16005
SR domain
10, 100
PE1
16001
P1
16002
10, 100
10, 100
PE/ASBR1
16004
100, 10
10, 100
P2
16003
100, 10
10, 10
PE/ASBR2
16005
25
HeadendでSIDを積むパターン
● VPNのIngress PE = HeadendでIntentを満たすSegment Listを定義
○
Explicit-PathやCSPF計算など、PEの機能のみで実現
○
シンプルな⼿法だが、TE経路の増減に合わせてHeadendに詳細な設定が必要
Explicit-Path 1: 16002/16005
Explicit-Path 2: 16002/16003/16005
Explicit-Path 3: 16003/16005
AS α
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
P1
16002
PE/ASBR1
16004
P2
16003
PE/ASBR2
16005
26
Flex-Algoで転送するパターン（1/2）
● IGPの経路計算を柔軟に実現するため、経路計算⾯を仮想化・多重化する技術
○
○
分けたAlgorithmごとにトポロジを持ち、AlgoごとのMetric/制約で経路計算を実施
■
Affinity制約: bitmapなColor。Include(any/all), Excludeなどが選択可能
■
■
Metric: IGP Metric・TE Metric・DelayなどAlgorithmごとに設定可能
Disjoint Path: SRLG（Shared Risk Link Group）を考慮した冗⻑パスの有効利⽤
QoS保証をしつつルーズソースルーティングをする、などということが可能
B
100, 10
SR domain
Legend
100, 10
Color
A
10, 100
Algorithm 128: Exclude RED IGP Metric
A
D
C
© NTT Communications Corporation All Rights Reserved.
B
10
10
10
C
10
A
Algorithm 130: include-all Blue IGP Metric
10
D
10
C
Metric: IGP, TE
10, 100
Algorithm 129: Exclude GREEN TE Metric
B
100
D
10, 10
100
A
D
10
C
10
27
Flex-Algoで転送するパターン（2/2）
● Intentを満たす詳細な経路をStrictに指定せず、Algoに基づくLooseな指定が可能
○
Intent/SliceをAlgoの形で管理可能
○
Algo/Affinityは全ルータで正しく設定・認識される必要あり
Algorithm 128: exclude-all RED, IGP Metric
Algorithm 129: exclude-all RED, TE Metric
Algorithm 130: exclude-all GREEN, IGP Metric
AS α
SR domain
10, 100
PE1
16001
10, 100
10, 100
PE/ASBR1
16004
100, 10
10, 100
© NTT Communications Corporation All Rights Reserved.
P1
16002
P2
16003
100, 10
10, 10
PE/ASBR2
16005
28
SR domain内でのTE実現⼿法⽐較
●
HeadendがIntentを満たすSIDを積む⽅式
○ IntentはSegment ListとしてInstance化
●
Intentを満たすFlex-Algoを利⽤し転送を⾏う⽅式
○ IntentはAlgorithmとしてInstance化
●
●
pros: 中間に追加Stateは不要。PEのみで管理
cons: 網がIntentを持たないため、障害等で経路変更が
⽣じた場合、Intentが満たされなくなる可能性あり
●
●
pros: Intent数分のステートを網に設定する必要あり
cons: 障害時の経路変更後も、必ずIntentが満たされる
Explicit-Path 1: 16002/16005
Explicit-Path 2: 16002/16003/16005
Explicit-Path 3: 16003/16005
Algorithm 128: exclude-all RED, IGP Metric
Algorithm 129: exclude-all RED, TE Metric
Algorithm 130: exclude-all GREEN, IGP Metric
AS α
AS α
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
P1
16002
P2
16003
PE/ASBR1
16004
PE/ASBR2
16005
SR domain
10, 100
PE1
16001
P1
16002
10, 100
10, 100
PE/ASBR1
16004
100, 10
10, 100
P2
16003
100, 10
10, 10
PE/ASBR2
16005
29
ユースケースを満たすTE実装のまとめ
● ASごとにSR domainを分離しつつ、Intentに基づくTEの接続を実現
○
ASごとにLinkstateが隠蔽されるためE2Eの最適経路は計算できないが、Intentの形でTEを実現
○
AS間ではColorによる疎結合なTEの接続
○
AS内ではIntentに基づいたSegment Listの積み込みや、Flex-AlgoによるLooseな指定が可能
AS α
AS β
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
Inter-AS
MPLS domain
SR domain
P1
16002
PE/ASBR1
16004
PE/ASBR3
16001
P3
16003
P2
16003
PE/ASBR2
16005
PE/ASBR4
16002
POP16004
P4
PE2
16005
30
その他SR-MPLSの検証について
網の持つ機能の向上・充実
© NTT Communications Corporation All Rights Reserved.
31
その他のSR-MPLS関連技術検証
● より柔軟・⾼度なTEを⽬指し、下記4点をマルチベンダ環境で検証︕
○
Performance Measurement
■
○
EPE（Egress Peer Enginieering）
■
○
AS間もSR Policyによるを実現
SR PolicyによるIGPメトリックの上書き
■
○
遅延ベースのTEを実現
ASBRをSR Policyにより選択
FRR / TI-LFA
■
障害発⽣時も⾼速に復旧
© NTT Communications Corporation All Rights Reserved.
32
Performance Measurement
● SR Policyの接続性や遅延などを計測
○
https://datatracker.ietf.org/doc/html/draft-gandhi-spring-stamp-srpm
○
遅延が最⼩になるようなTEメニューを提供したい︕
● TWAMP（Two-Way Active Measurement Protocol）
○
https://datatracker.ietf.org/doc/html/rfc5357
○
タイムスタンプ付きのUDPパケットを利⽤し、遅延を計測するためのプロトコル
■
○
通常のTWAMPの他に、Client-Serverを省略したTWAMP Lightも存在
計測結果はIGP / BGP-LSに載せて広告可能
■
Flex-Algoとの組み合わせ、Delay MetricのIGP計算スライスを作成するなど
● P2P遅延とE2E遅延
○
P2P遅延: ある区間の遅延を計測する⼿法。IGPで集め、Metricとして利⽤
○
E2E遅延: ある経路の遅延を計測する⼿法。定義済みのSR Policyの評価などに利⽤
© NTT Communications Corporation All Rights Reserved.
33
Performance Measurementの活⽤例（P2P）
● P2P区間の遅延を集めてLinkstateとして広告、Metricとして利⽤
○
Delay MetricベースでのSegment List構築やFlex-Algoの定義など
AS α
SR domain
TWAMP
P1
PE/ASBR1
P2
PE/ASBR2
PE1
● Performance Measurementの課題
○
遅延の測定結果がベンダによりオーダーが違うほどの差
■
E2Eの遅延計算がリンク遅延の合計となると、正しく実情を反映できない
© NTT Communications Corporation All Rights Reserved.
34
Performance Measurementの活⽤例（E2E）
● 発⾏済みSegment Listを⽐較し、最適な経路を選択
○
実測値に基づいてSegment Listを選択可能
AS α
Explicit-Path 1: 16002/16005
Explicit-Path 2: 16002/16003/16005
Explicit-Path 3: 16003/16005
SR domain
TWAMP
PE1
16001
○
P1
16002
PE/ASBR1
16004
P2
16003
PE/ASBR2
16005
計測⼿法にはOne-way / Two-way / Loopbackの3種が存在
■
時刻同期の必要性や計測可能区間（⽚道/往復）、計測精度に違い
© NTT Communications Corporation All Rights Reserved.
35
EPE
● EPE (Egress Peer Engineering)
○
対向ASへの経路が複数ある場合にそのどちらかを選択するための技術
● SRでのEPE
○
○
Peer Adj SID / Peer Node SIDで対向を識別
https://datatracker.ietf.org/doc/html/rfc9086
AS α
SR
Segment List
24001
Payload
PE/ASBR 1のSID Table（⼀部）
Label
Action
Next
24000
POP
ASBR β
24001
POP
ASBR γ
...
...
...
eBGP Peerごとに発⾏された
domain
EPE Peer Adj SIDで処理
P1
PE/ASBR1
ASBR β
P2
PE/ASBR2
ASBR γ
AS β
PE1
AS γ
© NTT Communications Corporation All Rights Reserved.
36
Egress/Egress Peer周りのTEについて
● 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なども必要
AS α
AS β
SR domain
P1
PE/ASBR1
ASBR β1
P2 / RR
PE/ASBR2
ASBR β2
PE1
© NTT Communications Corporation All Rights Reserved.
37
Inter-AS部分のTE設計の難しさ
1. Head-endから⾒た時のASBRの選択⽅法が難しい
○
PE1はASBR1/2どちらに送るか、先のLinkstateが⾒えないのでマクロな判断が不可
■
■
BGP attribute（LP等）での制御は可能
SR-TEのメトリクスによるASBR選択も⼀部ベンダでは可能
2. EPE/VPNの同時利⽤問題
○
Egressでのラベルの2枚消費が不可能。EPEとVPNラベルを兼ねる機能も検討されていそうだが...
AS α
AS β
SR domain
課題① IngressはEgressから先のLinkstateを持たないため、
冗⻑なEgressの選択材料がない
P1
PE/ASBR1
ASBR β1
P2 / RR
PE/ASBR2
ASBR β2
PE1
EPE label VPN label
16003
© NTT Communications Corporation All Rights Reserved.
24001
Payload
課題② EgressでEPEラベルとVPNラベルの同時処理が不可能
38
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/
© NTT Communications Corporation All Rights Reserved.
39
Inter-AS Option BとFRR/TI-LFAの課題
● Inter-AS部分の保護ができず、真のE2E FRRは不可能
○
TI-LFAはIGP前提の技術であるため、Option-BではASを超えて使⽤できない
Inter-AS区間にはIGPが存在しないため、
FRRでの保護は不可能
AS α
AS β
SR domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
Inter-AS
MPLS domain
SR domain
P1
16002
PE/ASBR1
16004
PE/ASBR3
16001
P3
16003
P2
16003
PE/ASBR2
16005
PE/ASBR4
16002
POP16004
P4
PE2
16005
40
その他のSR-MPLS関連技術検証のまとめ
● ⾼度なTEを実現するため、様々な技術を検証
○
Performance Measurement: 遅延ベースIntentの実現
○
EPE（Egress Peer Enginieering）: AS間部分のTEを実現
○
SR PolicyによるIGPメトリックの上書き: ASBR選択を実現
○
FRR / TI-LFA: 障害発⽣時の⾼速迂回（Local Repair）
● → これらの技術について、マルチベンダでの検証を実施済
© NTT Communications Corporation All Rights Reserved.
41
SR-MPLS / SRv6相互接続
Service Function Chainingの活⽤
© NTT Communications Corporation All Rights Reserved.
42
（再掲）作りたいネットワーク
● マルチAS/マルチドメインなSegment Routing
○
SRv6も⼀つのASとしてOption Bで接続︕
AS
SR-MPLS domain
Customer
CE
PE
Network
Function
Customer
P
PE
CE
Customer
PE/ASBR
CE
Inter-AS
MPLS
SFC
Proxy
PE/ASBR
PE
Customer
CE
Customer
PE
P
SRv6 domain
AS
© NTT Communications Corporation All Rights Reserved.
Interwork
ASBR
PE/ASBR
Inter-AS
MPLS
P
SR-MPLS domain
AS
PE/ASBR
PE/ASBR
Inter-AS
MPLS
P
PE
CE
SR-MPLS domain
AS
43
SRv6を利⽤・検証するモチベーション
● Service Function Chainingの導⼊
○
網への付加価値提供
○
Option BのASとして参加し、SFCを提供する網として設計︕
● SRv6の実装状況調査・機能検証
○
○
SRv6の技術検証のため、SRv6内でのTE/VPNのフィールド検証も兼ねてASを設計
■
SRv6 FunctionによるVPN・SFCの検討
■
C-Plane検証
SRv6のユースケース検討
■
SFCのユースケース
■
既存のIPv6網を活⽤︓将来的な商⽤網のマイグレーション難易度を下げる︖
© NTT Communications Corporation All Rights Reserved.
44
Service Function Chaining
● Service Function Chaining
○
TEの応⽤技術の⼀つ
■
○
NW上の機能を特定の順番でつなぎ、サービスとして提供する技術
■
○
https://datatracker.ietf.org/doc/html/rfc7665
ある通信に付加価値を提供することが可能
⽇本語ではサービスチェイニングと呼ぶことが多い
CGN
Firewall
Optimizer
DPI
Service Chain A
Service Chain B
Customer A
© NTT Communications Corporation All Rights Reserved.
Customer B
Dst.
45
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⽅式が提案
SR domain
PE 1
PE 2
End.AM
1. Segment Leftを1つ進め（End）
Destination AddressをSegment List [0]（末尾）で上書き
© NTT Communications Corporation All Rights Reserved.
SFF /
SR Proxy
Function
3. Destination AddressをSegment List [Segment Left]
（本来の先頭要素）で上書き、SRv6による転送を再開
2. Network Functionは正しく最終的なDestinationが
指定されたIPv6パケットを受け取る（拡張ヘッダは無視）
46
SFCの良い使い⽅とは︖
● 単なるSecurity Functionの提供ではメリットがない
○
Functionを利⽤者の⼿元（エッジ）に置く⽅が効率的な場合が存在
■
○
SRの⽴場としては、将来的にはSR対応のFunctionが欲しい
■
○
経路をねじ曲げて無駄に遅延をかける理由がない
Node SIDで指定するとInlineにFunctionを適⽤するようにして欲しい
→ これらがEnd.A系のFunction実装が盛り上がらない理由
■
ただし業界的にはSR対応のFunctionが開発されているわけではない
● SFCの良い使い⽅︖
○
① Streaming処理でFunctionを適⽤
■
①はSFC Proxyとの相性が悪い。Streamingと経路のねじ曲げの相性問題
●
○
その上Multi-AS構成でAS的にねじ曲げて引き込むと考えると...?
② 同⼀の機材を複数のCustomerで利⽤し、規模の経済を実現
■
ユースケース次第。SFC Proxy等を設定し、通信の途中に⼊れてまで利⽤したいFunctionがあるか
© NTT Communications Corporation All Rights Reserved.
47
2021/12時点で検討しているSFCのユースケース
● 全社に先⾏した新機能や最新機材の検証
○
SRv6網で最新機能を検証
○
他ASは気軽に接続しサービスを検証、良さそうなら⾃らのAS内部に取り込み
■
○
Security appliance、Load balancer、CGN、NFV基盤...
全社に先駆けて検証を⾏うR&D部⾨ならではの強み
● 構築、運⽤の⼿間を削減した隣接ASへのサービス提供
○
C-Planeを活⽤した拡張性の⾼い相互接続
○
チェインを含めたTEポリシーとして隣接ASに公開するなど、利⽤しやすいSFCメニューの提供
© NTT Communications Corporation All Rights Reserved.
48
SRv6/SR-MPLS相互接続の課題
● SR-MPLSのCustomer同⼠の通信にSFCを提供することを考える
○
シンプルなIP Forwardingだけでは折り返しは実現できない
■
SR-MPLSのSFCもdraftで議論されているが、折り返し可能な実装はない
192.168.0.0/24
Network
Function
同じ192.168.1.0/24宛のVPN経路を、
⾏きはSRv6⽅向に転送し、
戻りはSR-MPLS⽅向に転送する︖
SFC Proxy
Customer
CE1
PE1
192.168.1.0/24
Customer
SRv6 PE
SRv6 P
SRv6 domain
© NTT Communications Corporation All Rights Reserved.
Interwork
ASBR
ASBR
Inter-AS MPLS
P
PE2
CE2
SR-MPLS domain
49
解決策: ルーティング⾯の分割（1/2）
● ⾏きと戻りでルーティングを分割すれば実現可能
○
⾏きのTrafficを処理するノードと帰りのTrafficを処理するノードを⽤意
192.168.0.0/24
Customer
Network
Function
CE1
SFC Proxy
PE1
192.168.1.0/24
Interwork
ASBR
SRv6 PE
P
SRv6 P
Interwork
ASBR
SRv6 domain
© NTT Communications Corporation All Rights Reserved.
Customer
ASBR
PE2
CE2
ASBR
Inter-AS MPLS
SR-MPLS domain
50
解決策: ルーティング⾯の分割（2/2）
● ルーティング⾯の分割をVRFで実現
○
送信⽤、受信⽤のVRFを⽤意し、経路を分離
VRF cust-a-rcv
rt export 65001:1
VRF cust-a-snd
rt import 65001:101
192.168.0.0/24
Customer
Network
Function
CE1
SFC Proxy
PE1
VPN label（cust-a-snd）
192.168.1.0/24
Customer
SRv6 PE
SRv6 P
Interwork
ASBR
ASBR
P
PE2
CE2
End.DT6（cust-a-snd）
SRv6 domain
© NTT Communications Corporation All Rights Reserved.
Inter-AS MPLS
SR-MPLS domain
51
SR-MPLS、SRv6相互接続⼿法の課題
● SR-MPLS側 ASBRへの影響（後述）
○
SR-MPLS側にも接続⽤VRFを設定する必要
■
例えばiBGP由来のSend⽤ラベルとeBGP由来のRecv⽤ラベルをGlobal VRFだけで併⽤できれば解決
●
iBGP/eBGP由来のVPNラベルを同時にLFIB installする⽅法︖
● VRF/Route-Target 数の増加
○
Customer x2の数だけVRFを⽤意しなければならない...
○
Send/Recv⽤にGlobalなVRFを作成し、それぞれBGP sessionを貼る改善案も検討中
■
CustomerごとのSend/RecvのVRFは不要になる
■
Recv⽤に専⽤のVRF/RTを⽤意する必要がなくなり、スケーラビリティが向上するはず
© NTT Communications Corporation All Rights Reserved.
52
（補⾜）SR-MPLS側のInterwork ASBRについて
● MPLSはラベルによる転送⼿法であるため、折り返しの実現可能性あり
○
⾏きを⽰すラベルと帰りを⽰すラベルを別に⽤意、それぞれを指定する
■
現時点では、単⼀のVRFでeBGP/iBGPで学習した経路を同時にLFIB Installする実装がないため断念
192.168.0.0/24
Network
Function
Customer
ASBRのMPLS Table（⼀部）
Label
Action
Next
24000
SWAP 24000
SRv6へ
24001
SWAP 24000 SR-MPLSへ
...
...
...
SFC Proxy
CE1
PE1
VPN label
24000
Payload
192.168.1.0/24
Customer
SRv6 PE
SRv6 P
Interwork
ASBR
ASBR
24001
SRv6 domain
© NTT Communications Corporation All Rights Reserved.
Inter-AS MPLS
P
PE2
CE2
Payload
SR-MPLS domain
53
SRv6 - SR-MPLS相互接続検証まとめ
● SRv6の⼀つのユースケースであるService Funtion Chainingを導⼊
○
網への付加価値提供が可能
○
Option BのASとして参⼊し、SR-MPLSにもSFCを提供
■
作成したASはマルチベンダにSRv6を検証する網としても活⽤
● SR-MPLS - SRv6 - SR-MPLS折り返しのための⼿法を提案
○
折り返しの結果、SR-MPLS網にSFCの提供に成功
© NTT Communications Corporation All Rights Reserved.
54
SRv6 AS内部について
● SRv6の機能検証を⾏うASとしても設計、検証を実施
○
○
○
SRv6 FunctionによるVPN/TE（Flex-Algo）/ SFCの検証
SRv6⾮対応ノードのTransit活⽤
マルチベンダSRv6
● 複数の拠点にまたがる網を1つのASとして設計
○
将来的にはIPv6の性質を⽣かし、AS/拠点/Algo単位で階層化されたMulti-AS通信なども可能︖
Customer A
Network
Function
PE / SFC Proxy
SR domain
P
Site A
Site B
P
P
PE
Customer A
© NTT Communications Corporation All Rights Reserved.
Customer B
P
Site C
PE
Customer B
Customer A
Customer B
55
SRv6のSID設計案
● 基本的に可変⻑かつ⾃由（ただし⼀部の実装は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の⾃動払い出し
SID設計の例。2001:db8::/32 を利⽤し設計を実施
例では255拠点で、拠点ごとに65535ノードが収容可能になる
LocatorはASの持つPrefixや⾮SR網のアドレスブロック、
Function/ArgumentはSRv6の⽤途と相談して設計する
拠点ID（拠点1）
Algo内のindex
パラメータ2
2001:db8:180:1:1:4:1:a
Flex-Algo ID (128)
© NTT Communications Corporation All Rights Reserved.
Function Sub-ID
Function ID
パラメータ1
56
（参考）SR-MPLSとSRv6の⽐較
● SR-MPLS側の利点
○
SR-MPLSの⽅が先に実装が始まっているため、SRv6に⽐べ実装状況が良い
■
○
MPLS-VPNなど、MPLSの既存アーキテクチャもそのまま活⽤できる
SRv6に⽐べSIDサイズが⼩さい（SRv6 128bitに対しSR-MPLSは32bit）
● SRv6側の利点
○
128bitのSIDを活かして様々な動作を⾏うSRv6 Functionの存在、⾼い拡張性
○
SRv6に対応していない網も、IPv6さえ対応していれば⼟管として使⽤可能
■
仮に間にインターネットが挟まっていても、IPv6さえあれば転送可能
© NTT Communications Corporation All Rights Reserved.
57
SRv6活⽤のまとめ
● Service Function Chainingによる付加価値提供
○
R&D部⾨としてのNetwork Function検証、PoCの場として検討中
● Option Bで⼀つのASとして実現
○
疎結合なMulti-AS構成の利点
○
SR-MPLS網にSFCを提供
■
SR-MPLSには現状SFC実装がないので、折り返しに⼯夫が必要
● SRv6機能検証の場としてもASを活⽤中
© NTT Communications Corporation All Rights Reserved.
58
Future Work
© NTT Communications Corporation All Rights Reserved.
59
Future work
● PCEの活⽤
● セルフマネージポータルの開発
● より⾼度なTEの実現
● SRv6のさらなる活⽤
© NTT Communications Corporation All Rights Reserved.
60
PCE（Path Computation Element）
● 中央集権的に経路計算を実⾏するノード
○
複雑なポリシーの適⽤や経路計算、発⾏済みのLSP管理などを実現
○
○
遅延、トラフィック分散、Affinity制約などの複雑なTEの実現、SDN的なアプローチ
Stateful PCEによる発⾏済みのパスの管理や、可視化との相性、マルチドメインの集中管理
● → 集中的な網の管理や複雑な経路計算などに威⼒を発揮
Path情報（MPLSではLSP）の計算
トポロジ変更時の処理
(BGP Triggered Update)
経路(PCE)⽣成時の処理
PCE
LinkStateの共有
Router
(PCC)
© NTT Communications Corporation All Rights Reserved.
Path情報の伝達
Router
Router
(PCC)
61
Stateful PCEとStateless PCE
●
Stateless PCE: 発⾏済みのLSP/Segment Listを管理するPCE
○
●
PCReqに対応した経路を発⾏し、PCRepを返すだけ
Stateful PCE: 発⾏済みのLSP/Segment Listを管理しないPCE
○
経路変更などが⽣じた際、PCE側からPCCに能動的に経路変更が可能
○
新規LSPの確⽴（PCInitiate）、既存LSPの経路変更（PCUpd）など
○
ポータル等と組み合わせ、発⾏済みLSPの可視化等が可能
PCE
画像: https://www.slideshare.net/TakuyaMiyasaka/pce-mplssdn
© NTT Communications Corporation All Rights Reserved.
62
（参考）SRの帯域保証について
● SRのIGP機能だけではRSVP-TEのような帯域保証はできない
○
帯域を確保するシグナリングプロトコルを利⽤しないため
● Stateful PCE機能を備えたコントローラを⽤いることで可能となる
○
○
既存Segment Listの情報を管理することで帯域を管理
Telemetry等と組み合わせた機器情報管理と相性
● PCEを使わない場合の帯域保証も提案
○
SRでもRSVP-TEのような仕組みを使う
■
https://datatracker.ietf.org/doc/html/rfc8403
© NTT Communications Corporation All Rights Reserved.
63
マルチASなPCEの連携
● マルチASなPCEの効率的な設計、運⽤は難しい
○
○
○
集中と分散を考慮した設計
Linkstateを⼀元管理することで真のE2E最適は満たせるが、Option C的な情報管理となる
Option B的に情報を分離しつつ、E2E最適を満たすための仕組みを導⼊する︖
ASごとにPCEを配置する場合はOption B的な運⽤、
ASを超えてPCEに管理させる場合はOption C的な運⽤となる︖
マルチAS対応のものも出ているので、ベンダ実装を検証中
AS α
AS β
SR domain
PCE
SR domain
LinkStateや発⾏済みSegment Listの共有︖
PCE
Inter-AS
MPLS domain
PE1
16001
© NTT Communications Corporation All Rights Reserved.
P1
16002
PE/ASBR1
16004
PE/ASBR3
16001
P3
16003
P2
16003
PE/ASBR2
16005
PE/ASBR4
16002
POP16004
P4
PE2
16005
64
セルフマネージポータルとの組み合わせ
● マルチAS環境のセルフマネージ化
○
ユーザが⼿元のASから対向のASを操作、PCEとも好相性
○
ASを超えた制御に課題
■
横のASをオンデマンドに操作して良い︖
●
■
双⽅向なTEを考えると、対向ASのPEにもSR Policyを与える必要...?
TEメニューの提供⽅法や課⾦⼿法などが課題になるか
© NTT Communications Corporation All Rights Reserved.
https://onic.jp/_cms/wp-content/uploads/2019/11/onic2019_tajima.pdf
65
リアルタイムな監視技術の活⽤
● リアルタイムな情報と組み合わせ、より⾼度なTEを実現
○
リアルタイムな流量や帯域をベースにした最適化
○
故障予測と回避など
○
TelemetryやxFlowなど、様々な監視情報と組み合わせる
■
Telemetry技術検証について: https://engineers.ntt.com/entry/2021/09/02/162022
■
Service Function Chainingもパケットの監視⼿法として活躍できるかも
Telemetry情報から得たリンクの統計情報や、
コントローラで実施した機器の故障予測などを元にSegment Listを更新
PCE
Telemetry
Collector
Segment Listの更新
AS α
SR domain
Telemetry
P1
PE/ASBR1
P2
PE/ASBR2
PE1
© NTT Communications Corporation All Rights Reserved.
66
SRv6のさらなる活⽤
● 既存IPv6網の活⽤
○
○
⾮対応網を取り込んでおいて、少しずつSRv6化する︖
■
対応したところからTEができるようになるのは⾯⽩い
■
エッジ間でVPNを貼っておき、将来的にTEもできるようになるというのもgood
■
間に別のIPv6網が⼊るとアドレス設計をうまくできなくなるのが課題
運⽤中の網におけるマイグレーション︖
■
1. 既存網にSRv6網を接続
●
■
2. 既存網の⼀部をSRv6化する
●
■
SFCや固有Functionなどで付加価値提供
例えばエッジ部分をSRv6化し、⾮対応ノードをVPNの⼟管として利⽤
3. 既存網全体をSRv6化し、SRの適⽤範囲を拡⼤していく
●
© NTT Communications Corporation All Rights Reserved.
少しずつ参加するASを増やせるのもMulti-AS構成の強み
67
まとめ
● Multi-AS Segment Routingの提案
○
○
スケーラビリティの向上
■
ASごとのリソース分離・Intentに基づいたTEメニューの設計・集中と分散のバランス
■
疎結合なMulti-AS構成により新たな網の追加も容易に。SRv6も1つのASとして検証中
新たなユースケースの獲得
■
拠点ごとのAS設計
■
管理者の異なるASのつなぎ合わせ
■
SFCの活⽤
■
→ 将来的なネットワーク設計の⼀つの姿
SR-MPLS
CE
● ⼀緒に取り組む仲間を募集中
○
是⾮継続して議論しましょう
CE
PE
P
Network
Function
PE/ASBR
SFC
Proxy
PE/ASBR
P
SRv6
© NTT Communications Corporation All Rights Reserved.
PE
PE
CE
CE
Interw ork
ASBR
PE/ASBR
P
SR-MPLS
PE
PE/ASBR
PE/ASBR
P
PE
CE
SR-MPLS
68
© NTT Communications Corporation All Rights Reserved.