メインコンテンツまでスキップ

1. Introduction (はじめに)

BGPカラー感知ルーティング (BGP Color-Aware Routing, CAR) は、マルチドメインサービスプロバイダートランスポートネットワーク全体でエンドツーエンドのインテント感知パスを確立するためのBGPベースのルーティングソリューションです。BGP CARは、異なるインテントまたはカラーに対して、宛先ネットワークエンドポイント (例: プロバイダーエッジ (PE) ルーター) への異なるルートを配布します。カラーは、[RFC9256]のセクション2.1で定義されているように、ネットワークインテント (低コスト、低遅延、特定のリソースの回避、5Gネットワークスライスなど) に関連付けられた非ゼロの32ビット整数値です。

BGP CARは、[INTENT-AWARE]で説明されているトランスポートおよびVPNの問題記述と要件に対応します。

この目的のため、本文書では、インフラストラクチャルートを運ぶためのトランスポートパスを確立するために、BGP CAR SAFI (83) およびVPN CAR SAFI (84) と呼ばれる2つの新しいBGP SAFIを規定します。CAR SAFIとVPN CAR SAFIは、どちらもIPv4ユニキャストおよびIPv6ユニキャストAFI (AFI 1およびAFI 2) に適用されます。これらのSAFIを他のAFIと共に使用することは、本文書の範囲外です。

BGP CAR SAFIは、プロバイダーネットワーク (アンダーレイ) のトランスポートデバイスで有効化して、プロバイダーネットワーク間でカラー感知トランスポート/インフラストラクチャパスを確立できます。マルチドメイントランスポートネットワークには、複数のBGP自律システム (AS) と、単一のBGP AS内の複数のIGPドメインが含まれる場合があります。BGP CAR SAFIは、PEルーター上のVPNルーティングおよび転送 (VRF) でピアリングカスタマーエッジ (CE) ルーターに対して、また顧客ネットワーク内のデバイスでも有効化できます。VPN CAR SAFIは、PEルーターで異なる顧客から受信したインテント感知ルートを、重複する可能性のある顧客アドレス空間の分離を維持しながら、プロバイダーネットワーク全体に配布するために使用されます。したがって、BGP CARソリューションにより、顧客およびプロバイダーネットワークドメインにまたがるマルチドメインネットワークでインテント感知トランスポートパスを確立できます。

本文書では、この目的のために2つのBGP CARルートタイプも定義します。

BGP CAR Type-1 NLRI (E, C) は、異なるカラーに対して同じ宛先IPプレフィックスへの複数のカラー感知ルートを生成および配布することをサポートします。これは、トランスポートノード (PEなど) が複数のインテントアドバタイズメントに対して共通のIPアドレス (ループバックアドレスなど) を持つシナリオで発生します。オペレーターは、この共通のIPアドレスをサービスルートのBGPネクストホップとデータプレーンパスのトランスポートエンドポイントの両方として使用することを意図しています。各インテントに対して一意のパスを確立するには、この同じアドレスまたはプレフィックスへの複数のルートが必要です。例としては、MPLSまたはMPLS上のセグメントルーティング (SR-MPLS) の出口PEへの複数のラベルスイッチドパス (LSP) を確立することがあり、各インテントに1つずつです。

BGP CAR Type-2 NLRI (IPプレフィックスまたはE) は、オペレーターが特定のインテントに対して一意のネットワークIPアドレスブロックを指定し、トランスポートノードが各インテントに対して一意のIPプレフィックスまたはアドレスを割り当てるシナリオで、トランスポートノードへの複数のカラー感知ルートを配布することをサポートします。ユースケースの例としては、IPv6上のセグメントルーティング (SRv6) のインテントごとのロケーターがあります。

これらのBGP CARインテント感知パスは、その後、入口ノード (PEなど) によって、特定のインテントを必要とするサービスルートのトラフィックを誘導するために使用されます。誘導は、宛先へのすべてのトラフィックまたは特定のトラフィックに対して行われる場合があります。

BGP CARは、IPルーティング用のBGP (BGP-IP) [RFC4271] またはBGPラベル付きユニキャスト (BGP-LU) ([RFC8277]のSAFI 4) で使用されるフラットルーティングモデルに従い、インテント感知をサポートするように拡張することで、これらの広く展開されているトランスポートルーティング技術と一貫した運用エクスペリエンスを提供します。

1.1. Terminology (用語)​

Intent (in routing) (ルーティングにおけるインテント):
ルーティングまたはパス選択に影響を与える任意の動作。以下の動作の任意の組み合わせを含みます:

a. トポロジカルパス選択 (例: メトリックの最小化またはリソースの回避)
b. ネットワーク機能仮想化 (NFV) サービス挿入 (例: サービスチェーン誘導)
c. ホップごとの動作 (例: 5Gスライシング)

これは、[RFC9315]で宣言的抽象化としてのインテントと比較して、ルーティングの観点からベストエフォート以上のより具体的な概念です。

Color (カラー):
[RFC9256]のセクション2.1で定義されているように、インテント (例: 低コスト、低遅延、または特定のリソースの回避) に関連付けられた非ゼロの32ビット整数値。カラーの割り当てはオペレーターが管理します。

Colored service route (着色されたサービスルート):
出口PE (例: E2) は、そのBGPサービス (例: VPN) ルート (例: V/v) を着色して、V/vにバインドされたトラフィックに対して要求するインテントを示します。カラーは、[RFC9256]に従って使用されるBGPカラー拡張コミュニティ [RFC9012] としてエンコードされるか、SRv6サービスSID [RFC9252] のロケーター部分によって表されます。

Color-aware path to (E2, C) ((E2, C)へのカラー感知パス):
カラーCに関連付けられたインテントを満たす、E2に向けてパケットを転送するパス。複数の技術が(E2, C)へのカラー感知パスを提供できます。例えば、SRポリシー [RFC9256]、IGPフレキシブルアルゴリズム [RFC9350]、およびBGP CAR (本文書で規定) などです。

Color-aware route (E2, C) (カラー感知ルート (E2, C)):
カラーCに対してE2へのカラー感知パスを構築するための分散またはシグナリングされたルート。

Service route automated steering on color-aware path (カラー感知パス上のサービスルート自動誘導):
入口PE (またはASBR) E1は、E2からのC着色サービスルートV/vのトラフィックを(E2, C)カラー感知パスに自動的に誘導します。複数のそのようなパスが存在する場合、優先スキームを使用して最適なパスを選択します (例: IGPフレキシブルアルゴリズムがSRポリシーよりも優先され、SRポリシーがBGP CARよりも優先されます)。

Color domain (カラードメイン):
同じカラーからインテントへのマッピングを共有するノードのセット。通常、単一の管理下にあります。このセットは、1つ以上のネットワークドメイン (単一のBGP AS内のIGPエリア/インスタンス、または複数のBGP AS) に編成される場合があります。ノード上のカラーからインテントへのマッピングは、構成を介して設定されます。カラーの再マッピングとフィルタリングは、カラードメイン境界で発生する場合があります。[INTENT-AWARE]を参照してください。

Resolution of a BGP CAR route (E, C) (BGP CARルート (E, C) の解決):
Nを介したドメイン間BGP CARルート (E, C) は、ドメイン内カラー感知パス (N, C) 上で解決されます。ここで、NはBGP CARルートのネクストホップです。

Resolution versus steering (解決と誘導):
SRポリシー文書 ([RFC9256]セクション8) で使用される用語と一致して、本文書では、(サービスルート) 誘導は、サービスルートのトラフィックをBGP CARパスにマッピングすることを説明するために使用されます。逆に、解決という用語は、ドメイン間BGP CARルートをドメイン内カラー感知パスにマッピングするために予約されています。

Service steering (サービス誘導):
サービスルートは、トラフィックをBGP CARパス (または他のカラー感知パス、例: SRポリシー) にマッピングします。カラー感知パスが利用できない場合、ローカルポリシーはカラー非感知ルート/TEパス (例: BGP-LU、RSVP-TE、IGP/LDP) にマッピングする場合があります。サービス誘導の概念は、使用されるトランスポート技術とは独立しています。セクション3では、MPLS、SR-MPLS、およびSRv6の特定のサービス誘導メカニズムについて説明します。

Intra-domain resolution (ドメイン内解決):
BGP CARルートは、ドメイン内カラー感知パス (例: SRポリシー、IGPフレキシブルアルゴリズム、BGP CAR) またはカラー非感知ルート/TEパス (例: RSVP-TE、IGP/LDP、BGP-LU) にマッピングされます。

Transport network (トランスポートネットワーク):
1つ以上のオペレーターによって管理される複数の協調ドメインで構成されるネットワーク。ルーティング技術 (IP、MPLS、SRなど) を使用してパケットを転送し、接続およびその他のサービスを提供します。SRデプロイメントでは、トランスポートネットワークは[RFC8402]で定義されている信頼できるドメイン内にあります。

Transport layer (トランスポート層):
オーバーレイまたはサービス層 (例: MPLS VPN) によって使用されるアンダーレイネットワーク層 (例: PE間のMPLS LSP) を指します。

Transport RR (トランスポートRR):
ドメイン内またはドメイン間でトランスポート/アンダーレイルートを配布するために使用されるBGPルートリフレクター (RR)。

Service RR (サービスRR):
ドメイン内またはドメイン間でサービス/オーバーレイルートを配布するために使用されるBGPルートリフレクター (RR)。

Abbreviations (略語):

  • ABR: Area Border Router (エリア境界ルーター)
  • AFI: Address Family Identifier (アドレスファミリ識別子)
  • AIGP: Accumulated IGP Metric Attribute [RFC7311] (累積IGPメトリック属性)
  • ASBR: Autonomous System Border Router (自律システム境界ルーター)
  • BGP-LU: BGP Labeled Unicast SAFI ([RFC8277]によるSAFI値4)
  • BGP-IP: BGP IPv4/IPv6 Unicast SAFI ([RFC4760]および[RFC4271]によるSAFI値1)
  • BR: Border Router (境界ルーター、IGPエリア (ABR) またはBGP自律システム (ASBR) 用)
  • Color-EC: BGP Color Extended Community [RFC9012] (BGPカラー拡張コミュニティ)
  • E: トランスポートエンドポイントの汎用表現、例: PE、ABR、またはASBR
  • LCM-EC: BGP Local Color Mapping Extended Community (BGPローカルカラーマッピング拡張コミュニティ)
  • NLRI: Network Layer Reachability Information [RFC4271] (ネットワーク層到達可能性情報)
  • P node: ドメイン内トランスポートルーター
  • RD: Route Distinguisher (ルート識別子)
  • RR: Route Reflector (ルートリフレクター)
  • T-RR: Transport Route Reflector (トランスポートルートリフレクター)
  • S-RR: Service Route Reflector (サービスルートリフレクター)
  • SAFI: Subsequent Address Family Identifier (後続アドレスファミリ識別子)
  • TEA: Tunnel Encapsulation Attribute [RFC9012] (トンネルカプセル化属性)
  • V/v, W/w: AFI/SAFIまたは実際のNLRIエンコーディングに関係なく、サービスルートの汎用表現 (プレフィックス/マスク長を示す)

1.2. Illustration (図解)​

以下は、BGP CARソリューションの注目すべき機能の簡単な図解です。

+-------------+      +-------------+      +-------------+
|             |      |             |      |             | V/v with C1
|----+        |------|             |------|        +----|/
| E1 |        |      |             |      |        | E2 |\
|----+        |      |             |      |        +----| W/w with C2
|             |------|             |------|             |
|  Domain 1   |      |   Domain 2  |      |   Domain 3  |
+-------------+      +-------------+      +-------------+

図1: BGP CARソリューションの図解

すべてのノードは、一貫したカラーからインテントへのマッピングを持つ単一の権限下のドメイン間ネットワークの一部です:

  • C1は「低遅延」にマッピングされます

    • Flex-Algo 1は「低遅延」にマッピングされるため、C1にマッピングされます

  • C2は「低遅延およびリソースRの回避」にマッピングされます

    • Flex-Algo 2は「低遅延およびリソースRの回避」にマッピングされるため、C2にマッピングされます

E1は、E2から2つのサービスルートを受信します:

  • BGPカラーEC C1を持つV/v
  • BGPカラーEC C2を持つW/w

E1には、以下のカラー感知パスがあります:

  • (E2, C1) BGP CARによって提供され、ドメインごとのサポートは次のとおりです:

    • ドメイン1: IGP FA1経由
    • ドメイン2: カラーC1にバインドされたSRポリシー経由
    • ドメイン3: IGP FA1経由

  • (E2, C2) SRポリシーによって提供されます

E1は、受信したサービスルートのトラフィックを次のように自動的に誘導します:

  • V/vは、BGP CARによって提供される(E2, C1)経由
  • W/wは、SRポリシーによって提供される(E2, C2)経由

例の特性:

  • BGPカラーECの活用

    • サービスルートは、広く使用されているBGPカラー拡張コミュニティ [RFC9012] を使用して着色され、インテントを要求します

  • (E, C)自動誘導

    • V/vとW/wは、適切なカラー感知パスに自動的に誘導されます

  • BGP CARとSRポリシーのシームレスな共存

    • V/vは、BGP CARによって提供されるカラー感知パスに誘導されます
    • W/wは、SRポリシーによって提供されるカラー感知パスに誘導されます

  • BGP CARとSRポリシーのシームレスな相互運用

    • V/vは、BGP CARパスに誘導され、そのパス自体がドメイン2内でV/vのカラーにバインドされたSRポリシーに解決されます

追加の特性:

  • MPLSデータプレーン: 300k PEと5つのカラーの場合、BGP CARソリューションは、単一のノードがリモートPE * Cのオーダーのデータプレーンスケールをサポートする必要がないことを保証します (セクション5)。そうでなければ、MPLSデータプレーン機能を超えてしまいます。

  • コントロールプレーン: ノードがそのカラー感知パスに参加しない場合、(E, C)パスをインストールすべきではありません (SHOULD NOT)。

  • 一貫性のないカラーインテントマッピング: このソリューションは、異なるカラードメイン間でのBGP CARルートシグナリングをサポートします (セクション2.8)。

このモデルの主な利点は次のとおりです:

  • サービスルートの着色にBGPカラーEC [RFC9012] を活用
  • 自動サービス誘導の定義: E2からのC着色サービスルートV/vは、カラー感知パス(E2, C)に誘導されます
  • BGP CARパスデータモデルの定義: (E, C)
    • BGP-IP/BGP-LUデータモデル(E)の自然な拡張
    • SRポリシーデータモデルと一貫性があります
  • BGP CARルートの再帰的解決の定義: Nを介したBGP CAR (E2, C)ルートは、カラー感知パス(N, C)上で解決されます。このパス自体は、BGP CARによって、または別のカラー感知ルーティングソリューション (例: SRポリシー、IGPフレキシブルアルゴリズム) を介して提供される場合があります
  • 複数のトランスポートカプセル化の明示的な定義 (例: MPLS、SR、SRv6、IP)

1.3. Requirements Language (要件言語)​

本文書のキーワード「MUST (しなければならない)」、「MUST NOT (してはならない)」、「REQUIRED (必須)」、「SHALL (するものとする)」、「SHALL NOT (しないものとする)」、「SHOULD (すべきである)」、「SHOULD NOT (すべきでない)」、「RECOMMENDED (推奨される)」、「NOT RECOMMENDED (推奨されない)」、「MAY (してもよい)」、および「OPTIONAL (オプション)」は、BCP 14 [RFC2119] [RFC8174]に記載されているとおりに解釈されるものとします。ただし、ここに示すようにすべて大文字で表示される場合に限ります。

に最終更新