Internet Engineering Task Force (IETF) Y. Liu
Request for Comments: 9860 China Mobile
Category: Informational M. McBride
ISSN: 2070-1721 Futurewei
Z. Zhang
ZTE
J. Xie
Huawei
C. Lin
New H3C Technologies
October 2025
This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast-only Fast Reroute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA provides Fast Reroute (FRR) protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of FRR mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure.
この文書では、Protocol Independent Multicast (PIM) の Multicast-only Fast Reroute (MoFRR) での Topology Independent Loop-Free Alternate (TI-LFA) メカニズムの使用を指定します。TI-LFA は、潜在的な障害を回避するバックアップ パスを事前に計算することにより、IP ネットワーク内のユニキャスト トラフィックに高速リルート (FRR) 保護を提供します。このドキュメントでは、TI-LFA を MoFRR と統合することにより、FRR メカニズムの利点をマルチキャスト トラフィックに拡張し、マルチキャスト ネットワークにおける復元力の強化とパケット損失の最小化を可能にします。この文書では、PIM 用の MoFRR と組み合わせて TI-LFA を実装し、障害発生時にマルチキャスト トラフィックが迅速に再ルーティングされるようにするためのオプションのアプローチについて概説しています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9860.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9860 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
2. Problem Statement
2.1. LFA for MoFRR
2.2. TI-LFA for MoFRR
3. A Solution
3.1. Overview
3.2. Procedure
4. Illustration
5. Management and Operational Considerations
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Contributors
Authors' Addresses
Multicast-only Fast Reroute (MoFRR), as defined in [RFC7431], offers a mechanism to reduce multicast packet loss in the event of node or link failures by introducing simple enhancements to multicast routing protocols, such as Protocol Independent Multicast (PIM) [RFC7761]. However, the MoFRR mechanism [RFC7431], which selects the secondary multicast next hop based solely on the Loop-Free Alternate (LFA) FRR defined in [RFC7431], has limitations in certain multicast deployment scenarios (see Section 2).
[RFC7431] で定義されているマルチキャスト専用高速リルート (MoFRR) は、Protocol Independent Multicast (PIM) [RFC7761] などのマルチキャスト ルーティング プロトコルに簡単な機能拡張を導入することで、ノードまたはリンクの障害が発生した場合のマルチキャスト パケット損失を軽減するメカニズムを提供します。ただし、[RFC7431] で定義されているループフリー代替 (LFA) FRR のみに基づいてセカンダリ マルチキャスト ネクスト ホップを選択する MoFRR メカニズム [RFC7431] には、特定のマルチキャスト展開シナリオでは制限があります (セクション 2 を参照)。
This document introduces a new mechanism for MoFRR using FRR for Topology Independent Loop-Free Alternate (TI-LFA) [RFC9855]. Unlike conventional methods, TI-LFA is independent of network topology, enabling broader coverage across diverse network environments. This mechanism is applicable to PIM networks, including cases where PIM operates directly over IP in Segment Routing (SR) networks.
この文書では、トポロジー独立ループフリー代替 (TI-LFA) [RFC9855] の FRR を使用する MoFRR の新しいメカニズムを紹介します。従来の方法とは異なり、TI-LFA はネットワーク トポロジに依存しないため、多様なネットワーク環境にわたってより広い範囲をカバーできます。このメカニズムは、PIM がセグメント ルーティング (SR) ネットワークの IP 上で直接動作する場合を含め、PIM ネットワークに適用できます。
The TI-LFA mechanism is designed for standard link-state Interior Gateway Protocol (IGP) shortest path and SR scenarios. For each destination advertised by the IGP in a network, TI-LFA pre-installs a backup forwarding entry for the protected destination, which is ready to be activated upon the detection of a link failure used to reach that destination. This document leverages the backup path computed by TI-LFA through the IGP as a secondary Upstream Multicast Hop (UMH) for PIM. By sending PIM secondary Join messages hop by hop on the TI-LFA backup path, a FRR backup path can be created for PIM multicast.
TI-LFA メカニズムは、標準のリンクステート内部ゲートウェイ プロトコル (IGP) の最短パスおよび SR シナリオ向けに設計されています。ネットワーク内の IGP によってアドバタイズされる宛先ごとに、TI-LFA は保護された宛先のバックアップ転送エントリをプリインストールします。これは、その宛先に到達するために使用されるリンク障害の検出時にアクティブ化される準備ができています。このドキュメントでは、IGP を介して TI-LFA によって計算されたバックアップ パスを、PIM のセカンダリ アップストリーム マルチキャスト ホップ (UMH) として利用します。PIM セカンダリ参加メッセージを TI-LFA バックアップ パス上でホップバイホップで送信することにより、PIM マルチキャスト用の FRR バックアップ パスを作成できます。
The techniques described in this document are limited to protecting links and nodes within a link-state IGP area. Protecting domain exit routers and/or links attached to other routing domains is beyond the scope of this document. All the Segment Identifiers (SIDs) required are contained within the Link State Database (LSDB) of the IGP.
この文書で説明されている技術は、リンクステート IGP エリア内のリンクとノードの保護に限定されています。ドメイン出口ルーターや他のルーティング ドメインに接続されているリンクの保護については、このドキュメントの範囲を超えています。必要なすべてのセグメント識別子 (SID) は、IGP のリンク状態データベース (LSDB) 内に含まれています。
The approach does not alter the existing management and operation of LFA, TI-LFA, and Remote LFA (RLFA) [RFC7916] [RFC8102] [RFC9855]. Additionally, during post-failure reconvergence, micro-loops [RFC5715] may form due to transient forwarding inconsistencies across routers. PIM micro-loop prevention is out of scope for this document.
このアプローチは、LFA、TI-LFA、およびリモート LFA (RLFA) [RFC7916] [RFC8102] [RFC9855] の既存の管理と運用を変更するものではありません。さらに、障害後の再コンバージェンス中に、ルーター間での一時的な転送の不一致により、マイクロ ループ [RFC5715] が形成される可能性があります。PIM マイクロ ループ防止は、このドキュメントの範囲外です。
Note that this document introduces an optional approach for backup Join paths, designed to enhance the protection scope of existing multicast systems. It is fully compatible with current protocol implementations and does not necessitate any changes to the protocols or forwarding functions on intermediate nodes. All nodes along the backup Join paths must support the Reverse Path Forwarding (RPF) Vector Attribute as defined in [RFC5496] and [RFC7891]. If there is a choice between vector and non-vector Join messages on the intermediate nodes, the non-vector option should be prioritized, which implies that protection paths will remain inactive. This document does not modify the handling of conflicts in PIM Join messages. For guidance on conflicts in Join attributes, please refer to Section 3.3.3 of [RFC5384].
このドキュメントでは、既存のマルチキャスト システムの保護範囲を強化するために設計されたバックアップ参加パスのオプションのアプローチを紹介していることに注意してください。現在のプロトコル実装と完全な互換性があり、中間ノード上のプロトコルや転送機能を変更する必要はありません。バックアップ結合パスに沿ったすべてのノードは、[RFC5496] および [RFC7891] で定義されているリバース パス転送 (RPF) ベクトル属性をサポートする必要があります。中間ノードでベクトル結合メッセージと非ベクトル結合メッセージのどちらかを選択できる場合は、非ベクトル オプションを優先する必要があります。これは、保護パスが非アクティブのままになることを意味します。この文書は、PIM 参加メッセージの競合の処理を変更するものではありません。結合属性の競合に関するガイダンスについては、[RFC5384] のセクション 3.3.3 を参照してください。
This document utilizes the terminology as defined in [RFC7431] and incorporates the concepts established in [RFC7490]. The definitions of individual terms are not reiterated within this document.
この文書は、[RFC7431] で定義されている用語を使用し、[RFC7490] で確立された概念を組み込んでいます。個々の用語の定義は、この文書内では繰り返されません。
Section 3 of [RFC7431] specifies that a secondary UMH in PIM for MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA mechanism requires that at least one neighbor's next hop to the destination node is a loop-free next hop. Due to existing limitations of the LFA mechanism in network deployments, such as topology dependency and incomplete destination coverage, the LFA mechanism can only be deployed in certain network topology environments. In specific network topologies, the secondary UMH cannot be computed in PIM for MoFRR, preventing PIM from establishing a standby multicast tree, and thus preventing the implementation of MoFRR protection. Consequently, the MoFRR functionality [RFC7431] in PIM is applicable only in network topologies where LFA is feasible.
[RFC7431] のセクション 3 では、MoFRR の PIM のセカンダリ UMH がループフリー代替 (LFA) であると指定されています。ただし、従来の LFA メカニズムでは、宛先ノードへの少なくとも 1 つの隣接ノードのネクスト ホップがループフリーのネクスト ホップである必要があります。トポロジ依存性や不完全な宛先カバレッジなど、ネットワーク展開における LFA メカニズムの既存の制限により、LFA メカニズムは特定のネットワーク トポロジ環境でのみ展開できます。特定のネットワーク トポロジでは、MoFRR のセカンダリ UMH を PIM で計算できず、PIM がスタンバイ マルチキャスト ツリーを確立できなくなり、MoFRR 保護の実装が妨げられます。したがって、PIM の MoFRR 機能 [RFC7431] は、LFA が実現可能なネットワーク トポロジにのみ適用できます。
The limitations of the MoFRR applicability [RFC7431] can be illustrated using the example network depicted in Figure 1. In this example, the metric of the R1-R4 link is 20, the metric of the R5-R6 link is 100, and the metrics of the other links are 10. All link metrics are bidirectional.
MoFRR 適用性 [RFC7431] の制限は、図 1 に示すネットワーク例を使用して説明できます。この例では、R1-R4 リンクのメトリックは 20、R5-R6 リンクのメトリックは 100、その他のリンクのメトリックは 10 です。すべてのリンク メトリックは双方向です。
For multicast source S1 and receiver R, the primary path of the PIM Join packet is R3->R2->R1, and the secondary path is R3->R4->R1, which corresponds to the LFA path of unicast routing. In this scenario, MoFRR [RFC7431] operates effectively.
マルチキャスト送信元 S1 と受信者 R の場合、PIM Join パケットのプライマリ パスは R3->R2->R1 で、セカンダリ パスは R3->R4->R1 であり、ユニキャスト ルーティングの LFA パスに対応します。このシナリオでは、MoFRR [RFC7431] が効果的に機能します。
For multicast source S2 and receiver R, the primary path of the PIM Join packet is R3->R2. However, an LFA does not exist. If R3 sends the packet to R4, R4 will forward it back to R3 because the IGP shortest path from R4 to R1 is R4->R3->R2. In this case, MoFRR [RFC7431] cannot calculate a secondary UMH. Similarly, for multicast source S3 and receiver R, the MoFRR mechanism [RFC7431] is ineffective.
マルチキャスト送信元 S2 と受信者 R の場合、PIM Join パケットのプライマリ パスは R3->R2 です。ただし、LFA は存在しません。R3 がパケットを R4 に送信すると、R4 から R1 への IGP 最短パスは R4->R3->R2 であるため、R4 はそのパケットを R3 に転送します。この場合、MoFRR [RFC7431] はセカンダリ UMH を計算できません。同様に、マルチキャスト送信元 S3 と受信者 R の場合、MoFRR メカニズム [RFC7431] は無効です。
10 20
[S1]----(R1)-------------(R4)
| |
| |
|10 |10
10 | |
[S2]----(R2)-------------(R3)----[R]
| 10 | 10
| |
|10 |10
10 | |
[S3]----(R5)-----(R6)----(R7)
100 10
Figure 1: Example Network Topology
図 1: ネットワーク トポロジの例
The alternate path provided by the TI-LFA mechanism is represented as a segment list, which includes the Node SID of the P-space node and the Adjacency SIDs of the links between the P-space and Q-space nodes. When a remote PQ node exists in both P-space and Q-space, the segment list requires only the PQ node's Node SID.
TI-LFA メカニズムによって提供される代替パスは、P 空間ノードのノード SID と、P 空間ノードと Q 空間ノード間のリンクの隣接 SID を含むセグメント リストとして表されます。リモート PQ ノードが P スペースと Q スペースの両方に存在する場合、セグメント リストには PQ ノードのノード SID のみが必要です。
PIM can look up the corresponding node's IP address in the unicast route base according to the Node SID and the IP addresses of the endpoints of the corresponding link in the unicast route base according to the Adjacency SIDs. However, multicast protocol packets cannot be directly forwarded along the path of the segment list.
PIM は、ノード SID に従ってユニキャスト ルート ベース内の対応するノードの IP アドレスを検索し、隣接 SID に従ってユニキャスト ルート ベース内の対応するリンクのエンドポイントの IP アドレスを検索できます。ただし、マルチキャスト プロトコル パケットをセグメント リストのパスに沿って直接転送することはできません。
To establish a standby multicast tree, PIM Join messages need to be transmitted hop by hop. However, not all nodes and links on the unicast alternate path are included in the segment list. If PIM protocol packets are transmitted solely in unicast mode, they effectively traverse the unicast tunnel like unicast traffic and do not pass through the intermediate nodes of the tunnel. Consequently, the intermediate nodes on the alternate path cannot forward multicast traffic because they lack PIM state entries. PIM must create entries on each device hop by hop, generating an incoming interface and an outgoing interface list, to form a complete end-to-end multicast tree for forwarding multicast traffic. Therefore, simply sending PIM Join packets using the segment list, as done with unicast traffic, is insufficient to establish a standby multicast tree.
スタンバイ マルチキャスト ツリーを確立するには、PIM Join メッセージをホップごとに送信する必要があります。ただし、ユニキャスト代替パス上のすべてのノードとリンクがセグメント リストに含まれるわけではありません。PIM プロトコル パケットがユニキャスト モードのみで送信される場合、パケットはユニキャスト トラフィックと同様にユニキャスト トンネルを効果的に通過し、トンネルの中間ノードを通過しません。その結果、代替パス上の中間ノードには PIM 状態エントリがないため、マルチキャスト トラフィックを転送できません。PIM は、各デバイスにホップごとにエントリを作成し、受信インターフェイスと送信インターフェイス リストを生成して、マルチキャスト トラフィックを転送するための完全なエンドツーエンドのマルチキャスト ツリーを形成する必要があります。したがって、ユニキャスト トラフィックの場合と同様に、セグメント リストを使用して PIM Join パケットを送信するだけでは、スタンバイ マルチキャスト ツリーを確立するには不十分です。
A secondary UMH serves as a candidate next hop that can be used to reach the root of a multicast tree. In this document, the secondary UMH is derived from unicast routing, utilizing the segment list computed by TI-LFA.
セカンダリ UMH は、マルチキャスト ツリーのルートに到達するために使用できるネクスト ホップの候補として機能します。このドキュメントでは、セカンダリ UMH は、TI-LFA によって計算されたセグメント リストを利用して、ユニキャスト ルーティングから導出されます。
The path information from the segment list is incorporated into the PIM packets to guide hop-by-hop RPF selection. The IP address corresponding to the Node SID can be used as the segmented root node, while the IP addresses of the interfaces at both endpoints of the link associated with the Adjacency SID can be used as the local upstream interface and upstream neighbor.
セグメント リストからのパス情報は PIM パケットに組み込まれ、ホップバイホップの RPF 選択をガイドします。ノード SID に対応する IP アドレスはセグメント化されたルート ノードとして使用でき、隣接 SID に関連付けられたリンクの両方のエンドポイントのインターフェイスの IP アドレスはローカル アップストリーム インターフェイスおよびアップストリーム ネイバーとして使用できます。
[RFC5496] defines the PIM RPF Vector Attribute, which can carry the node's IP address corresponding to the Node SID. Additionally, [RFC7891] defines the Explicit RPF Vector, which can carry the peer's IP address corresponding to the Adjacency SID.
[RFC5496] は、ノード SID に対応するノードの IP アドレスを伝送できる PIM RPF ベクトル属性を定義しています。さらに、[RFC7891] は、隣接 SID に対応するピアの IP アドレスを伝送できる明示的 RPF ベクトルを定義しています。
For instance, in the network illustrated in Figure 1, the secondary path for the PIM Join packet towards multicast source S2 cannot be computed by MoFRR [RFC7431], as previously described. Using TI-LFA, R3 sends the packet to R4 while including an RPF Vector that contains the IP address of R1, which serves as R3's PQ node for the protected R3-R2 link. R4 then forwards the packet to R1 via the R1-R4 link according to the unicast route associated with the RPF Vector. R1 subsequently forwards the packet to R2, thus establishing the secondary path R3->R4->R1->R2.
たとえば、図 1 に示されているネットワークでは、マルチキャスト ソース S2 に向かう PIM Join パケットのセカンダリ パスは、前述したように MoFRR [RFC7431] によって計算できません。R3 は、TI-LFA を使用して、保護された R3-R2 リンクの R3 の PQ ノードとして機能する R1 の IP アドレスを含む RPF ベクトルを含めてパケットを R4 に送信します。次に、R4 は、RPF ベクトルに関連付けられたユニキャスト ルートに従って、R1-R4 リンクを介してパケットを R1 に転送します。その後、R1 はパケットを R2 に転送し、セカンダリ パス R3->R4->R1->R2 を確立します。
Additionally, for multicast source S3 and receiver R, the primary path of the PIM Join packet is R3->R2->R5. Using TI-LFA, R3 sends the PIM Join packet to R7 while including two RPF Vectors:
さらに、マルチキャスト送信元 S3 と受信者 R の場合、PIM Join パケットのプライマリ パスは R3->R2->R5 です。TI-LFA を使用して、R3 は 2 つの RPF ベクトルを含めて PIM Join パケットを R7 に送信します。
* The first RPF Vector contains the IP address of R6, which serves as R3's P-node for the protected R3-R2 link.
* 最初の RPF ベクトルには、保護された R3-R2 リンクの R3 の P ノードとして機能する R6 の IP アドレスが含まれています。
* The second RPF Vector contains the interface IP addresses of R6 and R5, which serve as R3's Q-node for the protected R3-R2 link.
* 2 番目の RPF ベクトルには、R6 と R5 のインターフェイス IP アドレスが含まれており、保護された R3-R2 リンクの R3 の Q ノードとして機能します。
The first RPF Vector guides the PIM Join path through R3->R7->R6, while the second RPF Vector guides the PIM Join path through R6->R5, thereby establishing the secondary path R3->R7->R6->R5.
最初の RPF ベクトルは R3->R7->R6 を介して PIM 参加パスをガイドし、2 番目の RPF ベクトルは R6->R5 を介して PIM 参加パスをガイドし、それによりセカンダリ パス R3->R7->R6->R5 を確立します。
This document leverages the above RPF Vector standards, obviating the need for PIM protocol extensions. This approach allows the establishment of a standby multicast tree based on the segment list calculated by TI-LFA, thereby providing comprehensive MoFRR protection for multicast services across diverse network environments.
このドキュメントでは上記の RPF Vector 標準を活用し、PIM プロトコル拡張の必要性を回避します。このアプローチにより、TI-LFA によって計算されたセグメント リストに基づいてスタンバイ マルチキャスト ツリーを確立できるため、多様なネットワーク環境にわたるマルチキャスト サービスに対して包括的な MoFRR 保護が提供されます。
Consider a segment list calculated by TI-LFA as (NodeSID(A), AdjSID(A-B)). Node A belongs to the P-space, and node B belongs to the Q-space. The IP address corresponding to NodeSID(A) can be retrieved from the local LSDB of the IGP and assumed to be IP-a. Similarly, the IP addresses of the two endpoints of the link corresponding to AdjSID(A-B) can also be retrieved from the local LSDB and assumed to be IP-La and IP-Lb.
TI-LFA によって (NodeSID(A), AdjSID(A-B)) として計算されたセグメント リストを考えてみましょう。ノード A は P 空間に属し、ノード B は Q 空間に属します。NodeSID(A) に対応する IP アドレスは、IGP のローカル LSDB から取得でき、IP-a であると想定されます。同様に、AdjSID(A-B) に対応するリンクの 2 つのエンドポイントの IP アドレスもローカル LSDB から取得でき、IP-La および IP-Lb であると想定されます。
Within the PIM process, IP-a is treated as the standard RPF Vector Attribute and added to the PIM Join packet. IP-La is considered the local address of the incoming interface, and IP-Lb is regarded as the address of the upstream neighbor. Consequently, IP-Lb can be included in the PIM Join packet as the Explicit RPF Vector Attribute.
PIM プロセス内では、IP-a は標準の RPF ベクトル属性として扱われ、PIM Join パケットに追加されます。IP-La は着信インターフェイスのローカル アドレスとみなされ、IP-Lb は上流のネイバーのアドレスとみなされます。したがって、IP-Lb を明示的な RPF ベクトル属性として PIM Join パケットに含めることができます。
The PIM protocol initially selects the RPF incoming interface and upstream neighbor towards IP-a and proceeds hop by hop to establish the PIM standby multicast tree until reaching node A. At node A, IP-Lb is treated as the PIM upstream neighbor. Node A identifies the incoming interface in the unicast routing table based on IP-Lb, and IP-Lb is used as the RPF upstream address for the PIM Join packet directed towards node B.
PIM プロトコルは、最初に RPF 着信インターフェイスと IP-a へのアップストリーム ネイバーを選択し、ホップごとに続行して、ノード A に到達するまで PIM スタンバイ マルチキャスト ツリーを確立します。ノード A では、IP-Lb が PIM アップストリーム ネイバーとして扱われます。ノード A は、IP-Lb に基づいてユニキャスト ルーティング テーブル内の着信インターフェイスを識別し、IP-Lb はノード B に向けられた PIM Join パケットの RPF アップストリーム アドレスとして使用されます。
Upon receiving the PIM Join packet at node B, the PIM protocol, finding no additional RPF Vector Attributes, selects the RPF incoming interface and upstream neighbor towards the multicast source directly. The protocol then continues hop by hop to establish the PIM standby multicast tree, extending to the router directly connected to the source.
ノード B で PIM Join パケットを受信すると、PIM プロトコルは追加の RPF ベクトル属性を検出せず、RPF 着信インターフェイスとマルチキャスト ソースへのアップストリーム ネイバーを直接選択します。その後、プロトコルはホップバイホップを続けて PIM スタンバイ マルチキャスト ツリーを確立し、送信元に直接接続されているルータまで拡張します。
When a remote PQ node exists in both P-space and Q-space, the processing can be simplified to involve only node A.
リモート PQ ノードが P 空間と Q 空間の両方に存在する場合、処理はノード A のみに関与するように簡素化できます。
This section provides an illustration of MoFRR based on TI-LFA. The example topology is depicted in Figure 2. The metric for the R3-R4 link is 100, while the metrics for the other links are 10. All link metrics are bidirectional.
このセクションでは、TI-LFA に基づく MoFRR の図を示します。トポロジの例を図 2 に示します。R3-R4 リンクのメトリックは 100 ですが、他のリンクのメトリックは 10 です。すべてのリンク メトリックは双方向です。
<-----Primary Path--- (S,G) Join
[S]---(R1)---(R2)******(R6)-------[R]
| |
<--- | | |
| | | |
| | (R5) |
| | | |
| | | |
| | | |
| (R3)------(R4) |
| |
--Secondary Path--
Figure 2: Example Topology
図 2: トポロジの例
The IP addresses and SIDs involved in the MoFRR calculation are configured as follows:
MoFRR の計算に含まれる IP アドレスと SID は次のように設定されます。
IPv4 data plane (SR-MPLS [RFC8660]):
IPv4 データ プレーン (SR-MPLS [RFC8660]):
Node IP Address Node SID
R4 IP4-R4 Label-R4
Link IP Address Adjacency SID
R3->R4 IP4-R3-R4 Label-R3-R4
R4->R3 IP4-R4-R3 Label-R4-R3
IPv6 data plane (SRv6 [RFC8986]):
IPv6 データ プレーン (SRv6 [RFC8986]):
Node IP Address Node SID (End)
R4 IP6-R4 SID-R4
Link IP Address Adjacency SID (End.X)
R3->R4 IP6-R3-R4 SID-R3-R4
R4->R3 IP6-R4-R3 SID-R4-R3
The primary path of the PIM Join packet is R6->R2->R1, and the secondary path is R6->R5->R4->R3->R2->R1. However, the conventional LFA does not function properly for the secondary path because the shortest path to R2 from R5 (or from R4) still traverses the R6-R2 link. In this scenario, R6 must calculate the secondary UMH using the proposed MoFRR method based on TI-LFA.
PIM Join パケットのプライマリ パスは R6->R2->R1 で、セカンダリ パスは R6->R5->R4->R3->R2->R1 です。ただし、R5 (または R4) から R2 への最短パスは依然として R6-R2 リンクを通過するため、従来の LFA はセカンダリ パスに対して適切に機能しません。このシナリオでは、R6 は、TI-LFA に基づいて提案された MoFRR 方法を使用してセカンダリ UMH を計算する必要があります。
According to the TI-LFA algorithm, the P-space and Q-space are illustrated in Figure 3. The TI-LFA repair path consists of the Node SID of R4 and the Adjacency SID of R4->R3. On the Segment Routing over MPLS (SR-MPLS) data plane, the repair segment list is (Label-R4, Label-R4-R3). On the Segment Routing over IPv6 (SRv6) data plane, the repair segment list is (SID-R4, SID-R4-R3).
TI-LFA アルゴリズムによる、P 空間と Q 空間は図 3 に示されています。TI-LFA 修復パスは、R4 のノード SID と R4->R3 の隣接 SID で構成されます。Segment Routing over MPLS (SR-MPLS) データ プレーンでは、修復セグメント リストは (Label-R4、Label-R4-R3) です。セグメント ルーティング オーバー IPv6 (SRv6) データ プレーンでは、修復セグメント リストは (SID-R4、SID-R4-R3) です。
........
. .
[S]---(R1)---(R2)******(R6)---[R]
. | . |
. | . +++|++++
. | . + | +
. | . + (R5) +
. | . + | +
. | . + | +
. | . + | +
. (R3)------(R4) +
. . + +
........ ++++++++
Q-Space P-Space
Figure 3: P-Space and Q-Space
図 3: P スペースと Q スペース
In the PIM process, the IP addresses associated with the repair segment list are retrieved from the IGP LSDB.
PIM プロセスでは、修復セグメント リストに関連付けられた IP アドレスが IGP LSDB から取得されます。
On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4, which will be carried in the RPF Vector Attribute. The Adjacency SID Label-R4-R3 corresponds to the local address IP4-R4-R3 and the remote peer address IP4-R3-R4, with IP4-R3-R4 carried in the Explicit RPF Vector Attribute.
IPv4 データ プレーンでは、ノード SID Label-R4 は IP4-R4 に対応し、RPF ベクトル属性で伝送されます。隣接 SID ラベル-R4-R3 は、ローカル アドレス IP4-R4-R3 およびリモート ピア アドレス IP4-R3-R4 に対応し、IP4-R3-R4 は明示的 RPF ベクトル属性で伝送されます。
On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4, which will be carried in the RPF Vector Attribute. The End.X SID SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF Vector Attribute.
IPv6 データ プレーンでは、エンド SID SID-R4 は IP6-R4 に対応し、RPF ベクトル属性で伝送されます。End.X SID SID-R4-R3 は、ローカル アドレス IP6-R4-R3 およびリモート ピア アドレス IP6-R3-R4 に対応し、IP6-R3-R4 は明示的な RPF ベクトル属性で伝送されます。
Subsequently, R6 installs the secondary UMH using these RPF Vectors.
その後、R6 はこれらの RPF ベクターを使用してセカンダリ UMH をインストールします。
+---------+
|Type = 0 |
|IP4-R4 |
+---------+ +---------+
|Type = 4 | |Type = 4 |
|IP4-R3-R4| |IP4-R3-R4|
+---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1
Figure 4: Forwarding PIM Join Packet Along Secondary Path (IPv4)
図 4: セカンダリ パス (IPv4) に沿った PIM 参加パケットの転送
On the IPv4 data plane, the forwarding of the PIM Join packet along the secondary path is shown in Figure 4.
IPv4 データ プレーン上での、セカンダリ パスに沿った PIM Join パケットの転送を図 4 に示します。
R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4 of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit RPF Vector Attribute). R6 then forwards the packet along the secondary path.
R6 は、PIM Join パケットに 2 つの RPF ベクトル属性、タイプ 0 の IP4-R4 (RPF ベクトル属性) とタイプ 4 (明示的な RPF ベクトル属性) の IP4-R3-R4 を挿入します。次に、R6 はセカンダリ パスに沿ってパケットを転送します。
When R5 receives the packet, it performs a unicast route lookup of the first RPF Vector IP4-R4 and sends the packet to R4.
R5 がパケットを受信すると、最初の RPF ベクトル IP4-R4 のユニキャスト ルート ルックアップを実行し、パケットを R4 に送信します。
R4, being the owner of IP4-R4, removes the first RPF Vector from the packet and forwards it according to the next RPF Vector. R4 sends the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM neighbor R3 corresponds to IP4-R3-R4.
IP4-R4 の所有者である R4 は、パケットから最初の RPF ベクトルを削除し、次の RPF ベクトルに従って転送します。R4 は、PIM ネイバー R3 が IP4-R3-R4 に対応するため、次の RPF ベクトル IP4-R3-R4 に基づいてパケットを R3 に送信します。
When R3 receives the packet, as the owner of IP4-R3-R4, it removes the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded to the source through R3->R2->R1 based on unicast routes.
R3 は、IP4-R3-R4 の所有者としてパケットを受信すると、RPF ベクトルを削除します。RPF ベクトルがなくなったパケットは、ユニキャスト ルートに基づいて R3->R2->R1 を介して送信元に転送されます。
After the PIM Join packet reaches R1, a secondary multicast tree, R1->R2->R3->R4->R5->R6, is established hop by hop for (S, G) using MoFRR based on TI-LFA.
PIM Join パケットが R1 に到着すると、TI-LFA に基づく MoFRR を使用して、(S, G) に対してセカンダリ マルチキャスト ツリー R1->R2->R3->R4->R5->R6 がホップごとに確立されます。
+---------+
|Type = 0 |
|IP6-R4 |
+---------+ +---------+
|Type = 4 | |Type = 4 |
|IP6-R3-R4| |IP6-R3-R4|
+---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1
Figure 5: Forwarding PIM Join Packet Along Secondary Path (IPv6)
図 5: セカンダリ パス (IPv6) に沿った PIM 参加パケットの転送
On the IPv6 data plane, the forwarding of the PIM Join packet along the secondary path is illustrated in Figure 5. The procedure is analogous to that of the IPv4 data plane.
IPv6 データ プレーンでの、セカンダリ パスに沿った PIM Join パケットの転送を図 5 に示します。この手順は、IPv4 データ プレーンの手順と類似しています。
When a remote PQ node exists in both P-space and Q-space, the processing can be simplified to involve only the PQ node. In this case, only a single RPF Vector needs to be carried, and all other processing steps remain unchanged.
リモート PQ ノードが P 空間と Q 空間の両方に存在する場合、処理は PQ ノードのみに関与するように簡素化できます。この場合、単一の RPF ベクトルのみを運ぶ必要があり、他のすべての処理ステップは変更されません。
The management of the proposed approach is consistent with [RFC7916]. However, in the operation of this approach, the node on the backup Join paths must have an independent configuration strategy for installing RPF Vector Attributes in the PIM Join packet and controlling the sending of this PIM Join message.
提案されたアプローチの管理は [RFC7916] と一致しています。ただし、このアプローチの運用では、バックアップ参加パス上のノードは、PIM 参加パケットに RPF ベクトル属性をインストールし、この PIM 参加メッセージの送信を制御するための独立した設定戦略を持っている必要があります。
All nodes on the backup Join paths must be able to parse the PIM Join message with the RPF Vector Attribute. If the nodes do not understand the RPF Vector Attribute in the PIM Join packet, then they must discard the RPF Vector Attribute because failing to remove the RPF Vectors could cause upstream nodes to send the Join packet back towards these nodes causing loops.
バックアップ結合パス上のすべてのノードは、RPF ベクトル属性を使用して PIM 結合メッセージを解析できる必要があります。ノードが PIM Join パケットの RPF ベクトル属性を理解できない場合は、RPF ベクトル属性を破棄する必要があります。これは、RPF ベクトルの削除に失敗すると、上流ノードがこれらのノードに向けて Join パケットを送り返し、ループが発生する可能性があるためです。
If an administrator is manually specifying the path that the Join messages need to be sent on, it is recommended that the administrator computes the path to include nodes that support the Explicit RPF Vector and check that the state is created correctly on each node along the path. Tools like Mtrace [RFC8487] can be used for debugging and to ensure that the Join state is set up correctly.
管理者が参加メッセージを送信する必要があるパスを手動で指定している場合は、管理者が明示的 RPF ベクトルをサポートするノードを含むパスを計算し、パスに沿った各ノードで状態が正しく作成されていることを確認することをお勧めします。Mtrace [RFC8487] のようなツールをデバッグに使用し、結合状態が正しく設定されていることを確認できます。
This document has no IANA actions.
この文書には IANA のアクションはありません。
This document does not introduce additional security concerns. It does not change the security properties of PIM. For general PIM - Sparse Mode (PIM-SM) protocol security considerations, see [RFC7761]. The security considerations of LFA, RLFA, and MoFRR described in [RFC5286], [RFC7490], and [RFC7431] should apply to this document.
この文書は、追加のセキュリティ上の懸念を紹介するものではありません。PIM のセキュリティ プロパティは変更されません。一般的な PIM - スパース モード (PIM-SM) プロトコルのセキュリティに関する考慮事項については、[RFC7761] を参照してください。[RFC5286]、[RFC7490]、および [RFC7431] で説明されている LFA、RLFA、および MoFRR のセキュリティに関する考慮事項がこの文書に適用される必要があります。
When deploying TI-LFA, packets may be sent over nodes and links they were not transported through before, potentially raising the following security issues:
TI-LFA を導入すると、パケットがこれまで転送されなかったノードやリンクを介して送信される可能性があり、次のセキュリティ問題が発生する可能性があります。
1. Spoofing and false route advertisements
1. スプーフィングと偽のルート広告
* Dependencies of LFA/RLFA/TI-LFA on routing information
* ルーティング情報に対する LFA/RLFA/TI-LFA の依存関係
- LFAs depend on accurate routing information to determine alternate paths. If an attacker can inject false routing information (e.g., by spoofing link-state advertisements), it could cause the network to select suboptimal or malicious paths for LFAs.
- LFA は、正確なルーティング情報に基づいて代替パスを決定します。攻撃者が（リンクステート アドバタイズメントのスプーフィングなどにより）偽のルーティング情報を挿入できる場合、ネットワークが LFA に対して次善のパスまたは悪意のあるパスを選択する可能性があります。
- RLFA and TI-LFA also depend on accurate routing information, particularly for determining the tunneling paths or explicit paths. False route advertisements could mislead the network into using insecure or compromised paths.
- RLFA と TI-LFA は、特にトンネリング パスまたは明示的なパスを決定するために、正確なルーティング情報にも依存します。誤ったルートのアドバタイズメントにより、ネットワークが安全でないパスや侵害されたパスを使用するように誤解される可能性があります。
2. On-path attacks
2. 路上攻撃
* Use of alternate paths
* 代替パスの使用
- By rerouting traffic through alternate paths, especially those that traverse multiple hops (as in RLFA and TI-LFA), the risk of on-path attacks increases if any of the intermediate routers on the alternate path are compromised.
- 代替パス、特に複数のホップを通過するトラフィック (RLFA や TI-LFA など) を介してトラフィックを再ルーティングすることにより、代替パス上の中間ルーターのいずれかが侵害された場合、オンパス攻撃のリスクが増加します。
- TI-LFA, which uses explicit paths, might expose traffic to routers that were not originally part of the primary path, potentially allowing for interception or alteration of the traffic.
- 明示的パスを使用する TI-LFA は、元々プライマリ パスの一部ではなかったルーターにトラフィックを公開する可能性があり、トラフィックの傍受や変更が可能になる可能性があります。
3. Confidentiality and integrity
3. 機密性と誠実性
* Traffic encapsulation
* トラフィックのカプセル化
- RLFA and TI-LFA involve encapsulating traffic, which may expose it to vulnerabilities if the encapsulation mechanisms are not secure. For instance, if IPsec or another secure encapsulation method is not used, an attacker might be able to intercept or alter the traffic in transit.
- RLFA と TI-LFA にはトラフィックのカプセル化が含まれるため、カプセル化メカニズムが安全でない場合、トラフィックが脆弱性にさらされる可能性があります。たとえば、IPsec または別の安全なカプセル化方法が使用されていない場合、攻撃者は転送中のトラフィックを傍受または変更できる可能性があります。
* Protection of explicit paths
* 明示的なパスの保護
- TI-LFA relies on explicit paths that are typically defined using SR. If these paths are not properly protected, an attacker could manipulate the segment list to reroute traffic through malicious nodes.
- TI-LFA は、通常 SR を使用して定義される明示的なパスに依存します。これらのパスが適切に保護されていない場合、攻撃者がセグメント リストを操作して、悪意のあるノードを介してトラフィックを再ルーティングする可能性があります。
4. Increased attack surface
4. 攻撃対象領域の増加
* Extended topology
* 拡張トポロジ
- By introducing LFA, RLFA, and TI-LFA, the network increases its reliance on additional routers and links, thereby expanding the potential attack surface. Compromise of any router in these alternate paths could expose traffic to unauthorized access or disruption.
- LFA、RLFA、および TI-LFA を導入すると、ネットワークは追加のルーターやリンクへの依存度が高まり、潜在的な攻撃対象領域が拡大します。これらの代替パス内のルーターが侵害されると、トラフィックが不正アクセスや中断にさらされる可能性があります。
To address security issues 1 and 2 mentioned above, control plane protocols need to provide security protection. To mitigate the risks associated with false route advertisements and on-path attacks, it is recommended to use secure routing protocols (e.g., OSPFv3 with IPsec, IS-IS HMAC-SHA256, or PIM with IPsec) that provide authentication and integrity protection for routing updates.
前述のセキュリティ問題 1 と 2 に対処するには、コントロール プレーン プロトコルがセキュリティ保護を提供する必要があります。偽のルート アドバタイズメントやパス上の攻撃に関連するリスクを軽減するには、ルーティング更新の認証と整合性保護を提供するセキュア ルーティング プロトコル (IPsec を使用した OSPFv3、IS-IS HMAC-SHA256、または IPsec を使用した PIM など) を使用することをお勧めします。
To address security issues 3 and 4 mentioned above, these mechanisms need to run within a trusted network. The security of LFA, RLFA, and TI-LFA mechanisms heavily relies on the trustworthiness of the underlying routing infrastructure. As the solution described in the document is based on SR technology, readers should be aware of the security considerations related to this technology (see [RFC8402]) and its data plane instantiations (see [RFC8660], [RFC8754], and [RFC8986]).
上記のセキュリティ問題 3 と 4 に対処するには、これらのメカニズムを信頼できるネットワーク内で実行する必要があります。LFA、RLFA、および TI-LFA メカニズムのセキュリティは、基盤となるルーティング インフラストラクチャの信頼性に大きく依存しています。この文書で説明されているソリューションは SR テクノロジーに基づいているため、読者はこのテクノロジー ([RFC8402] を参照) およびそのデータ プレーンのインスタンス化 ([RFC8660]、[RFC8754]、および [RFC8986] を参照) に関連するセキュリティ上の考慮事項に注意する必要があります。
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008,
<https://www.rfc-editor.org/info/rfc5384>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7891] Asghar, J., Wijnands, IJ., Ed., Krishnaswamy, S., Karan,
A., and V. Arya, "Explicit Reverse Path Forwarding (RPF)
Vector", RFC 7891, DOI 10.17487/RFC7891, June 2016,
<https://www.rfc-editor.org/info/rfc7891>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <https://www.rfc-editor.org/info/rfc7916>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute Using Segment Routing", RFC 9855,
DOI 10.17487/RFC9855, October 2025,
<https://www.rfc-editor.org/info/rfc9855>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
S. Litkowski, "Remote-LFA Node Protection and
Manageability", RFC 8102, DOI 10.17487/RFC8102, March
2017, <https://www.rfc-editor.org/info/rfc8102>.
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
Traceroute Facility for IP Multicast", RFC 8487,
DOI 10.17487/RFC8487, October 2018,
<https://www.rfc-editor.org/info/rfc8487>.
Mengxiao Chen
New H3C Technologies
China
Email: chen.mengxiao@h3c.com
Yisong Liu
China Mobile
China
Email: liuyisong@chinamobile.com
Mike McBride
Futurewei Inc.
United States of America
Email: michael.mcbride@futurewei.com
Zheng (Sandy) Zhang
ZTE Corporation
China
Email: zhang.zheng@zte.com.cn
Jingrong Xie
Huawei Technologies
China
Email: xiejingrong@huawei.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com