ナレッジセンター
匠コラム

Segment Routing入門③ ～現状と将来～

匠コラム: ネットワーク

2017.11.15

ビジネス推進本部応用技術部
コアネットワークチーム
高田聡士

前回はSegment Routing使用のユースケースとしてMPLSへの適用について説明しました。
MPLSでは、LDPの様なDynamic動作の部分に関しては機器への実装がかなり進んでおり、RSVP-TEの様なTraffic EngineeringやFRR(Fast ReRoute)機能もハイエンドルータを中心に実装が成熟しています。
連載最後の今回は、Segment Routingの現在の状況と将来の想定について説明していきます。

連載インデックス
Segment Routing入門① ～概要と基本動作～ Segment Routing入門② ～MPLSデータプレーンへの適用～ Segment Routing入門③ ～現状と将来～

MPLS/SRの現状

まずはMPLSにおけるSegment Routing（以下、SR）の現状について見ていきます。

既存環境における機能への対応状況

機器により実装状況の違いはありますが、既存のLDP/RSVP環境が持つ機能にSRがどこまで対応しているのかを示すと下記表の様になります。

Dynamic動作
Routing Tableに従ったpath形成のことで、SRの基本動作でもあるため当然対応しています。

Traffic Engineering
Rouging Tableに依存しないpath形成のことで、SRではlabel stackによりこの機能を実現しています。

FRR
障害発生時の高速経路切替（ここではlocal repairを想定）のことで、SRではTI-LFA（Topology Independent – Loop Free Alternate）という機能でこれを実現しています。

Multicast Tree作成
Multicastパケットの複製をMPLS網内の必要なルータだけが行う機能のことで、Multicastパケットの数を抑制することが出来ます。
SRはこの機能に対応しておらず、Multicast通信の際にはMPLS網の入口となるルータ（Ingress LER）で全ての出口となるルータ（Egress LER）分のMulticastパケットの複製を行うIngress Replicationという方式を使います。
そのため、Multicastに関係しない回線にもMulticastパケットが流れることとなり、帯域を圧迫する事となります。

＜Ingress Replication＞

＜Multicast Tree＞

Multicast Treeについては今後の対応を待つことになりますが、LDP/RSVP環境で実現している機能については概ねSRでも実現可能であると言えます。

SRの独自機能

Multicast Treeとは逆に、既存のLDP/RSVP環境では実現できないSRの独自機能もあります。
特にSRはSegmentという概念を用いることによりNetworkをシンプルに表現できSDN（Software Defined Network）との親和性が高いことから、SDN Controllerを用いた機能が多く提案されています。
SRの独自機能は既存機能以上に機器による実装状況に違いがありますが、SDN Controllerを用いる機能の1つとしてここではBGP-EPE（Egress Peer Engineering）を紹介します。

＜機能概要＞
BGP-EPEは他のASへ抜ける必要がある通信に対して適切なBGP-Peerを通るpathを提供することができる機能です。
Egress LERはBGP-peerに関するSegment情報（PeerNode SIDなど）を作成し、その情報をSDN Controllerが取得します。
これによりSDN ControllerはBGP-peerまで含めたpath計算を行い、そのpath情報をIngress LERに伝えることで適切なBGP-Peerの使用を実現します。
例えば複数のISPに接続されるData Centerやクラウドサービス環境などにこの機能を適用すると、サービスやユーザ毎に最適なISPを選択して通信を行わせることが可能となります。

＜BGP-EPE概要図＞

既存環境とSR環境の共存

共存についてはMulti-StackとInterworkingの2パターンが想定されます。

Multi-Stack
Multi-Stackでは、1つのMPLS網内でLDP/RSVPとSRを同時に使用します。
これを実現するためにはLDP/RSVPとSRで使用するlabel番号を分けておく必要があります。
なぜならばSRのPrefix-SIDはGlobalでユニークでなければならず、LDP/RSVPで同じlabel番号を使われると正常に通信が行えなくなるためです。
この機能は大抵のSR対応機器で実装されています。

Interworking
LDP網との相互接続を実現する機能としてSRMS（SR Mapping Server）があります。
SRMSは宛先がLDP網内のルータとなる通信を行う際に、宛先ルータ代わりにNode-SID情報を配信します。
宛先がSR網内のルータとなる通信では、宛先ルータのNode-SID情報はルータ自身が配信しているためSRMSは必要ありません。
また、RSVP網との相互接続を実現する機能は今のところ存在しません。

MPLSにおけるSRの適用については上記の様な現状です。
続いてSRのもう1つの適用対象であるIPv6におけるSR（以下、SRv6）の現状について見ていきます。

SRv6の現状

SRv6ではlabelの代わりにSRH（SR Header）と呼ばれるIPv6拡張ヘッダを用いてパケットの転送が行われます。
そのためMPLSを使用していない環境に対してもSRを適用することができ、MPLSと同様にTraffic EngineeringやFRR（TI-LFA）といった転送を最適化する機能を使用出来る様になります。
またSID長が128ビットと長いため、転送先の指定（Locator）だけでなくパケットを受け取った時のAction（Function）も合わせて指定することが想定されています。
しかしながらLocatorによるパケット転送動作については仕様が固まった印象ですが、Functionの定義に関しては検討中の状況です。
そのためSRv6が実装されたルータ製品はまだ存在していない状況です。（Linuxでは実装されています）

＜SRHでのSIDフォーマット＞

SRの将来

ここまでMPLSとIPv6におけるSR適用の現状について見てきました。
これを踏まえ、今後SRの技術や利用がどの様に進んで行くのかについて考えてみたいと思います。

MPLSへの適用
SR自体の動作に関する仕様については殆ど固まった様に見受けられます。
機器への機能実装も成熟してきていますので、今後は実網への適用も広がっていくと思われます。
しかしながら現時点では既存のLDP/RSVPに対する明確なメリットを打ち出せていないため、当面は既存網からのリプレースではなく新規網での適用という形が多いものと想定しています。
そしてその先、SDN Controllerの開発やAIの利用等によりNetworkの自動化が進んでくると、SDNとの親和性の高さを生かしてSRの爆発的な普及が起こる可能性もあるのではないかと考えています。

IPv6への適用
現状Functionの定義については検討中ですが、ここには様々な機能を載せることができます。
例えばL2/L3 VPNの機能を載せると、MPLSに対応していなくてもMPLSと同様のL2/L3 VPNサービスを提供することが可能となります。
同じ様にVLANやtunnelingなど現在使用されている通信メカニズム、さらには現在議論されているService ChainingやNFV/Linux Container間の接続についてもFunctionを定義することで、全ての通信をSRv6という1つの仕組みで実現できる可能性があります。
そのため、これまで動きの鈍かったIPv6の普及がSRv6を切っ掛けに急激に進む可能性もあるかと考えています。

まとめ

連載最後の今回はMPLSとIPv6それぞれでのSR適用の現状と将来について説明しました。
入門としては少し内容が細かかったかもしれませんが、SR全体の進捗状況や期待されている役割について大まかに把握いただけていれば幸いです。

執筆者プロフィール

高田聡士

ネットワンシステムズ株式会社ビジネス推進本部応用技術部コアネットワークチーム
SP事業会社のコアネットワークにNIerとして7年弱携わる
当時の主な担当製品はCisco社のCRSシリーズ
5年ほど前に現部署に異動し、Cisco社含めたハイエンドルータ製品を担当
現在はSP-SDN分野に注力中

情報処理「ネットワークスペシャリスト」
CCIE RS #50857

Webからのお問い合わせはこちらから

お問い合わせ窓口へ

ナレッジセンターを検索する

電子カタログ