[要約] このRFCは、2本の単方向セグメントルーティング（SR）LSPを1つの関連双方向SR LSPとしてグループ化するための、パス計算要素通信プロトコル（PCEP）の拡張を規定します。新しい関連付けタイプ Bidirectional SR LSP Association を導入し、逆方向パスのEROをイングレスノード（PCC）に伝えることで、指向性BFDやパフォーマンス測定などの機能を可能にします。RFC 9059 のRSVP-TE向け関連双方向LSPの仕組みをSR-MPLSとSRv6に拡張するもので、ステートフルとステートレスの両方のPCE、およびPCE起動とPCC起動のLSPに適用できます。
Internet Engineering Task Force (IETF) C. Li, Ed.
Request for Comments: 10067 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 W. Cheng
China Mobile
R. Gandhi, Ed.
Cisco Systems, Inc.
Q. Xiong
ZTE Corporation
October 2026
Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing. Stateful Path Computation Element Communication Protocol (PCEP) extensions are defined for SR Traffic Engineering (TE) LSPs.
セグメントルーティング（SR）は、ソースルーティングにより、IPv6またはMPLSのデータプレーンを用いてネットワーク内でパケットを誘導します。ステートフルなパス計算要素通信プロトコル（PCEP）拡張は、SR Traffic Engineering（TE）LSP向けに定義されています。
PCEP supports grouping two RSVP-TE signaled, unidirectional MPLS-TE Label-Switched Paths (LSPs) where a path in each direction in a network is grouped into an associated bidirectional LSP. This document extends PCEP support to group two unidirectional SR LSPs into an associated bidirectional SR LSP. The mechanisms defined in this document apply to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs.
PCEPは、RSVP-TEでシグナリングされる2つの単方向MPLS-TEラベルスイッチパス（LSP）をグループ化することをサポートしており、ネットワーク内の各方向のパスが1つの関連双方向LSPにグループ化されます。本書は、2つの単方向SR LSPを1つの関連双方向SR LSPにグループ化するところまでPCEPのサポートを拡張します。本書で定義するメカニズムは、PCE起動LSPとPCC起動LSPの両方について、ステートレスPCEとステートフルPCEの双方に適用されます。
This is an Internet Standards Track document.
これはInternet Standards Trackの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本書は、Internet Engineering Task Force（IETF）の成果物です。IETFコミュニティのコンセンサスを表しています。本書は公開レビューを受け、Internet Engineering Steering Group（IESG）により発行が承認されました。Internet Standardsの詳細については、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/rfc10067.
本書の現在の状況、正誤表、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc10067 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trustおよび文書の著者として特定された人々。All rights reserved.
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 Trustの IETF文書に関する法的規定（https://trustee.ietf.org/license-info）の適用を受けます。これらの文書は本書に関するあなたの権利と制限を記述しているため、注意深く確認してください。本書から抽出されるコードコンポーネントには、Trust Legal Provisionsの第4.e節に記載のとおり、改訂BSDライセンスの文面を含めなければならず、改訂BSDライセンスに記載のとおり無保証で提供されます。
1. Introduction 2. Terminology 2.1. Requirements Language 3. Overview 3.1. PCE-Initiated Associated Bidirectional SR LSPs 3.2. PCC-Initiated Associated Bidirectional SR LSPs 4. PCEP Extensions 4.1. Bidirectional SR LSP Association Group 4.2. Bidirectional LSP Association Group TLV 4.3. PATH-ATTRIB Object 4.4. MULTIPATH-OPPDIR-PATH TLV 5. Additional PCEP Considerations 5.1. PLSP-ID Usage 5.2. Error Handling 6. Security Considerations 7. Operational Considerations 7.1. Control of Function and Policy 7.2. Information and Data Models 7.3. Liveness Detection and Monitoring 7.4. Verify Correct Operations 7.5. Requirements on Other Protocols 7.6. Impact on Network Operations 8. IANA Considerations 8.1. Association Type 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Contributors Authors' Addresses
1. Introduction
1. はじめに
2. Terminology
2. 用語
2.1. Requirements Language
2.1. 要件の表記
3. Overview
3. 概要
3.1. PCE-Initiated Associated Bidirectional SR LSPs
3.1. PCE起動の関連双方向SR LSP
3.2. PCC-Initiated Associated Bidirectional SR LSPs
3.2. PCC起動の関連双方向SR LSP
4. PCEP Extensions
4. PCEPの拡張
4.1. Bidirectional SR LSP Association Group
4.1. 双方向SR LSP関連付けグループ
4.2. Bidirectional LSP Association Group TLV
4.2. 双方向LSP関連付けグループTLV
4.3. PATH-ATTRIB Object
4.3. PATH-ATTRIBオブジェクト
4.4. MULTIPATH-OPPDIR-PATH TLV
4.4. MULTIPATH-OPPDIR-PATH TLV
5. Additional PCEP Considerations
5. PCEPに関する追加の考慮事項
5.1. PLSP-ID Usage
5.1. PLSP-IDの使用
5.2. Error Handling
5.2. エラー処理
6. Security Considerations
6. セキュリティに関する考慮事項
7. Operational Considerations
7. 運用上の考慮事項
7.1. Control of Function and Policy
7.1. 機能とポリシーの制御
7.2. Information and Data Models
7.2. 情報モデルとデータモデル
7.3. Liveness Detection and Monitoring
7.3. 生存検出と監視
7.4. Verify Correct Operations
7.4. 正しい動作の検証
7.5. Requirements on Other Protocols
7.5. 他のプロトコルに対する要件
7.6. Impact on Network Operations
7.6. ネットワーク運用への影響
8. IANA Considerations
8. IANAに関する考慮事項
8.1. Association Type
8.1. 関連付けタイプ
9. References
9. 参考文献
9.1. Normative References
9.1. 引用規定
9.2. Informative References
9.2. 参考情報
Acknowledgments
謝辞
Contributors
貢献者
Authors' Addresses
著者の連絡先
Segment Routing (SR) [RFC8402] can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes.
セグメントルーティング（SR）[RFC8402]は、ソースルーティングを用いてネットワーク内でパケットを誘導するために使用できます。SRは、MPLS（SR-MPLS）とIPv6（SRv6）の両方のデータプレーンに適用できます。
[RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). [RFC8231] specifies a set of extensions to PCEP to enable stateful control of Traffic Engineering (TE) Label Switched Paths (LSPs) within and across PCEP sessions. As described in [RFC4655], a PCE can be either stateful or stateless. [RFC8664] specifies extensions to the PCEP for SR networks that allow a stateful PCE to compute and initiate SR TE paths, as well as a Path Computation Client (PCC) to request, report, or delegate them.
[RFC5440]は、パス計算要素（PCE）通信プロトコル（PCEP）を記述しています。[RFC8231]は、PCEPセッション内およびPCEPセッション間でのTraffic Engineering（TE）ラベルスイッチパス（LSP）のステートフルな制御を可能にする、PCEPの拡張の集合を規定しています。[RFC4655]に記述されているとおり、PCEはステートフルにもステートレスにもなり得ます。[RFC8664]は、ステートフルPCEがSR TEパスを計算および起動できるようにし、またパス計算クライアント（PCC）がそれらを要求、報告、または委任できるようにする、SRネットワーク向けのPCEPの拡張を規定しています。
There are features such as directed Bidirectional Forwarding Detection (BFD) [RFC9612] and Performance Measurement [RFC9503] that require the ingress node (PCC) to be aware of the reverse direction SR path. For such features, the reverse SR paths need to be communicated to the ingress nodes (PCCs) using PCEP mechanisms. This allows both endpoint nodes to be aware of the forward and reverse SR paths.
An SR Policy [RFC9256] contains one or more Candidate Paths (CPs), which may be computed by a PCE. A Candidate Path of an SR Policy can contain one or more Segment Lists (SLs). In PCEP messages, an SL is encoded as an Explicit Route Object (ERO) as described in Section 4.3 of [RFC8664]. [RFC10066] defines PCEP extensions for carrying multiple SLs in the PCEP messages along with their opposite direction SLs, as described in Section 4.4 of [RFC10066].
SRポリシー[RFC9256]は、1つ以上の候補パス（CP）を含み、これらはPCEによって計算される場合があります。SRポリシーの候補パスは、1つ以上のセグメントリスト（SL）を含むことができます。PCEPメッセージでは、[RFC8664]の4.3節に記述されているとおり、SLは明示的経路オブジェクト（ERO）としてエンコードされます。[RFC10066]は、[RFC10066]の4.4節に記述されているとおり、複数のSLを反対方向のSLとともにPCEPメッセージで運ぶためのPCEP拡張を定義しています。
As per [RFC8697], TE LSPs can be associated by adding them to a common association group by a PCEP peer. [RFC9059] uses the association group object to group two unidirectional RSVP-TE LSPs into an associated bidirectional LSP for both stateful and stateless PCE. This document extends this procedure and allows grouping two unidirectional SR LSPs into an associated bidirectional SR LSP for co-routed [RFC9059] and non-co-routed paths. This extension also utilizes the procedure defined in [RFC10066] to carry the multiple EROs and the associated reverse path EROs for an SR LSP. Note that the association group and the procedure introduced in this document are specific to SR-TE and SRv6 Path Setup Types.
[RFC8697]に従い、TE LSPは、PCEPピアが共通の関連付けグループに追加することで関連付けることができます。[RFC9059]は、ステートフルPCEとステートレスPCEの両方について、関連付けグループオブジェクトを用いて2つの単方向RSVP-TE LSPを1つの関連双方向LSPにグループ化しています。本書はこの手順を拡張し、共経路（co-routed）[RFC9059]および非共経路のパスについて、2つの単方向SR LSPを1つの関連双方向SR LSPにグループ化できるようにします。また、この拡張は、SR LSPの複数のEROと、関連する逆方向パスのEROを運ぶために、[RFC10066]で定義された手順も利用します。なお、本書で導入する関連付けグループと手順は、SR-TEおよびSRv6のパスセットアップタイプに固有のものです。
Explicit Route Object (ERO), Path Computation Client (PCC), Path Computation Element (PCE), Path Computation Element Communication Protocol (PCEP), PCEP peer, and PCEP speaker.
明示的経路オブジェクト（ERO）、パス計算クライアント（PCC）、パス計算要素（PCE）、パス計算要素通信プロトコル（PCEP）、PCEPピア、およびPCEPスピーカー。
This document extends the following term defined in [RFC3031]: Label Switched Path (LSP) - the base PCEP specification [RFC4655] originally defined the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. As specified in Section 2 of [RFC9603], the term "LSP" used in the PCEP specifications would be equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP using the SRv6 Path Setup Type.
Associated bidirectional SR LSPs can be created and updated by a Stateful PCE or by a PCC as described in the subsections below for the case when there are no errors encountered and all operations are successful.
関連双方向SR LSPは、エラーが発生せずすべての操作が成功する場合について、以下の各小節で説明するとおり、ステートフルPCEまたはPCCによって作成および更新できます。
High-level steps for creating associated bidirectional SR LSPs by a Stateful PCE are shown in Figures 1 and 2.
ステートフルPCEによる関連双方向SR LSPの作成の概要手順を、図1および図2に示します。
* Step 1 - Stateful PCE Behavior:
* ステップ1 - ステートフルPCEの動作：
Stateful PCE creates and updates the SR LSP and the associated reverse SR LSP EROs, for the "Bidirectional SR LSP Association" with the Association ID 1 on a PCC via PCInitiate and PCUpd messages, respectively.
ステートフルPCEは、関連付けID 1の「Bidirectional SR LSP Association」に対して、SR LSPと、関連する逆方向SR LSPのEROを、それぞれPCInitiateメッセージとPCUpdメッセージによりPCC上に作成および更新します。
+-----+
| PCE |
+-----+
PCInitiate: / \ PCInitiate:
Tunnel 1 (0) / \ Tunnel 2 (0)
LSP1 (F1, R2) / \ LSP2 (F2, R1)
Association ID 1 / \ Association ID 1
(Single LSP) / \ (Single LSP)
v v
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
Figure 1: Step 1: PCE-Initiated Associated Bidirectional SR LSP with Forward-Direction LSPs and Reverse-Direction EROs
図1: ステップ1: 順方向LSPと逆方向EROを持つPCE起動の関連双方向SR LSP
F1 and F2 =
F1 および F2 =
Forward LSP EROs
順方向LSPのERO
R1 and R2 =
R1 および R2 =
Reverse LSP EROs
逆方向LSPのERO
0 =
0 =
PLSP-ID
PLSP-ID
S =
S =
Source
送信元
D =
D =
Destination
宛先
* Step 2 - PCC Behavior:
* ステップ2 - PCCの動作：
The PCC, upon receiving the PCInitiate for the SR LSP and the associated reverse SR LSP EROs, locally assigns a PCEP-specific Identifier for the LSP (PLSP-ID) [RFC8231] and reports it to the PCE via a PCRpt message.
PCCは、SR LSPと関連する逆方向SR LSPのEROを含むPCInitiateを受信すると、LSPのPCEP固有の識別子（PLSP-ID）[RFC8231]をローカルに割り当て、PCRptメッセージでPCEに報告します。
+-----+
| PCE |
+-----+
PCRpt: ^ ^ PCRpt:
Tunnel 1 (100) / \ Tunnel 2 (200)
LSP1 (F1, R2==F2) / \ LSP2 (F2, R1==F1)
Association ID 1 / \ Association ID 1
(Single LSP) / \ (Single LSP)
/ \
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
Figure 2: Step 2: PCC-Reported Bidirectional SR LSP with Forward-Direction LSPs and Reverse-Direction EROs
図2: ステップ2: 順方向LSPと逆方向EROを持つ、PCCが報告した双方向SR LSP
F1 and F2 =
F1 and F2 =
Forward LSP EROs
順方向LSPのERO
R1 and R2 =
R1 and R2 =
Reverse LSP EROs
逆方向LSPのERO
100 and 200 =
100 and 200 =
PLSP-IDs
PLSP-ID
S =
S =
Source
送信元
D =
D =
Destination
宛先
High-level steps for creating associated bidirectional SR LSPs by a PCC are shown in Figures 3 and 4.
PCCによって関連双方向SR LSPを作成する際の概略手順を、図3および図4に示します。
* Step 1 - PCC Behavior:
* ステップ1 - PCCの動作：
PCC creates and updates an SR LSP for the "Bidirectional SR LSP Association" with the Association ID 2 and reports the change in the association group of an SR LSP to PCE(s) via a PCRpt message.
PCCは、関連付けID 2の「Bidirectional SR LSP Association」に対してSR LSPを作成および更新し、SR LSPの関連付けグループの変更をPCRptメッセージでPCEに報告します。
+-----+
| PCE |
+-----+
Report/Delegate: ^ ^ Report/Delegate:
Tunnel 1 (100) / \ Tunnel 2 (200)
LSP1 (F1) / \ LSP2 (F2)
Association ID 2 / \ Association ID 2
/ \
/ \
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
Figure 3: Step 1: PCC-Initiated Associated Bidirectional SR LSP with Forward-Direction LSP
図3: ステップ1: 順方向LSPを持つ、PCC起動の関連双方向SR LSP
F1 and F2 =
F1 and F2 =
Forward LSP EROs
順方向LSPのERO
100 and 200 =
100 and 200 =
PLSP-IDs
PLSP-ID
S =
S =
Source
送信元
D =
D =
Destination
宛先
* Step 2 - Stateful PCE Behavior:
* ステップ2 - ステートフルPCEの動作：
Stateful PCE updates the SR LSP and the associated reverse SR LSP EROs, for the "Bidirectional SR LSP Association" on a PCC via a PCUpd message.
ステートフルPCEは、PCUpdメッセージで、PCC上の「Bidirectional SR LSP Association」に対するSR LSPと、関連する逆方向SR LSPのEROを更新します。
+-----+
| PCE |
+-----+
PCUpd: / \ PCUpd:
Tunnel 1 (100) / \ Tunnel 2 (200)
LSP1 (F1, R2==F2) / \ LSP2 (F2, R1==F1)
Association ID 2 / \ Association ID 2
(Single LSP) / \ (Single LSP)
v v
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
Figure 4: Step 2: PCE-Updated Associated Bidirectional SR LSP with Forward- Direction LSPs and Reverse-Direction EROs
図4: ステップ2: 順方向LSPと逆方向EROを持つ、PCEが更新した関連双方向SR LSP
F1 and F2 =
F1 and F2 =
Forward LSP EROs
順方向LSPのERO
R1 and R2 =
R1 and R2 =
Reverse LSP EROs
逆方向LSPのERO
100 and 200 =
100 and 200 =
PLSP-IDs
PLSP-ID
S =
S =
Source
送信元
D =
D =
Destination
宛先
Two unidirectional SR LSPs (one in each direction between two nodes in a network) can be associated together by using the association group defined in this document for the PCEP messages and employing the procedures defined in [RFC9059] and [RFC10066].
2つの単方向SR LSP（ネットワーク内の2つのノード間の各方向に1つずつ）は、PCEPメッセージ向けに本文書で定義する関連付けグループを使用し、[RFC9059] と [RFC10066] で定義された手順を採用することで、互いに関連付けることができます。
For associating two unidirectional SR LSPs, this document defines a new Association Type called "Bidirectional SR LSP Association" for the Association Group object (Class-Value 40) as follows:
2つの単方向SR LSPを関連付けるため、本文書は、Association Groupオブジェクト（Class-Value 40）に対して、次のとおり "Bidirectional SR LSP Association" という新しいAssociation Typeを定義します。
* Association Type (value 8) = Bidirectional SR LSP Association
* Association Type（値8）= Bidirectional SR LSP Association
The handling of the Association ID, Association Source, optional Global Association Source and optional Extended Association ID in this association are set as defined in [RFC8697].
この関連付けにおけるAssociation ID、Association Source、任意のGlobal Association Source、および任意のExtended Association IDの扱いは、[RFC8697] で定義されたとおりに設定されます。
[RFC8697] specifies the mechanism for the capability advertisement of the Association Types supported by a PCEP speaker by defining an ASSOC-Type-List TLV (value 35) to be carried within an OPEN object. The PCEP speaker MUST include the "Bidirectional SR LSP Association" type in the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer before using it in the PCEP messages.
[RFC8697] は、OPENオブジェクト内で運ばれるASSOC-Type-List TLV（値35）を定義することで、PCEPスピーカーがサポートするAssociation Typeの機能アドバタイズのメカニズムを規定しています。PCEPスピーカーは、ASSOC-Type-List TLVに "Bidirectional SR LSP Association" タイプを含めなければならず (MUST)、PCEPメッセージでそれを使用する前に、PCEPピアから同じものを受信しなければなりません (MUST)。
An SR LSP MUST NOT be part of more than one "Bidirectional SR LSP Association" on a PCE. A PCE, upon detecting this condition, MUST NOT send the associated reverse EROs to the ingress node PCC. This error condition MUST be logged and an alarm MUST be generated.
SR LSPは、PCE上で複数の "Bidirectional SR LSP Association" に属してはなりません (MUST NOT)。この状態を検出したPCEは、関連する逆方向のEROをイングレスノードPCCに送信してはなりません (MUST NOT)。このエラー状態はログに記録されなければならず (MUST)、アラームが生成されなければなりません (MUST)。
A PCEP message for an associated bidirectional SR LSP MAY include the "Bidirectional LSP Association Group TLV" to indicate the co-routed path using the C flag defined in Section 4.2 of [RFC9059].
関連双方向SR LSPのPCEPメッセージは、[RFC9059] のセクション4.2で定義されたCフラグを使用して共経路（co-routed）パスを示すために、"Bidirectional LSP Association Group TLV" を含めてもよい (MAY)。
As there is no reverse SR LSP instantiated, the Reverse LSP (R flag) MUST NOT be set for an associated bidirectional SR LSP and MUST be ignored. This error condition MUST be logged and an alarm MUST be generated.
逆方向のSR LSPがインスタンス化されないため、関連双方向SR LSPではReverse LSP（Rフラグ）を設定してはならず (MUST NOT)、設定されていても無視されなければなりません (MUST)。このエラー状態はログに記録されなければならず (MUST)、アラームが生成されなければなりません (MUST)。
When a PCE informs an ingress node PCC about the associated reverse SR LSP EROs computed for an SR LSP with the "Bidirectional SR LSP Association", it MUST include the "PATH-ATTRIB" object with the Reverse (R flag) set to 1 to indicate that the ERO is for the reverse direction [RFC10066].
PCEが、"Bidirectional SR LSP Association" を持つSR LSPに対して計算した関連する逆方向SR LSPのEROをイングレスノードPCCに通知する場合、そのEROが逆方向のものであることを示すため、Reverse（Rフラグ）を1に設定した "PATH-ATTRIB" オブジェクトを含めなければなりません (MUST) [RFC10066]。
The PCE MAY include the "MULTIPATH-OPPDIR-PATH TLV" to indicate the co-routed path properties (in the N-flag and L-flag) for the reverse ERO [RFC10066] for an SR LSP.
PCEは、SR LSPの逆方向ERO [RFC10066] について、共経路（co-routed）パスの特性（NフラグおよびLフラグ）を示すために、"MULTIPATH-OPPDIR-PATH TLV" を含めてもよい (MAY)。
The PCC MUST detect the mismatch between the co-routed path properties in the "MULTIPATH-OPPDIR-PATH TLV" for the reverse ERO and the co-routed path (C) flag in the "Bidirectional LSP Association Group TLV" for the (forward) SR LSP and log it as an error condition and generate an alarm.
PCCは、逆方向EROの "MULTIPATH-OPPDIR-PATH TLV" 内の共経路（co-routed）パス特性と、（順方向の）SR LSPの "Bidirectional LSP Association Group TLV" 内の共経路（co-routed）パス（C）フラグとの不一致を検出しなければならず (MUST)、それをエラー状態としてログに記録し、アラームを生成しなければなりません。
Additional considerations for associating bidirectional SR LSPs are summarized in the subsections below.
双方向SR LSPを関連付けるための追加の考慮事項を、以下のサブセクションにまとめます。
As per [RFC8231], an ingress node PCC reports a unique PLSP-ID for each LSP of an SR Policy. For an associated bidirectional SR LSP, the PCE will maintain two PLSP-IDs, one from the ingress node PCC and one from the egress node PCC. In the examples shown in Figures 2 and 3, the ingress node PCC (node S) reports Tunnel 1, LSP1 to the PCE with PLSP-ID 100 whereas the egress node PCC (node D) reports Tunnel 2, LSP2 to the PCE with PLSP-ID 200.
[RFC8231] に従い、イングレスノードPCCは、SRポリシーの各LSPに対して一意のPLSP-IDを報告します。関連双方向SR LSPの場合、PCEは2つのPLSP-IDを保持します。1つはイングレスノードPCCからのもの、もう1つはエグレスノードPCCからのものです。図2および図3に示す例では、イングレスノードPCC（ノードS）はTunnel 1、LSP1をPLSP-ID 100でPCEに報告し、エグレスノードPCC（ノードD）はTunnel 2、LSP2をPLSP-ID 200でPCEに報告します。
The error handling as described in Section 5.7 of [RFC9059] continues to apply for the "Bidirectional SR LSP Association".
[RFC9059] のセクション5.7に記述されているエラー処理は、"Bidirectional SR LSP Association" に対しても引き続き適用されます。
The PCEP Path Setup Type (PST) for SR LSP uses either value "1: Traffic-engineering path is set up using Segment Routing" [RFC8664] or "3: Traffic engineering path is set up using SRv6" [RFC9603]. If a PCEP speaker receives a non-SR LSP PST value for the "Bidirectional SR LSP Association", the PCEP speaker MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-value = "16: Path Setup Type not supported" [RFC9059].
SR LSPのPCEPパスセットアップタイプ（PST）は、値 "1: Traffic-engineering path is set up using Segment Routing" [RFC8664] または "3: Traffic engineering path is set up using SRv6" [RFC9603] のいずれかを使用します。PCEPスピーカーが "Bidirectional SR LSP Association" に対してSR LSP以外のPST値を受信した場合、そのPCEPスピーカーは、Error-Type = 26 (Association Error)、Error-value = "16: Path Setup Type not supported" のPCErrメッセージを返さなければなりません (MUST) [RFC9059]。
A new Association Type for the Association object, "Bidirectional SR LSP Association", is introduced in this document. Additional security considerations related to LSP associations due to a malicious PCEP speaker are described in [RFC8697] and apply to this Association Type. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253], [RFC9916], as per the recommendations and best current practices in [RFC9325] is RECOMMENDED.
本文書では、Associationオブジェクトに対する新しいAssociation Typeとして "Bidirectional SR LSP Association" を導入します。悪意のあるPCEPスピーカーに起因するLSP関連付けに関する追加のセキュリティ上の考慮事項は [RFC8697] に記述されており、このAssociation Typeにも適用されます。したがって、[RFC9325] の推奨事項およびベストカレントプラクティスに従って、Transport Layer Security (TLS) [RFC8253] [RFC9916] でPCEPセッションを保護することを推奨します (RECOMMENDED)。
The manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8281], [RFC8697], and [RFC10066] apply to the PCEP protocol extensions defined in this document. In addition, the operational requirements and considerations listed in this section apply.
[RFC5440]、[RFC8231]、[RFC8281]、[RFC8697]、[RFC10066] に列挙されている管理性の要件と考慮事項は、本文書で定義するPCEPプロトコル拡張に適用されます。加えて、本セクションに列挙する運用上の要件と考慮事項も適用されます。
The mechanisms defined in this document do not imply any new control or policy requirements.
本文書で定義するメカニズムは、新たな制御要件やポリシー要件を意味するものではありません。
[RFC7420] describes the PCEP MIB; there are no new MIB Objects defined for LSP associations.
[RFC7420] はPCEP MIBを記述しており、LSPの関連付けに対して新たに定義されるMIBオブジェクトはありません。
The PCEP YANG module [RFC9826] defines a data model for LSP associations. However, it does not include information for associated bidirectional SR LSPs. It can be extended to include data related to the associated bidirectional SR LSPs, such as:
PCEP YANGモジュール [RFC9826] は、LSPの関連付けのデータモデルを定義しています。しかし、関連双方向SR LSPに関する情報は含まれていません。これは、たとえば次のような、関連双方向SR LSPに関するデータを含むように拡張できます。
* Indication of whether the associated bidirectional SR LSPs are supported
* 関連双方向SR LSPがサポートされているかどうかの表示
* Enablement and disablement of the bidirectional SR LSP association
* 双方向SR LSP関連付けの有効化と無効化
* Counters for the successfully associated bidirectional SR LSPs
* 双方向の関連付けに成功したSR LSPのカウンタ
* Counters for the SR LSPs that failed to form a bidirectional association
* 双方向の関連付けの形成に失敗したSR LSPのカウンタ
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements as they are performed independently on both sides of a bidirectional SR LSP, using the forward and reverse LSP paths of the bidirectional SR LSP. However, the monitoring on both sides of a bidirectional SR LSP needs to be correlated at the management level to ensure that the bidirectional service carried by the bidirectional SR LSP is operational.
本文書で定義するメカニズムは、双方向SR LSPの順方向および逆方向のLSPパスを使用して、双方向SR LSPの両側で独立に実行されるため、生存検出と監視に関する新たな要件を意味するものではありません。ただし、双方向SR LSPが運ぶ双方向サービスが稼働していることを確認するために、双方向SR LSPの両側での監視は、管理レベルで相関付ける必要があります。
Mechanisms defined in this document do not imply any new operation verification requirements.
本書で定義するメカニズムは、動作検証に関する新たな要件を伴うものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
本書で定義するメカニズムは、他のプロトコルに対する新たな要件を伴うものではありません。
Associating two SR LSPs to form an associated bidirectional SR LSP requires an operator to ensure that the correct LSP associations are employed on both sides of the bidirectional SR LSP. Tools such as directed BFD [RFC9612] and Performance Measurement [RFC9503] can be used to verify the correct operation of a bidirectional SR LSP.
IANA has registered the following Association Type for the Association Group object (Class-Value 40) in the "ASSOCIATION Type Field" registry [RFC8697] within the "Path Computation Element Protocol (PCEP) Numbers" registry group (see <https://www.iana.org/assignments/pcep>):
IANAは、「Path Computation Element Protocol (PCEP) Numbers」レジストリグループ（<https://www.iana.org/assignments/pcep> を参照）内の「ASSOCIATION Type Field」レジストリ [RFC8697] に、Association Groupオブジェクト（Class-Value 40）用の次の関連付けタイプを登録しました。
+======+==================================+===========+
| Type | Name | Reference |
+======+==================================+===========+
| 8 | Bidirectional SR LSP Association | RFC 10067 |
+------+----------------------------------+-----------+
Table 1
[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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[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>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[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>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, <https://www.rfc-editor.org/info/rfc8697>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 9059, DOI 10.17487/RFC9059, June 2021, <https://www.rfc-editor.org/info/rfc9059>.
[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>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, July 2024, <https://www.rfc-editor.org/info/rfc9603>.
[RFC9916] Dhody, D., Turner, S., and R. Housley, "Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 9916, DOI 10.17487/RFC9916, July 2026, <https://www.rfc-editor.org/info/rfc9916>.
[RFC10066] Koldychev, M., Ed. and S. Sidor, Ed., "Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information", RFC 10066, DOI 10.17487/RFC10066, October 2026, <https://www.rfc-editor.org/info/rfc10066>.
[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>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, October 2023, <https://www.rfc-editor.org/info/rfc9503>.
[RFC9612] Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, "Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs)", RFC 9612, DOI 10.17487/RFC9612, July 2024, <https://www.rfc-editor.org/info/rfc9612>.
[RFC9826] Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura, "A YANG Data Model for the Path Computation Element Communication Protocol (PCEP)", RFC 9826, DOI 10.17487/RFC9826, September 2025, <https://www.rfc-editor.org/info/rfc9826>.
Many thanks to Marina Fizgeer, Adrian Farrel, Andrew Stone, Tarek Saad, Samuel Sidor, and Mike Koldychev for the detailed review of this document and for providing many useful comments. Also, thank you, John Scudder, for the RtgDir Early review, Carlos Pignataro for the OpsDir review, Dhruv Dhody for the Shepherd review, Ketan Talaulikar for the WG AD review, Meral Shirazipour for Genart review, and Mohamed Boucadair, Éric Vyncke, Deb Cooley, Mahesh Jethanandani, Mike Bishop, and Gunter Van de Velde for the IESG review, which helped improve this document.
本書を詳細にレビューし、多くの有益なコメントを寄せてくださった Marina Fizgeer、Adrian Farrel、Andrew Stone、Tarek Saad、Samuel Sidor、Mike Koldychev に感謝します。また、RtgDir早期レビューを行った John Scudder、OpsDirレビューを行った Carlos Pignataro、Shepherdレビューを行った Dhruv Dhody、WG ADレビューを行った Ketan Talaulikar、Genartレビューを行った Meral Shirazipour、そしてIESGレビューを行った Mohamed Boucadair、Éric Vyncke、Deb Cooley、Mahesh Jethanandani、Mike Bishop、Gunter Van de Velde にも感謝します。これらのレビューは本書の改善に役立ちました。
The following people have substantially contributed to this document:
次の方々が本書に多大な貢献をしました。
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
Karnataka
India
Email: dhruv.ietf@gmail.com
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: lizhenbin@huawei.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: jie.dong@huawei.com
Cheng Li (editor)
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com
Mach(Guoyi) Chen
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: mach.chen@outlook.com
Weiqiang Cheng
China Mobile
China
Email: chengweiqiang@chinamobile.com
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Quan Xiong
ZTE Corporation
China
Email: xiong.quan@zte.com.cn