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

マルチAS/マルチドメインなSegment Routingの実現

マルチAS/マルチドメインなSegment Routingの実現

- Multi-AS Segment Routingの考案背景と利点の解説
- Inter-AS Option (A/B/C/D)の解説
- その他TE/VPN技術の紹介
 - Color-based TE, Flex-Algo, SR policyによるASBR選択, Performance Measurement (TWAMP), EPE, FRR/TI-LFA, SRv6/SR-MPLS相互接続, SFC

Wataru MISHIMA

December 03, 2021
Tweet

More Decks by Wataru MISHIMA

Other Decks in Technology

Transcript

  1. © NTT Communications Corporation All Rights Reserved.
    マルチAS/マルチドメインなSegment Routingの実現
    2021/12/3
    イノベーションセンター 三島 航

    View Slide

  2. © NTT Communications Corporation All Rights Reserved. 2
    ● マルチAS/マルチドメインなSegment Routing
    ○ 背景: NTT ComのSR活⽤事例と課題
    ○ 新たな要求とユースケース
    ○ Multi-AS SRについて
    ■ E2E TEとスケーラビリティのバランス(集中と分散)
    ● SR-MPLS/SRv6相互接続
    ○ Service Function Chainingの活⽤
    ● Future Work
    ○ PCEの活⽤
    ○ VPN/TEのセルフマネージ化
    ○ より⾼度なTEの実現
    ○ SRv6のさらなる活⽤
    CE CE
    Interwork
    ASBR
    P PE/ASBR PE/ASBR
    P
    PE/ASBR
    SFC
    Proxy
    Network
    Function
    PE PE/ASBR PE
    P
    PE
    CE
    CE
    PE PE
    P
    PE/ASBR
    CE
    SR-MPLS
    SR-MPLS SR-MPLS
    SRv6
    ⽬次

    View Slide

  3. © NTT Communications Corporation All Rights Reserved. 3
    マルチAS/マルチドメインなSegment Routing
    NTT ComのSR活⽤事例と課題

    View Slide

  4. © NTT Communications Corporation All Rights Reserved. 4
    Customer
    CE CE
    Customer
    Customer
    AS
    AS
    SR-MPLS domain
    Inter-AS
    MPLS
    作りたいネットワーク
    Interwork
    ASBR
    P
    SRv6 domain
    PE/ASBR PE/ASBR
    P
    PE/ASBR
    SFC
    Proxy
    Network
    Function
    SR-MPLS domain
    PE PE/ASBR PE
    P
    PE
    CE
    CE
    SR-MPLS domain
    Customer
    Inter-AS
    MPLS
    PE PE
    P
    PE/ASBR
    AS
    AS
    Inter-AS
    MPLS
    CE
    Customer
    ● マルチAS/マルチドメインなSegment Routing
    ○ なぜ必要か、どう作るかを説明して⾏きます

    View Slide

  5. © NTT Communications Corporation All Rights Reserved. 5
    Customer
    CE CE
    Customer
    Customer
    AS
    AS
    ● まずはMulti-AS SR-MPLSから︕
    SR-MPLS domain
    Inter-AS
    MPLS
    Multi-AS SR-MPLSについて
    Interwork
    ASBR
    P
    SRv6 domain
    PE/ASBR PE/ASBR
    P
    PE/ASBR
    SFC
    Proxy
    Network
    Function
    SR-MPLS domain
    PE PE/ASBR PE
    P
    PE
    CE
    CE
    SR-MPLS domain
    Customer
    PE PE
    P
    PE/ASBR
    AS
    AS
    Inter-AS
    MPLS
    CE
    Customer
    Inter-AS
    MPLS

    View Slide

  6. © NTT Communications Corporation All Rights Reserved. 6
    NTT ComとSegment Routing(2018〜)
    ● SR-MPLSを活⽤した全社的な商⽤インフラを構築・運⽤中
    ○ Customerごとにスライスを提供
    ○ SR網のみでのL2VPN / L3VPN提供
    ■ 要件と当時の実装状況を考慮し、SR-MPLS + MP-BGP(VPNv4/v6、EVPN)を選定
    ○ 過去の対外発表
    ■ SR-MPLSの導⼊事例と今後の展望について(MPLS JAPAN 2019)
    ● https://mpls.jp/2019/presentations/MPLS-Japan2019_NTTcom.pdf
    ■ ユーザによるセルフマネージ可能なネットワークサービス運⽤システムの事例(ONIC 2019)
    ● https://onic.jp/_cms/wp-content/uploads/2019/11/onic2019_tajima.pdf
    ■ マルチベンダASかつマルチベンダにおけるSR-MPLS TEの実現(MPLS JAPAN 2021)
    ● https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf

    View Slide

  7. © NTT Communications Corporation All Rights Reserved. 7
    ● SR-MPLSをより⼤規模に構成したい︕
    ○ 例として下記のようなユースケースを検討中
    ○ 複数拠点に跨がるSR-MPLS網の⼤規模展開
    ○ 複数の運⽤者の持つネットワークの相互接続
    ■ (参考)Docomo・NTT Com・NTTコムウェアの組織統合
    ● https://www.nttdocomo.co.jp/info/news_release/2021/10/25_00.html
    ○ 複数の機能を持つネットワーク同⼠の接続
    ■ コア網・アクセス網・データセンタなど
    実現したいこと(2021〜)

    View Slide

  8. © NTT Communications Corporation All Rights Reserved. 8
    Single-AS構成で⽣じる課題
    1. Global Unique空間の共有
    ○ ⽤途や管理者ごとにレベル/エリアの分割は可能だが、IP空間は共有する必要あり
    ○ SIDのindexも単⼀のSR domainでUniqueに管理、NW同⼠が密結合になる
    2. ある設定や障害の影響範囲が全体に及ぶ
    ○ フラットな単⼀ネットワーク設計はスケーラビリティの⾜枷となる
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16006
    ⽤途 β のNW
    ⽤途 α のNW
    PE1
    16001
    PE/ASBR2
    16005
    P2
    16003
    PE/ASBR4
    16007
    SR domain
    P3
    16008
    P/SFF1
    16009
    PE2
    16010
    Single-AS
    障害情報の伝搬
    IP addr / SIDはSR domainでGlobal Uniqueに設計しなければならない

    View Slide

  9. © NTT Communications Corporation All Rights Reserved. 9
    ● マルチASにネットワークを設計、各ASでSRを利⽤し相互接続
    ○ ASごとのリソース分離によるスケーラビリティ向上・新規ユースケースの創出︕
    ■ 既存網同⼠の相互接続によるサービス連携、リソースの有効活⽤
    ■ SR domainの範囲、LSDBの共有⽅法、TEの実現⽅法などで形態が実現可能
    ■ SR-MPLS-SRv6 Interworkなど、新たな価値の提供
    提案: Multi-AS Segment Routing
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    PE/ASBR2
    16005
    P2
    16003
    PE/ASBR4
    16002
    SR domain
    P3
    16003
    P/SFF1
    16004
    PE2
    16005
    UnderlayをASごとに隠蔽、IP addr / SIDはSR domainを⾃由に設計︕
    障害影響もAS内に閉じる
    Inter-AS
    MPLS

    View Slide

  10. © NTT Communications Corporation All Rights Reserved. 10
    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

    View Slide

  11. © NTT Communications Corporation All Rights Reserved. 11
    Inter-AS Option
    ● Multi-AS MPLS-VPNでは複数の接続オプションが提案済(RFC4364)
    ○ 実現⽅式により、Option A, B, Cの3種に分類
    ■ Option AとBを組み合わせたOption D(AB)も提案
    ○ それぞれのOptionにPros/Consが存在
    PE/ASBR1
    P1 PE/ASBR2
    AS β
    AS α
    PE1 P2 PE2
    以降のページで、下記のトポロジをそれぞれのInter-AS Optionで繋ぐ例を紹介
    Customers Customers

    View Slide

  12. © NTT Communications Corporation All Rights Reserved. 12
    Inter-AS Option A
    ● AS間をCustomerごとのサブインターフェースで分割する⼿法
    ○ 最もシンプルな⼿法
    ■ リモートASとはCEと同様の構成で接続
    ■ AS間は単純なIPパケットで転送
    ○ スケーラビリティは低い
    ■ AS間にCustomerの数だけサブインターフェースと経路共有(eBGP/IGP/Static Route等)が必要
    SR domain
    PE/ASBR1
    16003
    P1
    16002
    PE/ASBR2
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P2
    16002
    PE2
    16003
    eBGP per-VRF
    iBGP
    POP
    iBGP
    24001 Payload
    16003
    VPN label
    TE label
    PUSH POP
    Payload 24002 Payload
    VPN label
    24001 Payload
    VPN label
    PUSH
    24002 Payload
    16003
    VPN label
    TE label
    Subinterface
    per-VRF
    POP POP

    View Slide

  13. © NTT Communications Corporation All Rights Reserved. 13
    Inter-AS Option B
    ● ASBR間でVPN経路を広告、VPNラベルのSWAPでAS間を接続する⽅式
    ○ ASBRはVRFに紐づくインターフェースを持たないため、経路のRIB Installが不要
    ○ AS間は単⼀のインターフェースで接続可能
    ○ ASBR間もMPLS-VPNで接続。AS内のVPNとSWAPし、⼀連のVPNを構築
    ○ → ASを分離し、疎結合に接続することでスケーラビリティの確保が可能
    SR domain
    PE/ASBR1
    16003
    P1
    16002
    PE/ASBR2
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P2
    16002
    PE2
    16003
    eBGP
    iBGP
    POP
    Inter-AS
    MPLS domain
    iBGP
    Next-hop self
    24001 Payload
    16003
    VPN label
    TE label
    PUSH SWAP
    24002 Payload
    VPN label
    24002 Payload
    VPN label
    24001 Payload
    VPN label
    SWAP & PUSH
    24002 Payload
    16003
    VPN label
    TE label
    POP POP

    View Slide

  14. © NTT Communications Corporation All Rights Reserved. 14
    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など)
    PE/ASBR1
    16003
    P1/RR
    16002
    PE/ASBR2
    16004
    AS β
    AS α
    PE1
    16001
    SR domain
    P2/RR
    16005
    PE2
    16006
    iBGP
    SWAP
    iBGP
    24002 Payload
    16006
    VPN label
    TE label
    PUSH SWAP
    24002 Payload
    VPN label
    24002 Payload
    VPN label
    24002 Payload
    VPN label
    SWAP
    24002 Payload
    16006
    VPN label
    TE label
    POP POP
    16006 16006
    TE label
    TE label
    eBGP(LinkState)
    eBGP (VPN)
    IGP IGP
    IGP IGP
    IP addr / SIDはASを超えたSR domainでGlobal Uniqueに設計

    View Slide

  15. © NTT Communications Corporation All Rights Reserved. 15
    Inter-AS Option D(AB)
    ● Option Aの抱えるスケーラビリティの課題を⼀部改善する⼿法
    ○ データ転送とeBGPセッション⽤のリンクを分割
    ■ Option Aと同様に、AS間はCustomerごとのサブインターフェースで分割しデータを転送
    ■ Option Bと同様に、Global VRFの単⼀BGPセッションで接続
    ○ → BGPセッション数は削減。サブインターフェースによるスケーラビリティの制限は残る
    SR domain
    PE/ASBR1
    16003
    P1
    16002
    PE/ASBR2
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P2
    16002
    PE2
    16003
    eBGP
    iBGP
    POP
    iBGP
    24001 Payload
    16003
    VPN label
    TE label
    PUSH POP
    Payload 24002 Payload
    VPN label
    24001 Payload
    VPN label
    PUSH
    24002 Payload
    16003
    VPN label
    TE label
    POP POP
    Global VRF for eBGP /
    Subinterface per-VRF

    View Slide

  16. © NTT Communications Corporation All Rights Reserved. 16
    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ポリシーの接続により解決︕(次章で解説)

    View Slide

  17. © NTT Communications Corporation All Rights Reserved. 17
    Inter-AS Option BによるL3VPN(VPNv4/VPNv6)
    ● ASBRはAS内とAS間のVPNラベルを相互にSWAPしてVPNを接続
    ○ TEラベルはASごとにPUSH
    ○ 3AS以上でも正しく接続可能なことを検証済︕
    ○ Route-Targetは慣例的にAS番号を埋め込むため⼯夫が必要
    ■ AS間で書き換え or 相互接続⽤のRTを利⽤
    SR domain
    PE/ASBR1
    16003
    P1
    16002
    PE/ASBR2
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P2
    16002
    PE2
    16003
    eBGP
    iBGP
    POP
    Inter-AS
    MPLS domain
    iBGP
    Next-hop self
    24001 Payload
    16003
    VPN label
    TE label
    PUSH SWAP
    24002 Payload
    VPN label
    24002 Payload
    VPN label
    24001 Payload
    VPN label
    SWAP & PUSH
    24002 Payload
    16003
    VPN label
    TE label
    POP POP
    Node SIDはAS内でUniqueであれば良い。横のASを気にせず設計可能

    View Slide

  18. © NTT Communications Corporation All Rights Reserved. 18
    Inter-AS Option BによるL2VPN(EVPN)
    ● 基本的な動作はL3VPNと同様
    ● 各ベンダ機能実装中の段階
    ○ Type-2経路(MAC Advertisement)に限られるなど制約あり
    SR domain
    PE/ASBR1
    16003
    P1
    16002
    PE/ASBR2
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P2
    16002
    PE2
    16003
    eBGP
    iBGP
    POP
    Inter-AS
    MPLS domain
    iBGP
    Next-hop self
    24001 Payload
    16003
    VPN label
    TE label
    PUSH SWAP
    24002 Payload
    VPN label
    24002 Payload
    VPN label
    24001 Payload
    VPN label
    SWAP & PUSH
    24002 Payload
    16003
    VPN label
    TE label
    POP POP

    View Slide

  19. © NTT Communications Corporation All Rights Reserved. 19
    SR domain
    AS β
    Inter-AS
    MPLS
    ● ASごとにSRドメインを分離し、Option BでVPN実装
    ○ Global Uniqueな情報(SID/IGP情報)を分離、スケーラビリティを確保︕
    ● AS間の接続の⾃由度も確保
    ○ AS間の繋がりはSRに依存しない、MPLS-VPNでVPN経路を交換するだけの疎結合
    ○ トランジットASを挟み、3AS以上での検証にも成功︕
    SR domain
    PE/ASBR1
    16003
    P1
    16002
    PE/ASBR2
    16001
    AS γ
    AS α
    PE1
    16001
    SR domain
    P2
    16002
    PE2
    16003
    Inter-AS
    MPLS
    Node SIDはAS内でUniqueであれば良い。横のASを気にせず設計可能
    IGP空間はASごとに閉じる。横のASに内部的な設定変更/障害影響を与えない
    PE/ASBR2
    16001
    P2
    16002
    PE2
    16003
    Multi-AS SR(VPN)のまとめ

    View Slide

  20. © NTT Communications Corporation All Rights Reserved. 20
    Multi-AS SR - Traffic Engineering

    View Slide

  21. © NTT Communications Corporation All Rights Reserved. 21
    Inter-AS Option BのLSDBによるTEの限界
    ● Option BではPEがASを超えた最適経路を計算できない
    ○ SR domain/IGP情報をASごとに分離するため
    ○ Option-CであればIGP情報が混ざるため、PEが最適経路を計算可能
    ○ TE情報の集中と分散設計
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P3
    16003
    Inter-AS
    MPLS domain
    POP
    P2
    16003
    P4
    16004
    PE/ASBR2
    16005
    PE/ASBR4
    16002
    PE2
    16005
    PE1はAS α内のLinkStateしか持たないため、AS α内部のTEパスしか計算できない
    AS β内部のTEはASBR3やASBR4のポリシーに依存する

    View Slide

  22. © NTT Communications Corporation All Rights Reserved. 22
    Multi-AS構成におけるTE
    ● Multi-ASでのユースケースを満たすようなTEとは︖
    ○ この通信を帯域 X bps以上 / 遅延 X ms未満 で送りたい / 冗⻑系のうち1系をメインに送りたい
    ○ → ある意図(Intent)に基づいたTEが構築できればOK
    ■ 送信元PEでE2Eの最適経路計算を⾏う代わり、ASごとにIntentを満たす部分最適経路を構築し接続
    ■ ASごとのIntentは他ASへTEメニューとして提供
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P3
    16003
    Inter-AS
    MPLS domain
    POP
    P2
    16003
    P4
    16004
    PE/ASBR2
    16005
    PE/ASBR4
    16002
    PE2
    16005
    Intentに基づく部分最適なTE α Intentに基づく部分最適なTE β
    Intent情報を事前に共有、⼀連のTEを実現

    View Slide

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

    View Slide

  24. © NTT Communications Corporation All Rights Reserved. 24
    TEメニューの実現
    ● BGP Color Extended Communityを利⽤
    ○ TEメニュー(Intent)に対応するColorを定義、伝搬
    ○ Colorの値はTE区間 = SR domainに隠蔽
    ■ AS間では相互流通⽤のColorに変換、ASごとに値を変換しながら伝達
    ● 下記は極端な例だが、全区間でColorを変換している
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P3
    16003
    Inter-AS
    MPLS domain
    POP
    P2
    16003
    P4
    16004
    PE/ASBR2
    16005
    PE/ASBR4
    16002
    PE2
    16005
    eBGP
    iBGP iBGP
    Color: 1000
    Color: 300 Color: 200
    相互流通ルールの
    Color = 1000に変換
    AS αのルールで
    Color = 300に変換
    Color = 300に紐づく
    最短遅延パスを割当
    最短遅延のIntentを指定したい
    経路にColor = 200を付与

    View Slide

  25. © NTT Communications Corporation All Rights Reserved. 25
    SR domain内でのTE実現⼿法の例
    ● TEには複数の⼿法が存在。管理のしやすさを考慮し⼿法を検討
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    ● Headend(PE/ASBR)がIntentを満たすように
    TailendまでのSIDを積む⽅式(Explicit-Path/CSPF)
    ○ IntentはSegment ListとしてInstance化される
    ● Intentを満たすFlex-Algoを定義し転送を⾏う⽅式
    ○ IntentはAlgorithmとしてInstance化される
    10, 100
    10, 100
    100, 10
    10, 10
    10, 100
    10, 100
    100, 10
    Algorithm 128: exclude-all RED, IGP Metric
    Algorithm 129: exclude-all RED, TE Metric
    Algorithm 130: exclude-all GREEN, IGP Metric
    Explicit-Path 1: 16002/16005
    Explicit-Path 2: 16002/16003/16005
    Explicit-Path 3: 16003/16005

    View Slide

  26. © NTT Communications Corporation All Rights Reserved. 26
    HeadendでSIDを積むパターン
    Explicit-Path 1: 16002/16005
    Explicit-Path 2: 16002/16003/16005
    Explicit-Path 3: 16003/16005
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    ● VPNのIngress PE = HeadendでIntentを満たすSegment Listを定義
    ○ Explicit-PathやCSPF計算など、PEの機能のみで実現
    ○ シンプルな⼿法だが、TE経路の増減に合わせてHeadendに詳細な設定が必要

    View Slide

  27. © NTT Communications Corporation All Rights Reserved. 27
    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保証をしつつルーズソースルーティングをする、などということが可能
    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

    View Slide

  28. © NTT Communications Corporation All Rights Reserved. 28
    Flex-Algoで転送するパターン(2/2)
    ● Intentを満たす詳細な経路をStrictに指定せず、Algoに基づくLooseな指定が可能
    ○ Intent/SliceをAlgoの形で管理可能
    ○ Algo/Affinityは全ルータで正しく設定・認識される必要あり
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    10, 100
    10, 100
    100, 10
    10, 10
    10, 100
    10, 100
    100, 10
    Algorithm 128: exclude-all RED, IGP Metric
    Algorithm 129: exclude-all RED, TE Metric
    Algorithm 130: exclude-all GREEN, IGP Metric

    View Slide

  29. © NTT Communications Corporation All Rights Reserved. 29
    SR domain内でのTE実現⼿法⽐較
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    ● HeadendがIntentを満たすSIDを積む⽅式
    ○ IntentはSegment ListとしてInstance化
    ● pros: 中間に追加Stateは不要。PEのみで管理
    ● cons: 網がIntentを持たないため、障害等で経路変更が
    ⽣じた場合、Intentが満たされなくなる可能性あり
    ● Intentを満たすFlex-Algoを利⽤し転送を⾏う⽅式
    ○ IntentはAlgorithmとしてInstance化
    ● pros: Intent数分のステートを網に設定する必要あり
    ● cons: 障害時の経路変更後も、必ずIntentが満たされる
    10, 100
    10, 100
    100, 10
    10, 10
    10, 100
    10, 100
    100, 10
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    Algorithm 128: exclude-all RED, IGP Metric
    Algorithm 129: exclude-all RED, TE Metric
    Algorithm 130: exclude-all GREEN, IGP Metric
    Explicit-Path 1: 16002/16005
    Explicit-Path 2: 16002/16003/16005
    Explicit-Path 3: 16003/16005

    View Slide

  30. © NTT Communications Corporation All Rights Reserved. 30
    ユースケースを満たすTE実装のまとめ
    ● ASごとにSR domainを分離しつつ、Intentに基づくTEの接続を実現
    ○ ASごとにLinkstateが隠蔽されるためE2Eの最適経路は計算できないが、Intentの形でTEを実現
    ○ AS間ではColorによる疎結合なTEの接続
    ○ AS内ではIntentに基づいたSegment Listの積み込みや、Flex-AlgoによるLooseな指定が可能
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P3
    16003
    Inter-AS
    MPLS domain
    POP
    P2
    16003
    P4
    16004
    PE/ASBR2
    16005
    PE/ASBR4
    16002
    PE2
    16005

    View Slide

  31. © NTT Communications Corporation All Rights Reserved. 31
    その他SR-MPLSの検証について
    網の持つ機能の向上・充実

    View Slide

  32. © NTT Communications Corporation All Rights Reserved. 32
    その他のSR-MPLS関連技術検証
    ● より柔軟・⾼度なTEを⽬指し、下記4点をマルチベンダ環境で検証︕
    ○ Performance Measurement
    ■ 遅延ベースのTEを実現
    ○ EPE(Egress Peer Enginieering)
    ■ AS間もSR Policyによるを実現
    ○ SR PolicyによるIGPメトリックの上書き
    ■ ASBRをSR Policyにより選択
    ○ FRR / TI-LFA
    ■ 障害発⽣時も⾼速に復旧

    View Slide

  33. © NTT Communications Corporation All Rights Reserved. 33
    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の評価などに利⽤

    View Slide

  34. © NTT Communications Corporation All Rights Reserved. 34
    Performance Measurementの活⽤例(P2P)
    ● P2P区間の遅延を集めてLinkstateとして広告、Metricとして利⽤
    ○ Delay MetricベースでのSegment List構築やFlex-Algoの定義など
    ● Performance Measurementの課題
    ○ 遅延の測定結果がベンダによりオーダーが違うほどの差
    ■ E2Eの遅延計算がリンク遅延の合計となると、正しく実情を反映できない
    SR domain
    PE/ASBR1
    P1
    AS α
    PE1
    P2 PE/ASBR2
    TWAMP

    View Slide

  35. © NTT Communications Corporation All Rights Reserved. 35
    Performance Measurementの活⽤例(E2E)
    ● 発⾏済みSegment Listを⽐較し、最適な経路を選択
    ○ 実測値に基づいてSegment Listを選択可能
    ○ 計測⼿法にはOne-way / Two-way / Loopbackの3種が存在
    ■ 時刻同期の必要性や計測可能区間(⽚道/往復)、計測精度に違い
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    AS α
    PE1
    16001
    P2
    16003
    PE/ASBR2
    16005
    TWAMP
    Explicit-Path 1: 16002/16005
    Explicit-Path 2: 16002/16003/16005
    Explicit-Path 3: 16003/16005

    View Slide

  36. © NTT Communications Corporation All Rights Reserved. 36
    eBGP Peerごとに発⾏された
    EPE Peer Adj SIDで処理
    ● EPE (Egress Peer Engineering)
    ○ 対向ASへの経路が複数ある場合にそのどちらかを選択するための技術
    ● SRでのEPE
    ○ Peer Adj SID / Peer Node SIDで対向を識別
    ○ https://datatracker.ietf.org/doc/html/rfc9086
    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(⼀部)

    View Slide

  37. © NTT Communications Corporation All Rights Reserved. 37
    ● 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

  38. © NTT Communications Corporation All Rights Reserved. 38
    1. Head-endから⾒た時のASBRの選択⽅法が難しい
    ○ PE1はASBR1/2どちらに送るか、先のLinkstateが⾒えないのでマクロな判断が不可
    ■ BGP attribute(LP等)での制御は可能
    ■ SR-TEのメトリクスによるASBR選択も⼀部ベンダでは可能
    2. EPE/VPNの同時利⽤問題
    ○ Egressでのラベルの2枚消費が不可能。EPEとVPNラベルを兼ねる機能も検討されていそうだが...
    Inter-AS部分のTE設計の難しさ
    SR domain
    PE/ASBR1
    P1 ASBR β1
    AS β
    AS α
    PE1
    PE/ASBR2
    P2 / RR ASBR β2
    24001 Payload
    16003
    VPN label
    EPE label
    課題② EgressでEPEラベルとVPNラベルの同時処理が不可能
    課題① IngressはEgressから先のLinkstateを持たないため、
    冗⻑なEgressの選択材料がない

    View Slide

  39. © NTT Communications Corporation All Rights Reserved. 39
    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

  40. © NTT Communications Corporation All Rights Reserved. 40
    Inter-AS Option BとFRR/TI-LFAの課題
    ● Inter-AS部分の保護ができず、真のE2E FRRは不可能
    ○ TI-LFAはIGP前提の技術であるため、Option-BではASを超えて使⽤できない
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P3
    16003
    Inter-AS
    MPLS domain
    POP
    P2
    16003
    P4
    16004
    PE/ASBR2
    16005
    PE/ASBR4
    16002
    PE2
    16005
    Inter-AS区間にはIGPが存在しないため、
    FRRでの保護は不可能

    View Slide

  41. © NTT Communications Corporation All Rights Reserved. 41
    その他のSR-MPLS関連技術検証のまとめ
    ● ⾼度なTEを実現するため、様々な技術を検証
    ○ Performance Measurement: 遅延ベースIntentの実現
    ○ EPE(Egress Peer Enginieering): AS間部分のTEを実現
    ○ SR PolicyによるIGPメトリックの上書き: ASBR選択を実現
    ○ FRR / TI-LFA: 障害発⽣時の⾼速迂回(Local Repair)
    ● → これらの技術について、マルチベンダでの検証を実施済

    View Slide

  42. © NTT Communications Corporation All Rights Reserved. 42
    SR-MPLS / SRv6相互接続
    Service Function Chainingの活⽤

    View Slide

  43. © NTT Communications Corporation All Rights Reserved. 43
    ● マルチAS/マルチドメインなSegment Routing
    ○ SRv6も⼀つのASとしてOption Bで接続︕
    Customer
    CE CE
    Customer
    Customer
    AS
    AS
    SR-MPLS domain
    Inter-AS
    MPLS
    (再掲)作りたいネットワーク
    Interwork
    ASBR
    P
    SRv6 domain
    PE/ASBR PE/ASBR
    P
    PE/ASBR
    SFC
    Proxy
    Network
    Function
    SR-MPLS domain
    PE PE/ASBR PE
    P
    PE
    CE
    CE
    SR-MPLS domain
    Customer
    Inter-AS
    MPLS
    PE PE
    P
    PE/ASBR
    AS
    AS
    Inter-AS
    MPLS
    CE
    Customer

    View Slide

  44. © NTT Communications Corporation All Rights Reserved. 44
    SRv6を利⽤・検証するモチベーション
    ● Service Function Chainingの導⼊
    ○ 網への付加価値提供
    ○ Option BのASとして参加し、SFCを提供する網として設計︕
    ● SRv6の実装状況調査・機能検証
    ○ SRv6の技術検証のため、SRv6内でのTE/VPNのフィールド検証も兼ねてASを設計
    ■ SRv6 FunctionによるVPN・SFCの検討
    ■ C-Plane検証
    ○ SRv6のユースケース検討
    ■ SFCのユースケース
    ■ 既存のIPv6網を活⽤︓将来的な商⽤網のマイグレーション難易度を下げる︖

    View Slide

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

    View Slide

  46. © NTT Communications Corporation All Rights Reserved. 46
    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

  47. © NTT Communications Corporation All Rights Reserved. 47
    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があるか

    View Slide

  48. © NTT Communications Corporation All Rights Reserved. 48
    2021/12時点で検討しているSFCのユースケース
    ● 全社に先⾏した新機能や最新機材の検証
    ○ SRv6網で最新機能を検証
    ○ 他ASは気軽に接続しサービスを検証、良さそうなら⾃らのAS内部に取り込み
    ■ Security appliance、Load balancer、CGN、NFV基盤...
    ○ 全社に先駆けて検証を⾏うR&D部⾨ならではの強み
    ● 構築、運⽤の⼿間を削減した隣接ASへのサービス提供
    ○ C-Planeを活⽤した拡張性の⾼い相互接続
    ○ チェインを含めたTEポリシーとして隣接ASに公開するなど、利⽤しやすいSFCメニューの提供

    View Slide

  49. © NTT Communications Corporation All Rights Reserved. 49
    SRv6/SR-MPLS相互接続の課題
    Interwork
    ASBR
    SRv6 P ASBR PE2
    P
    PE1
    CE2
    CE1
    SFC Proxy
    Network
    Function
    SRv6 PE
    ● SR-MPLSのCustomer同⼠の通信にSFCを提供することを考える
    ○ シンプルなIP Forwardingだけでは折り返しは実現できない
    ■ SR-MPLSのSFCもdraftで議論されているが、折り返し可能な実装はない
    同じ192.168.1.0/24宛のVPN経路を、
    ⾏きはSRv6⽅向に転送し、
    戻りはSR-MPLS⽅向に転送する︖
    SRv6 domain Inter-AS MPLS SR-MPLS domain
    Customer
    Customer
    192.168.0.0/24
    192.168.1.0/24

    View Slide

  50. © NTT Communications Corporation All Rights Reserved. 50
    解決策: ルーティング⾯の分割(1/2)
    Interwork
    ASBR
    SRv6 P
    ASBR
    PE2
    P
    PE1
    CE2
    CE1
    SFC Proxy
    Network
    Function
    SRv6 PE
    ● ⾏きと戻りでルーティングを分割すれば実現可能
    ○ ⾏きのTrafficを処理するノードと帰りのTrafficを処理するノードを⽤意
    Interwork
    ASBR
    ASBR
    SRv6 domain Inter-AS MPLS SR-MPLS domain
    Customer
    Customer
    192.168.0.0/24
    192.168.1.0/24

    View Slide

  51. © NTT Communications Corporation All Rights Reserved. 51
    解決策: ルーティング⾯の分割(2/2)
    SRv6 P PE2
    P
    PE1
    CE2
    CE1
    SFC Proxy
    Network
    Function
    SRv6 PE
    ● ルーティング⾯の分割をVRFで実現
    ○ 送信⽤、受信⽤のVRFを⽤意し、経路を分離
    Interwork
    ASBR
    ASBR
    rt export 65001:1
    rt import 65001:101
    VRF cust-a-rcv
    VRF cust-a-snd
    End.DT6(cust-a-snd)
    VPN label(cust-a-snd)
    SRv6 domain Inter-AS MPLS SR-MPLS domain
    Customer
    Customer
    192.168.0.0/24
    192.168.1.0/24

    View Slide

  52. © NTT Communications Corporation All Rights Reserved. 52
    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を⽤意する必要がなくなり、スケーラビリティが向上するはず

    View Slide

  53. © NTT Communications Corporation All Rights Reserved. 53
    (補⾜)SR-MPLS側のInterwork ASBRについて
    SRv6 P
    SRv6 domain
    PE2
    P
    PE1
    CE2
    CE1
    SFC Proxy
    Network
    Function
    Inter-AS MPLS SR-MPLS domain
    SRv6 PE
    Customer
    ● MPLSはラベルによる転送⼿法であるため、折り返しの実現可能性あり
    ○ ⾏きを⽰すラベルと帰りを⽰すラベルを別に⽤意、それぞれを指定する
    ■ 現時点では、単⼀のVRFでeBGP/iBGPで学習した経路を同時にLFIB Installする実装がないため断念
    Customer
    192.168.0.0/24
    192.168.1.0/24
    Interwork
    ASBR
    ASBR
    24000 Payload
    VPN label
    24001 Payload
    Label Action Next
    24000 SWAP 24000 SRv6へ
    24001 SWAP 24000 SR-MPLSへ
    ... ... ...
    ASBRのMPLS Table(⼀部)

    View Slide

  54. © NTT Communications Corporation All Rights Reserved. 54
    SRv6 - SR-MPLS相互接続検証まとめ
    ● SRv6の⼀つのユースケースであるService Funtion Chainingを導⼊
    ○ 網への付加価値提供が可能
    ○ Option BのASとして参⼊し、SR-MPLSにもSFCを提供
    ■ 作成したASはマルチベンダにSRv6を検証する網としても活⽤
    ● SR-MPLS - SRv6 - SR-MPLS折り返しのための⼿法を提案
    ○ 折り返しの結果、SR-MPLS網にSFCの提供に成功

    View Slide

  55. © NTT Communications Corporation All Rights Reserved. 55
    SRv6 AS内部について
    ● SRv6の機能検証を⾏うASとしても設計、検証を実施
    ○ SRv6 FunctionによるVPN/TE(Flex-Algo)/ SFCの検証
    ○ SRv6⾮対応ノードのTransit活⽤
    ○ マルチベンダSRv6
    ● 複数の拠点にまたがる網を1つのASとして設計
    ○ 将来的にはIPv6の性質を⽣かし、AS/拠点/Algo単位で階層化されたMulti-AS通信なども可能︖
    Customer A
    P
    Customer B
    SR domain
    Site B
    Network
    Function
    PE
    PE / SFC Proxy
    Customer A Customer B
    Site C
    Site A
    PE
    P P P
    Customer A Customer B

    View Slide

  56. © NTT Communications Corporation All Rights Reserved. 56
    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の⽤途と相談して設計する 2001:db8:180:1:1:4:1:a
    拠点ID(拠点1)
    Flex-Algo ID (128)
    Algo内のindex Function Sub-ID
    Function ID パラメータ1
    パラメータ2

    View Slide

  57. © NTT Communications Corporation All Rights Reserved. 57
    (参考)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さえあれば転送可能

    View Slide

  58. © NTT Communications Corporation All Rights Reserved. 58
    SRv6活⽤のまとめ
    ● Service Function Chainingによる付加価値提供
    ○ R&D部⾨としてのNetwork Function検証、PoCの場として検討中
    ● Option Bで⼀つのASとして実現
    ○ 疎結合なMulti-AS構成の利点
    ○ SR-MPLS網にSFCを提供
    ■ SR-MPLSには現状SFC実装がないので、折り返しに⼯夫が必要
    ● SRv6機能検証の場としてもASを活⽤中

    View Slide

  59. © NTT Communications Corporation All Rights Reserved. 59
    Future Work

    View Slide

  60. © NTT Communications Corporation All Rights Reserved. 60
    Future work
    ● PCEの活⽤
    ● セルフマネージポータルの開発
    ● より⾼度なTEの実現
    ● SRv6のさらなる活⽤

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  64. © NTT Communications Corporation All Rights Reserved. 64
    ● マルチASなPCEの効率的な設計、運⽤は難しい
    ○ 集中と分散を考慮した設計
    ○ Linkstateを⼀元管理することで真のE2E最適は満たせるが、Option C的な情報管理となる
    ○ Option B的に情報を分離しつつ、E2E最適を満たすための仕組みを導⼊する︖
    ASごとにPCEを配置する場合はOption B的な運⽤、
    ASを超えてPCEに管理させる場合はOption C的な運⽤となる︖
    マルチAS対応のものも出ているので、ベンダ実装を検証中
    マルチASなPCEの連携
    SR domain
    PE/ASBR1
    16004
    P1
    16002
    PE/ASBR3
    16001
    AS β
    AS α
    PE1
    16001
    SR domain
    P3
    16003
    Inter-AS
    MPLS domain
    POP
    P2
    16003
    P4
    16004
    PE/ASBR2
    16005
    PE/ASBR4
    16002
    PE2
    16005
    PCE PCE
    LinkStateや発⾏済みSegment Listの共有︖

    View Slide

  65. © NTT Communications Corporation All Rights Reserved. 65
    セルフマネージポータルとの組み合わせ
    ● マルチAS環境のセルフマネージ化
    ○ ユーザが⼿元のASから対向のASを操作、PCEとも好相性
    ○ ASを超えた制御に課題
    ■ 横のASをオンデマンドに操作して良い︖
    ● 双⽅向なTEを考えると、対向ASのPEにもSR Policyを与える必要...?
    ■ TEメニューの提供⽅法や課⾦⼿法などが課題になるか
    https://onic.jp/_cms/wp-content/uploads/2019/11/onic2019_tajima.pdf

    View Slide

  66. © NTT Communications Corporation All Rights Reserved. 66
    リアルタイムな監視技術の活⽤
    ● リアルタイムな情報と組み合わせ、より⾼度なTEを実現
    ○ リアルタイムな流量や帯域をベースにした最適化
    ○ 故障予測と回避など
    ○ TelemetryやxFlowなど、様々な監視情報と組み合わせる
    ■ Telemetry技術検証について: https://engineers.ntt.com/entry/2021/09/02/162022
    ■ Service Function Chainingもパケットの監視⼿法として活躍できるかも
    SR domain
    PE/ASBR1
    P1
    AS α
    PE1
    P2 PE/ASBR2
    PCE
    Telemetry
    Collector
    Telemetry情報から得たリンクの統計情報や、
    コントローラで実施した機器の故障予測などを元にSegment Listを更新
    Segment Listの更新
    Telemetry

    View Slide

  67. © NTT Communications Corporation All Rights Reserved. 67
    SRv6のさらなる活⽤
    ● 既存IPv6網の活⽤
    ○ ⾮対応網を取り込んでおいて、少しずつSRv6化する︖
    ■ 対応したところからTEができるようになるのは⾯⽩い
    ■ エッジ間でVPNを貼っておき、将来的にTEもできるようになるというのもgood
    ■ 間に別のIPv6網が⼊るとアドレス設計をうまくできなくなるのが課題
    ○ 運⽤中の網におけるマイグレーション︖
    ■ 1. 既存網にSRv6網を接続
    ● SFCや固有Functionなどで付加価値提供
    ■ 2. 既存網の⼀部をSRv6化する
    ● 例えばエッジ部分をSRv6化し、⾮対応ノードをVPNの⼟管として利⽤
    ■ 3. 既存網全体をSRv6化し、SRの適⽤範囲を拡⼤していく
    ● 少しずつ参加するASを増やせるのもMulti-AS構成の強み

    View Slide

  68. © NTT Communications Corporation All Rights Reserved. 68
    まとめ
    ● Multi-AS Segment Routingの提案
    ○ スケーラビリティの向上
    ■ ASごとのリソース分離・Intentに基づいたTEメニューの設計・集中と分散のバランス
    ■ 疎結合なMulti-AS構成により新たな網の追加も容易に。SRv6も1つのASとして検証中
    ○ 新たなユースケースの獲得
    ■ 拠点ごとのAS設計
    ■ 管理者の異なるASのつなぎ合わせ
    ■ SFCの活⽤
    ■ → 将来的なネットワーク設計の⼀つの姿
    ● ⼀緒に取り組む仲間を募集中
    ○ 是⾮継続して議論しましょう
    CE CE
    Interwork
    ASBR
    P PE/ASBR PE/ASBR
    P
    PE/ASBR
    SFC
    Proxy
    Network
    Function
    PE PE/ASBR PE
    P
    PE
    CE
    CE
    PE PE
    P
    PE/ASBR
    CE
    SR-MPLS
    SR-MPLS SR-MPLS
    SRv6

    View Slide

  69. © NTT Communications Corporation All Rights Reserved.

    View Slide