RFC 8402: セグメント・ルーティング・アーキテクチャ

概要

セグメント・ルーティング(SR)は、ソース・ルーティング・パラダイムを活用している。ノードは、「セグメント」と呼ばれる順序付き命令リストを通じてパケットを誘導する。セグメントは、トポロジまたはサービス・ベースの任意の命令を表すことができる。セグメントは、SRノードに対してローカルなセマンティックを持つことも、SRドメイン内でグローバルなセマンティックを持つこともできる。SRは、SRドメインへのイングレス・ノードにおいてのみ、フローごとの状態を維持しながら、フローを特定のトポロジ・パスに制限することが可能なメカニズムを提供する。

SRは、フォワーディング・プレーンを変更することなく、MPLSアーキテクチャに直接適用できる。セグメントは、MPLSラベルとしてエンコードされる。セグメントの順序付きリストは、ラベルのスタックとしてエンコードされる。処理するセグメントは、スタックの一番上にある。セグメントの処理が完了すると、関連するラベルがスタックからポップされる。

SRは、新しいタイプのルーティング・ヘッダを持つIPv6アーキテクチャに適用できる。セグメントは、IPv6アドレスとしてエンコードされる。セグメントの順序付きリストは、ルーティング・ヘッダ内のIPv6アドレスの順序付きリストとしてエンコードされる。アクティブなセグメントは、パケットの宛先アドレス(DA)によって示される。次のアクティブ・セグメントは、新しいルーティング・ヘッダ内のポインタによって示される。

本文書の位置付け

本文書はインターネット標準化過程の文書である。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc8402>で入手できる。

著作権表示

Copyright (c) 2018 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

セグメント・ルーティング(SR)は、ソース・ルーティング・パラダイムを活用する。ノードは、「セグメント」と呼ばれる順序付き命令リストとしてインスタンス化されたSRポリシーを通じてパケットを誘導する。セグメントは、トポロジまたはサービス・ベースの任意の命令を表すことができる。セグメントは、SRノードに対してローカルなセマンティックを持つことも、SRドメイン内でグローバルなセマンティックを持つこともできる。SRは、SRドメインへのイングレス・ノードでのみフローごとの状態を維持しながら、フローごとの明示的なルーティングをサポートする。

セグメントは、セグメント識別子(SID)で参照されることが多い。

セグメントは、トポロジ命令に関連付けられる場合がある。トポロジカルなローカル・セグメントは、特定の送信インタフェースを介してパケットをフォワーディングするようにノードに指示することができる。トポロジカル・グローバル・セグメントは、特定のパスを介してパケットを宛先にフォワーディングするよう、SRドメインに指示することができる。同じ宛先に対して異なるセグメントが存在し、それぞれが異なるパスの目的(例えば、メトリックを最小化するか、どのような制約を指定するかなど)を持つ場合がある。

セグメントは、サービス命令(例: パケットはセグメントに関連付けられたコンテナまたは仮想マシン(VM)によって処理する必要がある)に関連付けられている場合がある。セグメントは、QoS処理(例: このセグメントで受信したパケットをx Mbpsでシェーピングする)に関連付けられている場合がある。

SRアーキテクチャは、セグメントに関連するあらゆるタイプの命令をサポートする。

SRアーキテクチャは、分散型、集中型、ハイブリッド型のあらゆるタイプのコントロール・プレーンをサポートする。

分散型シナリオでは、セグメントはIS-IS、OSPF、BGPによって割り当てられ、シグナリングされる。ノードは、SRポリシー(例えば、事前に計算されたローカル・プロテクション[RFC8355])に基づいてパケットを誘導することを個別に決定する。ノードは、SRポリシーを個別に計算する。

集中型シナリオでは、セグメントはSRコントローラによって割り当てられ、インスタンス化される。SRコントローラは、どのノードがどのパケットをどのソース・ルーティング・ポリシーに基づいて誘導する必要があるかを決定する。SRコントローラは、ソース・ルーティング・ポリシーを計算する。SRアーキテクチャは、コントローラがネットワークをプログラムするかどうかを制限しない。考えられる選択肢は、ネットワーク構成プロトコル(NETCONF)、パス計算要素通信プロトコル(PCEP)、BGPである。SRアーキテクチャは、SRコントローラの数を制限しない。具体的には、複数のSRコントローラが同じSRドメインをプログラムできる。SRアーキテクチャにより、これらのSRコントローラは、どのSIDがどのノードでインスタンス化されているか、及び、どのノードでどのローカル・ラベル(SRLB)とグローバル・ラベル(SRGB)・セットが利用できる化を検出できる。

ハイブリッド型シナリオは、基本的な分散型コントロール・プレーンを集中型コントローラで補完する。例えば、宛先がIGPドメイン外にある場合、SRコントローラはIGPノードに代わってSRポリシーを計算する。SRアーキテクチャは、分散コントローラ・プレーンの一部であるノードがどのようにSRコントローラと対話するかを制限しない。考えられる選択肢はPCEPとBGPである。

ホストはSRドメインの一部になる場合がある(MAY)。集中型コントローラは、これらのポリシーをホストにプッシュするか、ホストからの要求に応答することで、ポリシーについてホストに通知することができる。

SRアーキテクチャは、さまざまなデータ・プレーンでインスタンス化できる。本文書では、SRの2つのデータ・プレーンのインスタンス化、SR over MPLS (SR-MPLS)とSR over IPv6 (SRv6)を紹介する。

SRは、フォワーディング・プレーンに変更を加えることなく、MPLSアーキテクチャに直接適用できる[SR-MPLS]。セグメントはMPLSラベルとしてエンコードされる。SRポリシーは、ラベルのスタックとしてインスタンス化される。処理するセグメント (アクティブ・セグメント) は、スタックの最上部にある。セグメントが完了すると、関連するラベルがスタックからポップされる。

SRは、SRヘッダ(SRH)[IPv6-SRH]と呼ばれる新しいタイプのルーティング・ヘッダを使用してIPv6アーキテクチャに適用できる。命令はセグメントに関連付けられ、IPv6アドレスとしてエンコードされる。SRv6セグメントはSRv6 SIDとも呼ばれる。SRポリシーは、ルーティング・ヘッダ内のSRv6 SIDの順序付きリストとしてインスタンス化される。アクティブ・セグメントは、パケットの宛先アドレス(DA)によって示される。次のアクティブ・セグメントは、SRH内のSegmentsLeft (SL)ポインタによって示される。SRv6 SIDが完了すると、SLはデクリメントされ、次のセグメントがDAにコピーされる。パケットがSRポリシー上でステアリングされると、関連するSRHがパケットに追加される。

IGPベースの分散コントロール・プレーンの文脈では、IGP-隣接セグメントとIGPプレフィックス・セグメントの2つのトポロジカル・セグメントを定義する。

BGPベースの分散コントロール・プレーンの文脈では、BGPピアリング・セグメントとBGPプレフィックス・セグメントという2つのトポロジカル・セグメントを定義する。

SRポリシーのヘッドエンドは、SID(バインディング・セグメントまたはBSIDと呼ばれる)をそのポリシーにバインドする。ヘッドエンドがローカルSRポリシーのBSIDと一致するアクティブ・セグメントを持つパケットを受信すると、ヘッドエンドはそのパケットを関連するSRポリシーにステアリングする。

本文書では、SR-MPLSとSRv6データ・プレーンのIGP、BGP、バインディング・セグメントを定義する。

注記: 本文書は、セグメント・ルーティングのアーキテクチャを定義する。これには、基本的なオブジェクトと機能の定義、全体的な設計の説明を含む。アーキテクチャを実装する方法は定義しない。アーキテクチャの実装方法は多くの参照文書に含まれており、そのうちのいくつかは読者の便宜のために本文書で言及する。

2. 用語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

SR-MPLS: MPLSデータ・プレーン上でのSRのインスタンス化。

SRv6: IPv6データ・プレーン上でのSRのインスタンス化。

セグメント: ノードが着信パケットに対して実行する命令(例えば、宛先への最短パスに従ってパケットをフォワーディングする、特定のインタフェースを介してパケットをフォワーディングする、または特定のアプリケーション/サービス・インスタンスにパケットを配信する)。

SID: セグメント識別子。SIDという用語は「セグメント」という用語の代わりによく使われるが、これは必要な翻訳を見落としているため、技術的に不正確である。

SR-MPLS SID: セグメントに明示的に関連付けられたMPLSラベルまたはMPLSラベル空間へのインデックス値。

SRv6 SID: セグメントに明示的に関連付けられたIPv6アドレス。

セグメント・ルーティング・ドメイン(SRドメイン): ソースベースのルーティング・モデルに参加するノード・セット。これらのノードは同じ物理インフラ(サービス・プロバイダのネットワークなど)に接続されている場合がある。また、相互にリモート接続されている場合もある(エンタープライズVPNやオーバーレイなど)。複数のプロトコル・インスタンスが展開されている場合、SRドメインにはネットワーク内のすべてのプロトコル・インスタンスを含むのが一般的である。しかし、ネットワークを複数のSRドメインに分割し、それぞれのSRドメインに1つ以上のプロトコル・インスタンスを含めることもできる。SRドメイン内のすべてのノードは、同じ管理エンティティによって管理されることが想定される。

アクティブ・セグメント: 受信ルータがパケットを処理するために使用するセグメント。MPLS データ・プレーンでは最上位ラベルである。IPv6データ・プレーンでは宛先アドレスとなる[IPv6-SRH]。

PUSH: セグメント・リストの先頭にセグメントを挿入する操作。SR-MPLSでは、セグメント・リストの先頭はラベル・スタックの最上位(外側)ラベルである。SRv6では、セグメント・リストの先頭は[IPv6-SRH]で定義されているセグメント・ルーティング・ヘッダの最初のセグメントで表される。

NEXT: アクティブ・セグメントが完了すると、NEXTは次のセグメントの検査を行う操作である。次のセグメントはアクティブ・セグメントになる。SR-MPLSでは、NEXTは先頭ラベルのPOPとして実装される。SRv6では、NEXTはSRHからIPv6ヘッダの宛先アドレスへの次のセグメントのコピーとして実装される。

CONTINUE: アクティブ・セグメントが完了していないため、アクティブのままである。SR-MPLSでは、CONTINUE操作は先頭ラベルのSWAP[RFC3031]として実装している。SRv6では、これはプレーンなIPv6パケットを宛先アドレスに従ってフォワーディングする動作である。

SRグローバル・ブロック(SRGB): SRドメイン内のグローバル・セグメント・セット。ノードが複数のSRドメインに参加している場合、SRドメインごとに1つのSRGBが存在する。SR-MPLSでは、SRGBはノードのローカル・プロパティであり、グローバル・セグメント用に予約されたローカル・ラベル・セットを識別する。SR-MPLSでは、SRドメイン内のすべてのノードで同一のSRGBを使用することを強く推奨している。こうすることで、同じラベルが各ノードで同じグローバル・セグメントを表すため、操作やトラブル・シューティングが容易になる。SRv6では、SRGBはSRドメイン内のグローバルSRv6 SIDセットである。

SRローカル・ブロック(SRLB): SRノードのローカル・プロパティ。ノードが複数のSRドメインに参加している場合、SRドメインごとに1つのSRLBが存在する。SR-MPLSでは、SRLBはローカル・セグメント用に予約されたローカル・ラベル・セットである。SRv6では、SRLBはローカルSRv6 SID用に予約されたローカルIPv6アドレス・セットである。コントローラ駆動型ネットワークでは、コントローラやアプリケーションによっては、利用可能なローカル・セグメント・セットを検出するためにコントロール・プレーンを使用することがある。

グローバル・セグメント: ドメインのSRGBの一部であるセグメント。セグメントに関連付けられた命令は、SRドメイン・レベルで定義される。SRドメイン内の特定の宛先へのトポロジカル最短パス・セグメントは、グローバル・セグメントの典型的な例である。

ローカル・セグメント: SR-MPLSでは、SRGBの外側にあるローカル・ラベルである。これは、明示的に広告されたSRLBの一部である場合もある。SRv6では、これは任意のIPv6アドレスである。つまり、アドレスはSRGBの一部だが、ローカルな意味を持つように使用される。セグメントに関連付けられた命令は、ノード・レベルで定義される。

IGPセグメント: リンクステートIGPによって広告された情報の一部、例えばIGPプレフィックスやIGP隣接(adjacency)に付随する総称。

IGP-プレフィックス・セグメント: IGP-プレフィックス・セグメントは、IGPプレフィックスを表すIGPセグメントである。IGP-プレフィックス・セグメントがSR IGPインスタンス/トポロジ内でグローバルの場合、アルゴリズム・フィールド、トポロジ、および広告されたIGPインスタンスで指定されたルーティング・アルゴリズムを使用して計算されたパスに沿ってパケットを転送する命令を識別する。「プレフィックス・セグメント」とも呼ばれる。

プレフィックスSID: IGP-プレフィックス・セグメントのSID。

IGP-エニーキャスト・セグメント: IGP-エニーキャスト・セグメントは、ルータ・セットによって広告されるエニーキャスト・プレフィックスを識別するIGP-プレフィックス・セグメントである。

エニーキャスト-SID: IGP-エニーキャスト・セグメントのSID。

IGP-隣接セグメント: IGP-隣接セグメントは、単方向隣接または単方向隣接セットにアタッチされるIGP-セグメントである。デフォルトでは、IGP-隣接セグメントは、それを広告するノードに対してローカルである(明示的に広告されない限り)。「Adj-SID」とも呼ばれる。

Adj-SID: IGP-隣接セグメントのSID。

IGP-ノード・セグメント: IGP-ノード・セグメントは、特定のルータ(ループバックなど)を識別するIGP-プレフィックス・セグメントである。「ノード・セグメント」とも呼ばれる。

ノード-SID: IGP-ノード・セグメントのSID。

SRポリシー: セグメントの順序付きリスト。SRポリシーのヘッドエンドはパケットをSRポリシーにステアリングする。セグメントのリストは、SR-MPLSではラベル・スタックとして、SRv6では SRv6 SIDの順序付きリストとして明示的に指定することができる。あるいはは、セグメント・リストは、宛先と一連の最適化目的と制約(レイテンシ、アフィニティ、SRLGなど)に基づいて計算される。計算はローカルで行うことも、PCEサーバに委任することもできる。SRポリシーは、オペレータが構成することも、NETCONF[RFC6241] を介してプロビジョニングすることも、PCEP [RFC5440] を介してプロビジョニングすることもできる。SRポリシーは、トラフィック・エンジニアリング(TE)、運用、管理、保守(OAM)、または高速再ルーティング (FRR) の理由で使用できる。

セグメント・リストの深さ: SRポリシーのセグメントの数。ノードNでSRポリシーをインスタンス化するエンティティは、ノードNの深度挿入機能を検出できなければならない。例えば、[PCEP-SR-EXT]で説明しているPCEP SRケーパビリティの広告は、このケーパビリティを検出する1つの手段である。

フォワーディング情報ベース(FIB): ノードのフォワーディング・テーブル。

3. リンク・ステートIGPセグメント

SRドメイン内では、SR対応IGPノードは、その接続されたプレフィックスと隣接関係のセグメントを広告する。これらのセグメントは、「IGPセグメント」または「IGP SID」と呼ばれる。これらは、セグメント・ルーティングやユースケースにおいて重要な役割を果たし、SRドメイン全体で任意のパスを表現することができる。このようなパスは、単一のIGPセグメントまたは複数のIGPセグメントのリストとして表現する。

IGPセグメントの広告には、リンクステートIGPプロトコルの拡張が必要である。これらの拡張は、[ISIS-SR-EX]、[OSPF-SR-EXT]、[OSPFv3-SR-EXT]で定義されている。

3.1. IGP-プレフィックス・セグメント (プレフィックスSID)

IGP-プレフィックス・セグメントは、IGP-プレフィックスにアタッチされたIGPセグメントである。IGP-プレフィックス・セグメントは、SRドメイン内でグローバルである(明示的に広告されない限り)。IGP-プレフィックス・セグメントの文脈には、プレフィックス、トポロジ、アルゴリズムが含まれる。タプル<プレフィックス,トポロジ, アルゴリズム>がユニークである限り、同じプレフィックスに複数のSIDを割り当てることができる。

複数インスタンスとトポロジは、IS-ISとOSPFの[RFC5120]、[RFC8202]、[RFC6549]、[RFC4915] で定義されている。

3.1.1. プレフィックス-SIDアルゴリズム

セグメント・ルーティングは、複数のルーティング・アルゴリズムの使用をサポートしている。つまり、さまざまな制約ベースの最短パス計算をサポートすることができる。アルゴリズム識別子は、プレフィックス-SID広告の一部として含まれている。アルゴリズム固有のパス計算がどのように行われるかの仕様は、アルゴリズムを定義する文書で必要となる。

本文書では、以下の2つのアルゴリズムを定義する。

• 最短パス優先(Shortest Path First): このアルゴリズムはデフォルトの動作である。パケットは、IGPが採用している周知のECMP対応の最短パス優先(SPF)アルゴリズムに沿ってフォワードされる。ただし、ミッドポイントがローカル・ポリシーに基づいて別のフォワーディングを実装することは明示的に許されている。実際、最短パス優先アルゴリズムは、ローカル・ポリシーがSPFの決定を上書きする可能性があるほとんどのネットワークのデフォルトかつ現在の動作である。

• 厳密な最短パス優先(Strict-SPF): このアルゴリズムは、ECMP対応のSPFアルゴリズムに従って、パケットをフォワーディングすることを義務付け、SPFの決定を上書きする可能性のあるローカル・ポリシーを無視するように、パス内のルータに指示する。Strict-SPFアルゴリズムで広告されるSIDは、パケットがたどるパスは変更されず、想定されるSPFパスであることを保証する。Fast Reroute (FRR)[RFC5714]メカニズムは、依然として厳密な最短パス優先アルゴリズムに準拠していることに留意する。つまり、Strict-SPFのSIDで受信したパケットは、FRRメカニズムを通じて再ルーティングされる可能性がある。Strict-SPFは、最短パス優先アルゴリズムで使用されるのと同じトポロジを使用する。当然、Strict-SPFをサポートしないノードは、このアルゴリズムのフォワーディング・エントリをインストールしない。このアルゴリズムをサポートするノードのみにトポロジーを制限しても、望ましい動作は最短パス優先アルゴリズムによって計算されたパスに従うことなので、望ましいフォワーディング・パスは生成されない。したがって、ソースSRノードは、パスがStrict-SPFアルゴリズムをサポートしていないノードを通過する場合、厳密なSPFセグメントを含むSRポリシーを使用してはならない(MUST NOT)。

IGP-プレフィックス・セグメントは、関連するアルゴリズムに従って計算された、関連するプレフィックスへのパスを識別する。アクティブなプレフィックス-SIDを持つSRドメイン内の任意の場所に注入されたパケットは、指定されたアルゴリズムを使って計算されたパスに沿ってフォワーディングされることが想定される。これが可能であるためには、指定されたアルゴリズムをサポートするルータの完全に接続されたトポロジーが必要である。

3.1.2. SR-MPLS

SRがMPLSデータ・プレーン上で使用される場合、SIDはMPLSラベルまたはMPLSラベル空間(SRGBまたはSRLB)へのインデックスである。

可能であれば、SRドメイン内のすべてのノードで同一のSRGBを設定することを推奨する。これにより、すべてのノードで同じラベルが同じプレフィックスに関連付けられ、トラブルシューティングが簡単になる。さらに、セクション3.3で説明しているように、エニーキャストのサポートが簡単になる。

以下の動作は、MPLSデータ・プレーン上で動作するSRに関連付けられている。

• IGP-プレフィックス・セグメントのIGPシグナリング拡張には、プレフィックスがアタッチされているノードに直接接続されている隣接ノードがSIDを処理するときにNEXT操作を実行すべきか、CONTINUE操作を実行すべきかを示すフラグが含まれている。この動作は、MPLSにおけるPenultimate Hop Popping (NEXT)やUltimate Hop Popping (CONTINUE)に相当する。

• プレフィックス-SIDは、IPアドレス割り当てと同様のプロセスに従い、MPLSラベル(またはSRGB内のインデックス)の形式で割り当てられる。通常、プレフィックス-SIDは、オペレータ(またはネットワーク管理システム(NMS))のポリシーによって割り当てられ、SIDが変更されることはほとんどない。

• SRではローカル・セグメントをIGP-プレフィックスにアタッチできるが、「IGP-プレフィックス・セグメント」または「プレフィックス-SID」という用語が使用されている場合、セグメントはグローバルであると見なされる(つまり、SID は広告されたSRGBから定義される)。これは、IGP-プレフィックスにグローバル・セグメントをアタッチする必要があり、説明されているすべてのユースケースと一致している。

• 割り当てプロセスでは、同じプレフィックス-SIDを異なるプレフィックスに割り当ててはならない(MUST NOT)。

• ノードがローカルに設定されたSRGB範囲外の値を持つプレフィックス-SIDを認識した場合、ノードはそのプレフィックス-SIDを使用せず、設定ミスを報告するエラーログを発行する必要がある(SHOULD)。

• ノードNが、NにアタッチされたプレフィックスRに対して、プレフィックス-SID SID-Rを広告し、直接接続されている隣接ノードが実行する操作としてCONTINUEを指定した場合、Nは次のFIBエントリを保持しなければならない(MUST)。

  • 着信アクティブ・セグメント: SID-R
  • イングレス操作: NEXT
  • エグレス・インタフェース: NULL

• リモート・ノードMは、プレフィックスRにアタッチされた学習済みプレフィックス-SID SID-Rに対して、以下のFIBエントリを保持しなければならない。

  • 着信アクティブ・セグメント: SID-R
  • イングレス操作:
    If Rのネクストホップが is Rの発信元
    and Mがアクティブ・セグメントの削除を指示されている場合: NEXT
    Else: CONTINUE
    
  • エグレス・インタフェース: プレフィックスRに向け、SIDで広告されたアルゴリズムを使用して計算されたパスに沿って、ネクストホップに向かうインタフェース。

プレフィックス-SIDは特定のアルゴリズムに固有のものであるため、アルゴリズムに関連付けられたトラフィックがそのアルゴリズムをサポートしていないノードに到着すると、着信ラベルに一致するフォワーディング・エントリが存在しないため、トラフィックは破棄される。

3.1.3. SRv6

SRがIPv6データ・プレーンで使用される場合:

• プレフィックス-SIDはIPv6アドレスである。

• オペレータはSRv6 SIDを明示的にインスタンス化しなければならない(MUST)。IPv6ノード・アドレスは、デフォルトではSRv6 SIDではない。

セグメント識別子として使用可能なIPv6アドレスRを広告するノードNは、以下のFIBエントリを保持しなければならない(MUST):

着信アクティブ・セグメント: R
イングレス操作: NEXT
エグレス・インタフェース: NULL

Rへのフォワーディングは、他のすべてのルータのFIBにRのエントリを必要としないことに留意する。Rへのフォワーディングは、Rをカバーする、より短いマスク・プレフィックスによって実現できる(ほとんどの場合、実現できる)。

SRのサポートとは関係なく、リモートIPv6ノードはプレフィックスがセグメントを表すかどうかに関係なく、どのプレフィックスに対してもプレーンなIPv6のFIBエントリを保持する。これにより、SRをサポートしていないノードでも、SIDを所有するノードにパケットをフォワーディングできる。

複数のアルゴリズムのサポートはSRv6に適用される。アルゴリズム固有のSIDは単なるIPv6アドレスなので、アルゴリズム固有のフォワーディング・エントリは、ノードが割り当てるアルゴリズム固有の SID(のセット)にアルゴリズム固有のサブネットを割り当てることで実現できる。

あるアルゴリズムをサポートしていないノードは、そのノードによってアルゴリズム固有のパスが計算されていなくても、アルゴリズム固有のアドレスをカバーするFIBエントリを持つことがある。これは、与えられたアルゴリズムをサポートしていないノードがそのアルゴリズム固有のSPFに関連付けられたトポロジに含まれないという事実によって軽減される。したがって、アルゴリズム固有の宛先を使用するトラフィックは、通常、除外されたノードを経由して流れない。そのようなトラフィックが到着し、そのようなノードによってフォワーディングされたとしても、トラフィックは宛先ノードに向かって進む。ネクストホップは、アルゴリズムをサポートするノード(この場合、パケットはアルゴリズム固有のパスに沿ってフォワードされる(または、利用可能なパスがない場合は破棄される))か、アルゴリズムをサポートしないノード(この場合、パケットは引き続きアルゴリズム0のパスに沿って宛先ノードに向かってフォワードされる) のいずれかとなる。

3.2. IGP-ノード・セグメント(ノードSID)

IGP-ノードSIDは、同じルーティング・ドメイン内の複数のルータが所有するプレフィックスに関連付けてはならない(MUST NOT)。

3.3. IGP-エニキャスト・セグメント(エニキャスト-SID)

エニキャスト・セグメントまたはエニキャスト-SIDは、ECMPを考慮した最短パス・フォワーディングを、エニキャスト・セットの最も近いノードに向けて強制する。これは、マクロ・エンジニアリングのポリシーや保護メカニズムを表現するのに役立つ。

IGP-エニキャスト・セグメントは特定のノードを参照してはならない(MUST NOT)。

エニキャスト・グループ内で、SRドメイン内のすべてのルータは、同じSID値を持つ同じプレフィックスを広告しなければならない(MUST)。

3.3.1. SR-MPLSのエニキャスト-SID

図1: トランジット・デバイス・グループ

図1は、2つのトランジット・デバイス・グループを持つネットワークの例を示している。グループAは、デバイスA1、A2、A3、A4で構成されている。これらはすべて、エニーキャスト・アドレス192.0.2.10/32とエニーキャストSID 100でプロビジョニングされている。

同様に、グループBはデバイスB1、B2、B3、B4で構成され、すべてエニーキャスト・アドレス192.0.2.1/32とエニーキャストSID 200でプロビジョニングされている。上記のネットワーク・トポロジでは、各プロバイダ・エッジ(PE)デバイスは、グループAとBへのそれぞれのパスを持っている。

PE1は、トラフィックをPE3またはPE4に送信するとき、特定のトランジット・デバイス・グループを選択できる。これは、スタック内のグループのエニーキャスト-SIDをプッシュすることで行われる。

エニーキャストとそれに続くセグメントの処理には特別な注意が必要である。

図2: エニーキャスト・グループA経由のトランジット・パス

MPLSの展開を考慮すると、上記のトポロジで、デバイスPE1(またはPE2)がデバイスPE3(またはPE4)にパケットを送信する必要がある場合、以下のラベル・スタックを用いてパケットをMPLSペイロードにカプセル化する必要がある。

• R1がエニーキャスト-SID 100に対して割り当てたラベル(外部ラベル)

• グループA内の最も近いルータがSID 30(宛先PE3)に割り当てたラベル。

この場合、最初のラベルは簡単に計算できる。しかし、トポロジ的に最も近いデバイスが複数あるため(A1とA2)、A1とA2が同じプレフィックスに同じラベル値を割り当てない限り、2番目のラベルを決定することは不可能である。デバイスA1とA2は、異なるハードウェア・ベンダーのデバイスの可能性がある。両方がSID 30に同じラベル値を割り当てていない場合、エニーキャスト・グループAをPE3へのトランジット・エニーキャスト・グループとして使用することはできない。したがって、PE1 (またはPE2)は、パケットをグループAデバイスのみにステアリングするための適切なラベル・スタックを計算することができない。PE3やPE4が、PE1やPE2にパケットを送信しようとする場合も同様である。

エニーキャスト・セグメントを使い易くするために、特定のエニーキャスト・グループのすべてのノードで同一のSRGBを設定することを推奨する。前述のように、この方法を使用すると、エニーキャスト・セグメントに続くラベルの計算が簡単になる。

同じエニーキャスト・グループに属するすべてのノードに同一の SRGBを設定せずにエニーキャスト・セグメントを使用すると、ルーティング・ミスが発生する可能性がある(MPLS VPNの展開では、一部のトラフィックがVPN間でリークする可能性がある)。

3.4. IGP隣接セグメント(Adj-SID)

隣接(adjacency)は、ローカル・ノード(つまり、IGPで隣接を広告するノード)とリモート・ノード(つまり、隣接のもう一方の端)によって形成される。ローカル・ノードはIGPノードでなければならない(MUST)。リモート・ノードは、隣接するIGPネイバーでも、隣接しないネイバー(例えば、フォワーディング隣接、[RFC4206])でもどちらでもよい。

セグメント・リスト{SN, SNL}を持つSRドメイン内の任意の場所に注入されたパケット(SNはノードNのノードSID、SNLはノードNによってリンクL経由で隣接にアタッチされたAdj-SID)は、最短パスに沿ってNにフォワーディングされ、IP最短パスを考慮することなく、NによってリンクLに切り替えられる。Adj-SIDが隣接関係セットを識別する場合、ノードNはセットのさまざまなメンバー間でトラフィックを負荷分散する。

同様に、グローバルAdj-SIDを使用する場合、セグメント・リストSNLを持つSRドメイン内の任意の場所に注入されたパケット(SNLはノードNによってリンクL経由で隣接にアタッチされたグローバルAdj-SID)は、最短パスに沿ってNにフォワードされ、IP最短パスを考慮することなく、NによってリンクLに切り替えられる。Adj-SIDが隣接関係セットを識別する場合、ノードNはセットのさまざまなメンバー間でトラフィックを負荷分散する。グローバルAdj-SIDを使用すると、追加の状態を犠牲にして、パスを表現するときにセグメント・リストのサイズを縮小することができる(つまり、グローバルAdj-SIDは、エリア内のすべてのルータによって転送テーブルに挿入される)。

「IGP-隣接セグメント」または「Adj-SID」は、ノードから定義されたインタフェースまたはインタフェース・セットへのパケットの切り替え(スイッチ)を強制する。これは、どんなパスでもセグメントのリストとして表現できることを理論的に証明する鍵である。

Adj-SIDのエンコーディングには、以下の機能をサポートするフラグ・セットが含まれる:

• プロテクション対象(IPFRRやMPLS-FRRの使用など)。プロテクションにより、Adj-SIDに関連付けられたインタフェースがダウンした場合でも、パケットを代替パス経由でフォワードできる。プロテクションの使用は明らかにポリシーに基づいた決定である。つまり、ポリシーによっては、プロテクションが望ましい場合と望ましくない場合がある。

• Adj-SIDにローカル・スコープかグローバル・スコープかを示す。デフォルトのスコープはローカルの必要がある(SHOULD)。

• Adj-SIDがコントロール・プレーンの再起動後も永続的であるかどうかを示す。永続性は、SRポリシーがAdj-SIDの再割り当てによって一時的にミスフォワーディング(誤転送)を起こさないようにするための重要な属性である。

重み(以下で説明)もAdj-SID広告に関連付けられる。

ノードは、隣接ごとに1つのAdj-SIDを割り当てる必要がある(SHOULD)。

ノードは、同じ隣接に対して複数のAdj-SIDを割り当てることができる(MAY)。例えば、プロテクションの対象となるAdj-SIDとプロテクションの対象とならないAdj-SIDをサポートする場合が挙げられる。

ノードは、同じAdj-SIDを複数の隣接関係に関連付けることができる(MAY)。

2つのノード間のIGP隣接を表すすべてのAdj-SIDをIGP 広告できるようにするためには、IGPで並列隣接の抑制を行ってはならない(MUST NOT)。

ノードがAdj-SID Vをローカル・データ・リンクLにバインドする場合、ノードは次のFIB エントリをインストールしなければならない(MUST)。

着信アクティブ・セグメント: V
イングレス操作: NEXT
エグレス・インタフェース: L

Adj-SIDは、それを広告するルータから、IGP/SPFコストに関係なく、Adj-SIDによって識別される隣接を介してパケットをフォワードすることを意味する。つまり、隣接セグメントを使うことは、SPFアルゴリズムによって行われたルーティング決定が上書きする。

3.4.1. 並列隣接関係

Adj-SIDは、2つの隣接ルータ間の並列インタフェース・セットを表すために使用できる。

ノードは、リンクBのセットにアタッチされた値Wのローカルで生成されたAdj-SIDのFIBエントリをインストールしなければならない(MUST)。

着信アクティブ・セグメント: W
イングレス操作: NEXT
エグレス・インタフェース: セットB内の任意のデータリンク間のロードバランス

並列隣接が使用され、同じAdj-SIDに関連付けられている場合、ロードバランス機能を最適化するために、各隣接で広告されるAdj-SIDに「重み」係数を関連付けることができる。重みは、イングレス(またはSDN/オーケストレーション・システム)に並列隣接の負荷分散係数を伝える。図3に示すように、AとBは2つの並列隣接を介して接続されている。

図3: 並列リンクとAdj-SID

ノードAは以下のAdj-SIDと重みを広告する:

• リンク1: Adj-SID 1000, 重み: 1

• リンク2: Adj-SID 1000, 重み: 2

ノードSは並列隣接関係の広告を受信し、Adj-SID 1000を使用することで、ノードAが並列リンク(リンク1とリンク2)間でトラフィックを1:2の比率で負荷分散すること、つまり、リンク2にはリンク1の2倍のパケットが流れることを理解する。

3.4.2. LAN隣接セグメント

LANサブネットワークでは、リンク・ステート・プロトコルはブロードキャスト・サブネットワークでフラッディングを行う指定ルータ(OSPFではDR)または指定中間システム(IS-ISではDIS)の概念を定義し、特別なルーティング・アップデート(OSPFタイプ 2 LSAまたはIS-IS擬似ノードLSP)でLANトポロジを記述する。LANの難点は、各ルータがDR/DISへの接続性のみ広告し、LAN内の個々のノードへの接続性は広告しない。したがって、LAN内の各ルータがLAN内の各隣接ノードに関連付けられたAdj-SIDを広告するには、追加のプロトコル・メカニズム(IS-ISとOSPF)が必要となる。

3.5. エリア間の考慮事項

次の図の例では、すべてのエリアが単一のSRドメインの一部であると想定している。

図4では、MPLSデータ・プレーンを含むIPv6コントロール・プレーンを想定している。

図4: エリア間トポロジの例

エリア2では、ノードZは自分のローカルIPv6プレフィックス 2001:DB8::2:1/128にノード-SID 150を割り当てる。

エリア・ボーダー・ルータ(ABR)GとJは、通常のエリア間/レベルIGP伝搬ルールに従って、プレフィックスの新しいインスタンスを作成することで、プレフィックスとそのSIDをバックボーン・エリアに伝搬する。

ノードCとIは、バックボーン・エリアからエリア1にプレフィックスをリークするときも、同じ動作を適用する。したがって、ノードSは、プレフィックスSID 150を持ち、ノードCとIによって広告されたプレフィックス2001:DB8::2:1/128を参照することになる。

したがって、結果として、プレフィックス-SIDは、エリア間プロセスを通じて関連するIGP-プレフィックスにアタッチされたままとなり、これはシングルSRドメインで予想される動作である。

ノードSがトラフィックを2001:DB8::2:1/128に送信すると、ノード-SID(150)をアクティブ・セグメントとしてプッシュし、Aにフォワードする。

パケットがABR I(またはC)に到着すると、ABRはアクティブ・セグメント(ノード-SID(150))に従ってパケットをフォワードする。フォワーディングは、パケットが宛先に到達するまで、同じノード-SID(150)を使用して、エリア境界を越えて継続する。

4. BGPセグメント

BGPセグメントは、BGPによって割り当てられ、配布されることがある。

4.1. BGP-プレフィックス・セグメント

BGP-プレフィックス・セグメントは、BGP-プレフィックスにアタッチされたBGPセグメントである。

BGP-プレフィックス・セグメントは、SRドメイン内でグローバルである(明示的に広告されない限り)。

BGP-プレフィックス・セグメントは、IGPプレフィックス・セグメントに相当する。

BGP-プレフィックス・セグメントの使用例として考えられるのは、接続がBGPのみを介して学習されるIGPを使用しないハイパースケール・スパイン・リーフ・トポロジである[RFC7938]

4.2. BGPピアリング・セグメント

[SR-CENTRAL-EPE]で説明されているように、BGPエグレス・ピア・エンジニアリング(EPE)の文脈では、EPE対応のエグレス・ノードは、アタッチされたピアに対応するセグメントを広告することができる(MAY)。これらのセグメントは、BGPピアリング・セグメントまたは BGPピアリングSIDと呼ばれる。これらのセグメントによって、ソース・ルートされたドメイン間パスの表現が可能になる。

自律システム (AS)のイングレス・ボーダー・ルータは、AS内の選択されたパスに沿って、ASの選択されたエグレス・ボーダー・ルータCに向かい、特定のピアを経由するフローを誘導するために、セグメントのリストを作成することができる。イングレス・ノードに適用されるBGPピアリング・エンジニアリング・ポリシーには、選択されたエグレス・ノードのNode-SIDと、選択されたエグレス・ノードのピアまたはピアリング・インタフェースの BGPピアリング・セグメントという少なくとも2つのセグメントが含まれる。

PeerNode SID、PeerAdj SID、PeerSet SIDの3種類のBGPピアリング・セグメント/SIDが定義されている。

• PeerNode SID: BGP PeerNodeセグメント/SIDはローカル・セグメントである。これを広告するBGPノードでは、そのセマンティクスは以下のようになる。

  • SR操作: NEXT
  • ネクストホップ: セグメントが関連付けられている接続されたピアリング・ノード

• PeerAdj SID: BGP PeerAdjセグメント/SIDはローカル・セグメントである。これを広告するBGPノードでは、セマンティクスは以下のようになる:

  • SR操作: NEXT
  • ネクストホップ: セグメントが関連付けられているインタフェースを介して接続されているピア

• PeerSet SID: BGP PeerSetセグメント/SIDはローカル・セグメントである。これを広告するBGPノードでは、セマンティクスは以下のようになる:

  • SR操作: NEXT
  • ネクストホップ: 関連付けられているグループ内の任意のピアに接続されたインタフェースを介してロードバランスをする

  ピア・セットは、同じASからのすべての接続ピア、またはこれらのサブセットになる。グループは複数のASにまたぐこともできる。グループの定義は、オペレータが設定するポリシーである。

これらのBGPピアリング・セグメントをシグナリングするために必要なBGP拡張は、[BGPLS-SR-EPE]で定義されている。

5. バインディング・セグメント

スケーラビリティ、ネットワークの不透明性、サービスの独立性を高めるために、SRはバインディングSID(BSID)を利用する。BSIDはSRポリシーにバインドされ、そのインスタンス化にはSIDのリストが含まれる。BSIDと同じアクティブ・セグメントを持つ受信パケットはすべて、バインドされたSRポリシーに誘導される(steered)。

BSIDは、ローカルSIDでも、グローバルSIDでもよい。ローカルの場合、BSIDはSRLBから割り当てる必要がある(SHOULD)。グローバルの場合、BSIDはSRGBから割り当てられなければならない(MUST)。

BSIDを使用することで、ポリシーのインスタンス化(SIDリスト)を、ポリシーを適用する必要のあるノードにのみ保存することができる。ポリシーをサポートするノードへのトラフィックの方向は、BSIDを適用することのみを必要とする。ポリシーが変更された場合、ポリシーを適用するノードのみを更新する必要がある。ポリシーのユーザは影響を受けない。

5.1. IGPミラーリング・コンテキスト・セグメント

バインディング・セグメントの使用例の1つは、ミラーリング・コンテキスト・セグメントが、ミラーリングされたノードにローカル・サービス・セグメントの前にセグメント・リストに挿入されていることを条件として、別のIGP-ノード(「ミラーリング・ノード」と呼ばれ、IP アドレスまたはノード-SIDで識別される)に元々向けられたトラフィックを処理する能力をIGP-ノードが広告できるようにサポートすることである。

指定されたノードBがエグレス・ノードAの保護を提供する場合、ノードAのコンテキストを識別するセグメントを広告する。このようなセグメントは「ミラーリング・コンテキスト・セグメント」と呼ばれ、ミラー-SIDで識別される。

ミラー-SIDは、SR IGPプロトコル拡張 [ISIS-SR-EXT]で定義されているバインディング・セグメントを使用して広告される。

障害が発生した場合、AからBへトラフィックを迂回させるローカル修復ポイント(PLR)は、保護されたトラフィックに対してミラー-SIDのPUSHを実行する。ミラー-SIDをアクティブ・セグメントとしてトラフィックを受信すると、Bはそのセグメントを使用し、Aのコンテキストで基礎となるセグメントを処理する。

6. マルチキャスト

セグメント・ルーティングはユニキャスト用に定義している。ソース・ルートの概念をマルチキャストに適用することは、本文書の範囲外である。

7. IANA の考慮事項

本文書にはIANAアクションはない。

8. セキュリティに関する考慮事項

セグメント・ルーティングは、MPLSとIPv6データ・プレーンの両方に適用できる。

SRは、パケットにメタデータ(指示)を追加し、パケットが通過しなければならないフォワーディング・パス要素(ノード、リンク、サービスなど)のリストを追加する。完全なソース・ルート・パスは、1 つのセグメントで表される場合があることに注意する。これは、バインディング-SIDの場合である。

デフォルトでは、SRは信頼されたドメイン内で動作する。トラフィックは、ドメイン境界でフィルタリングしなければならない(MUST)。

信頼されたドメイン内での改ざんのリスクを軽減するためのベスト・プラクティスの使用は重要である。このようなプラクティスは[RFC4381]で説明されており、SR-MPLSとSRv6の両方に適用できる。

8.1. SR-MPLS

MPLSデータ・プレーンに適用する場合、SRは新しい動作を導入したり、MPLSデータ・プレーンの動作方法を変更したりすることはない。したがって、セキュリティの観点から、本文書はMPLSデータ・プレーンに追加のメカニズムは定義しない。

SRは、1つのセグメント(バインディング-SID)を使用してソース・ルート・パスを表現できる。明示的なルーティング機能を提供するRSVP-TEと比較して、提供される情報に関して基本的な違いはない。RSVP-TEとセグメント・ルーティングはどちらも、1つのセグメントを使ってソース・ルート・パスを表現できる。

パスが1つのラベルを使用して表現される場合、メタデータの構文はRSVP-TE[RFC3209]とSRの間で同等である。

ソース・ルート・パスがセグメントのリストで表現される場合、パケットが辿らなければならないソース・ルート・パスをセグメント・リストで表現したメタデータがパケットに追加される。

ラベル・スタックを使ってパスを表現する場合、ラベルの意味(つまり、転送等価クラス)にアクセスできれば、明示的なパスが分かる。MPLSデータ・プレーンでは、データ・プレーンの変更は必要ないため、基本的な機能の変更はない。ただし、ラベル・スタッキングの発生は増加する。

SRドメイン境界ルータは、信頼されたドメイン内のセグメントに関連付けられたラベルを宛先とするすべての外部トラフィックをフィルタリングしなければならない(MUST)。これには、信頼されたドメインのSRGB内のラベル、特定の境界ルータのSRLB内のラベル、およびこれらのブロックの外側のラベルが含まれる。外部トラフィックとは、信頼されたドメインの外側のノードに接続されたインタフェースから受信するすべてのトラフィックである。

ネットワーク保護の観点からは、パケットにラベル・スタックを適用するすべてのノードは、その適用が許可されると想定されるような信頼モデルがある。これは、最短パス・ルーティングを提供するプレーンIPと比較すると大きな変更だが、RSVP-TEなどの明示的なルーティング機能を提供する既存の手法と比較して、根本的な違いはない。デフォルトでは、明示的なルーティング情報は、管理対象ドメインの境界を通して漏洩してはならない(MUST NOT)。さまざまなプロトコルで定義されているセグメント・ルーティング拡張は、暗号化、認証、フィルタリングなどのプロトコルのセキュリティ・メカニズムを活用する。

一般的なケースでは、セグメント・ルーティングが可能なルータは、ラベルが信頼できるソースによって前もって広告された場合にのみ、ラベルを受け入れてインストールする。受信した情報は、認証とセキュリティ・メカニズムを提供する既存のコントロール・プレーン・プロトコルを使用して検証する。セグメント・ルーティングは、既存のコントロール・プレーン・プロトコルに追加のセキュリティ・メカニズムを定義しない。

SRは、ソース・ルーティング・パスのソースと中間点の間のシグナリングを導入しない。SRでは、ソース・ルーティング・パスは、IPコントロール・プレーンで事前に広告されたSIDを使用して計算する。したがって、SRドメインの境界でのSIDのフィルタリングと制御された広告に加えて、データ・プレーンでのフィルタリングも必要である。フィルタリングは、SRドメインの境界にあるフォワーディング・プレーンで実行しなければならず(MUST)、複数のラベル/指示の確認が必要になる場合がある。

MPLSデータ・プレーンの場合、既存のMPLSアーキテクチャがすでに複数のラベルをスタックすることで、このようなソース・ルーティングを可能にしているため、新しい要件はない。また、セキュリティ保護のために、[RFC4381]と[RFC5920]はすでに信頼境界でのMPLSパケットのフィルタリングを要求する。

8.2. SRv6

セグメント・ルーティングをIPv6データ・プレーンに適用すると、[RFC8200]で定義しているルーティング拡張ヘッダの一種であるセグメント・ルーティング・ヘッダ(SRH, [IPv6-SRH])を導入する。

SRHは、パケットが通過しなければならないIPv6アドレスで表される転送パス要素(ノード、リンク、サービスなど)のリストを含むメタデータをIPv6パケットに追加する。完全なソース・ルーティング・パスは、1つのセグメント(単一のIPv6アドレス)を使用してパケットにエンコードできる。

SRドメイン境界ルータは、信頼されたドメインのSRGBまたは特定の境界ルータのSRLB内のアドレスを宛先とする外部トラフィックをフィルタリングしなければならない(MUST)。外部トラフィックとは、信頼されたドメインの外部にあるノードに接続されたインタフェースから受信したトラフィックのことである。

ネットワーク保護の観点からは、パケットにSRHを追加するノードはすべて、追加が許可されていると想定される信頼モデルがある。したがって、デフォルトでは、明示的なルーティング情報は管理ドメインの境界を越えて漏洩してはならない。さまざまなプロトコルで定義されているセグメント・ルーティング拡張は、暗号化、認証、フィルタリングなどのプロトコルのセキュリティ・メカニズムを活用する。

一般的なケースでは、SRv6ルータは、信頼できるソースからSIDが広告された場合にのみ、セグメント識別子(IPv6アドレス形式) を受け入れてインストールする。受信した情報は、認証とセキュリティ・メカニズムを提供する既存のコントロール・プレーン・プロトコルを使用して検証する。セグメント・ルーティングは、既存のコントロール・プレーン・プロトコルにおける追加のセキュリティ・メカニズムを定義しない。

上記の動作が実装されていない場合や、想定される信頼モデルが侵害された場合(セキュリティ侵害など)に発生する可能性のある問題には、以下のようなものがある。

• 悪意のあるループ

• アクセス制御の回避

• DoS攻撃元の隠蔽

IPv6データ・プレーンにおけるSRに関するセキュリティ上の懸念については、[RFC5095]でより詳細に説明している。新しいIPv6ベースのセグメント・ルーティング・ヘッダは、[IPv6-SRH]で定義されている。本文書では、上記のセキュリティ上の懸念についても説明する。

8.3. 輻輳制御

SRは、輻輳制御のための新しい要件を導入しない。デフォルトでは、トラフィックの配信はベスト・エフォートという前提である。輻輳制御はエンドポイントで実装することができる。SRポリシーが使用されている場合、SRポリシーを識別するバインディングSIDに関連付けられた着信トラフィックを監視することで、帯域幅の割り当てを管理できる。[RFC8084]で提示されているような他のソリューションも適用可能である。

9. 管理性に関する考慮事項

SR対応ネットワークでは、パケットが辿るパスはヘッダにエンコードされる。パスはプロトコルを通じてシグナリングされないため、ネットワーク・オペレータがパスの有効性を検証し、その有効性と性能をチェックし、その監視にはOAMメカニズムが必要である。ただし、SRはトランジット・ノードの状態数を大幅に減らすことができるため、トランジット・ノードが管理しなければならない要素の数が少なくなることに留意する。

MPLSデータ・プレーンのSR OAMのユースケースは、[RFC8403]で定義されている。MPLSデータ・プレーンのSR OAM手順は、[RFC8287]で定義されている。

SRルータは、SR用に拡張されたさまざまなルーティング・プロトコルからSID(インデックス、ラベル、またはIPv6アドレス)の広告を受信する。これらのプロトコルにはそれぞれ、SIDのトラブルシューティングと監視機能を含めるために拡張しなければならないIPアドレスの操作と管理機能を提供するための監視とトラブルシューティング・メカニズムがある。

SRアーキテクチャは、グローバル・セグメントの使用が導入されている。各グローバル・セグメントは、SRドメイン内のユニークなインデックスまたはアドレスにバインドされなければならない(MUST)。オペレータによるそのようなインデックスやアドレスの割り当て管理は、誤ったルーティングなどの状況を回避するために、ネットワークの動作にとって重要である。オペレータが持つ割り当てポリシー/ツールに加えて、実装は決定論的な解決方法を提供することで、競合が検出された場合にネットワークを保護する必要がある(SHOULD)。

ラベル・スタックを使用してパスを表現する場合、ラベル・スタッキングの発生が増加する。ノードは、コントロール・プレーンで、サポートできるラベル・スタックのサイズという点で、その能力を通知したいと思うかもしれない。

SRの設定と操作のためのYANGデータ・モデル[RFC6020]は、[SR-YANG]で定義されている。

SRがIPv6データ・プレーンに適用される場合、セグメントはIPv6アドレスで識別する。セグメント識別子の割り当て、管理、トラブルシューティングは、IPv6アドレスの割り当てと管理に適用される既存のメカニズムと変わらない。

パケットのDAが、アクティブなセグメント・アドレスを示す。SRHのセグメント・リストは、パケットのパス全体を示す。ソース・ルート・パスの検証は、同等のルーティング・テーブル・エントリと一致するパケット・ヘッダ内のDAとSRHの照合を通じて行われる。

SRv6データ・プレーンのコンテキストでは、[IPv6-SRH]で説明しているように、SRHにソース・ルート・パスがエンコードされる。SRv6ソース・ルート・パスは、IPv6パケット・ヘッダのDAフィールドにアクティブ・セグメントがあるIPv6アドレスのリストとしてSRHにインスタンス化される。通常、任意のノードでパケット・ヘッダを検査することで、そのパケットが属するソース・ルート・パスを導き出すことができる。SR-MPLSデータ・プレーンのコンテキストと同様に、実装は、エンドツーエンドのパスと性能を測定するために、ソース・ルート・パスがSRHに挿入され、パスの各セグメントが関連データをパケットに挿入するパス制御と監視パケットを発信することができる。

10. 参考文献

10.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

10.2. 参考規格

[BGPLS-SR-EPE] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Work in Progress, draft-ietf-idr-bgpls- segment-routing-epe-15, March 2018.

[IPv6-SRH] Filsfils, C., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-14, June 2018.

[ISIS-SR-EXT] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-19, July 2018.

[OSPF-SR-EXT] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-25, April 2018.

[OSPFv3-SR-EXT] Psenak, P., Ed., Filsfils, C., Previdi, S., Ed., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-13, May 2018.

[PCEP-SR-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.

[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <https://www.rfc-editor.org/info/rfc4381>.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.

[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <https://www.rfc-editor.org/info/rfc6549>.

[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/info/rfc7938>.

[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.

[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, <https://www.rfc-editor.org/info/rfc8202>.

[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>.

[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.

[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, <http://www.rfc-editor.org/info/rfc8403>.

[SR-CENTRAL-EPE] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-10, December 2017.

[SR-MPLS] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-14, June 2018.

[SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", Work in Progress, draft-ietf-spring-sr-yang-09, June 2018.

謝辞

デイブ・ウォード、ピーター・プセナク、ダン・フロスト、スチュワート・ブライアント、ピエール・フランソワ、トーマス・テルカンプ、ルディガー・ガイブ、ハンネス・グレドラー、プシュパシス・サルカル、エリック・ローゼン、クリス・バワーズ、そしてアルバロ・レタナの各氏のコメントとレビューに感謝する。

貢献者

以下の方々が、セグメント・ルーティング・アーキテクチャの定義と本文書の編集に大きく貢献した:

アハメド・バシャンディ
Cisco Systems, Inc.
メールアドレス: <[e-mail]>

マーティン・ホーネファー
Deutsche Telekom
メールアドレス: <[e-mail]>

ヴィム・ヘンデリクス
Nokia
メールアドレス: <[e-mail]>

ジェフ・タンツーラ
メールアドレス: <[e-mail]>

エドワード・クラブ
メールアドレス: <[e-mail]>

イゴール・ミロジェビッチ
メールアドレス: <[e-mail]>

サク・イッティ
TDC
メールアドレス: <[e-mail]>

著者のアドレス

クラレンス・フィルス (編集者)
Cisco Systems, Inc.
ブリュッセル
ベルギー
メール: <[e-mail]>

ステファノ・プレヴィディ (編集者)
Cisco Systems, Inc.
イタリア
メール: <[e-mail]>

レス・ギンズバーグ
Cisco Systems, Inc.
メール: <[e-mail]>

ブルーノ・デクレーヌ
Orange
フランス
メール: <[e-mail]>

ステファン・リトコウスキー
Orange
フランス
メール: <[e-mail]>

ロブ・シャキール
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
アメリカ合衆国
メール: <[e-mail]>

更新履歴

• 2024.9.16
• 2024.9.21