SR-MPLSの導⼊事例と今後の展望について
NTTコミュニケーションズ
技術開発部
野⽥ 昌孝，⽊村 安宏(発表者)
Copyright © NTT Communications Corporation. All rights reserved.

発表の⽬的❏ 弊社の取り組みを知っていただきたい❏ 改善につながるフィードバックをいただきたい
お客さまサービス

VPN

オフィス

CloudETC.

開発

商⽤インフラその他

ここにSRを⼊れました※ 商⽤インフラ: お客さまサービスを⽀えるインフラ
サービス開発，データ解析，⼀般オフィス業務 などを実施

Copyright © NTT Communications Corporation. All rights reserved.

2

アジェンダ❏ 商⽤インフラの課題と要望❏ SRを⽤いたネットワーク構築❏ 今後の展望❏ まとめ

Copyright © NTT Communications Corporation. All rights reserved.

3

商⽤インフラの課題と要望

Copyright © NTT Communications Corporation. All rights reserved.

4

商⽤インフラが抱えていた課題 1❏ 組織毎に異なるネットワークを保有❏ コスト増 (機器，回線の重複)❏ 拠点開通に時間がかかる
同じ拠点に複数の機器と回線が有りコスト増

商⽤インフラ
オフィス

開発

その他

拠点A

拠点B

拠点C

Copyright © NTT Communications Corporation. All rights reserved.

既存設備を流⽤せず，新規開通するため時間がかかる

5商⽤インフラが抱えていた課題 2❏ 複雑なネットワーク設計❏ ⾊んなシステムの要望を叶えたら複雑な設計に❏ 設計に時間がかかる，⾃動化が進まない

他のシステムとは通信させない

インターネット接続は禁⽌特定の拠点間でだけ通信したい
Copyright © NTT Communications Corporation. All rights reserved.

ACLやPBRを多⽤した
複雑なネットワーク

Config作成/レビューに時間がかかる
障害時の切り分けが難しい
複雑すぎて⾃動化できない
6

課題を解決させるためのPJ発⾜❏ 商⽤インフラを再検討するPJを発⾜❏ 課題だけでなく商⽤インフラに対する要望をヒアリング❏ お客さまサービスに対してノウハウ，知⾒をインプット
時代に適した技術で商⽤インフラを構築

商⽤インフラを統合

新技術

開発

⾃働化

お客さまサービスに知⾒をインプット
お客さまサービス

可視化

商⽤インフラ
商⽤インフラCopyright © NTT Communications Corporation. All rights reserved.

オフィス

その他

商⽤インフラ7

商⽤インフラの課題と要望のサマリ
[課題]

[要望]

NW重複によるコスト増

各組織でNWを管理したい

拠点開通に時間がかかる帯域を有効に使いたい

複雑な設計

災害に強いNWにして欲しい

⾃動化が進まない

⽌まらないNWにして欲しい
APIを開放して欲しい
新しい要望に応えれるNW

Copyright © NTT Communications Corporation. All rights reserved.

8

SRを⽤いたネットワーク構築

Copyright © NTT Communications Corporation. All rights reserved.

9

ネットワークイメージ図 (2019/10/1時点)
クラウド❏ 初期構築は⼤規模拠点を中⼼に展開❏ Aggregate層とEdge層の2層構成❏ ツール類はクラウドに配備
関⻄エリア

ツール類設定投⼊関東エリア
PPP

P

スライスPEPE

Copyright © NTT Communications Corporation. All rights reserved.

PEPE

PE

PE

PE

PE

PE

PEPE

PE

PE

PE

10

本システムにおけるスライスの定義❏ スライス➢ネットワークの分割単位をスライスとする■ L3VPNでは，VRFをスライスの単位とする■ L2VPNでは，EVPNのEVIをスライスの単位とする
L3VPN

L2VPN

スライス1001 (VRF 1001)

スライス2001 (EVI 2001)

スライス1002 (VRF 1002)

スライス2002 (EVI 2002)

Copyright © NTT Communications Corporation. All rights reserved.

11スライス技術によるNWの統合，シンプル化❏ 複数のNWをスライス技術を⽤いて統合SR❏ システム/機能毎にスライスしてシンプル化❏ L2VPNとL3VPNを同⼀のNWに収容
オフィス
開発

統合，シンプル化

L2VPN
L3VPN

その他Copyright © NTT Communications Corporation. All rights reserved.

12

トランスポート技術の選定❏ トランスポート技術の⽐較を実施しSR-MPLSを選定

SR❏ L2VPNとL3VPNを同じNW収容，TE，スケールがポイント❏ SRv6も候補だったが実装スケジュールの関係で採⽤断念
L2/L3の収容

TE

スケール

SR-MPLS◯◎◎

SRv6△△?

MPLS

◯

◯

◯

Copyright © NTT Communications Corporation. All rights reserved.

※ ⽐較した当時の実装の評価です．
プロトコルとしての評価ではありません．

13

IGP，VPN❏ 実装の速さから IS-ISを選定○ 先に実装されたほうがBug潰しも早いことを期待SR❏ L2VPN❏ 1対1のL2VPNではなくLANタイプのL2VPNが必要❏ BGPオペレータが運⽤しやすい EVPNを選定❏ L3VPN❏ EVPNの検討したがL3VPNの実装に難があり VPNv4を選定❏ PEがCEからeBGPで学習した経路をEVPN Route type5でアドバタイズできなかった(PoC実施時)
Copyright © NTT Communications Corporation. All rights reserved.

14

SRで何が嬉しい? ~設定，運⽤のシンプル化~❏ よく⾔われていること

SR❏ LDPが不要になり，設定，運⽤のシンプル化❏ [検証]ラベル交換⽤の設定❏ LDP: LDPを使⽤するIFでLDPを宣⾔❏ SR: IGPの設定項⽬の中でSRを宣⾔❏ SRの⽅が設定は多少簡易だが劇的に変わるわけじゃない

Copyright © NTT Communications Corporation. All rights reserved.

15

SRで何が嬉しい? ~設定，運⽤のシンプル化~
SR❏ [検証]トラブルシュートなどでLabel経路を確認する場合❏ LDP: ルータ毎にLocal uniqueなLabelを交換していくので追いにくい❏ SR: Head-EndからEnd-Pointまで同じLabelが使われるので追いやすい
Global uniqueなのでLabel管理が容易(素晴らしい)❏ 運⽤でSRのメリットは感じられる
[LDP]

push

Local uniqueなLabelを交換していく

pop ※

[SR]

push

Global uniqueなLabelなので追いやすい

pop ※Out Out
Label IF

Local OutLabel LabelOutIF

Local Out Out
Label Label IF

Local OutLabel IFOut Out
Label IF

Local OutLabel Label

Out
IF

Local Out Out
Label Label IF

Local OutLabel IF

1001 te0/0

1001 2001 te0/0

2001 3001 te0/0

3001 te0/0

1001 te0/0

1001 1001 te0/0

1001 1001 te0/0

1001 te0/0

PEPPPEPEPP※ 実際の運⽤では，PEの⼿前PでPHPを⽤いてPEにはLabel情報は送らない

Copyright © NTT Communications Corporation. All rights reserved.

PENode SID
1001
16

SRで何が嬉しい? ~FRRはSRの特徴の1つ~❏ よく⾔われていること❏ SRのFRRはMPLSでは出来なかったことを実現しているSR❏ [検証] FRRの設定❏ MPLS❏ 予めBackup path設定❏ 該当IFでFRRの設定❏ 構成が変わった場合にはPathの再設定が必要❏ SR❏ IGP階層の該当IFでFRRの設定❏ Backup path設定は不要で構成に依存せずFRRが可能❏ SRの⽅が簡単でかつ柔軟にFRR(TI-LFA)が可能❏ Backup経路を指定しないリスクも考慮に⼊れるべき❏ 迂回先のトラフィックが溢れて障害拡⼤にならないように

Copyright © NTT Communications Corporation. All rights reserved.

17

SRで何が嬉しい? ~柔軟かつSDNに適したTE~
SR❏ よく⾔われていること❏ SIDを指定するだけで容易にTEが可能でSDNに適している❏ [検証] EXPLICITのSR-TE設定❏ SIDを指定して経路を選択

EXPLICIT-PATH

1005

1002

1004

1001

1003

1006

1005
1003
1004
1007

1007

❏ ルーティングに依存せずSIDだけで経路が指定可能(TEの柔軟性)❏ ｢⾏って来い｣，｢ヘアピンカーブ｣のようなTEも可能❏ ユースケース: D-Planeの疎通性を確認❏ ステートを持たないのでルータへの負荷が低くスケールが期待できる

Copyright © NTT Communications Corporation. All rights reserved.

18

本システムでのTEの使い⽅❏ 帯域の有効活⽤❏ Dynamic(Metricベース)で経路選択❏ IGPコストとTEコストの値を逆にしてトラフィック分散SR❏ 特定経路の救済❏ 帯域が埋まっている際に，救いたいを特定経路をTEで迂回❏ ExplicitでIP Prefixを指定して経路選択[TE利⽤イメージ]
Head-endはColorに従い転送
RD
IP Prefix
Color
10.10.1.1:1
Red
10.10.1.1:2
Blue10.10.1.1:3
Red
10.10.1.1:4
Blue
10.10.1.1:5
Red
10.10.1.1:5
172.16.1.0/24
GreenCopyright © NTT Communications
Corporation. All rights reserved.

17001

P10 1210 11101011 10100 17002
P 12 101000
1000
100
100
PE 100 PE
16001
16002

1012

17003

10 111110
12 10P

⾚字: IGP Metric
⻘字: TE Metric
緑字: Node-SID

P

10101000
17004 100
1001000

100
PE 100
PE

16101

16102

End-pointでColorを付けて配信(VPN経路にColor ExtendedCommunityを付与)
Color
Red
Blue
Green

Type
IGP
TE
Explicit
19利⽤者からのTEへの要望❏ 利⽤者からの声 ｢O365，Win updateをTEしたい｣SR❏ O365，Win updateは確かに無視できないトラフィック量❏ 簡単に⾔うが簡単ではないことも多々❏ 現在の実装ではIP-Prefix単位でTE❏ O365は無数のIPを使⽤し，IPが変動する❏ MSが定期的に公開するリスト(JSON形式)を元にIP-Prefixリストを作り込むか?(https://docs.microsoft.com/en-us/office365/enterprise/urls-andip-address-ranges)❏ そもそもこのクラスのルータで細かい設定をするのが運⽤的に正しいか?
❏ 同じようなニーズをお持ちの⽅います?
Copyright © NTT Communications Corporation. All rights reserved.

20利⽤者からのTEへの要望❏ 利⽤者からの声 ｢O365，Win updateをTEしたい｣SR❏ ルータでアプリケーション識別が可能か❏ メーカーさんで実装を考えています?
❏ PEの⼿前でアプリ識別をしてColorをつけるのがよい?
❏ CEで識別してもらうか?
❏ DPIをおく?
❏ P4を使うとうまくできる?

Copyright © NTT Communications Corporation. All rights reserved.

21

SRで何が嬉しい? ~｢MPLSの⼼の壁｣~
SR❏ MPLSに対する｢⼼の壁｣を下げられる❏ MPLSはキャリアで使うもの，難しいといったイメージが強い❏ IGPの拡張で扱えるのはオペレータの⼼理に優しい❏ 本NWはEnterprise系の運⽤チームが運⽤している

LDP? RSVP???

Copyright © NTT Communications Corporation. All rights reserved.

IGPなら頑張れ
そう

22

物理設計

❏ 論理を完璧にしても物理が駄⽬なら論理も崩壊

物理❏ 激甚対策❏ ⼤災害などで置局が崩落しても網全体としては通信を確保したい❏ Pルータを設置する置局間は100km以上離す
Aggregate拠点

Aggregate拠点

P

P

Copyright © NTT Communications Corporation. All rights reserved.

100km以上PE
Edge拠点

PE
23

物理設計
物理

❏ 異経路でのファイバルート❏ PEルータはロケーションの異なる2つのPルータへ回線を伸ばす❏ 冗⻑した回線が障害時に両系断にならないように設計
異経路分散無し
PE

異経路分散有り

1箇所の障害で両系断

P

PE

P

中継局
中継局
PE
Copyright © NTT Communications Corporation. All rights reserved.

中継局

中継局
PPE

P

⽚系のみの障害24

⾃動化，API連携❏ ユーザによるセルフマネージ可能なシステムを構築 ⾃動化，API連携
ポータル

ユーザ

GUI

NWコントローラ

API

Netconf❏ APIを開放しており他のシステムとのAPI連携も可能
ポータル

他システム

API

Copyright © NTT Communications Corporation. All rights reserved.

NWコントローラ

API

Netconf25

詳細はONICで!
⾃動化，API連携

Copyright © NTT Communications Corporation. All rights reserved.

26

Demo

❏ シナリオ➢ L3VPNの開通➢ PE〜CE間はBGP接続➢ 配線済み，CEは設定済み➢ ポータル画⾯から設定投⼊➢ 拠点間通信をPingで確認設定投⼊1

LaptopPingPE

設定投⼊2
PPPE
CE

CE

Copyright © NTT Communications Corporation. All rights reserved.

PEPP

Laptop

PE27

今後の展望Copyright © NTT Communications Corporation. All rights reserved.

28

さらなる拠点展開❏ 中⼩規模拠点への展開(今年度下期検討開始)❏ 網型のNWサービスを活⽤せざるを得ない❏ MTUが専⽤線タイプよりも⼩さくなる❏ SID段数を気にする必要が出てくるか❏ 海外拠点への展開❏ SD-WANとの接続 (PoC実施済み)❏ SR over IPsec (今年度下期にPoC予定)[海外拠点展開イメージ(SD-WAN接続)][中⼩規模展開イメージ]P

P

専⽤線(MTU 9000以上)

PEPE

PPE

Copyright © NTT Communications Corporation. All rights reserved.

⼤規模拠点PEPPP
Internet

網側NWPE

中⼩規模拠点

PEBGP
PE

PE

SD-WAN

⼤規模拠点

網型NW
SD-WAN29

海外拠点

その他のSRプロジェクトとの連携（メトロDCIのフィールド検証）❏ メトロDCIおよびエッジコンピューティングのNWを検討❏ DWDMトランシーバ + ダークファイバーでメトロエリアを繋ぐ
CFP2-ACO：WhiteBoxのトランスポンダーに搭載(TIP仕様)
CFP2-DCO：SRルータのポートアダプタに搭載❏ 各スライスのトラフィック特性に応じ,SR-TEによるパス選択
低遅延,広帯域のトラフィックを最適な経路で運ぶ
ユースケースInternet
クラウド

クラウド

SR-TE

低遅延パス

⾼精細映像
VNFのエッジ展開

低遅延パス
VxF

⾼精細映像

VxF

リモートストレージ
Copyright © NTT Communications Corporation. All rights reserved.

30その他のSRプロジェクトとの連携（メトロDCIのフィールド検証）❏ フィールド環境は,東京エリアの2拠点間をダークファイバで接続❏ DC1,DC2に,SRルータとWhiteBoxトランスポンダーを設置【検証1】スループット検証(100G,200G)

広帯域①WhiteBoxトラポン間100G QPSKモードで,100Gbpsを確認②SRルータ間100G QPSKモードで,100Gbpsを確認③SRルータ間200G 16QAMモードで,100Gbps x 2 = 200Gbpsを確認

・BGP SR-policyで,DWDM1とDWDM2をスネークするAdj-SIDを指定し,合計200Gbpsを確認

DC2

TP2①

DC1

TP1

SR-TE
DWDM 1

NWテスタ
送受信
100G

SR2
SR2

DWDM 2②,③

SR1
SR1③③

SID追加

SID追加

Copyright © NTT Communications Corporation. All rights reserved.

SID追加後 SID追加前

NWテスタ
送受信
100G

SID追加後SID追加前31

[⼩ネタ]❏ スネーク(⾏って来いネットワーク)構成をSRでシンプルに❏ どんなときに使う?
｢回線は200G，テスタのIFは100G，でも200Gスループット試験をしたい｣[SRのスネーク構成]
往復するAdj-SIDを指定し帯域を稼ぐ
R1で指定 [ 24001 -> 24004 -> 24003 ]
NWテスタ
R1

NodeSID
16001

IS-IS Peer 2本100G波⻑ x 2 = 200G
AdjAdjSID
SID
24002
24001

24003
Copyright © NTT Communications Corporation. All rights reserved.

R2

NodeSID
16002

24004
NWテスタ

32

その他のSRプロジェクトとの連携（メトロDCIのフィールド検証）【検証2】広帯域,低遅延を要求するアプリの想定検証①NWストレージ⽤パフォーマンステスタによる品質測定

低遅延

・距離遅延と⽐べ,機器の転送遅延は少なく,品質には殆ど影響ない
・期待通りのストレージ性能が出ており、リモートストレージのNWとして期待できる②⾼精細ビデオ映像の伝送・トラポンのみで構成した場合,クリアに視聴可能
・SRルータを経由すると1us程度のジッタの影響でPTPが同期できず,映像が乱れる※外部クロックが受信できない環境のため,インチャンネルでPTP同期を⾏った結果,ジッタの影響を受けた※外部クロックを使⽤すれば問題ない想定であるが,別環境で再確認が必要

DC2② ⾼精細映像

TP2

TP1

受信側

② ⾼精細映像
受信側① ストレージ
Copyright © NTT Communications Corporation. All rights reserved.

SR2

SR1

DC1⾼精細映像 ②
送信側
⾼精細映像 ②
送信側
ストレージ ①テスタ
33

その他のSRプロジェクトとの連携（メトロDCIのフィールド検証）【検証3】Flex-Algoによるトラフィック制御

Slicing, TE

⾼精細映像，NWテスタを異なるAlgoを適⽤しトラフィックを制御

試験項目

Color

Algo # / Metric

トラフィックVLAN

遅延IGPコスト

高精細映像

Blue

Algo128 / 遅延

15.8G DC2 <-DC1100

小10 -> 100

NWテスタ

Green

Algo129 / IGPコスト

9.3G DC2 <-> DC1200

大20

DC2

DC1

⾼精細映像
受信側
ColorGreen
15.8G
NWテスタ
送受信Color Blue
9.3G

SR2TP2from DC1 to DC2
from DC2 to DC1

VLAN100

from DC1 to DC2
from DC2 to DC1

VLAN200

⾼精細映像
送信側
ColorGreen
15.8G

TP1Blue + Green
to DC2 (vlan100)

SR
1NWテスタ
送受信
Color Blue
9.3G

Blue
Green

IGPコスト変更前--------->VLAN100にトラフィックが寄る

Copyright © NTT Communications Corporation. All rights reserved.

to DC1 (vlan100)

Green
to DC1(vlan200)<----------- IGPコスト変更後
34
トラフィックが分散

まとめ

Copyright © NTT Communications Corporation. All rights reserved.

35

まとめ
❏ SR-MPLSを使ってみて⼗分に商⽤で使えることがわかった❏ MPLS LDP(RSVP)でもほぼ同様のことはできるがSR-MPLSの⽅がBetter○ 新規構築ならMPLS LDP(RSVP)よりもSR-MPLS○ 既存のMPLSからSRに移⾏するかは強いユースケースがなければ，機器のマイグレのタイミングか❏ MPLSの壁(技術⾯，⼼理⾯)は確実に低くなった，使⽤されるケースが増える❏ SR-TEはアイデア次第，様々な世界が描ける❏ SRで｢こんな使い⽅があるよ｣，｢こんな機能はどう?｣といったご意⾒があればぜひ教えて下さい
Copyright © NTT Communications Corporation. All rights reserved.

36

ご清聴ありがとうございました

Copyright © NTT Communications Corporation. All rights reserved.

37