[要約] RFC 9961は、MPLSセグメントルーティングP2MPポリシーにおける接続確認や障害診断のためのpingおよびtraceroute拡張機能を定義するドキュメントです。マルチキャストツリー内の転送問題をトラブルシューティングするためのOAMツールを提供し、SR P2MPポリシーを利用するネットワークの運用の堅牢性を強化します。既存のMPLS/SR OAMツールの適用範囲を広げます。
Internet Engineering Task Force (IETF) H. Bidgoli, Ed.
Request for Comments: 9961 Nokia
Category: Standards Track Z. Ali
ISSN: 2070-1721 Cisco System
Z. Zhang
Juniper Networks
A. Budhiraja
D. Voyer
Cisco System
April 2026
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanism and installed via, e.g., a Path Computation Element (PCE). In other cases, these policies can be installed using the Network Configuration Protocol (NETCONF) / YANG or a Command Line Interface (CLI). They are used to steer Multicast traffic along optimized paths from a Root to a set of Leaf routers.
セグメント ルーティング (SR) ポイントツーマルチポイント (P2MP) ポリシーは、ネットワーク内の明示的な P2MP パスを定義および管理するために使用されます。これらのポリシーは通常、コントローラーベースのメカニズムを介して計算され、パス計算要素 (PCE) などを介してインストールされます。他の場合には、これらのポリシーは、ネットワーク構成プロトコル (NETCONF) / YANG またはコマンド ライン インターフェイス (CLI) を使用してインストールできます。これらは、ルート ルーターから一連のリーフ ルーターまでの最適化されたパスに沿ってマルチキャスト トラフィックを誘導するために使用されます。
This document defines extensions to ping and traceroute mechanisms for an SR P2MP Policy with MPLS encapsulation to provide Operations, Administration, and Maintenance (OAM) capabilities. The extensions enable operators to verify connectivity, diagnose failures, and troubleshoot forwarding issues within SR P2MP Policy Multicast trees.
このドキュメントでは、運用、管理、およびメンテナンス (OAM) 機能を提供するために、MPLS カプセル化を使用した SR P2MP ポリシーの ping およびtraceroute メカニズムの拡張機能を定義します。この拡張機能により、オペレータは接続の確認、障害の診断、SR P2MP ポリシー マルチキャスト ツリー内の転送問題のトラブルシューティングを行うことができます。
By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP Multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing SR P2MP Policies.
このドキュメントでは、障害の検出とパスの整合性の検証のための新しいメカニズムを導入することにより、P2MP マルチキャスト展開の運用の堅牢性を強化します。さらに、既存の MPLS および SR ベースの OAM ツールを、SR P2MP ポリシーを利用するネットワークに効果的に適用できるようにします。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9961.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9961 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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. Conventions Used in This Document
3. Motivation
3.1. MPLS SR P2MP Policy Ping and Traceroute
3.1.1. Applicability of RFC 6425 to MPLS SR P2MP Policy
3.1.2. Conformance to Existing Procedures and Additional
Considerations
3.1.3. Considerations for Interworking with Unicast Paths
3.2. Packet Format and New TLVs
3.2.1. Identifying a P2MP Policy
3.2.1.1. SR MPLS P2MP Policy Tree Instance FEC Stack
Sub-TLVs
3.3. Limiting the Scope of Response
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Authors' Addresses
[RFC9960] explains the concept of the SR P2MP Policy and its candidate paths (CPs). It also explains the concept of how a CP is selected to be the active CP. To enable seamless global optimization, a CP may consist of multiple P2MP tree instances (PTIs), allowing for Make-Before-Break procedures between an active PTI and a newly established, optimized PTI. A PTI is the actual P2MP tunnel set up from the Root to a set of Leaves via transit routers. A PTI is identified on the Root node by the PTI's instance ID.
[RFC9960] は、SR P2MP ポリシーとその候補パス (CP) の概念を説明しています。また、CP がアクティブ CP として選択される方法の概念についても説明します。シームレスなグローバル最適化を可能にするために、CP は複数の P2MP ツリー インスタンス (PTI) で構成され、アクティブな PTI と新しく確立され最適化された PTI の間の Make-Before-Break プロシージャが可能になります。PTI は、ルートからトランジット ルーターを介して一連のリーブに設定される実際の P2MP トンネルです。PTI は、ルート ノード上で PTI のインスタンス ID によって識別されます。
To ensure reliable network operation, it is essential to verify end-to-end connectivity for both active and backup CPs, as well as all associated PTIs. This document specifies a mechanism for detecting data plane failures within an SR P2MP Policy CP and its associated PTIs, enabling operators to monitor and troubleshoot Multicast path integrity.
信頼性の高いネットワーク運用を確保するには、アクティブ CP とバックアップ CP の両方、および関連するすべての PTI のエンドツーエンド接続を検証することが不可欠です。この文書では、SR P2MP ポリシー CP およびそれに関連する PTI 内のデータ プレーン障害を検出するメカニズムを指定し、オペレーターがマルチキャスト パスの整合性を監視およびトラブルシューティングできるようにします。
This specification applies exclusively to Replication Segments (Replication-SIDs) that use MPLS encapsulation for forwarding and does not cover Segment Routing over IPv6 (SRv6). The mechanisms described herein build upon the concepts established in [RFC6425] for P2MP MPLS OAM. All considerations and limitations described in Section 6 of [RFC6425] apply to this document as well.
この仕様は、転送に MPLS カプセル化を使用するレプリケーション セグメント (レプリケーション SID) にのみ適用され、IPv6 経由のセグメント ルーティング (SRv6) はカバーされません。ここで説明するメカニズムは、P2MP MPLS OAM について [RFC6425] で確立された概念に基づいて構築されています。[RFC6425] のセクション 6 に記載されているすべての考慮事項と制限は、この文書にも適用されます。
The readers of this document should familiarize themselves with the following documents and sections for terminology and details regarding the implementation of the SR P2MP Policy.
このドキュメントの読者は、SR P2MP ポリシーの実装に関する用語と詳細について、次のドキュメントとセクションをよく理解しておく必要があります。
[RFC9524], Section 1.1 defines terms specific to an SR Replication segment and also explains the node terminology in a Multicast domain, including the Root node, Leaf node, and Bud node.
[RFC9524] のセクション 1.1 では、SR レプリケーション セグメントに固有の用語を定義し、ルート ノード、リーフ ノード、バッド ノードなど、マルチキャスト ドメインのノード用語についても説明しています。
[RFC9960], Section 1.1 defines terms and concepts specific to the SR P2MP Policy including the CP and the PTI.
[RFC9960] のセクション 1.1 は、CP と PTI を含む SR P2MP ポリシーに特有の用語と概念を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
An SR P2MP Policy and its corresponding Replication segments are typically provisioned via a centralized controller or configured using NETCONF/YANG or CLI. The Root and the Leaves are discovered in accordance with [RFC9960], and the Multicast tree is computed from the Root to the Leaves. However, there is no underlay signaling protocol to distribute the SR P2MP Policy from the Root to the Leaf routers. Consequently, when a P2MP tree fails to deliver user traffic, identifying the failure can be challenging without ping and traceroute mechanisms to isolate faults along the tree.
SR P2MP ポリシーとそれに対応するレプリケーション セグメントは通常、集中コントローラーを介してプロビジョニングされるか、NETCONF/YANG または CLI を使用して構成されます。ルートとリーフは [RFC9960] に従って検出され、マルチキャスト ツリーはルートからリーフまで計算されます。ただし、SR P2MP ポリシーをルート ルーターからリーフ ルーターに配布するためのアンダーレイ シグナリング プロトコルはありません。したがって、P2MP ツリーがユーザー トラフィックの配信に失敗した場合、ツリーに沿って障害を分離するための ping およびtraceroute メカニズムがなければ、障害を特定することが困難になる可能性があります。
To address this challenge, SR P2MP Policy ping and traceroute can be utilized to detect and localize faults within the P2MP tree and its associated Replication segments, as defined in [RFC9524]. These OAM tools enable periodic ping operations to verify connectivity between the Root and the Leaves. In cases where a ping fails, a traceroute can be initiated to determine the point of failure along the tree. This diagnostic process can be initiated from the node responsible for establishing the SR P2MP Policy, ensuring proactive monitoring and fault detection.
この課題に対処するには、[RFC9524] で定義されているように、SR P2MP ポリシーの ping とtraceroute を利用して、P2MP ツリーとそれに関連するレプリケーション セグメント内の障害を検出し、位置を特定できます。これらの OAM ツールにより、定期的な ping 操作が可能になり、ルートとリーフ間の接続を確認できます。ping が失敗した場合は、traceroute を開始してツリー上の障害点を特定できます。この診断プロセスは、SR P2MP ポリシーの確立を担当するノードから開始でき、プロアクティブな監視と障害検出を保証します。
Ping/traceroute packets are forwarded based upon the SR P2MP Policy on a specific CP and its PTI toward the designated Leaf routers. These packets are replicated at the replication point based on the Replication segment forwarding information on the corresponding router.
Ping/traceroute パケットは、特定の CP 上の SR P2MP ポリシーとその PTI に基づいて、指定されたリーフ ルーターに転送されます。これらのパケットは、対応するルーターのレプリケーション セグメント転送情報に基づいて、レプリケーション ポイントで複製されます。
MPLS packets are processed based on the standard behavior when their Time to Live (TTL) expires or when they reach the egress (Leaf) router. The appropriate response is sent back to the Root node following the procedures outlined in [RFC6425].
MPLS パケットは、Time to Live (TTL) の期限が切れたとき、または出力 (リーフ) ルーターに到達したときに、標準の動作に基づいて処理されます。[RFC6425] で概説されている手順に従って、適切な応答がルート ノードに送り返されます。
The procedures in [RFC6425] define fault detection and isolation mechanisms for P2MP MPLS Label Switched Paths (LSPs) and extend the LSP ping techniques described in [RFC8029] such that they may be applied to P2MP MPLS LSPs, ensuring alignment with existing fault management tools. [RFC6425] emphasizes the reuse of existing LSP ping mechanisms designed for Point-to-Point (P2P) LSPs, adapting them to P2MP MPLS LSPs to facilitate seamless implementation and network operation.
[RFC6425] の手順は、P2MP MPLS ラベル スイッチド パス (LSP) の障害検出および分離メカニズムを定義し、[RFC8029] で説明されている LSP ping 技術を P2MP MPLS LSP に適用できるように拡張して、既存の障害管理ツールとの整合性を確保します。[RFC6425] は、ポイントツーポイント (P2P) LSP 用に設計された既存の LSP ping メカニズムを再利用し、それらを P2MP MPLS LSP に適応させてシームレスな実装とネットワーク運用を促進することを強調しています。
The fault detection procedures specified in [RFC6425] are applicable to all P2MP MPLS protocols, including P2MP RSVP-TE and Multicast LDP and now the SR P2MP Policy. While [RFC6425] highlights specific differences for P2MP RSVP-TE and Multicast LDP, this document introduces considerations unique to SR P2MP Policies, including:
[RFC6425] で指定されている障害検出手順は、P2MP RSVP-TE およびマルチキャストLDP、そして現在は SR P2MP ポリシーを含むすべての P2MP MPLS プロトコルに適用されます。[RFC6425] では P2MP RSVP-TE とマルチキャストLDP の具体的な違いを強調していますが、この文書では次のような SR P2MP ポリシーに固有の考慮事項を紹介します。
1. Egress Address P2MP Responder sub-TLVs: Multicast LDP, as per Section 3.2.1 of [RFC6425], does not allow for the inclusion of Egress Address P2MP Responder sub-TLVs, as upstream Label Switching Routers (LSRs) lack visibility into downstream Leaf nodes. Similarly, SR P2MP Policies often rely on a PCE for programming transit routers. This is why in the SR P2MP domain, transit routers do not have knowledge of the Leaf nodes. Only the Root node, where the SR P2MP Policy is programmed, has visibility into the Leaf nodes. Consequently, these sub-TLVs SHOULD NOT be used when an echo request carries an SR P2MP Policy MPLS CP Forwarding Equivalence Class (FEC). If a node receives the Egress Address P2MP Responder sub-TLVs in an echo request, then it will not respond since it is unaware of whether it lies on the path to the address in the sub-TLV.
1. 出力アドレス P2MP レスポンダーのサブ TLV: [RFC6425] のセクション 3.2.1 に従って、上流のラベル スイッチング ルーター (LSR) には下流のリーフ ノードへの可視性がないため、マルチキャストLDP では出力アドレス P2MP レスポンダーのサブ TLV を含めることができません。同様に、SR P2MP ポリシーは多くの場合、トランジット ルーターのプログラミングに PCE に依存します。SR P2MP ドメインでは、トランジット ルーターがリーフ ノードについての情報を持たないのはこのためです。SR P2MP ポリシーがプログラムされているルート ノードのみが、リーフ ノードを認識できます。したがって、エコー要求が SR P2MP ポリシー MPLS CP 転送等価クラス (FEC) を伝送する場合、これらのサブ TLV を使用すべきではありません (SHOULD NOT)。ノードがエコー要求で出力アドレス P2MP レスポンダーのサブ TLV を受信した場合、ノードはサブ TLV 内のアドレスへのパス上にあるかどうかを認識しないため、応答しません。
2. End of processing for traceroutes: As per Section 4.3.1 of [RFC6425], it is RECOMMENDED that traceroute orations provide for a configurable upper limit on TTL values. This is because, for some protocols like Multicast LDP, there may not be an easy way to figure out the end of the traceroute processing, as the initiating LSR might not always know about all of the Leaf routers. In the case of an SR P2MP Policy, the Root node has visibility of the Leaf nodes; as such, there is a definitive way to estimate the end of processing for a traceroute, and a configurable upper limit on TTL may not be necessary. However, a configurable upper limit on the TTL value is an implementation choice.
2. トレースルートの処理の終了: [RFC6425] のセクション 4.3.1 に従って、トレースルートの説明で TTL 値に設定可能な上限を設けることが推奨されます(RECOMMENDED)。これは、マルチキャストLDPなどの一部のプロトコルでは、開始LSRがすべてのリーフルーターについて常に知っているとは限らないため、traceroute処理の終了を把握する簡単な方法がない可能性があるためです。SR P2MP ポリシーの場合、ルート ノードはリーフ ノードを認識できます。したがって、traceroute の処理の終了を推定する決定的な方法があり、TTL の構成可能な上限は必要ない場合があります。ただし、TTL 値の設定可能な上限は実装の選択です。
3. Identification of the LSP under test: Section 3.1 of [RFC6425] defines distinct identifiers for P2MP RSVP-TE and Multicast LDP when identifying an LSP under test. As each protocol has its own identifier, this document introduces a new Target FEC Stack TLV specific to SR P2MP Policies to uniquely identify their CPs and PTIs. These modifications ensure that SR P2MP Policy OAM mechanisms are properly aligned with existing MPLS ping and traceroute tools while addressing the specific operational characteristics of SR P2MP Policies.
3. テスト対象の LSP の識別: [RFC6425] のセクション 3.1 では、テスト対象の LSP を識別する際の P2MP RSVP-TE とマルチキャストLDP の個別の識別子を定義しています。各プロトコルには独自の識別子があるため、このドキュメントでは、CP と PTI を一意に識別するために、SR P2MP ポリシーに固有の新しいターゲット FEC スタック TLV を導入します。これらの変更により、SR P2MP ポリシーの特定の動作特性に対処しながら、SR P2MP ポリシーの OAM メカニズムが既存の MPLS ping およびtraceroute ツールと適切に連携することが保証されます。
In addition to major differences outlined in the previous section, SR P2MP Policies SHOULD follow the common procedures specified in [RFC6425] for P2MP MPLS LSPs. Furthermore, this specification reuses the same destination UDP port as defined in [RFC8029] for consistency with the existing MPLS OAM mechanism.
前のセクションで概説した主な違いに加えて、SR P2MP ポリシーは、P2MP MPLS LSP に対して [RFC6425] で指定されている共通手順に従う必要があります (SHOULD)。さらに、この仕様は、既存の MPLS OAM メカニズムとの一貫性を保つために、[RFC8029] で定義されているのと同じ宛先 UDP ポートを再利用します。
Implementations MUST account for the fact that an SR P2MP Policy may contain multiple CPs, and each CP may consist of multiple PTIs. As such, implementations SHOULD support the ability to individually test each CP and its corresponding PTI using ping and traceroute mechanisms. The ping and traceroute packets are forwarded along the specified CP and its PTI, traversing the associated Replication segments. When a downstream node capable of understanding the Replication-SID receives a ping or traceroute packet, it MUST process the request and generate a response even if the CP and its PTI are not currently the active path.
実装では、SR P2MP ポリシーに複数の CP が含まれる可能性があり、各 CP が複数の PTI で構成される可能性があるという事実を考慮しなければなりません (MUST)。そのため、実装では、ping およびtraceroute メカニズムを使用して、各 CP とそれに対応する PTI を個別にテストする機能をサポートする必要があります (SHOULD)。ping およびtraceroute パケットは、指定された CP およびその PTI に沿って転送され、関連するレプリケーション セグメントを通過します。Replication-SID を理解できるダウンストリーム ノードが ping またはtraceroute パケットを受信した場合、CP とその PTI が現在アクティブ パスでない場合でも、要求を処理し、応答を生成しなければなりません (MUST)。
As per [RFC9960], there are two ways to build a P2MP tree:
[RFC9960] によれば、P2MP ツリーを構築するには 2 つの方法があります。
1. P2MP tree with non-adjacent Replication segments
1. 隣接しないレプリケーション セグメントを含む P2MP ツリー
2. P2MP tree with adjacent Replication segments
2. 隣接するレプリケーション セグメントを持つ P2MP ツリー
For the case of adjacent Replication segments, there are no special considerations for the TTL or Hop Limit propagation, and the TTL should be decremented hop by hop as the OAM packet traverses the Replication segments of a P2MP tree.
隣接するレプリケーション セグメントの場合、TTL またはホップ制限の伝播について特別な考慮事項はありません。OAM パケットが P2MP ツリーのレプリケーション セグメントを通過するときに、TTL はホップごとに減分する必要があります。
For the case of non-adjacent Replication segments (for example, two Replication segments that are connected via an SR Policy or similar technology), there are special considerations. In such scenarios, SR P2MP Policy OAM tools should be used to verify the connectivity of the non-adjacent Replication segments that are building the P2MP tree, while the unicast OAM tools should be used to verify the connectivity of the unicast path connecting the two non-adjacent Replication segments. In these scenarios, the Replication-SID should not be exposed or examined in the unicast path. Proper TTL handling to copy the Replication segment TTL to the unicast path can be achieved via the hierarchical MPLS TTL mode being used (e.g., Pipe Mode vs. Uniform Mode) as per [RFC3270]. For the P2MP tree traceroute, the TTL mode MUST be set to Pipe Mode on the router that the unicast path starts. This will ensure that the unicast path TTL is set to a large value that allows the traceroute packet to be delivered to the downstream Replication segment. For ping, either the Pipe Mode or the Uniform Mode can be used depending on the implementation. The unicast path failure detection is considered out of scope for this document.
レプリケーション セグメントが隣接していない場合 (たとえば、SR ポリシーまたは同様のテクノロジを介して接続されている 2 つのレプリケーション セグメント)、特別な考慮事項があります。このようなシナリオでは、SR P2MP ポリシー OAM ツールを使用して、P2MP ツリーを構築している隣接しないレプリケーション セグメントの接続を検証する必要があります。また、ユニキャスト OAM ツールを使用して、2 つの隣接しないレプリケーション セグメントを接続するユニキャスト パスの接続を検証する必要があります。これらのシナリオでは、ユニキャスト パスでレプリケーション SID を公開したり調べたりする必要はありません。[RFC3270] に従って、レプリケーション セグメント TTL をユニキャスト パスにコピーするための適切な TTL 処理は、使用されている階層 MPLS TTL モード (パイプ モードとユニフォーム モードなど) を介して実現できます。P2MP ツリーのトレースルートの場合、ユニキャスト パスが開始するルーター上で TTL モードをパイプ モードに設定する必要があります。これにより、ユニキャスト パス TTL が大きな値に設定され、traceroute パケットがダウンストリーム レプリケーション セグメントに配信されるようになります。ping の場合、実装に応じてパイプ モードまたはユニフォーム モードのいずれかを使用できます。ユニキャスト パス障害の検出は、このドキュメントの範囲外とみなされます。
The packet format used in this specification follows Section 3 of [RFC8029]. However, additional TLVs and sub-TLVs are required to support the new functionality introduced for SR P2MP Policies. These extensions are described in the following sections.
この仕様で使用されるパケット形式は、[RFC8029] のセクション 3 に従います。ただし、SR P2MP ポリシーに導入された新しい機能をサポートするには、追加の TLV とサブ TLV が必要です。これらの拡張機能については、次のセクションで説明します。
[RFC8029] defines a standardized mechanism for detecting data plane failures in MPLS LSPs. To correctly identify the Replication segment associated with a given CP and PTI, the echo request message MUST include a Target FEC Stack TLV that explicitly specifies the CP and PTI under test.
[RFC8029] は、MPLS LSP のデータ プレーン障害を検出するための標準化されたメカニズムを定義しています。特定の CP および PTI に関連付けられたレプリケーション セグメントを正しく識別するには、テスト対象の CP および PTI を明示的に指定するターゲット FEC スタック TLV をエコー要求メッセージに含める必要があります。
This document introduces a new sub-TLV, referred to as the SR MPLS P2MP Policy Tree Instance sub-TLV, which is defined as follows:
このドキュメントでは、SR MPLS P2MP ポリシー ツリー インスタンス サブ TLV と呼ばれる新しいサブ TLV を導入します。これは次のように定義されます。
+==========+==========+===================================+
| Sub-Type | Length | Value Field |
+==========+==========+===================================+
| 41 | Variable | SR MPLS P2MP Policy Tree Instance |
+----------+----------+-----------------------------------+
Table 1
Further details regarding the structure and processing of this sub-TLV are provided in subsequent sections.
このサブ TLV の構造と処理に関する詳細については、後続のセクションで説明します。
The SR MPLS P2MP Policy Tree Instance sub-TLV value field follows the format specified in Section 2.3 of [RFC9960]. The structure of this sub-TLV is illustrated in the figure below. It should be noted that this sub-TLV is testing a specific PTI within a specific CP and it is not testing the CP.
SR MPLS P2MP ポリシー ツリー インスタンスのサブ TLV 値フィールドは、[RFC9960] のセクション 2.3 で指定された形式に従います。このサブ TLV の構造を次の図に示します。このサブ TLV は特定の CP 内の特定の PTI をテストしており、CP をテストしているわけではないことに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Root ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family:
アドレスファミリー:
2 octets. IPv4/IPv6 Address Family Numbers as specified in [IANA-AF], indicating the Address Family of the Root. Any other Address Family, except IPv4/IPv6, is not supported by this document.
2オクテット。[IANA-AF] で指定されている IPv4/IPv6 アドレス ファミリ番号。ルートのアドレス ファミリを示します。IPv4/IPv6 を除く他のアドレス ファミリは、このドキュメントではサポートされていません。
Address Length:
アドレスの長さ:
1 octet. Specifies the length of the Root Address in octets (4 octets for IPv4, and 16 octets for IPv6).
1オクテット。ルート アドレスの長さをオクテット単位で指定します (IPv4 の場合は 4 オクテット、IPv6 の場合は 16 オクテット)。
Reserved:
予約済み：
MUST be set to zero by the sender and should be ignored by the receiver.
送信者はゼロに設定しなければならず、受信者は無視する必要があります。
Root:
根：
Variable length depending on the Address Family field. The Root node of the SR P2MP Policy, as defined in [RFC9960].
Address Family フィールドに応じた可変長。[RFC9960] で定義されている SR P2MP ポリシーのルート ノード。
Tree-ID:
ツリーID:
4 octets. A unique identifier for the P2MP tree, as defined in [RFC9960].
4オクテット。[RFC9960] で定義されている、P2MP ツリーの一意の識別子。
Instance-ID:
インスタンスID:
2 octets. Identifies the specific Path-Instance, as defined in [RFC9960].
2オクテット。[RFC9960] で定義されているように、特定のパスインスタンスを識別します。
As specified in Section 3.2 of [RFC6425], four sub-TLVs are used within the P2MP Responder Identifier TLV that is included in the echo request message.
[RFC6425] のセクション 3.2 で規定されているように、エコー要求メッセージに含まれる P2MP レスポンダー識別子 TLV 内で 4 つのサブ TLV が使用されます。
The sub-TLVs for IPv4 and IPv6 egress addresses of the P2MP responder are aligned with Section 3.2.1 of [RFC6425].
P2MP レスポンダの IPv4 および IPv6 出力アドレスのサブ TLV は、[RFC6425] のセクション 3.2.1 に準拠しています。
The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder are aligned with Section 3.2.2 of [RFC6425].
P2MP レスポンダの IPv4 および IPv6 ノード アドレスのサブ TLV は、[RFC6425] のセクション 3.2.2 に準拠しています。
These mechanisms ensure that responses are appropriately scoped to limit unnecessary processing and improve the efficiency of P2MP OAM procedures.
これらのメカニズムにより、応答のスコープが適切に設定され、不必要な処理が制限され、P2MP OAM プロシージャの効率が向上します。
IANA has assigned a sub-type value for the SR MPLS P2MP Policy Tree Instance sub-TLV in the "Sub-TLVs for TLV Types 1, 16, and 21" registry under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group. The sub-type value has been assigned from the Standards Action range of 0-16383 as shown below. Note that the sub-TLV has been assigned from Type 1 (Target FEC Stack) of the "TLVs" registry.
IANA は、「マルチプロトコル ラベル スイッチング (MPLS) ラベル スイッチド パス (LSP) Ping パラメーター」レジストリ グループの「TLV タイプ 1、16、および 21 のサブ TLV」レジストリ内の SR MPLS P2MP ポリシー ツリー インスタンスのサブ TLV にサブタイプ値を割り当てました。サブタイプ値は、以下に示すように、標準アクションの範囲 0 ～ 16383 から割り当てられています。サブ TLV は、「TLV」レジストリのタイプ 1 (ターゲット FEC スタック) から割り当てられていることに注意してください。
+==========+===================================+
| Sub-Type | Sub-TLV Name |
+==========+===================================+
| 41 | SR MPLS P2MP Policy Tree Instance |
+----------+-----------------------------------+
Table 2
Overall, the security needs for SR P2MP Policy ping are the same as in [RFC9960], [RFC6425], and [RFC8029]. SR P2MP Policy ping is susceptible to the same three attack vectors as explained in Section 5 of [RFC8029]. The same procedures and recommendations explained in Section 5 of [RFC8029] should be taken and implemented to mitigate these attack vectors for SR P2MP Policy ping as well.
全体として、SR P2MP ポリシー ping のセキュリティのニーズは [RFC9960]、[RFC6425]、および [RFC8029] と同じです。SR P2MP ポリシー ping は、[RFC8029] のセクション 5 で説明されているのと同じ 3 つの攻撃ベクトルの影響を受けます。[RFC8029] のセクション 5 で説明されているのと同じ手順と推奨事項を採用し、SR P2MP ポリシー ping に対するこれらの攻撃ベクトルを軽減するために実装する必要があります。
In addition, the security considerations in Section 8 of [RFC6425] should be followed, specifically the security recommendations from [RFC4379], which recommend the following:
さらに、[RFC6425] のセクション 8 のセキュリティに関する考慮事項、特に次のことを推奨する [RFC4379] のセキュリティ推奨事項に従う必要があります。
To avoid potential Denial-of-Service attacks, it is RECOMMENDED that implementations regulate the LSP ping traffic going to the control plane. A rate limiter SHOULD be applied to the well-known UDP port [allocated for this service].
潜在的なサービス拒否攻撃を回避するために、コントロール プレーンに送信される LSP ping トラフィックを実装で規制することが推奨されます。[このサービスに割り当てられた]既知の UDP ポートにレート リミッタを適用する必要があります (SHOULD)。
[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>.
[RFC3270] Le Faucheur, F., Ed., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, DOI 10.17487/RFC3270,
May 2002, <https://www.rfc-editor.org/info/rfc3270>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<https://www.rfc-editor.org/info/rfc4379>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
February 2024, <https://www.rfc-editor.org/info/rfc9524>.
[RFC9960] Parekh, R., Ed., Voyer, D., Ed., Filsfils, C., Bidgoli,
H., and Z. Zhang, "Segment Routing Point-to-Multipoint
Policy", RFC 9960, DOI 10.17487/RFC9960, April 2026,
<https://www.rfc-editor.org/info/rfc9960>.
[IANA-AF] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
Hooman Bidgoli (editor)
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Zafar Ali
Cisco System
San Jose,
United States of America
Email: zali@cisco.com
Zhaohui Zhang
Juniper Networks
Boston,
United States of America
Email: zzhang@juniper.net
Anuj Budhiraja
Cisco System
San Jose,
United States of America
Email: abudhira@cisco.com
Daniel Voyer
Cisco System
Montreal
Canada
Email: davoyer@cisco.com