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

RFC 9026 - マルチキャスト VPN の高速アップストリームフェイルオーバー

  • ステータス: Proposed Standard
  • 発行日: 2021年4月
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要​

本文書は,ダウンストリーム Provider Edge (PE) が VPN マルチキャストフローの Upstream PE を選択するときに Provider Tunnel (P-tunnel) の状態を考慮できるようにし,アップストリーム障害からの高速フェイルオーバーを実現する Multicast Virtual Private Network (VPN) の拡張と手順を定義する.高速フェイルオーバーには「Bidirectional Forwarding Detection (BFD) for Multipoint Networks」[RFC8562] と,新しい BGP 属性 BFD Discriminator を用いる.さらに,新しい BGP Community である Standby PE を導入し,C-multicast route を Standby Upstream PE へ広告できるよう BGP MVPN ルーティングを拡張する.

本メモの位置付け​

本文書は Internet Standards Track 文書であり,IETF コミュニティの合意を表す.公開レビューを受け,IESG によって公開が承認されている.現在の状態,エラッタ,フィードバック方法は https://www.rfc-editor.org/info/rfc9026 を参照されたい.

著作権表示​

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

本文書には,公開日時点で有効な BCP 78 および IETF Trust Legal Provisions (https://trustee.ietf.org/license-info) が適用される.本文書から抽出した Code Components には,同規定 4.e 節の Simplified BSD License 文を含めなければならず,同ライセンスに記載されたとおり無保証で提供される.

1. はじめに​

読者は,[RFC6513] および [RFC6514] に記述されたマルチキャスト MPLS/BGP IP VPN の動作を理解しているものとする.

BGP/MPLS VPN [RFC6513] のマルチキャストでは,各種障害から接続性を高速に回復する仕組みが望まれる.本文書は,受信者を持つ VPN サイトに接続された PE よりアップストリームにある,プロバイダーネットワーク要素の障害を扱う.

3 節は,egress PE (受信サイトに接続する PE) が P-tunnel の状態を考慮し,所与の (C-S,C-G) に対する Upstream Multicast Hop (UMH) を決定するローカル手順を定義する.任意選択の方法の 1 つは [RFC8562] と新しい BGP 属性 BFD Discriminator を用いる.これらの方法だけでは高速フェイルオーバーにならないが,4 節の仕組みと組み合わせれば高速フェイルオーバーを実現できる.

4 節は,復旧時に MVPN ルーティングメッセージを交換せずにフェイルオーバーを高速化する,新しい Standby PE Community という任意選択の BGP 拡張を定義する.5 節は,3 節と 4 節の仕組みを組み合わせた「hot root standby」を定義する.これは,一定のトポロジーとメトリック制約の下で PIM ルーティングを用いる場合にフェイルオーバー時間を改善する [RFC7431] の方式と類似する.

2. 本文書で使用する規約​

2.1. 要件を表す言語​

キーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は,ここに示すとおりすべて大文字で現れる場合に限り,BCP 14 [RFC2119] [RFC8174] に従って解釈する.

2.2. 用語​

本文書では [RFC6513] および [RFC6514] で定義された用語を使用する.

2.3. 略語​

  • BFD: Bidirectional Forwarding Detection
  • MVPN: Multicast Virtual Private Network
  • NLRI: Network Layer Reachability Information
  • PE: Provider Edge
  • PMSI: Provider Multicast Service Interface
  • RPT: Rendezvous Point Tree
  • SPT: Shortest Path Tree
  • UMH: Upstream Multicast Hop
  • VPN: Virtual Private Network
  • VRF: VPN Routing and Forwarding

3. トンネル状態に基づく UMH 選択​

RFC 6513 の 5.1 節は,MVPN ダウンストリーム PE が所与の (C-S,C-G) に対する UMH を決定する手順を定義する.

所与のダウンストリーム PE と VRF について,所与の (C-S,C-G) 状態に対する Upstream PE に対応する P-tunnel は,その Upstream PE が (C-S,C-G) に対して広告し,その VRF にインポートされた S-PMSI tunnel である.該当する S-PMSI がなければ,その PE が広告し VRF にインポートされた I-PMSI tunnel である.

ここで定義する任意選択の手順では,ダウンストリーム PE が各候補 Upstream PE をルートとする P-tunnel の状態を考慮し,各 PE を (C-S,C-G) の候補 UMH リストへ含めるかを決める.P-tunnel の現在状態が Up か判断できない場合,「Down であることが判明していない」とみなし,利用を試みられるよう Up として扱ってよい.P-tunnel が Down の場合 (3.1 節),そのルート PE は UMH 選択の対象外となり,ダウンストリーム PE は候補リストの次の Upstream PE へフェイルオーバーする.障害が一部ブランチだけに影響する場合,ダウンストリーム PE ごとに状態判断が異なる可能性がある.したがって,I-PMSI P-tunnel を用いるときは RFC 6513 の 9.1.1 節の手順を適用する.

RFC 6513 の 5.1 節には Upstream PE を選ぶ 3 つの選択肢がある.最初の 2 つは,IP アドレスまたはハッシュアルゴリズムに基づいて候補集合から選ぶ.本文書の P-tunnel 状態確認と併用する場合,次のいずれかに該当する候補 Upstream PE を集合へ含める.

  • トンネルに束縛された x-PMSI を広告し,そのトンネルが Down であると判明していない.
  • 所与の (C-S,C-G) に適用される x-PMSI は広告しないが,S の unicast VPN route に VRF Route Import BGP Extended Community を関連付けている.これは,所与の VRF で I-PMSI を広告せず S-PMSI だけを使用するポリシーの UMH PE を誤って無効化しないために必要である.S-PMSI は,Upstream PE が,広告した S-PMSI で運ぶ (C-S,C-G) または (C-*,C-G) の C-multicast route を受信した後に限り広告できる.

候補集合が空になった場合,P-tunnel の状態を考慮せず手順を繰り返す.

第 3 の選択肢は,インストール済み UMH Route (C-root に対する最良経路) を Selected UMH Route とし,その生成元 PE を Upstream PE とする.本文書の任意選択手順では,生成元 PE の P-tunnel が Down でない経路のうち最良のものを選ぶ.該当経路がなければ,P-tunnel の状態にかかわらずインストール済み UMH Route を選ぶ.

3.1. トンネル状態の判定​

P-tunnel の状態を判定する要因を以下に示す.ダウンストリーム PE がすべて同じ判定規則を用いず,PE ごとに結果が異なる場合も扱う (6 節).したがって,ここでいう P-tunnel の「状態」はトンネル固有の属性ではなく,特定のダウンストリーム PE から見た状態である.一部の方法はトンネル自体の状態ではなく,ダウンストリーム PE がその P-tunnel からトラフィックを受信できるかを判定するが,簡潔にするためすべて「状態」と呼ぶ.

判定基準によっては,P-tunnel 自体の別の耐障害機構と相互作用し,UMH の更新を直ちに行える場合と遅延が必要な場合がある.実装は以下の方法を任意に組み合わせ,運用者が導入環境で使う方法を選べるようにしてよい.

3.1.1. MVPN Tunnel Root Tracking​

P-tunnel が Up かを判断するとき,x-PMSI Tunnel 属性で指定されたトンネルルートへユニキャストルーティングテーブルで到達可能かを考慮する.この場合,到達可能性が変化した時点でダウンストリーム PE は直ちに UMH を更新できる.これは VPN route の BGP next-hop tracking と似ているが,監視するのは BGP next-hop address ではなく x-PMSI Tunnel 属性の root address である.

3.1.2. PE-P アップストリームリンク状態​

ダウンストリーム PE は Upstream PE へ到達するために使うリンクの状態を確認できる.リンクが Down なら P-tunnel も Down とみなす.

3.1.3. P2MP RSVP-TE Tunnel​

Point-to-Multipoint (P2MP) RSVP-TE tunnel では,RSVP-TE Label Switched Path (LSP) の状態でトンネル状態を判定できる.LSP が Down なら P-tunnel も Down とみなす.

3.1.4. Leaf-Initiated P-Tunnel​

leaf-initiated P-tunnel では,トンネル設定に用いるシグナリングプロトコルの状態で判定できる.

3.1.5. (C-S,C-G) カウンタ情報​

特定の (C-S,C-G) のトラフィック統計から P-tunnel の状態を推測できる.トラフィックレートが一定のしきい値を下回れば Down とみなせる.

3.1.6. BFD Discriminator 属性​

本文書は,BFD セッションを P-tunnel に関連付ける新しい BGP 属性 BFD Discriminator を定義する.BFD セッションの状態によって P-tunnel の状態を決める.

3.1.7. PE-CE リンクごとの BFD Discriminator​

BFD discriminator を特定の PE-CE リンクに関連付けると,ダウンストリーム PE は BFD を用いて CE へのリンク状態を監視できる.

3.1.8. P-Tunnel 状態監視の運用上の考慮事項​

誤検出を避け,監視機構が過大なオーバーヘッドを持ち込まないよう注意する.

4. Standby C-Multicast Route​

本文書は,復旧時に MVPN ルーティングメッセージを交換せずフェイルオーバーを高速化する,新しい Standby PE Community という任意選択の BGP 拡張を定義する.

4.1. ダウンストリーム PE の動作​

Standby PE Community をサポートするダウンストリーム PE は,C-multicast route を Standby Upstream PE へ広告できる.これにより Standby Upstream PE は (C-S,C-G) のトラフィック転送に必要な状態を事前設定できる.

4.2. アップストリーム PE の動作​

Standby PE Community 付き C-multicast route を受信した Upstream PE は,(C-S,C-G) の状態をインストールしなければならない (MUST) が,UMH に選ばれるまでトラフィックを転送してはならない (MUST NOT).

4.3. 到達可能性の判定​

ダウンストリーム PE は 3 節の仕組みで Upstream PE と Standby Upstream PE の到達可能性を判定する.

4.4. Inter-AS​

4.4.1. ダウンストリーム PE の Inter-AS 手順と ASBR 高速フェイルオーバー​

Inter-AS 環境では,ダウンストリーム PE は Standby PE Community を用いて C-multicast route を ASBR へ広告できる.

4.4.2. ASBR の Inter-AS 手順​

ASBR は Standby PE Community を用いて C-multicast route を別の ASBR または Upstream PE へ広告できる.

5. Hot Root Standby​

本文書の hot root standby は,3 節と 4 節の仕組みを組み合わせ,MVPN のフェイルオーバー時間を改善する.[RFC7431] が,一定のトポロジーとメトリック制約の下で PIM routing を用いるネットワークについて定義する方式と類似する.

6. 重複パケット​

本文書の高速フェイルオーバー機構を使うと,重複パケットが受信者へ届く可能性がある.実装と運用では重複の影響を考慮し,必要に応じて緩和しなければならない.

7. IANA に関する考慮事項​

7.1. Standby PE Community​

IANA は Standby PE Community に BGP Community 値を割り当てた.

7.2. BFD Discriminator​

IANA は BFD Discriminator 属性に BGP Attribute type code を割り当てた.

7.3. BFD Discriminator Optional TLV Type​

IANA は BGP Tunnel Encapsulation Attribute 内の BFD Discriminator Optional TLV に Type 値を割り当てた.

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

本文書のセキュリティ上の考慮事項は [RFC6513] および [RFC6514] と同様である.さらに,BFD の利用により,BFD パケットの認証と完全性に関する考慮事項が生じる.

9. 参考文献​

9.1. 規範的参考文献​

  • [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, 1997年3月.
  • [RFC6513] E. Rosen and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 2012年2月.
  • [RFC6514] R. Aggarwal et al., "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", 2012年2月.
  • [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", 2017年5月.
  • [RFC8562] D. Katz et al., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", 2019年4月.

9.2. 参考文献​

  • [RFC7431] A. Karan et al., "Multicast-Only Fast Reroute", 2015年8月.
  • [RFC7841] J. Halpern et al., "RFC Streams, Headers, and Boilerplates", 2016年5月.

謝辞​

著者は,本文書に協力した貢献者とレビュー担当者に感謝する.

貢献者​

...

著者の連絡先​