[要約] RFC 9960は、セグメントルーティング（SR）ドメインにおける効率的なポイントツーマルチポイント（P2MP）配信のためのアーキテクチャと手順を規定しています。SR-MPLSおよびSRv6上でP2MPポリシーを適用し、ツリーの構築や候補パスの管理、レプリケーションセグメントを用いた実装方法を定義しています。RFC 9524を更新し、マルチキャスト配信のスケーラビリティを向上させます。
Internet Engineering Task Force (IETF) R. Parekh, Ed.
Request for Comments: 9960 Arrcus
Updates: 9524 D. Voyer, Ed.
Category: Standards Track C. Filsfils
ISSN: 2070-1721 Cisco Systems, Inc.
H. Bidgoli
Nokia
Z. Zhang
Juniper Networks
April 2026
The Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees for efficient multipoint packet delivery in a Segment Routing (SR) domain. This document specifies the architecture, signaling, and procedures for SR P2MP Policies with Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct, candidate paths (CPs) of an SR P2MP Policy, and the instantiation of the P2MP tree instances (PTIs) of a CP using Replication segments. Additionally, it describes the required extensions for a controller to support P2MP path computation and provisioning. This document updates RFC 9524.
ポイントツーマルチポイント (P2MP) ポリシーにより、セグメント ルーティング (SR) ドメインでの効率的なマルチポイント パケット配信のための P2MP ツリーの作成が可能になります。この文書では、セグメント ルーティング オーバー MPLS (SR-MPLS) およびセグメント ルーティング オーバー IPv6 (SRv6) を使用した SR P2MP ポリシーのアーキテクチャ、シグナリング、および手順を規定します。これは、SR P2MP ポリシー構成、SR P2MP ポリシーの候補パス (CP)、およびレプリケーション セグメントを使用した CP の P2MP ツリー インスタンス (PTI) のインスタンス化を定義します。さらに、コントローラが P2MP パスの計算とプロビジョニングをサポートするために必要な拡張機能についても説明します。この文書は RFC 9524 を更新します。
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/rfc9960.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9960 で入手できます。
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
1.2. Requirements Language
2. SR P2MP Policy
2.1. SR P2MP Policy Identification
2.2. Components of an SR P2MP Policy
2.3. Candidate Paths and P2MP Tree Instances
3. Steering Traffic into an SR P2MP Policy
4. P2MP Tree Instance
4.1. Replication Segments at Leaf Nodes
4.2. Shared Replication Segments
4.3. Packet Forwarding in a P2MP Tree Instance
5. Using a Controller to Build a P2MP Tree
5.1. SR P2MP Policy on a Controller
5.2. Controller Functions
5.3. P2MP Tree Compute
5.4. SID Management
5.5. Instantiating P2MP Tree Instance on Nodes
5.6. Protection
5.6.1. Local Protection
5.6.2. Path Protection
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Illustration of the SR P2MP Policy and P2MP Tree
A.1. P2MP Tree with Non-Adjacent Replication Segments
A.1.1. SR-MPLS
A.1.2. SRv6
A.2. P2MP Tree with Adjacent Replication Segments
A.2.1. SR-MPLS
A.2.2. SRv6
Acknowledgements
Contributors
Authors' Addresses
[RFC9524] defines a Replication segment that enables a SR node to replicate traffic to multiple downstream nodes in an SR domain [RFC8402]. A Point-to-Multipoint (P2MP) service can be realized by a single Replication segment spanning from the ingress node to the egress nodes of the service. This effectively achieves ingress replication, which is inefficient since the traffic of the P2MP service may traverse the same set of nodes and links in the SR domain on its path from the ingress node to the egress nodes.
[RFC9524] は、SR ノードが SR ドメイン内の複数の下流ノードにトラフィックを複製できるようにする複製セグメントを定義しています [RFC8402]。ポイントツーマルチポイント (P2MP) サービスは、サービスの入口ノードから出口ノードまでにわたる単一のレプリケーション セグメントによって実現できます。これにより、イングレス レプリケーションが効果的に実現されますが、P2MP サービスのトラフィックがイングレス ノードからエグレス ノードへのパス上の SR ドメイン内の同じノードとリンクのセットを通過する可能性があるため、非効率的です。
A multipoint service delivery can be efficiently realized with a P2MP tree in a SR domain. A P2MP tree spans from a Root node to a set of Leaf nodes via intermediate Replication nodes. It consists of a Replication segment at the Root node, and that Replication segment is stitched to one or more Replication segments between the Leaf nodes and intermediate Replication nodes. A Bud node [RFC9524] is a node that is both a Replication node and a Leaf node. Any mention of "Leaf node(s)" in this document should be considered as referring to "Leaf or Bud node(s)".
SR ドメインの P2MP ツリーを使用すると、マルチポイント サービス配信を効率的に実現できます。P2MP ツリーは、ルート ノードから中間のレプリケーション ノードを介してリーフ ノードのセットまで広がります。これは、ルート ノードのレプリケーション セグメントで構成され、そのレプリケーション セグメントは、リーフ ノードと中間レプリケーション ノードの間の 1 つ以上のレプリケーション セグメントに結合されます。バッド ノード [RFC9524] は、レプリケーション ノードとリーフ ノードの両方であるノードです。このドキュメントでの「葉ノード」という記述は、「葉または芽ノード」を指すものとみなしてください。
An SR P2MP Policy defines the Root and Leaf nodes of a P2MP tree. It has one or more CPs provisioned with optional constraints and/or optimization objectives.
SR P2MP ポリシーは、P2MP ツリーのルート ノードとリーフ ノードを定義します。オプションの制約や最適化目標を備えた 1 つ以上の CP がプロビジョニングされています。
A controller computes PTIs of the CPs using the constraints and objectives specified in the CP. The controller then instantiates a PTI in the SR domain by signaling Replication segments to the Root, Replication, and Leaf nodes. A Path Computation Element (PCE) [RFC4655] is one example of such a controller. In other cases, a PTI can be installed using the Network Configuration Protocol (NETCONF) / YANG or the Command Line Interface (CLI) on the Root, Replication, and Leaf nodes.
コントローラーは、CP で指定された制約と目標を使用して CP の PTI を計算します。次に、コントローラーはルート、レプリケーション、およびリーフ ノードにレプリケーション セグメントを通知することにより、SR ドメインで PTI をインスタンス化します。パス計算要素 (PCE) [RFC4655] は、そのようなコントローラーの一例です。他の場合には、ネットワーク構成プロトコル (NETCONF) / YANG またはコマンド ライン インターフェイス (CLI) を使用して、ルート、レプリケーション、およびリーフ ノードに PTI をインストールできます。
The Replication segments of a PTI can be instantiated for SR-MPLS [RFC8660] and SRv6 [RFC8986] data planes, enabling efficient packet replication within an SR domain.
PTI のレプリケーション セグメントは SR-MPLS [RFC8660] および SRv6 [RFC8986] データ プレーン用にインスタンス化できるため、SR ドメイン内で効率的なパケット レプリケーションが可能になります。
This document updates the Replication-ID portion of the Replication segment identifier (Replication-SID) specified in Section 2 of [RFC9524].
この文書は、[RFC9524] のセクション 2 で指定されているレプリケーション セグメント識別子 (レプリケーション SID) のレプリケーション ID 部分を更新します。
This section defines terms used frequently in this document. Refer to the Terminology section of [RFC9524] for the definitions of Replication segment and other terms associated with it and the definitions of Root, Leaf, and Bud nodes.
このセクションでは、このドキュメントで頻繁に使用される用語を定義します。レプリケーションセグメントとそれに関連するその他の用語の定義、およびルート、リーフ、バッドノードの定義については、[RFC9524] の用語セクションを参照してください。
SR P2MP Policy:
SR P2MP ポリシー:
An SR P2MP Policy is a framework to construct P2MP trees in an SR domain by specifying Root and Leaf nodes.
SR P2MP ポリシーは、ルート ノードとリーフ ノードを指定して SR ドメイン内に P2MP ツリーを構築するためのフレームワークです。
Tree-ID:
ツリーID:
An identifier of an SR P2MP Policy in context of the Root node.
ルート ノードのコンテキストにおける SR P2MP ポリシーの識別子。
Candidate path (CP):
候補パス (CP):
A CP of the SR P2MP Policy defines topological or resource constraints and optimization objectives that are used to compute and construct PTIs.
SR P2MP ポリシーの CP は、PTI の計算と構築に使用されるトポロジーまたはリソースの制約と最適化目標を定義します。
P2MP tree instance (PTI):
P2MP ツリー インスタンス (PTI):
A PTI of a CP is constructed by stitching Replication segments between the Root and Leaf nodes of an SR P2MP Policy. Its topology is determined by the constraints and optimization objective of the CP.
CP の PTI は、SR P2MP ポリシーのルート ノードとリーフ ノードの間でレプリケーション セグメントを結合することによって構築されます。そのトポロジは、CP の制約と最適化目標によって決まります。
Instance-ID:
インスタンスID:
An identifier of a PTI in context of the SR P2MP Policy.
SR P2MP ポリシーのコンテキストにおける PTI の識別子。
Tree-SID:
ツリー SID:
The Replication-SID of the Replication segment at the Root node of a PTI.
PTI のルート ノードにあるレプリケーション セグメントのレプリケーション SID。
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 is used to instantiate P2MP trees between Root and Leaf nodes in an SR domain. Note that multiple SR P2MP Policies can have identical Root nodes and identical sets of Leaf nodes. An SR P2MP Policy has one or more CPs [RFC9256].
SR P2MP ポリシーは、SR ドメイン内のルート ノードとリーフ ノードの間で P2MP ツリーをインスタンス化するために使用されます。複数の SR P2MP ポリシーは、同一のルート ノードと同一のリーフ ノードのセットを持つことができることに注意してください。SR P2MP ポリシーには 1 つ以上の CP があります [RFC9256]。
An SR P2MP Policy is uniquely identified by the tuple <Root, Tree-ID>, where:
SR P2MP ポリシーは、タプル <Root, Tree-ID> によって一意に識別されます。ここで、
* Root: The IP address of the Root node of P2MP trees instantiated by the SR P2MP Policy.
* ルート: SR P2MP ポリシーによってインスタンス化された P2MP ツリーのルート ノードの IP アドレス。
* Tree-ID: A 32-bit unsigned integer that uniquely identifies the SR P2MP Policy in the context of the Root node.
* Tree-ID: ルート ノードのコンテキストで SR P2MP ポリシーを一意に識別する 32 ビットの符号なし整数。
An SR P2MP Policy consists of the following elements:
SR P2MP ポリシーは次の要素で構成されます。
* Leaf nodes: A set of nodes that terminate the P2MP trees of the SR P2MP Policy.
* リーフ ノード: SR P2MP ポリシーの P2MP ツリーを終了するノードのセット。
* Candidate paths: A set of possible paths that define constraints and optimization objectives for PTIs of the SR P2MP Policy.
* 候補パス: SR P2MP ポリシーの PTI の制約と最適化目標を定義する一連の可能なパス。
An SR P2MP Policy and its CPs are provisioned on a controller (see Section 5) or the Root node or both, depending upon the provisioning model. After provisioning, the Policy and its CPs are instantiated on the Root node or the controller by using a signaling protocol.
SR P2MP ポリシーとその CP は、プロビジョニング モデルに応じて、コントローラー (セクション 5 を参照) またはルート ノード、あるいはその両方でプロビジョニングされます。プロビジョニング後、ポリシーとその CP は、シグナリング プロトコルを使用してルート ノードまたはコントローラ上でインスタンス化されます。
An SR P2MP Policy has one or more CPs. The tuple <Protocol-Origin, Originator, Discriminator>, as specified in Section 2.6 of [RFC9256], uniquely identifies a CP in the context of an SR P2MP Policy. The semantics of Protocol-Origin, Originator, and Discriminator fields of the identifier are the same as in Sections 2.3, 2.4, and 2.5 of [RFC9256], respectively.
SR P2MP ポリシーには 1 つ以上の CP があります。[RFC9256] のセクション 2.6 で指定されているタプル <Protocol-Origin, Originator, Discriminator> は、SR P2MP ポリシーのコンテキストで CP を一意に識別します。識別子の Protocol-Origin、Originator、および Discriminator フィールドのセマンティクスは、それぞれ [RFC9256] のセクション 2.3、2.4、および 2.5 と同じです。
The Root node of the SR P2MP Policy selects the active CP based on the tiebreaking rules defined in Section 2.9 of [RFC9256].
SR P2MP ポリシーのルート ノードは、[RFC9256] のセクション 2.9 で定義されているタイブレーク ルールに基づいてアクティブ CP を選択します。
A CP may include topological and/or resource constraints and optimization objectives that influence the computation of the PTIs of the CP.
CP には、CP の PTI の計算に影響を与えるトポロジー制約および/またはリソース制約と最適化目標が含まれる場合があります。
A CP has zero or more PTIs. A CP does not have a PTI when the controller cannot compute a P2MP tree from the network topology based on the constraints and/or optimization objectives of the CP. A CP can have more than one PTI, e.g., during the Make-Before-Break (see Section 5.3) procedure to handle a network state change. However, one and only one PTI MUST be the active instance of the CP. If more than one PTI of a CP is active at same time, and that CP is the active CP of the SR P2MP Policy, then duplicate traffic may be delivered to the Leaf nodes.
CP には 0 個以上の PTI があります。コントローラが CP の制約や最適化目標に基づいてネットワーク トポロジから P2MP ツリーを計算できない場合、CP には PTI がありません。CP は、ネットワーク状態の変化を処理するための Make-Before-Break (セクション 5.3 を参照) 手順中に、複数の PTI を持つことができます。ただし、1 つの PTI だけが CP のアクティブなインスタンスでなければなりません。CP の複数の PTI が同時にアクティブであり、その CP が SR P2MP ポリシーのアクティブ CP である場合、重複したトラフィックがリーフ ノードに配信される可能性があります。
A PTI is identified by an Instance-ID. This is an unsigned 16-bit number that is unique in context of the SR P2MP Policy of the CP.
PTI はインスタンス ID によって識別されます。これは、CP の SR P2MP ポリシーのコンテキストにおいて一意の符号なし 16 ビットの数値です。
PTIs are instantiated using Replication segments. Section 2 of [RFC9524] specifies the Replication-ID of the Replication segment control plane identifier tuple as a variable length field that can be modified as required based on the use of a Replication segment. However, length is an imprecise indicator of the actual structure of the Replication-ID. This document updates the Replication-ID of the control plane identifier of a Replication segment [RFC9524] to be the tuple: <Root, Tree-ID, Instance-ID>, where <Root, Tree-ID> identifies the SR P2MP Policy and Instance-ID identifies the PTI within that SR P2MP Policy. The Replication segments used to instantiate a PTI are thus identified in the control plane by the tuple: <Root, Tree-ID, Instance-ID, Node-ID>. As per Section 2 of [RFC9524], for a simple use case, the Replication-ID is a 32-bit number. To map this use case to the tuple for the control plane identifier of a Replication segment as defined in this document, the Root MUST be zero (0.0.0.0 for IPv4 and :: for IPv6), the Instance-ID MUST be zero, and the 32-bit Tree-ID to effectively make the tuple <[0.0.0.0 or ::], Tree-ID, 0, Node-ID>.
PTI はレプリケーション セグメントを使用してインスタンス化されます。[RFC9524] のセクション 2 では、レプリケーション セグメントのコントロール プレーン識別子タプルの Replication-ID を、レプリケーション セグメントの使用に基づいて必要に応じて変更できる可変長フィールドとして指定しています。ただし、長さは、レプリケーション ID の実際の構造を示す不正確な指標です。この文書は、レプリケーション セグメント [RFC9524] のコントロール プレーン識別子のレプリケーション ID をタプル <Root, Tree-ID, Instance-ID> になるように更新します。ここで、<Root, Tree-ID> は SR P2MP ポリシーを識別し、Instance-ID はその SR P2MP ポリシー内の PTI を識別します。したがって、PTI のインスタンス化に使用されるレプリケーション セグメントは、コントロール プレーン内でタプル <Root, Tree-ID, Instance-ID, Node-ID> によって識別されます。[RFC9524] のセクション 2 に従って、単純な使用例では、レプリケーション ID は 32 ビットの数値です。このドキュメントで定義されているように、この使用例をレプリケーション セグメントのコントロール プレーン識別子のタプルにマップするには、ルートはゼロ (IPv4 の場合は 0.0.0.0、IPv6 の場合は ::)、インスタンス ID はゼロでなければならず、タプルを効果的に <[0.0.0.0 または ::]、ツリー ID、0、ノード ID> にするための 32 ビットのツリー ID でなければなりません。
PTIs may have different tree topologies due to possibly differing constraints and optimization objectives of the CPs in an SR P2MP Policy and across different policies. Even within a given CP, two PTIs of that CP, say during the Make-Before-Break procedure, are likely to have different tree topologies due to a change in the network state. Since the PTIs may have different tree topologies, their replication states also differ at various nodes in the SR domain. Therefore, each PTI has its own Replication segment and a unique Replication-SID in the data plane at a given node in the SR domain.
SR P2MP ポリシー内および異なるポリシー間で CP の制約と最適化目標が異なる可能性があるため、PTI は異なるツリー トポロジを持つ場合があります。特定の CP 内であっても、その CP の 2 つの PTI は、たとえば Make-Before-Break 手順中に、ネットワーク状態の変化により異なるツリー トポロジを持つ可能性があります。PTI は異なるツリー トポロジを持つ可能性があるため、SR ドメイン内のさまざまなノードでそのレプリケーション状態も異なります。したがって、各 PTI は、SR ドメイン内の特定のノードのデータ プレーンに独自のレプリケーション セグメントと一意のレプリケーション SID を持ちます。
A controller designates an active instance of a CP at the Root node of the SR P2MP Policy by signaling this state through the protocol used to instantiate the Replication segment of the instance.
コントローラーは、インスタンスのレプリケーション セグメントのインスタンス化に使用されるプロトコルを通じてこの状態を通知することにより、SR P2MP ポリシーのルート ノードで CP のアクティブなインスタンスを指定します。
This document focuses on the use of a controller to compute and instantiate PTIs of SR P2MP Policy CPs. It is also feasible to provision an explicit CP in an SR P2MP Policy with a static tree topology using NETCONF/YANG or CLI. Note that a static tree topology will not adapt to any changes in the network state of an SR domain. The explicit CPs may be provisioned on the controller or the Root node. When an explicit CP is provisioned on the controller, the controller bypasses the compute stage and directly instantiates the PTIs in the SR domain. When an explicit CP is provisioned on the Root node, the Root node instantiates the PTIs in the SR domain. The exact procedures for provisioning an explicit CP and the signaling from the Root node to instantiate the PTIs are outside the scope of this document.
このドキュメントでは、SR P2MP ポリシー CP の PTI を計算およびインスタンス化するためのコントローラーの使用に焦点を当てます。NETCONF/YANG または CLI を使用して、静的ツリー トポロジを備えた SR P2MP ポリシーで明示的な CP をプロビジョニングすることも可能です。静的ツリー トポロジは、SR ドメインのネットワーク状態の変化には適応しないことに注意してください。明示的な CP は、コントローラーまたはルート ノードにプロビジョニングできます。明示的な CP がコントローラ上でプロビジョニングされると、コントローラはコンピューティング ステージをバイパスし、SR ドメインで PTI を直接インスタンス化します。明示的 CP がルート ノードでプロビジョニングされると、ルート ノードは SR ドメインで PTI をインスタンス化します。明示的な CP をプロビジョニングするための正確な手順と、PTI をインスタンス化するためのルート ノードからのシグナリングについては、このドキュメントの範囲外です。
The Replication-SID of the Replication segment at the Root node is referred to as the Tree-SID of a PTI. It is RECOMMENDED that the Tree-SID is also used as the Replication-SID for the Replication segments at the intermediate Replication nodes and the Leaf nodes of the PTI as it simplifies operations and troubleshooting. However, the Replication-SIDs of the Replication segments at the intermediate Replication nodes and the Leaf nodes MAY differ from the Tree-SID. For SRv6, Replication-SID is the FUNCT portion of the SRv6 segment ID (SID) [RFC8986] [RFC9524]. Note that even if the Tree-SID is the Replication-SID of all the Replication segments of a PTI, the locator (LOC) portion of the SRv6 SID [RFC8986] differs for the Root node, the intermediate Replication nodes, and the Leaf nodes of the PTI.
ルート ノードのレプリケーション セグメントのレプリケーション SID は、PTI のツリー SID と呼ばれます。操作とトラブルシューティングが簡素化されるため、ツリー SID を PTI の中間レプリケーション ノードおよびリーフ ノードのレプリケーション セグメントのレプリケーション SID としても使用することをお勧めします。ただし、中間レプリケーション ノードおよびリーフ ノードのレプリケーション セグメントのレプリケーション SID は、ツリー SID と異なっていてもよい(MAY)。SRv6 の場合、Replication-SID は SRv6 セグメント ID (SID) [RFC8986] [RFC9524] の FUNCT 部分です。Tree-SID が PTI のすべてのレプリケーション セグメントのレプリケーション SID である場合でも、SRv6 SID [RFC8986] のロケーター (LOC) 部分は、PTI のルート ノード、中間レプリケーション ノード、およびリーフ ノードで異なることに注意してください。
An SR P2MP Policy has a Binding SID (BSID). The BSID is used to steer traffic into an SR P2MP Policy, as described below, when the Root node is not the ingress node of the SR domain where the traffic arrives. The packets are steered from the ingress node to the Root node using a segment list with the BSID as the last segment in the list. In this case, it is RECOMMENDED that the BSID of an SR P2MP Policy SHOULD be constant throughout the lifetime of the policy so the steering of traffic to the Root node remains unchanged. The BSID of an SR P2MP Policy MAY be the Tree-SID of the active P2MP instance of the active CP of the policy. In this case, the BSID of an SR P2MP Policy changes when the active CP or the active PTI of the SR P2MP Policy changes. Note that the BSID is not required to steer traffic into an SR P2MP Policy when the Root node of an SR P2MP Policy is also the ingress node of the SR domain where the traffic arrives.
SR P2MP ポリシーにはバインディング SID (BSID) があります。BSID は、ルート ノードがトラフィックが到着する SR ドメインの入口ノードではない場合に、以下で説明するようにトラフィックを SR P2MP ポリシーに誘導するために使用されます。パケットは、BSID がリストの最後のセグメントであるセグメント リストを使用して、入力ノードからルート ノードに誘導されます。この場合、ルート ノードへのトラフィックのステアリングが変更されないように、SR P2MP ポリシーの BSID はポリシーの存続期間を通じて一定であるべきであることが推奨されます。SR P2MP ポリシーの BSID は、ポリシーのアクティブな CP のアクティブな P2MP インスタンスの Tree-SID であってもよい (MAY)。この場合、SR P2MP ポリシーのアクティブ CP またはアクティブ PTI が変更されると、SR P2MP ポリシーの BSID が変更されます。SR P2MP ポリシーのルート ノードがトラフィックが到着する SR ドメインの入口ノードでもある場合、BSID はトラフィックを SR P2MP ポリシーに誘導する必要がないことに注意してください。
The Root node can steer an incoming packet into an SR P2MP Policy in one of following methods:
ルート ノードは、次のいずれかの方法で受信パケットを SR P2MP ポリシーに誘導できます。
* Local-policy-based forwarding: The Root node maps the incoming packet to the active PTI of the active CP of an SR P2MP Policy based on local forwarding policy, and it is replicated with the encapsulated Replication-SIDs of the downstream nodes. The procedures to map an incoming packet to an SR P2MP Policy are out of scope of this document. It is RECOMMENDED that an implementation provide a mechanism to examine the result of application of the local forwarding policy, i.e., provide information about the traffic mapped to an SR P2MP Policy and the active CP and active PTI of the policy.
* ローカル ポリシー ベースの転送: ルート ノードは、ローカル転送ポリシーに基づいて、受信パケットを SR P2MP ポリシーのアクティブ CP のアクティブ PTI にマッピングし、ダウンストリーム ノードのカプセル化されたレプリケーション SID を使用して複製されます。受信パケットを SR P2MP ポリシーにマッピングする手順は、このドキュメントの範囲外です。実装では、ローカル転送ポリシーの適用結果を検査するメカニズムを提供すること、つまり、SR P2MP ポリシーにマッピングされたトラフィックと、ポリシーのアクティブ CP およびアクティブ PTI に関する情報を提供することが推奨されます。
* Tree-SID-based forwarding: The BSID, which may be the Tree-SID of the active PTI, in an incoming packet is used to map the packet to the active PTI. The BSID in the incoming packet is replaced with the Tree-SID of the active PTI of the active CP, and the packet is replicated with the Replication-SIDs of the downstream nodes.
* ツリー SID ベースの転送: 受信パケット内の BSID (アクティブ PTI のツリー SID である場合もあります) は、パケットをアクティブ PTI にマッピングするために使用されます。受信パケット内の BSID は、アクティブ CP のアクティブ PTI の Tree-SID に置き換えられ、パケットはダウンストリーム ノードの Replication-SID で複製されます。
For local-policy-based forwarding with SR-MPLS, the TTL for the Root node SHOULD set the TTL in the encapsulating MPLS header so that the replicated packet can reach the furthest Leaf node. The Root MAY set the TTL in the encapsulating MPLS header from the payload. In this case, the TTL may not be sufficient for the replicated packet to reach the furthest node. For SRv6, Section 2.2 of [RFC9524] provides guidance to set the IPv6 Hop Limit of the encapsulating IPv6 header.
SR-MPLS を使用したローカル ポリシー ベースの転送の場合、複製されたパケットが最も遠いリーフ ノードに到達できるように、ルート ノードの TTL をカプセル化する MPLS ヘッダーに TTL を設定する必要があります (SHOULD)。ルートは、ペイロードからのカプセル化 MPLS ヘッダーに TTL を設定してもよい(MAY)。この場合、複製されたパケットが最も遠いノードに到達するには TTL が十分ではない可能性があります。SRv6 の場合、[RFC9524] のセクション 2.2 は、カプセル化 IPv6 ヘッダーの IPv6 ホップ制限を設定するためのガイダンスを提供します。
A PTI within an SR domain establishes a forwarding structure that connects a Root node to a set of Leaf nodes via a series of intermediate Replication nodes. The tree consists of:
SR ドメイン内の PTI は、一連の中間レプリケーション ノードを介してルート ノードをリーフ ノードのセットに接続する転送構造を確立します。ツリーは次のもので構成されます。
* A Replication segment at the Root node.
* ルート ノードのレプリケーション セグメント。
* Zero or more Replication segments at intermediate Replication nodes.
* 中間レプリケーション ノードに 0 個以上のレプリケーション セグメント。
* Replication segments at the Leaf nodes.
* リーフ ノードのレプリケーション セグメント。
A specific service is identified by a service context in a packet. A PTI is usually associated with one and only one multipoint service. On a Leaf node of such a multipoint service, the transport identifier, which is the Tree-SID or Replication-SID of the Replication segment at a Leaf node, is also associated with the service context because it is not always feasible to separate the transport and service context with efficient replication in core since a) multipoint services may have differing sets of endpoints and b) downstream allocation of a service context cannot be encoded in packets replicated in the core.
特定のサービスは、パケット内のサービス コンテキストによって識別されます。通常、PTI は 1 つのマルチポイント サービスに関連付けられます。このようなマルチポイント サービスのリーフ ノードでは、リーフ ノードのレプリケーション セグメントのツリー SID またはレプリケーション SID であるトランスポート識別子もサービス コンテキストに関連付けられます。これは、a) マルチポイント サービスには異なるエンドポイントのセットがある可能性があり、b) サービス コンテキストのダウンストリーム割り当てはコアで複製されたパケットにエンコードできないため、コアでの効率的なレプリケーションでトランスポートとサービス コンテキストを分離することが常に実現可能であるとは限らないためです。
A PTI can be associated with one or more multipoint services on the Root and Leaf nodes. In SR-MPLS deployments, if it is known a priori that multipoint services mapped to an SR-MPLS PTI can be uniquely identified with their service label, a controller MAY opt to not instantiate Replication segments at Leaf nodes. In such cases, Replication nodes upstream of the Leaf nodes can remove the Tree-SID from the packet before forwarding it. A multipoint service context allocated from an upstream assigned label or Domain-wide Common Block (DCB), as specified in [RFC9573], is an example of a globally unique context that facilitates this optimization.
PTI は、ルート ノードおよびリーフ ノード上の 1 つ以上のマルチポイント サービスに関連付けることができます。SR-MPLS 導入において、SR-MPLS PTI にマッピングされたマルチポイント サービスがサービス ラベルで一意に識別できることが事前にわかっている場合、コントローラはリーフ ノードでレプリケーション セグメントをインスタンス化しないことを選択してもよい(MAY)。このような場合、リーフ ノードの上流のレプリケーション ノードは、パケットを転送する前にパケットから Tree-SID を削除できます。[RFC9573] で規定されているように、上流に割り当てられたラベルまたはドメイン全体の共通ブロック (DCB) から割り当てられたマルチポイント サービス コンテキストは、この最適化を容易にするグローバルに固有のコンテキストの例です。
In SRv6 deployments, Replication segments of a PTI MUST be instantiated on Leaf nodes of the tree since behavior like Penultimate Hop Popping (PHP) is not feasible because the Tree-SID is carried in the IPv6 Destination Address field of the outer IPv6 header. If two or more multipoint services are mapped to one SRv6 PTI, an SRV6 SID representing the service context is assigned by the Root node or assigned from the DCB. This SRv6 SID MUST be encoded as the last segment in the Segment List of the Segment Routing Header [RFC8754] by the Root node to derive the packet processing context (PPC) for the service, as described in Section 2.2 of [RFC9524], at a Leaf node.
SRv6 展開では、ツリー SID が外側の IPv6 ヘッダーの IPv6 宛先アドレス フィールドで伝送されるため、PHP (Penultimate Hop Popping) のような動作が実現できないため、PTI のレプリケーション セグメントはツリーのリーフ ノードでインスタンス化されなければなりません。2 つ以上のマルチポイント サービスが 1 つの SRv6 PTI にマッピングされている場合、サービス コンテキストを表す SRV6 SID はルート ノードによって割り当てられるか、DCB から割り当てられます。この SRv6 SID は、[RFC9524] のセクション 2.2 で説明されているように、リーフ ノードでサービスのパケット処理コンテキスト (PPC) を導出するために、ルート ノードによってセグメント ルーティング ヘッダー [RFC8754] のセグメント リストの最後のセグメントとしてエンコードされなければなりません (MUST)。
A Replication segment MAY be shared across different PTIs. One simple use of a shared Replication segment is for local protection on a Replication node. Assume a Replication node, say node X, has multiple PTIs. Assume the Replications segments of these PTIs replicate to a downstream node, say node Y, amongst other downstream nodes. This node Y is a common downstream node of these Replication segments at node X. A Replication segment is established to protect the adjacency or path between node X and node Y; this Replication segment can be shared across all the Replication segments of the PTIs replicating from node X to node Y.
レプリケーション セグメントは、異なる PTI 間で共有できます (MAY)。共有レプリケーション セグメントの簡単な用途の 1 つは、レプリケーション ノード上のローカル保護です。レプリケーション ノード (ノード X など) に複数の PTI があるとします。これらの PTI のレプリケーション セグメントが、他の下流ノードの中から下流ノード、たとえばノード Y に複製されると仮定します。このノード Y は、ノード X にあるこれらのレプリケーション セグメントの共通の下流ノードです。レプリケーション セグメントは、ノード X とノード Y の間の隣接関係またはパスを保護するために確立されます。このレプリケーション セグメントは、ノード X からノード Y にレプリケートされる PTI のすべてのレプリケーション セグメント間で共有できます。
A shared Replication segment MUST be identified using a Root set to zero (0.0.0.0 for IPv4 and :: for IPv6), an Instance-ID set to zero, and a Tree-ID that is unique within the context of the node where the Replication segment is instantiated. The Root is zero because a shared Replication segment is not associated with a particular SR P2MP Policy or a PTI. Note that the shared Replication-SID conforms with the updated Replication-ID definition in Section 2.3.
共有レプリケーション セグメントは、ゼロに設定されたルート (IPv4 の場合は 0.0.0.0、IPv6 の場合は ::)、ゼロに設定されたインスタンス ID、およびレプリケーション セグメントがインスタンス化されるノードのコンテキスト内で一意のツリー ID を使用して識別されなければなりません (MUST)。共有レプリケーション セグメントは特定の SR P2MP ポリシーまたは PTI に関連付けられていないため、ルートはゼロです。共有レプリケーション SID は、セクション 2.3 の更新されたレプリケーション ID 定義に準拠していることに注意してください。
It is possible for different PTIs to share a P2MP tree at a Replication node. This allows a common sub-tree to be shared across PTIs whose tree topologies are identical in some portion of an SR domain. The procedures to share a P2MP tree across PTIs are outside the scope of this document.
異なる PTI がレプリケーション ノードで P2MP ツリーを共有することが可能です。これにより、SR ドメインの一部でツリー トポロジが同一である PTI 間で共通のサブツリーを共有できるようになります。PTI 間で P2MP ツリーを共有する手順は、このドキュメントの範囲外です。
When a packet is steered into a PTI, the Replication segment at the Root node performs packet replication and forwards copies to downstream nodes.
パケットが PTI に誘導されると、ルート ノードのレプリケーション セグメントがパケットのレプリケーションを実行し、コピーを下流のノードに転送します。
* Each replicated packet carries the Replication-SID of the Replication segment at the downstream node.
* 複製された各パケットには、ダウンストリーム ノードのレプリケーション セグメントのレプリケーション SID が含まれます。
* A downstream node can be either:
* ダウンストリーム ノードは次のいずれかになります。
- A Leaf node, in which case the replication process terminates, or
- リーフ ノード (この場合、レプリケーション プロセスは終了します)、または
- An intermediate Replication node, which further replicates the packet through its associated Replication segments until it reaches all Leaf nodes.
- 中間レプリケーション ノード。すべてのリーフ ノードに到達するまで、関連するレプリケーション セグメントを通じてパケットをさらに複製します。
A Replication node and a downstream node can be non-adjacent. In this case, the replicated packet has to traverse a path to reach the downstream node. For SR-MPLS, this is achieved by inserting one or more SIDs before the downstream Replication-SID. For SRv6, the LOC [RFC8986] of the downstream Replication-SID can guide the packet to the downstream node or an optional segment list may be used to steer the replicated packet on a specific path to the downstream node. For details of SRv6 replication to a non-adjacent downstream node and IPv6 Hop Limit considerations, refer to Section 2.2 of [RFC9524].
レプリケーション ノードとダウンストリーム ノードは隣接していなくてもかまいません。この場合、複製されたパケットは、下流ノードに到達するためにパスを通過する必要があります。SR-MPLS の場合、これは、ダウンストリームのレプリケーション SID の前に 1 つ以上の SID を挿入することによって実現されます。SRv6 の場合、ダウンストリーム Replication-SID の LOC [RFC8986] は、パケットをダウンストリーム ノードにガイドできます。または、オプションのセグメント リストを使用して、複製されたパケットを特定のパス上でダウンストリーム ノードに導くことができます。隣接しないダウンストリーム ノードへの SRv6 複製および IPv6 ホップ制限に関する考慮事項の詳細については、[RFC9524] のセクション 2.2 を参照してください。
A controller is instantiated or provisioned with the SR P2MP Policy and its CPs to compute and instantiate PTIs in an SR domain. The procedures for provisioning or instantiation of these constructs on a controller are outside the scope of this document.
コントローラーは、SR ドメイン内の PTI を計算してインスタンス化するために、SR P2MP ポリシーとその CP を使用してインスタンス化またはプロビジョニングされます。コントローラー上でこれらの構成をプロビジョニングまたはインスタンス化する手順は、このドキュメントの範囲外です。
An SR P2MP Policy is provisioned on a controller by an entity that can be an operator, a network node, or a machine by specifying the addresses of the Root, the set of Leaf nodes, and the CPs. In this case, the policy and its CPs are instantiated on the Root node using a signaling protocol. An SR P2MP Policy, its Leaf nodes, and the CPs may also be provisioned on the Root node and then instantiated on the controller using a signaling protocol. The procedures and mechanisms for provisioning and instantiation of an SR P2MP Policy and its CPS on a controller or a Root node are outside the scope of this document.
SR P2MP ポリシーは、ルート、リーフ ノードのセット、および CP のアドレスを指定することにより、オペレーター、ネットワーク ノード、またはマシンとなるエンティティによってコントローラー上にプロビジョニングされます。この場合、ポリシーとその CP は、シグナリング プロトコルを使用してルート ノード上でインスタンス化されます。SR P2MP ポリシー、そのリーフ ノード、および CP は、ルート ノード上でプロビジョニングされ、シグナリング プロトコルを使用してコントローラ上でインスタンス化される場合もあります。コントローラーまたはルート ノード上での SR P2MP ポリシーとその CPS のプロビジョニングとインスタンス化の手順とメカニズムは、このドキュメントの範囲外です。
The possible set of constraints and optimization objective of a CP are described in Section 3 of [SR-POLICY]. Other constraints and optimization objectives MAY be used for P2MP tree computation.
CP の考えられる制約セットと最適化目標については、[SR-POLICY] のセクション 3 で説明されています。他の制約と最適化目標を P2MP ツリーの計算に使用してもよい(MAY)。
A controller performs the following functions in general:
コントローラーは一般に次の機能を実行します。
* Topology Discovery: A controller discovers network topology across Interior Gateway Protocol (IGP) areas, levels, or Autonomous Systems (ASes).
* トポロジ検出: コントローラは、インテリア ゲートウェイ プロトコル (IGP) エリア、レベル、または自律システム (AS) 全体のネットワーク トポロジを検出します。
* Capability Exchange: A controller discovers a node's capability to participate in an SR P2MP Policy as well as advertise its capability to support the SR P2MP Policy.
* 機能交換: コントローラーは、SR P2MP ポリシーに参加するノードの機能を検出し、SR P2MP ポリシーをサポートする機能をアドバタイズします。
A controller computes one or more PTIs for CPs of an SR P2MP Policy. A CP may not have any PTIs if a controller cannot compute a P2MP tree for it.
コントローラーは、SR P2MP ポリシーの CP の 1 つ以上の PTI を計算します。コントローラが P2MP ツリーを計算できない場合、CP は PTI を持たない可能性があります。
A controller MUST compute a P2MP tree such that there are no loops in the tree at steady state as required by [RFC9524].
コントローラは、[RFC9524] で要求されているように、定常状態でツリー内にループが存在しないように P2MP ツリーを計算しなければなりません (MUST)。
A controller SHOULD modify a PTI of a CP on detecting a change in the network topology if the change affects the tree instance or when a better path can be found based on the new network state. Alternatively, the controller MAY decide to implement a Make-Before-Break approach to minimize traffic loss. The controller can do this by creating a new PTI, activating the new instance once it is instantiated in the network, and then removing the old PTI.
コントローラは、ネットワーク トポロジの変更を検出したときに、その変更がツリー インスタンスに影響を与える場合、または新しいネットワーク状態に基づいてより適切なパスが見つかる場合に、CP の PTI を変更する必要があります (SHOULD)。あるいは、コントローラは、トラフィック損失を最小限に抑えるために、Make-Before-Break アプローチを実装することを決定してもよい(MAY)。コントローラーは、新しい PTI を作成し、ネットワーク内でインスタンス化された後に新しいインスタンスをアクティブ化し、古い PTI を削除することでこれを実行できます。
The controller assigns the Replication-SIDs for the Replication segments of the PTI.
コントローラーは、PTI のレプリケーション セグメントにレプリケーション SID を割り当てます。
The Replication-SIDs of a PTI of a CP of an SR P2MP Policy can be either dynamically assigned by the controller or statically assigned by the entity provisioning the SR P2MP Policy.
SR P2MP ポリシーの CP の PTI のレプリケーション SID は、コントローラーによって動的に割り当てられるか、SR P2MP ポリシーをプロビジョニングするエンティティによって静的に割り当てられます。
For SR-MPLS, a Replication-SID may be assigned from the SR Local Block (SRLB) or the SR Global Block (SRGB) [RFC8402]. It is RECOMMENDED to assign a Replication-SID from the SRLB since Replication segments are local to each node of the PTI. It is NOT RECOMMENDED to allocate a Replication-SID from the SRGB since this block is globally significant in the SR domain any it may get depleted if a significant number of PTIs are instantiated in the SR domain.
SR-MPLS の場合、レプリケーション SID は SR ローカル ブロック (SRLB) または SR グローバル ブロック (SRGB) から割り当てられる場合があります [RFC8402]。レプリケーション セグメントは PTI の各ノードに対してローカルであるため、SRLB からレプリケーション SID を割り当てることが推奨されます。このブロックは SR ドメイン内でグローバルに重要であり、SR ドメイン内で多数の PTI がインスタンス化されると枯渇する可能性があるため、SRGB からレプリケーション SID を割り当てることは推奨されません。
Section 3 recommends that the Tree-SID be used as the Replication-SIDs for all the Replication segments of a PTI. It may be feasible to allocate the same Tree-SID value for all the Replication segments if the blocks used for allocation are not identical on all the nodes of the PTI or if the particular Tree-SID value in the block is assigned to some other SID on some node.
セクション 3 では、PTI のすべてのレプリケーション セグメントのレプリケーション SID として Tree-SID を使用することを推奨しています。割り当てに使用されるブロックが PTI のすべてのノードで同一ではない場合、またはブロック内の特定の Tree-SID 値がノード上の他の SID に割り当てられている場合、すべてのレプリケーション セグメントに同じ Tree-SID 値を割り当てることが可能な場合があります。
A BSID is also assigned for the SR P2MP Policy. The controller MAY decide to not assign a BSID and allow the Root node of the SR P2MP Policy to assign the BSID. It is RECOMMENDED to assign the BSID of an SR P2MP Policy from the SRLB for SR-MPLS.
BSID は SR P2MP ポリシーにも割り当てられます。コントローラーは、BSID を割り当てず、SR P2MP ポリシーのルート ノードに BSID を割り当てることを許可することを決定してもよい(MAY)。SR-MPLS の SRLB から SR P2MP ポリシーの BSID を割り当てることが推奨されます。
The controller MAY be provisioned with a reserved block or multiple reserved blocks for assigning Replication-SIDs and/or the BSIDs for SR P2MP Policies. A single block maybe be reserved for the whole SR domain, or dedicated blocks can be reserved for each node or a group of nodes in the SR domain. These blocks MAY overlap with either the SRGB, the SRLB, or both. The procedures for provisioning these reserved blocks and procedures for deconflicting assignments from these reserved blocks with overlapping SRLB or SRGB blocks are outside the scope of this document.
コントローラーには、SR P2MP ポリシーのレプリケーション SID および/または BSID を割り当てるために、1 つまたは複数の予約ブロックをプロビジョニングしてもよい(MAY)。SR ドメイン全体に対して 1 つのブロックを予約することも、SR ドメイン内の各ノードまたはノードのグループに対して専用のブロックを予約することもできます。これらのブロックは、SRGB、SRLB、またはその両方とオーバーラップしてもよい(MAY)。これらの予約ブロックをプロビジョニングする手順、および重複する SRLB または SRGB ブロックとのこれらの予約ブロックからの割り当ての競合を解消する手順は、このドキュメントの範囲外です。
A controller may not be aware of all the assignments of SIDs from the SRGB or the SRLB of the SR domain. If reserved blocks are not used, the assignment of Replication-SIDs or BSIDs of SR P2MP Policies from these blocks may conflict with other SIDs.
コントローラーは、SR ドメインの SRGB または SRLB からの SID の割り当てをすべて認識しているとは限りません。予約ブロックが使用されていない場合、これらのブロックからの SR P2MP ポリシーのレプリケーション SID または BSID の割り当てが他の SID と競合する可能性があります。
After computing P2MP trees, the controller instantiates the Replication segments that compose the PTIs in the SR domain using signaling protocols such as the Path Computation Element Communication Protocol (PCEP) [SR-P2MP-PCEP], BGP [P2MP-BGP], or other mechanisms such as NETCONF/YANG [SR-P2MP-YANG], etc. The procedures for the instantiation of the Replication segments in an SR domain are outside the scope of this document.
P2MP ツリーを計算した後、コントローラーは、Path Computation Element Communication Protocol (PCEP) [SR-P2MP-PCEP]、BGP [P2MP-BGP]、または NETCONF/YANG [SR-P2MP-YANG] などの他のメカニズムなどのシグナリング プロトコルを使用して、SR ドメイン内の PTI を構成するレプリケーション セグメントをインスタンス化します。 SR 内のレプリケーション セグメントのインスタンス化の手順ドメインはこのドキュメントの範囲外です。
A node SHOULD report a successful instantiation of a Replication segment. The exact procedure for reporting this is outside the scope of this document.
ノードは、レプリケーション セグメントのインスタンス化の成功を報告する必要があります (SHOULD)。これを報告するための正確な手順は、このドキュメントの範囲外です。
The instantiation of a Replication segment on a node may fail, e.g., when the Replication-SID conflicts with another SID on the node. The node SHOULD report this, preferably with a reason for the failure, using a signaling protocol. The exact procedure for reporting this failure is outside the scope of this document.
たとえば、レプリケーション SID がノード上の別の SID と競合する場合、ノード上のレプリケーション セグメントのインスタンス化は失敗することがあります。ノードは、シグナリングプロトコルを使用して、できれば失敗の理由とともにこれを報告すべきである(SHOULD)。この障害を報告するための正確な手順は、このドキュメントの範囲外です。
If the instantiation of a Replication segment on a node fails, the controller SHOULD attempt to re-instantiate the Replication segment. There SHOULD be an upper bound on the number of attempts. If the instantiation of a Replication segment ultimately fails after the allowed number of attempts, the controller SHOULD generate an alert via mechanisms like syslog. These alerts SHOULD be rate-limited to protect the logging facility in case Replication segment instantiation fails on multiple nodes. The controller MAY decide to tear down the PTI if the instantiations of some of the Replication segments of the instance fail. The controller is RECOMMENDED to tear down the PTI if the instantiation of the Replication segment on the Root node fails. The controller can employ different strategies to retry instantiating a PTI after a failure. These are out of scope of this document.
ノード上でレプリケーション セグメントのインスタンス化が失敗した場合、コントローラはレプリケーション セグメントの再インスタンス化を試みるべきです(SHOULD)。試行回数には上限があるべきです。レプリケーション セグメントのインスタンス化が、許可された試行回数を超えて最終的に失敗した場合、コントローラは syslog などのメカニズムを介してアラートを生成する必要があります (SHOULD)。複数のノードでレプリケーションセグメントのインスタンス化が失敗した場合に備えてロギング機能を保護するために、これらのアラートはレート制限されるべきです(SHOULD)。コントローラーは、インスタンスのレプリケーション セグメントの一部のインスタンス化が失敗した場合、PTI を破棄することを決定してもよい(MAY)。ルート ノード上のレプリケーション セグメントのインスタンス化が失敗した場合、コントローラーは PTI を破棄することが推奨されます。コントローラーは、失敗後に PTI のインスタンス化を再試行するためにさまざまな戦略を採用できます。これらはこのドキュメントの範囲外です。
A PTI should be instantiated within a reasonable time, especially if it is the active PTI of an SR P2MP Policy. One approach is the controller instantiates the Replication segments in a batch. For example, the controller instantiates the Replication segments of the Leaf nodes and the intermediate Replication nodes first. If all of these Replication segments are successfully instantiated, the controller then proceeds to instantiate the Replication segment at the Root node. If the Replication segment instantiation at the Root node succeeds, the controller can immediately activate the instance if it needs to carry traffic of the SR P2MP Policy. A controller can adopt a similar approach when instantiating the new PTI for the Make-Before-Break procedure.
PTI は、特に SR P2MP ポリシーのアクティブな PTI である場合、適切な時間内にインスタンス化する必要があります。1 つのアプローチは、コントローラーがバッチでレプリケーション セグメントをインスタンス化することです。たとえば、コントローラーは最初にリーフ ノードと中間レプリケーション ノードのレプリケーション セグメントをインスタンス化します。これらのレプリケーション セグメントがすべて正常にインスタンス化されると、コントローラーはルート ノードでレプリケーション セグメントのインスタンス化を開始します。ルート ノードでのレプリケーション セグメントのインスタンス化が成功すると、コントローラーは SR P2MP ポリシーのトラフィックを伝送する必要がある場合にインスタンスをすぐにアクティブ化できます。コントローラーは、Make-Before-Break プロシージャの新しい PTI をインスタンス化するときに、同様のアプローチを採用できます。
A network link, node, or replication branch on a PTI can be protected using SR Policies [RFC9256]. The backup SR Policies are associated with replication branches of a Replication segment and are programmed in the data plane in order to minimize traffic loss when the protected link/node fails. The segment list of the backup SR Policy is imposed on the downstream Replication-SID of a replication branch to steer the traffic on the backup path.
PTI 上のネットワーク リンク、ノード、またはレプリケーション ブランチは、SR ポリシー [RFC9256] を使用して保護できます。バックアップ SR ポリシーは、レプリケーション セグメントのレプリケーション ブランチに関連付けられており、保護されたリンク/ノードに障害が発生した場合のトラフィック損失を最小限に抑えるためにデータ プレーンにプログラムされます。バックアップ SR ポリシーのセグメント リストは、バックアップ パス上のトラフィックを誘導するために、レプリケーション ブランチのダウンストリーム レプリケーション SID に適用されます。
It is also possible to use a node local Loop-Free Alternate [RFC5286] or Topology Independent Loop-Free Alternate (TI-LFA) [RFC9855] protection and a Micro-Loop [RFC5715] or SR Micro-Loop [SR-LOOP] prevention mechanism to protect the links/nodes of a PTI.
ノードのローカル ループフリー代替 [RFC5286] またはトポロジ独立ループフリー代替 (TI-LFA) [RFC9855] 保護と、マイクロループ [RFC5715] または SR マイクロループ [SR-LOOP] 防止メカニズムを使用して、PTI のリンク/ノードを保護することもできます。
A controller can create a disjoint backup tree instance for providing end-to-end tree protection if the topology permits. This can be achieved by having a backup CP with constraints and/or optimization objectives that ensure its PTIs are disjoint from the PTIs of the primary/active CP.
トポロジーが許可する場合、コントローラーは、エンドツーエンドのツリー保護を提供するために、切り離されたバックアップ ツリー インスタンスを作成できます。これは、PTI がプライマリ/アクティブ CP の PTI から切り離されていることを保証する制約や最適化目標を備えたバックアップ CP を用意することで実現できます。
This document has no IANA actions.
この文書には IANA のアクションはありません。
This document describes how a PTI can be created in an SR domain by stitching Replication segments together. Some security considerations for Replication segments outlined in [RFC9524] are also applicable to this document. Following is a brief reminder of those security considerations.
このドキュメントでは、レプリケーション セグメントを結合して SR ドメインに PTI を作成する方法について説明します。[RFC9524] で概説されているレプリケーションセグメントのセキュリティ上の考慮事項の一部は、この文書にも適用されます。以下は、セキュリティに関する考慮事項を簡単に思い出させるものです。
An SR domain needs protection from outside attackers as described in [RFC8402], [RFC8754], and [RFC8986].
SR ドメインは、[RFC8402]、[RFC8754]、[RFC8986] で説明されているように、外部の攻撃者から保護する必要があります。
Failure to protect the SR-MPLS domain by correctly provisioning MPLS support per interface permits attackers from outside the domain to send packets to receivers of the multipoint services that use the SR P2MP Policies provisioned within the domain.
インターフェイスごとに MPLS サポートを正しくプロビジョニングして SR-MPLS ドメインを保護しないと、ドメイン外部からの攻撃者が、ドメイン内でプロビジョニングされた SR P2MP ポリシーを使用するマルチポイント サービスの受信者にパケットを送信することができます。
Failure to protect the SRv6 domain with inbound Infrastructure Access Control Lists (IACLs) on external interfaces, combined with failure to implement the method described in RFC 2827 [BCP38] or apply IACLs on nodes provisioning SIDs, permits attackers from outside the SR domain to send packets to the receivers of multipoint services that use the SR P2MP Policies provisioned within the domain.
外部インターフェイス上の受信インフラストラクチャ アクセス コントロール リスト (IACL) で SRv6 ドメインを保護できなかったり、RFC 2827 [BCP38] で説明されている方法を実装しなかったり、SID をプロビジョニングするノードに IACL を適用しなかったりすると、SR ドメインの外部からの攻撃者が、ドメイン内でプロビジョニングされた SR P2MP ポリシーを使用するマルチポイント サービスの受信者にパケットを送信することが可能になります。
Incorrect provisioning of Replication segments by a controller that computes SR PTI can result in a chain of Replication segments forming a loop. In this case, replicated packets can create a storm until MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero.
SR PTI を計算するコントローラーによるレプリケーション セグメントのプロビジョニングが正しくないと、レプリケーション セグメントのチェーンがループを形成する可能性があります。この場合、MPLS TTL (SR-MPLS の場合) または IPv6 ホップ制限 (SRv6 の場合) がゼロに減少するまで、複製されたパケットによってストームが発生する可能性があります。
The control plane protocols (like PCEP, BGP, etc.) used to instantiate Replication segments of SR PTI can leverage their own security mechanisms such as encryption, authentication filtering, etc.
SR PTI のレプリケーション セグメントのインスタンス化に使用されるコントロール プレーン プロトコル (PCEP、BGP など) は、暗号化、認証フィルタリングなどの独自のセキュリティ メカニズムを利用できます。
For SRv6, [RFC9524] describes an exception for the ICMPv6 Parameter Problem message with Code 2. If an attacker is able to inject a packet into a multipoint service with the source address of a node and with an extension header using an unknown option type marked as mandatory, then a large number of ICMPv6 Parameter Problem messages can cause a denial-of-service attack on the source node.
SRv6 については、[RFC9524] でコード 2 の ICMPv6 パラメータ問題メッセージの例外が説明されています。攻撃者がノードの送信元アドレスと、必須としてマークされた未知のオプション タイプを使用した拡張ヘッダを持つパケットをマルチポイント サービスに注入できる場合、大量の ICMPv6 パラメータ問題メッセージが送信元ノードでサービス拒否攻撃を引き起こす可能性があります。
[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>.
[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>.
[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>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[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>.
[BCP38] Best Current Practice 38,
<https://www.rfc-editor.org/info/bcp38>.
At the time of writing, this BCP comprises the following:
Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[P2MP-BGP] Bidgoli, H., Voyer, D., Stone, A., Parekh, R., Krier, S.,
and S. Agrewal, "Advertising p2mp policies in BGP", Work
in Progress, Internet-Draft, draft-ietf-idr-sr-p2mp-
policy-01, 29 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
p2mp-policy-01>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[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>.
[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>.
[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>.
[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels",
RFC 9573, DOI 10.17487/RFC9573, May 2024,
<https://www.rfc-editor.org/info/rfc9573>.
[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>.
[SR-LOOP] Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B.,
Francois, P., and P. Psenak, "Loop avoidance using Segment
Routing", Work in Progress, Internet-Draft, draft-
bashandy-rtgwg-segment-routing-uloop-18, 19 April 2026,
<https://datatracker.ietf.org/doc/html/draft-bashandy-
rtgwg-segment-routing-uloop-18>.
[SR-P2MP-PCEP]
Bidgoli, H., Voyer, D., Budhiraja, A., Parekh, R., and S.
Sivabalan, "PCEP extensions for SR P2MP Policy", Work in
Progress, Internet-Draft, draft-ietf-pce-sr-p2mp-policy-
14, 23 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-
p2mp-policy-14>.
[SR-P2MP-YANG]
Bidgoli, H., Voyer, D., Parekh, R., Saad, T., and T.
Kundu, "YANG Data Model for p2mp sr policy", Work in
Progress, Internet-Draft, draft-hb-spring-sr-p2mp-policy-
yang-02, 30 October 2020,
<https://datatracker.ietf.org/doc/html/draft-hb-spring-sr-
p2mp-policy-yang-02>.
[SR-POLICY]
Filsfils, C., Talaulikar, K., Król, P. G., Horneffer, M.,
and P. Mattes, "SR Policy Implementation and Deployment
Considerations", Work in Progress, Internet-Draft, draft-
filsfils-spring-sr-policy-considerations-09, 24 April
2022, <https://datatracker.ietf.org/doc/html/draft-
filsfils-spring-sr-policy-considerations-09>.
Consider the following topology:
次のトポロジを考えてみましょう。
R3------R6
Controller--/ \
R1----R2----R5-----R7
\ /
+--R4---+
Figure 1: SR Topology
図 1: SR トポロジ
In these examples, the Node-SID of a node Rn is N-SIDn and the Adjacency-SID from node Rm to node Rn is A-SIDmn. The interface between Rm and Rn is Lmn.
これらの例では、ノード Rn のノード SID は N-SIDn であり、ノード Rm からノード Rn への隣接関係 SID は A-SIDmn です。Rm と Rn の間の境界は Lmn です。
For SRv6, the reader is expected to be familiar with SRv6 Network Programming [RFC8986] to follow the examples.
SRv6 の場合、読者は例に従うために SRv6 ネットワーク プログラミング [RFC8986] に精通していることが期待されます。
* 2001:db8::/32 is an IPv6 block allocated by a Regional Internet Registry (RIR) to the operator.
* 2001:db8::/32 は、地域インターネット レジストリ (RIR) によってオペレーターに割り当てられた IPv6 ブロックです。
* 2001:db8:0::/48 is dedicated to the internal address space.
* 2001:db8:0::/48 は内部アドレス空間専用です。
* 2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space.
* 2001:db8:cccc::/48 は内部 SRv6 SID スペース専用です。
* We assume a location is expressed in 64 bits and a function is expressed in 16 bits.
* 位置は 64 ビットで表現され、関数は 16 ビットで表現されると仮定します。
* Node k has a classic IPv6 loopback address 2001:db8::k/128, which is advertised in the IGP.
* ノード k には、IGP でアドバタイズされる、クラシック IPv6 ループバック アドレス 2001:db8::k/128 があります。
* Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs will be explicitly assigned from that block.
* ノード k には、ローカル SID スペースとして 2001:db8:cccc:k::/64 があります。その SID はそのブロックから明示的に割り当てられます。
* Node k advertises 2001:db8:cccc:k::/64 in its IGP.
* ノード k は、IGP で 2001:db8:cccc:k::/64 をアドバタイズします。
* Function :1:: (function 1, for short) represents the End function with Penultimate Segment Pop (PSP) support.
* 関数 :1:: (関数 1、略して) は、最後から 2 番目のセグメント ポップ (PSP) をサポートする End 関数を表します。
* Function :Cn:: (function Cn, for short) represents the End.X function to node n.
* Function :Cn:: (function Cn、略して) は、ノード n に対する End.X 関数を表します。
* Function :C1n: (function C1n for short) represents the End.X function to node n with Ultimate Segment Decapsulation (USD).
* 関数 :C1n: (関数 C1n の略称) は、Ultimate Segment Decapsulation (USD) を使用したノード n への End.X 関数を表します。
Each node k has:
各ノード k には次のものがあります。
* An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an End function with additional support for PSP
* PSP の追加サポートを備えた End 関数にバインドされた明示的な SID インスタンス化 2001:db8:cccc:k:1::/128
* An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an End.X function to neighbor J with additional support for PSP
* PSP の追加サポートを備えた、J に隣接する End.X 関数にバインドされた明示的な SID インスタンス化 2001:db8:cccc:k:Cj::/128
* An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to an End.X function to neighbor J with additional support for USD
* USD の追加サポートを備えた J に隣接する End.X 関数にバインドされた明示的な SID インスタンス化 2001:db8:cccc:k:C1j::/128
Assume a controller is provisioned with the following SR P2MP Policy at Root R1 with Tree-ID T-ID:
コントローラが、ツリー ID T-ID を持つルート R1 で次の SR P2MP ポリシーを使用してプロビジョニングされていると仮定します。
SR P2MP Policy <R1,T-ID>:
Leaf nodes: {R2, R6, R7}
candidate-path 1:
Optimize: IGP metric
Tree-SID: T-SID1
The controller is responsible for computing a PTI of the CP. In this example, we assume one active PTI with Instance-ID I-ID1. Assume the controller instantiates PTIs by signaling Replication segments, i.e., the Replication-ID of these Replication segments is <Root, Tree-ID, Instance-ID>. All Replication segments use the Tree-SID T-SID1 as the Replication-SID. For SRv6, assume the Replication-SID at node k, bound to an End.Replicate function, is 2001:db8:cccc:k:fa::/128.
コントローラーは CP の PTI を計算する責任があります。この例では、インスタンス ID I-ID1 を持つ 1 つのアクティブな PTI を想定しています。コントローラーがレプリケーション セグメントに信号を送ることによって PTI をインスタンス化すると仮定します。つまり、これらのレプリケーション セグメントのレプリケーション ID は <ルート、ツリー ID、インスタンス ID> です。すべてのレプリケーション セグメントは、ツリー SID T-SID1 をレプリケーション SID として使用します。SRv6 の場合、End.Replicate 関数にバインドされたノード k のレプリケーション SID が 2001:db8:cccc:k:fa::/128 であると仮定します。
Assume the controller computes a PTI with Root node R1, Intermediate and Leaf node R2, and Leaf nodes R6 and R7. The controller instantiates the instance by stitching Replication segments at R1, R2, R6, and R7. The Replication segment at R1 replicates to R2. The Replication segment at R2 replicates to R6 and R7. Note that nodes R3, R4, and R5 do not have any Replication segment state for the tree.
コントローラーがルート ノード R1、中間ノードとリーフ ノード R2、リーフ ノード R6 と R7 を使用して PTI を計算すると仮定します。コントローラーは、R1、R2、R6、および R7 でレプリケーション セグメントをステッチすることによってインスタンスをインスタンス化します。R1 のレプリケーション セグメントは R2 にレプリケートされます。R2 のレプリケーション セグメントは R6 と R7 にレプリケートされます。ノード R3、R4、および R5 にはツリーのレプリケーション セグメント状態がないことに注意してください。
The Replication segment state at nodes R1, R2, R6, and R7 is shown below.
ノード R1、R2、R6、および R7 でのレプリケーション セグメントの状態を以下に示します。
Replication segment at R1:
R1 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: T-SID1
Replication State:
R2: <T-SID1->L12>
Replication to R2 steers a packet directly to the node on interface L12.
R2 へのレプリケーションは、パケットをインターフェイス L12 上のノードに直接送信します。
Replication segment at R2:
R2 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: T-SID1
Replication State:
R2: <Leaf>
R6: <N-SID6, T-SID1>
R7: <N-SID7, T-SID1>
R2 is a Bud node. It performs the role of a Leaf as well as a transit node replicating to R6 and R7. Replication to R6, using N-SID6, steers a packet via IGP shortest path to that node. Replication to R7, using N-SID7, steers a packet via IGP shortest path to R7 via either R5 or R4 based on ECMP hashing.
R2 はバド ノードです。これは、リーフの役割と、R6 および R7 に複製する中継ノードの役割を実行します。N-SID6 を使用した R6 へのレプリケーションは、IGP 最短パス経由でパケットをそのノードに誘導します。N-SID7 を使用した R7 へのレプリケーションは、ECMP ハッシュに基づいて、IGP 最短パスを介して R5 または R4 を介してパケットを R7 に誘導します。
Replication segment at R6:
R6 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: T-SID1
Replication State:
R6: <Leaf>
Replication segment at R7:
R7 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: T-SID1
Replication State:
R7: <Leaf>
When a packet is steered into the active instance CP 1 of the SR P2MP Policy at R1:
パケットが R1 の SR P2MP ポリシーのアクティブ インスタンス CP 1 に誘導されると、次のようになります。
* Since R1 is directly connected to R2, R1 performs the PUSH operation with just the <T-SID1> label for the replicated copy and sends it to R2 on interface L12.
* R1 は R2 に直接接続されているため、R1 は複製されたコピーの <T-SID1> ラベルのみを使用して PUSH 操作を実行し、それをインターフェイス L12 で R2 に送信します。
* R2, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload. For replication to R6, R2 performs a PUSH operation of N-SID6 to send the <N-SID6,T-SID1> label stack to R3. R3 is the penultimate hop for N-SID6; it performs PHP, which corresponds to the NEXT operation, and the packet is then sent to R6 with <T-SID1> in the label stack. For replication to R7, R2 performs a PUSH operation of N-SID7 to send the <N-SID7,T-SID1> label stack to R4, which is one of the IGP ECMP next hops (R5 is other) towards R7. R4 is the penultimate hop for N-SID7; it performs PHP, which corresponds to the NEXT operation, and the packet is then sent to R7 with <T-SID1> in the label stack.
* R2 はリーフとして、NEXT 操作を実行し、T-SID1 ラベルをポップし、ペイロードを配信します。R6 へのレプリケーションの場合、R2 は N-SID6 の PUSH 操作を実行して、<N-SID6,T-SID1> ラベル スタックを R3 に送信します。R3 は、N-SID6 の最後から 2 番目のホップです。NEXT 操作に対応する PHP を実行し、パケットはラベル スタック内の <T-SID1> とともに R6 に送信されます。R7 へのレプリケーションの場合、R2 は N-SID7 の PUSH 操作を実行して、<N-SID7,T-SID1> ラベル スタックを R7 への IGP ECMP ネクスト ホップ (R5 はその他) の 1 つである R4 に送信します。R4 は、N-SID7 の最後から 2 番目のホップです。NEXT 操作に対応する PHP を実行し、パケットはラベル スタック内の <T-SID1> とともに R7 に送信されます。
* R6, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload.
* R6 はリーフとして、NEXT 操作を実行し、T-SID1 ラベルをポップし、ペイロードを配信します。
* R7, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload.
* R7 はリーフとして、NEXT 操作を実行し、T-SID1 ラベルをポップし、ペイロードを配信します。
For SRv6, the replicated packet from R2 to R7 has to traverse R4 using an SR Policy, Policy27. The policy has one SID in the segment list: End.X function with USD of R4 to R7. The Replication segment state at nodes R1, R2, R6, and R7 is shown below.
SRv6 の場合、R2 から R7 に複製されたパケットは、SR ポリシー、Policy27 を使用して R4 を通過する必要があります。ポリシーには、セグメント リストに 1 つの SID があります: R4 ～ R7 の USD を持つ End.X 関数。ノード R1、R2、R6、および R7 でのレプリケーション セグメントの状態を以下に示します。
Policy27: <2001:db8:cccc:4:c17::>
Replication segment at R1:
R1 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: 2001:db8:cccc:1:fa::
Replication State:
R2: <2001:db8:cccc:2:fa::->L12>
Replication to R2 steers a packet directly to the node on interface L12.
R2 へのレプリケーションは、パケットをインターフェイス L12 上のノードに直接送信します。
Replication segment at R2:
R2 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: 2001:db8:cccc:2:fa::
Replication State:
R2: <Leaf>
R6: <2001:db8:cccc:6:fa::>
R7: <2001:db8:cccc:7:fa:: -> Policy27>
R2 is a Bud node. It performs the role of a Leaf as well as a transit node replicating to R6 and R7. Replication to R6 steers a packet via IGP shortest path to that node. Replication to R7, via an SR Policy, first encapsulates the packet using H.Encaps and then steers the outer packet to R4. End.X USD on R4 decapsulates the outer header and sends the original inner packet to R7.
R2 はバド ノードです。これは、リーフの役割と、R6 および R7 に複製する中継ノードの役割を実行します。R6 へのレプリケーションは、IGP 最短パスを介してパケットをそのノードに誘導します。SR ポリシーを介した R7 へのレプリケーションは、まず H.Encaps を使用してパケットをカプセル化し、次に外側のパケットを R4 に誘導します。R4 上の End.X USD は外側のヘッダーをカプセル化解除し、元の内側のパケットを R7 に送信します。
Replication segment at R6:
R6 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: 2001:db8:cccc:6:fa::
Replication State:
R6: <Leaf>
Replication segment at R7:
R7 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: 2001:db8:cccc:7:fa::
Replication State:
R7: <Leaf>
When a packet (A,B2) is steered into the active instance of CP 1 of the SR P2MP Policy at R1 using H.Encaps.Replicate behavior:
H.Encaps.Replicate 動作を使用して、パケット (A、B2) が R1 の SR P2MP ポリシーの CP 1 のアクティブ インスタンスに誘導されると、次のようになります。
* Since R1 is directly connected to R2, R1 sends the replicated copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on interface L12.
* R1 は R2 に直接接続されているため、R1 は複製されたコピー (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) をインターフェイス L12 で R2 に送信します。
* R2, as a Leaf, removes the outer IPv6 header and delivers the payload. R2, as a Bud node, also replicates the packet.
* R2 はリーフとして、外側の IPv6 ヘッダーを削除し、ペイロードを配信します。R2 もバッド ノードとしてパケットを複製します。
- For replication to R6, R2 sends (2001:db8::1, 2001:db8:cccc:6:fa::) (A,B2) to R3. R3 forwards the packet using the 2001:db8:cccc:6::/64 packet to R6.
- R6 へのレプリケーションの場合、R2 は (2001:db8::1, 2001:db8:cccc:6:fa::) (A,B2) を R3 に送信します。R3 は、2001:db8:cccc:6::/64 パケットを使用してパケットを R6 に転送します。
- For replication to R7 using Policy27, R2 encapsulates and sends (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R4. R4 performs End.X USD behavior, decapsulates the outer IPv6 header, and sends (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7.
- Policy27 を使用した R7 へのレプリケーションの場合、R2 は (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) をカプセル化して R4 に送信します。R4 は End.X USD 動作を実行し、外側の IPv6 ヘッダーをカプセル化解除して、(2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) を R7 に送信します。
* R6, as a Leaf, removes the outer IPv6 header and delivers the payload.
* R6 はリーフとして、外側の IPv6 ヘッダーを削除し、ペイロードを配信します。
* R7, as a Leaf, removes the outer IPv6 header and delivers the payload.
* R7 はリーフとして、外側の IPv6 ヘッダーを削除し、ペイロードを配信します。
Assume the controller computes a PTI with Root node R1, Intermediate and Leaf node R2, Intermediate nodes R3 and R5, and Leaf nodes R6 and R7. The controller instantiates the PTI by stitching Replication segments at R1, R2, R3, R5, R6, and R7. The Replication segment at R1 replicates to R2. The Replication segment at R2 replicates to R3 and R5. The Replication segment at R3 replicates to R6. The Replication segment at R5 replicates to R7. Note that node R4 does not have any Replication segment state for the tree.
コントローラーがルート ノード R1、中間ノードとリーフ ノード R2、中間ノード R3 と R5、およびリーフ ノード R6 と R7 を使用して PTI を計算すると仮定します。コントローラーは、R1、R2、R3、R5、R6、および R7 でレプリケーション セグメントをステッチすることによって PTI をインスタンス化します。R1 のレプリケーション セグメントは R2 にレプリケートされます。R2 のレプリケーション セグメントは R3 と R5 にレプリケートされます。R3 のレプリケーション セグメントは R6 にレプリケートされます。R5 のレプリケーション セグメントは R7 にレプリケートされます。ノード R4 にはツリーのレプリケーション セグメント状態がないことに注意してください。
The Replication segment state at nodes R1, R2, R3, R5, R6, and R7 is shown below.
ノード R1、R2、R3、R5、R6、および R7 でのレプリケーション セグメントの状態を以下に示します。
Replication segment at R1:
R1 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: T-SID1
Replication State:
R2: <T-SID1->L12>
Replication to R2 steers a packet directly to the node on interface L12.
R2 へのレプリケーションは、パケットをインターフェイス L12 上のノードに直接送信します。
Replication segment at R2:
R2 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: T-SID1
Replication State:
R2: <Leaf>
R3: <T-SID1->L23>
R5: <T-SID1->L25>
R2 is a Bud node. It performs the role of a Leaf as well as a transit node replicating to R3 and R5. Replication to R3 steers a packet directly to the node on L23. Replication to R5 steers a packet directly to the node on L25.
R2 はバド ノードです。これは、リーフの役割だけでなく、R3 および R5 に複製する中継ノードの役割も実行します。R3 へのレプリケーションは、パケットを L23 上のノードに直接誘導します。R5 へのレプリケーションは、パケットを L25 上のノードに直接誘導します。
Replication segment at R3:
R3 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R3>:
Replication-SID: T-SID1
Replication State:
R6: <T-SID1->L36>
Replication to R6 steers a packet directly to the node on L36.
R6 へのレプリケーションは、パケットを L36 上のノードに直接誘導します。
Replication segment at R5:
R5 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R5>:
Replication-SID: T-SID1
Replication State:
R7: <T-SID1->L57>
Replication to R7 steers a packet directly to the node on L57.
R7 へのレプリケーションは、パケットを L57 上のノードに直接誘導します。
Replication segment at R6:
R6 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: T-SID1
Replication State:
R6: <Leaf>
Replication segment at R7:
R7 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: T-SID1
Replication State:
R7: <Leaf>
When a packet is steered into the SR P2MP Policy at R1:
パケットが R1 の SR P2MP ポリシーに誘導されると、次のようになります。
* Since R1 is directly connected to R2, R1 performs the PUSH operation with just the <T-SID1> label for the replicated copy and sends it to R2 on interface L12.
* R1 は R2 に直接接続されているため、R1 は複製されたコピーの <T-SID1> ラベルのみを使用して PUSH 操作を実行し、それをインターフェイス L12 で R2 に送信します。
* R2, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload. It also performs the PUSH operation on T-SID1 for replication to R3 and R5. For replication to R6, R2 sends the <T-SID1> label stack to R3 on interface L23. For replication to R5, R2 sends the <T-SID1> label stack to R5 on interface L25.
* R2 はリーフとして、NEXT 操作を実行し、T-SID1 ラベルをポップし、ペイロードを配信します。また、R3 および R5 へのレプリケーションのために T-SID1 で PUSH 操作を実行します。R6 へのレプリケーションの場合、R2 はインターフェイス L23 で <T-SID1> ラベル スタックを R3 に送信します。R5 へのレプリケーションの場合、R2 はインターフェイス L25 で <T-SID1> ラベル スタックを R5 に送信します。
* R3 performs the NEXT operation on T-SID1, performs a PUSH operation for replication to R6, and sends the <T-SID1> label stack to R6 on interface L36.
* R3 は、T-SID1 で NEXT 操作を実行し、R6 へのレプリケーションの PUSH 操作を実行して、インターフェイス L36 で <T-SID1> ラベル スタックを R6 に送信します。
* R5 performs the NEXT operation on T-SID1, performs a PUSH operation for replication to R7, and sends the <T-SID1> label stack to R7 on interface L57.
* R5 は、T-SID1 で NEXT 操作を実行し、R7 へのレプリケーションの PUSH 操作を実行して、<T-SID1> ラベル スタックをインターフェイス L57 で R7 に送信します。
* R6, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload.
* R6 はリーフとして、NEXT 操作を実行し、T-SID1 ラベルをポップし、ペイロードを配信します。
* R7, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload.
* R7 はリーフとして、NEXT 操作を実行し、T-SID1 ラベルをポップし、ペイロードを配信します。
The Replication segment state at nodes R1, R2, R3, R5, R6, and R7 is shown below.
ノード R1、R2、R3、R5、R6、および R7 でのレプリケーション セグメントの状態を以下に示します。
Replication segment at R1:
R1 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: 2001:db8:cccc:1:fa::
Replication State:
R2: <2001:db8:cccc:2:fa::->L12>
Replication to R2 steers a packet directly to the node on interface L12.
R2 へのレプリケーションは、パケットをインターフェイス L12 上のノードに直接送信します。
Replication segment at R2:
R2 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: 2001:db8:cccc:2:fa::
Replication State:
R2: <Leaf>
R3: <2001:db8:cccc:3:fa::->L23>
R5: <2001:db8:cccc:5:fa::->L25>
R2 is a Bud node. It performs the role of a Leaf as well as a transit node replicating to R3 and R5. Replication to R3 steers a packet directly to the node on L23. Replication to R5 steers a packet directly to the node on L25.
R2 はバド ノードです。これは、リーフの役割だけでなく、R3 および R5 に複製する中継ノードの役割も実行します。R3 へのレプリケーションは、パケットを L23 上のノードに直接誘導します。R5 へのレプリケーションは、パケットを L25 上のノードに直接誘導します。
Replication segment at R3:
R3 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R3>:
Replication-SID: 2001:db8:cccc:3:fa::
Replication State:
R6: <2001:db8:cccc:6:fa::->L36>
Replication to R6 steers a packet directly to the node on L36.
R6 へのレプリケーションは、パケットを L36 上のノードに直接誘導します。
Replication segment at R5:
R5 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R5>:
Replication-SID: 2001:db8:cccc:5:fa::
Replication State:
R7: <2001:db8:cccc:7:fa::->L57>
Replication to R7 steers a packet directly to the node on L57.
R7 へのレプリケーションは、パケットを L57 上のノードに直接誘導します。
Replication segment at R6:
R6 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: 2001:db8:cccc:6:fa::
Replication State:
R6: <Leaf>
Replication segment at R7:
R7 のレプリケーション セグメント:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: 2001:db8:cccc:7:fa::
Replication State:
R7: <Leaf>
When a packet (A,B2) is steered into the active instance of CP 1 of the SR P2MP Policy at R1 using the H.Encaps.Replicate behavior:
H.Encaps.Replicate 動作を使用して、パケット (A、B2) が R1 の SR P2MP ポリシーの CP 1 のアクティブ インスタンスに誘導されると、次のようになります。
* Since R1 is directly connected to R2, R1 sends the replicated copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on interface L12.
* R1 は R2 に直接接続されているため、R1 は複製されたコピー (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) をインターフェイス L12 で R2 に送信します。
* R2, as a Leaf, removes the outer IPv6 header and delivers the payload. R2, as a Bud node, also replicates the packet. For replication to R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:fa::) (A,B2) to R3 on interface L23. For replication to R5, R2 sends (2001:db8::1, 2001:db8:cccc:5:fa::) (A,B2) to R5 on interface L25.
* R2 はリーフとして、外側の IPv6 ヘッダーを削除し、ペイロードを配信します。R2 もバッド ノードとしてパケットを複製します。R3 へのレプリケーションの場合、R2 はインターフェイス L23 で (2001:db8::1, 2001:db8:cccc:3:fa::) (A,B2) を R3 に送信します。R5 へのレプリケーションの場合、R2 はインターフェイス L25 で (2001:db8::1, 2001:db8:cccc:5:fa::) (A,B2) を R5 に送信します。
* R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:fa::) (A,B2) to R6 on interface L36.
* R3 は複製し、(2001:db8::1, 2001:db8:cccc:6:fa::) (A,B2) をインターフェイス L36 上の R6 に送信します。
* R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7 on interface L57.
* R5 は複製し、(2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) をインターフェイス L57 上の R7 に送信します。
* R6, as a Leaf, removes the outer IPv6 header and delivers the payload.
* R6 はリーフとして、外側の IPv6 ヘッダーを削除し、ペイロードを配信します。
* R7, as a Leaf, removes the outer IPv6 header and delivers the payload.
* R7 はリーフとして、外側の IPv6 ヘッダーを削除し、ペイロードを配信します。
The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, and Vishnu Pavan Beeram for their valuable input.
著者らは、貴重なご意見をいただいた Siva Sivabalan、Mike Koldychev、Vishnu Pavan Beeram に感謝の意を表します。
Clayton Hassen
Bell Canada
Vancouver
Canada
Email: clayton.hassen@bell.ca
Kurtis Gillis
Bell Canada
Halifax
Canada
Email: kurtis.gillis@bell.ca
Arvind Venkateswaran
Cisco Systems, Inc.
San Jose,
United States of America
Email: arvvenka@cisco.com
Zafar Ali
Cisco Systems, Inc.
United States of America
Email: zali@cisco.com
Swadesh Agrawal
Cisco Systems, Inc.
San Jose,
United States of America
Email: swaagraw@cisco.com
Jayant Kotalwar
Nokia
Mountain View,
United States of America
Email: jayant.kotalwar@nokia.com
Tanmoy Kundu
Nokia
Mountain View,
United States of America
Email: tanmoy.kundu@nokia.com
Andrew Stone
Nokia
Ottawa
Canada
Email: andrew.stone@nokia.com
Tarek Saad
Juniper Networks
Canada
Email: tsaad@juniper.net
Kamran Raza
Cisco Systems, Inc.
Canada
Email: skraza@cisco.com
Anuj Budhiraja
Cisco Systems, Inc.
United States of America
Email: abudhira@cisco.com
Mankamana Mishra
Cisco Systems, Inc.
United States of America
Email: mankamis@cisco.com
Rishabh Parekh (editor)
Arrcus
San Jose,
United States of America
Email: rishabh@arrcus.com
Daniel Voyer (editor)
Cisco Systems, Inc.
Montreal
Canada
Email: davoyer@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Hooman Bidgoli
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net