[要約] RFC 9059は、関連する双方向ラベルスイッチパス(LSPs)のためのパス計算要素通信プロトコル(PCEP)拡張に関するものです。この文書の目的は、PCEPを使用して双方向LSPsの設定と管理を効率化する方法を定義することにあります。主に、ネットワークの性能を最適化し、リソースの利用効率を高めるために利用されます。
Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 9059 Cisco Systems, Inc.
Category: Standards Track C. Barth
ISSN: 2070-1721 Juniper Networks
B. Wen
Comcast
June 2021
Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)
関連する双方向ラベルスイッチ付きパス（LSP）のためのパス計算要素通信プロトコル（PCE）拡張子
Abstract
概要
This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.
この文書は、ネットワーク内の各方向に1つずつ、1つの単方向のMPLS-TEラベルスイッチングパス（LSP）を、関連する双方向LSPにグループ化するためのパス計算要素通信プロトコル（PCE）拡張子を定義しています。これらのPCEP拡張は、PCE開始されたLSPとPCCの両方のLSPまたはステートレスPCEを使用して、ステートフルPCEを使用して適用できます。定義されたPCEP手順は、シグナリングのためにRSVP-TEを使用したLSPに適用されます。
Status of This Memo
本文書の位置付け
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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc9059.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc9059で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
2.1. Key Word Definitions
2.2. Terminology
3. Overview
3.1. Single-Sided Initiation
3.1.1. PCE-Initiated Single-Sided Bidirectional LSP
3.1.2. PCC-Initiated Single-Sided Bidirectional LSP
3.2. Double-Sided Initiation
3.2.1. PCE-Initiated Double-Sided Bidirectional LSP
3.2.2. PCC-Initiated Double-Sided Bidirectional LSP
3.3. Co-routed Associated Bidirectional LSP
3.4. Summary of PCEP Extensions
3.5. Operational Considerations
4. Protocol Extensions
4.1. ASSOCIATION Object
4.2. Bidirectional LSP Association Group TLV
5. PCEP Procedure
5.1. PCE-Initiated LSPs
5.2. PCC-Initiated LSPs
5.3. Stateless PCE
5.4. Bidirectional (B) Flag
5.5. PLSP-ID Usage
5.6. State Synchronization
5.7. Error Handling
6. Security Considerations
7. Manageability 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 Types
8.2. Bidirectional LSP Association Group TLV
8.2.1. Flag Field in Bidirectional LSP Association Group TLV
8.3. PCEP Errors
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP) as a communication mechanism between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCE and PCC, that enables computation of Multiprotocol Label Switching (MPLS) - Traffic Engineering (TE) Label Switched Paths (LSPs).
[RFC5440] PATH計算クライアント（PCC）とパス演算要素（PCE）との間の通信機構としてのパス算出要素通信プロトコル（PCE）、あるいはPCEとPCCの間（MPLS）を記述している。 - トラフィックエンジニアリング（TE）ラベルスイッチパス（LSP）。
[RFC8231] specifies extensions to PCEP to enable stateful control of MPLS-TE LSPs. It describes two modes of operation: passive stateful PCE and active stateful PCE. In [RFC8231], the focus is on active stateful PCE where LSPs are provisioned on the PCC and control over them is delegated to a PCE. Further, [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs for the stateful PCE model.
[RFC8231] MPLS-TE LSPのステートフル制御を有効にするためのPCEPへの拡張機能を指定します。それは2つの操作モードを説明します：パッシブステートフルPCEとアクティブなステートフルPCE。[RFC8231]では、フォーカスはPCC上でLSPがプロビジョニングされ、それらを制御するアクティブなステートフルPCEがPCEに委任されます。さらに、[RFC8281]は、ステートフルPCEモデルのためのPCE開始されたLSPのセットアップ、メンテナンス、および破壊を説明しています。
[RFC8697] introduces a generic mechanism for creating a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes, and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.
[RFC8697] LSPのグループ化を作成するための一般的なメカニズムを紹介します。このグループ化を使用して、LSPのセット間またはLSPのセットと一連の属性との間の関連付けを定義することができ、ステートフルPCE（アクティブモードとパッシブモード）およびステートレスPCEに等しく適用できます。
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that "MPLS-TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths". [RFC7551] defines RSVP signaling extensions for binding forward and reverse unidirectional LSPs into an associated bidirectional LSP. The fast reroute (FRR) procedures for associated bidirectional LSPs are described in [RFC8537].
MPLSトランスポートプロファイル（MPLS-TP）要件文書[RFC5654]は、「MPLS-TPは単方向、共ルード双方向、および関連する双方向のポイントツーポイントトランスポートパスをサポートしなければならない」を指定します。[RFC7551]は、順方向および逆一方のLSPを関連する双方向LSPにバインドするためのRSVPシグナリング拡張機能を定義します。関連する双方向LSPのための高速再ルーチ（FRR）手順は[RFC8537]に記載されている。
This document defines PCEP extensions for grouping two unidirectional MPLS-TE LSPs into an associated bidirectional LSP for both single-sided and double-sided initiation cases either when using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or when using a stateless PCE. The procedures defined are applicable to the LSPs using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling [RFC3209]. Specifically, this document defines two new Association Types, Single-Sided Bidirectional LSP Association and Double-Sided Bidirectional LSP Association, as well as the Bidirectional LSP Association Group TLV, to carry additional information for the association.
このドキュメントでは、PCE開始されたLSPとPCCの両方のLSPのステートフルPCEを使用する場合、またはステートレスを使用する場合に、2つの単方向MPLS-TE LSPを関連する双方向LSPにグループ化するためのPCEP拡張機能を定義します。PCE。定義された手順は、シグナリングのためのリソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を使用したLSPに適用されます[RFC3209]。具体的には、この文書は、双方向の双方向LSP協会、両面双方向LSPアソシエーション、双方向LSPアソシエーショングループTLVを定義し、関連情報を搭載しています。
The procedure for associating two unidirectional Segment Routing (SR) paths to form an associated bidirectional SR path is defined in [BIDIR-PATH] and is outside the scope of this document.
関連する双方向SRパスを形成するために2つの単方向セグメントルーティング（SR）パスを関連付ける手順は、[Bidir-Path]で定義されており、この文書の範囲外です。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader is assumed to be familiar with the terminology defined in [RFC5440], [RFC7551], [RFC8231], and [RFC8697].
リーダーは、[RFC5440]、[RFC7551]、[RFC8231]、[RFC8697]で定義されている用語に精通していると見なされます。
As shown in Figure 1, forward and reverse unidirectional LSPs can be grouped to form an associated bidirectional LSP. Node A is the ingress node for LSP1 and egress node for LSP2, whereas node D is the ingress node for LSP2 and egress node for LSP1. There are two methods of initiating the Bidirectional LSP Association, single-sided and double-sided, as defined in [RFC7551] and described in the following sections.
図1に示すように、順方向および逆方向の一方向LSPをグループ化して関連する双方向LSPを形成することができる。ノードAはLSP2用のLSP1および出力ノード用の入力ノードであり、ノードDはLSP2用のLSP2および出力ノードの入力ノードである。[RFC7551]で定義され、以下のセクションで説明されているように、双方向LSPアソシエーション、片面および両面を開始する方法があります。
LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +--+--+ +--+--+ +-----+
<-- LSP2 | | <-- LSP2
| |
| |
+--+--+ +--+--+
| E +-----------+ F |
+-----+ +-----+
<-- LSP2
Figure 1: Example of Associated Bidirectional LSP
図1：関連する双方向LSPの例
As specified in [RFC7551], in the single-sided case, the bidirectional tunnel is provisioned only on one endpoint node (PCC) of the tunnel. Both endpoint nodes act as PCCs. Both forward and reverse LSPs of this tunnel are initiated with the Association Type set to "Single-Sided Bidirectional LSP Association" on the originating endpoint node. The forward and reverse LSPs are identified in the Bidirectional LSP Association Group TLV of their PCEP ASSOCIATION objects.
[RFC7551]で指定されているように、片側ケースでは、双方向トンネルはトンネルの1つのエンドポイントノード（PCC）にのみプロビジョニングされます。両方のエンドポイントノードはPCCとして機能します。このトンネルの順方向および逆LSPの両方が、発信元エンドポイントノードの「片面双方向LSPアソシエーション」に設定されているアソシエーションタイプで開始されます。順方向および逆方向LSPは、PCEPアソシエーションオブジェクトの双方向LSPアソシエーショングループTLVで識別されます。
The originating endpoint node signals the properties for the reverse LSP in the RSVP REVERSE_LSP object [RFC7551] of the forward LSP Path message. The remote endpoint node then creates the corresponding reverse tunnel and reverse LSP, and it then signals the reverse LSP in response to the received RSVP-TE Path message. Similarly, the remote endpoint node deletes the reverse LSP when it receives the RSVP-TE message to delete the forward LSP [RFC3209].
発信元エンドポイントノードは、順方向LSPパスメッセージのRSVP Restable_LSPオブジェクト[RFC7551]内のリバースLSPのプロパティを通知します。次に、リモートエンドポイントノードは対応する逆トンネルとリバースLSPを作成し、次に受信したRSVP-TEパスメッセージに応答してリバースLSPを送ります。同様に、リモートエンドポイントノードはRSVP-TEメッセージを受信してRSVP-TEメッセージを受信してRFC3209を削除したときにリバースLSPを削除します。
As specified in [RFC8537], for fast reroute bypass tunnel assignment, the LSP starting from the originating endpoint node is identified as the forward LSP of the single-sided initiated bidirectional LSP.
[RFC8537]で指定されているように、高速再ルーチバイパストンネル割り当てのために、発信エンドポイントノードから始まるLSPは、片側開始双方向LSPの順方向LSPとして識別されます。
+-----+
| PCE |
+-----+
Initiates: | \
Tunnel 1 (F) | \
(LSP1 (F, 0), LSP2 (R, 0)) | \
Association #1 v \
+-----+ +-----+
| A | | D |
+-----+ +-----+
+-----+
| PCE |
+-----+
Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #1 | \ Association #1
+-----+ +-----+
| A | | D |
+-----+ +-----+
Legend: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs
Figure 2: Example of PCE-Initiated Single-Sided Bidirectional LSP
図2：PCE開始片面双方向LSPの例
Using partial topology from Figure 1, as shown in Figure 2, the forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node A by the PCE. The PCEP-specific LSP identifiers (PLSP-IDs) used are P1 and P2 on the originating endpoint node A and P3 on the remote endpoint node D. The originating endpoint node A reports Tunnel 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the PCE.
図1から部分的なトポロジを使用して、図2に示すように、順方向トンネル1と順方向LSP1と逆LSP2の両方がPCEによって発信エンドポイントノードAで開始されます。使用されるPCEP固有のLSP識別子（PLSP - ID）は、リモートエンドポイントノードD上の発信エンドポイントノードAおよびP3のP1およびP2である。発信エンドポイントノードAは、トンネル1および順方向LSP1およびリバースLSP2をPCEに報告する。エンドポイント（PCC）ノードDは、トンネル2とLSP2をPCEに報告します。
+-----+
| PCE |
+-----+
Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #2 | \ Association #2
+-----+ +-----+
| A | | D |
+-----+ +-----+
Legend: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs
Figure 3: Example of PCC-Initiated Single-Sided Bidirectional LSP
図3：PCC開始片面双方向LSPの例
Using partial topology from Figure 1, as shown in Figure 3, the forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node A (the originating PCC). The PLSP-IDs used are P1 and P2 on the originating endpoint node A and P3 on the remote endpoint node D. The originating endpoint (PCC) node A may delegate the forward LSP1 and reverse LSP2 to the PCE. The originating endpoint node A reports Tunnel 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the PCE.
図1から部分的なトポロジを使用して、図3に示すように、順方向トンネル1と順方向LSP1とリバースLSP2の両方が発信エンドポイントノードA（発信PCC）で開始されます。使用されているPLSP-IDは、リモートエンドポイントノードD上の発信エンドポイントノードA、P3のP1とP2である。発信エンドポイント（PCC）ノードAは、順方向LSP1とリバースLSP2をPCEに委任することができる。発信元エンドポイントノードAは、トンネル1と順方向LSP1とREVERSE LSP2をPCEに報告します。エンドポイント（PCC）ノードDは、トンネル2とLSP2をPCEに報告します。
As specified in [RFC7551], in the double-sided case, the bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of the tunnel. The forward and reverse LSPs of this tunnel are initiated with the Association Type set to "Double-Sided Bidirectional LSP Association" on both endpoint nodes. The forward and reverse LSPs are identified in the Bidirectional LSP Association Group TLV of their ASSOCIATION objects.
[RFC7551]で指定されているように、両面の場合、双方向トンネルはトンネルの両方のエンドポイントノード（PCC）にプロビジョニングされます。このトンネルの順方向および逆LSPは、両方のエンドポイントノードの「両面双方向LSPアソシエーション」に設定された関連タイプで開始されます。順方向および逆方向LSPは、それらの関連オブジェクトの双方向LSPアソシエーショングループTLVにおいて識別される。
As specified in [RFC8537], for fast reroute bypass tunnel assignment, the LSP with the higher source address [RFC3209] is identified as the forward LSP of the double-sided initiated bidirectional LSP.
[RFC8537]で指定されているように、高速再ルーチバイパストンネル割り当てのために、より高い送信元アドレス[RFC3209]のLSPは、両面開始双方向LSPの順方向LSPとして識別されます。
+-----+
| PCE |
+-----+
Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, 0)) | \ (LSP2 (F, 0))
Association #3 v v Association #3
+-----+ +-----+
| A | | D |
+-----+ +-----+
+-----+
| PCE |
+-----+
Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #3 | \ Association #3
+-----+ +-----+
| A | | D |
+-----+ +-----+
Legend: F = Forward LSP, (0,P4,P5) = PLSP-IDs
Figure 4: Example of PCE-Initiated Double-Sided Bidirectional LSP
図4：PCE開始両面双方向LSPの例
Using partial topology from Figure 1, as shown in Figure 4, the forward Tunnel 1 and forward LSP1 are initiated on the endpoint node A, and the reverse Tunnel 2 and reverse LSP2 are initiated on the endpoint node D by the PCE. The PLSP-IDs used are P4 on the endpoint node A and P5 on the endpoint node D. The endpoint node A (PCC) reports the forward LSP1, and endpoint node D reports the forward LSP2 to the PCE.
図1から部分的なトポロジを使用して、図4に示すように、順方向トンネル1と順方向LSP1がエンドポイントノードAで開始され、逆トンネル2とリバースLSP2はPCEによってエンドポイントノードD上で開始されます。使用されるPLSP-IDは、エンドポイントノードA、エンドポイントノードD上のP4である。エンドポイントノードA（PCC）は、順方向LSP1を報告し、エンドポイントノードDは順方向LSP2をPCEに報告する。
+-----+
| PCE |
+-----+
Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #4 | \ Association #4
+-----+ +-----+
| A | | D |
+-----+ +-----+
Legend: F = Forward LSP, (P4,P5) = PLSP-IDs
Figure 5: Example of PCC-Initiated Double-Sided Bidirectional LSP
図5：PCC開始両面双方向LSPの例
Using partial topology from Figure 1, as shown in Figure 5, the forward Tunnel 1 and forward LSP1 are initiated on the endpoint node A, and the reverse Tunnel 2 and reverse LSP2 are initiated on the endpoint node D (the PCCs). The PLSP-IDs used are P4 on the endpoint node A and P5 on the endpoint node D. Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to the PCE. The endpoint node A (PCC) reports the forward LSP1, and endpoint node D reports the forward LSP2 to the PCE.
図1から部分的なトポロジを使用して、図5に示すように、順ポイントノードA上で順方向トンネル1と順方向LSP1が開始され、逆トンネル2とリバースLSP2はエンドポイントノードD（PCC）で開始されます。使用されるPLSP-IDは、エンドポイントノードA、およびエンドポイントノードD上のP5である。エンドポイント（PCC）ノードは、順方向LSP1およびLSP2をPCEに委任することができる。エンドポイントノードA（PCC）は順方向LSP1を報告し、エンドポイントノードDは順方向LSP2をPCEに報告します。
In both single-sided and double-sided initiation cases, forward and reverse LSPs can be co-routed as shown in Figure 6, where both forward and reverse LSPs of a bidirectional LSP follow the same congruent path in the forward and reverse directions, respectively.
片面および両面の開始ケースの両方で、順方向LSPの順方向および逆方向LSPの両方がそれぞれ前方および逆方向の同じ合同パスに従うように、順方向および逆方向LSPを同時ルーティングすることができる。。
LSP3 --> LSP3 --> LSP3 -->
+-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +-----+ +-----+ +-----+
<-- LSP4 <-- LSP4 <-- LSP4
Figure 6: Example of Co-routed Associated Bidirectional LSP
図6：共ルーテッド関連双方向LSPの例
The procedure specified in [RFC8537] for fast reroute bypass tunnel assignment is also applicable to the co-routed associated bidirectional LSPs.
高速Rerouteバイパストンネル割り当てのために[RFC8537]で指定された手順は、共同ルーティングされた関連双方向LSPにも適用されます。
The PCEP extensions defined in this document cover the following modes of operation under the stateful PCE model:
このドキュメントで定義されているPCEP拡張機能は、ステートフルPCEモデルで次の動作モードをカバーしています。
* A PCC initiates the forward and reverse LSP of a single-sided bidirectional LSP and retains control of the LSPs. Similarly, both PCCs initiate the forward LSPs of a double-sided bidirectional LSP and retain control of the LSPs. The PCC computes the path itself or makes a request for path computation to a PCE. After the path setup, it reports the information and state of the path to the PCE. This includes the association group identifying the bidirectional LSP. This is the passive stateful mode defined in [RFC8051].
* PCCは、片面双方向LSPの順方向および逆LSPを開始し、LSPの制御を保持します。同様に、両方のPCCは両面双方向LSPの順方向LSPを開始し、LSPの制御を保持する。PCCはパス自体を計算するか、パス計算の要求をPCEにする。パス設定の後、PCEへのパスの情報と状態を報告します。これには、双方向LSPを識別する関連グループが含まれます。これは[RFC8051]で定義されているパッシブステートフルモードです。
* A PCC initiates the forward and reverse LSP of a single-sided bidirectional LSP and delegates control of the LSPs to a stateful PCE. Similarly, both PCCs initiate the forward LSPs of a double-sided bidirectional LSP and delegate control of the LSPs to a stateful PCE. During delegation, the association group identifying the bidirectional LSP is included. The PCE computes the path of the LSP and updates the PCC with the information about the path as long as it controls the LSP. This is the active stateful mode defined in [RFC8051].
* PCCは、片面双方向LSPの順方向および逆LSPを開始し、LSPの制御をステートフルPCEに代表する。同様に、両方のPCCは両面双方向LSPの順方向LSPを開始し、LSPの制御をステートフルPCEに代表する。委任中、双方向LSPを識別する関連グループが含まれています。PCEはLSPのパスを計算し、LSPを制御する限り、パスに関する情報を入力してPCCを更新します。これは[RFC8051]で定義されているアクティブなステートフルモードです。
* A PCE initiates the forward and reverse LSP of a single-sided bidirectional LSP on a PCC and retains control of the LSP. Similarly, a PCE initiates the forward LSPs of a double-sided bidirectional LSP on both PCCs and retains control of the LSPs. The PCE is responsible for computing the path of the LSP and updating the PCC with the information about the path as well as the association group identifying the bidirectional LSP. This is the PCE-initiated mode defined in [RFC8281].
* PCEは、PCC上の片面双方向LSPの順方向および逆LSPを開始し、LSPの制御を保持します。同様に、PCEは両方のPCC上の両面双方向LSPの順方向LSPを開始し、LSPの制御を保持します。PCEは、LSPのパスを計算し、経路に関する情報と双方向LSPを識別する関連グループとPCCを更新する責任があります。これは[RFC8281]で定義されているPCE開始モードです。
* A PCC requests co-routed or non-co-routed paths for forward and reverse LSPs of a bidirectional LSP, including when using a stateless PCE [RFC5440].
* PCCは、ステートレスPCE [RFC5440]を使用する場合を含む、双方向LSPの順方向および逆方向LSPのための共同ルーティングまたは非共同パスを要求します。
The double-sided case has an advantage when compared to the single-sided case, summarized as follows:
両面ケースは、片面ケースと比較したときに有利であり、次のように要約されています。
* In the double-sided case, two existing unidirectional LSPs in reverse directions in the network can be associated to form a bidirectional LSP without significantly increasing the operational complexity.
* 両面ケースでは、ネットワーク内の逆方向に2つの既存の一方向LSPを関連付けて、動作複雑さを大幅に増大させることなく双方向LSPを形成することができる。
The single-sided case has some advantages when compared to the double-sided case, summarized as follows:
片側ケースには、次のようにまとめられた両面の場合と比較していくつかの利点があります。
* Some Operations, Administration, and Maintenance (OAM) use cases may require an endpoint node to know both forward and reverse paths for monitoring the bidirectional LSP. For such use cases, the single-sided case may be preferred.
* 一部の操作、管理、およびメンテナンス（OAM）の使用例には、双方向LSPを監視するための順方向および逆のパスの両方を知るためにエンドポイントノードが必要になる場合があります。このような使用例としては、片面ケースが好ましい場合がある。
* For co-routed associated bidirectional LSPs in PCC-initiated mode, the single-sided case allows the originating PCC to dynamically compute co-routed forward and reverse paths. This may not be possible with the double-sided case where the forward and reverse paths are computed separately as triggered by two different PCCs.
* PCC開始モードでの共ルーテッド関連双方向LSPの場合、片側ケースは、発信側PCCが共同ルーティングされた前方および反転経路を動的に計算することを可能にします。これは、順方向および逆方向経路が2つの異なるPCCによって引き起こされるように別々に計算される両側の場合では不可能であるかもしれない。
* The associated bidirectional LSPs in the single-sided case can be deployed in a network where PCEP is only enabled on the originating endpoint nodes as remote endpoint nodes create the reverse tunnels using RSVP-TE Path messages.
* 片側ケース内の関連する双方向LSPは、リモートエンドポイントノードがRSVP-TEパスメッセージを使用してリバーストンネルを作成するため、PCEPが発信元エンドポイントノードでのみ有効になっているネットワークに展開できます。
As per [RFC8697], LSPs are associated by adding them to a common association group. This document defines two new Association Types, called "Single-Sided Bidirectional LSP Association" (4) and "Double-Sided Bidirectional LSP Association" (5), using the generic ASSOCIATION object (Object-Class value 40). A member of the Bidirectional LSP Association can take the role of a forward or reverse LSP and follows the following rules:
[RFC8697]のように、LSPはそれらを共通の関連グループに追加することによって関連付けられています。この資料は、一般的な関連付けオブジェクトを使用して、「片面双方向LSPアソシエーション」（4）と「両面双方向LSP協会」（5）と呼ばれる2つの新しい関連付けタイプを定義しています（オブジェクトクラス値40）。双方向LSPアソシエーションのメンバーは、順方向または逆方向LSPの役割を果たすことができ、次の規則に従うことができます。
* An LSP (forward or reverse) MUST NOT be part of more than one Bidirectional LSP Association.
* LSP（前方または逆転）は、複数の双方向LSP協会の一部であるべきではありません。
* The LSPs in a Bidirectional LSP Association MUST have matching endpoint nodes in the reverse directions.
* 双方向LSP関連のLSPは、逆方向にエンドポイントノードを一致させる必要があります。
* The same tunnel (as defined in Section 2.1 of [RFC3209]) MUST contain the forward and reverse LSPs of the Single-Sided Bidirectional LSP Association on the originating node, albeit both LSPs have reversed endpoint nodes.
* 同じトンネル（[RFC3209]のセクション2.1で定義されているように）は、両方のLSPが逆エンドポイントノードを持ち、発信ノード上の片面双方向LSPアソシエーションの順方向および逆方向LSPを含める必要があります。
The Bidirectional LSP Association Types are considered to be both dynamic and operator configured in nature. As per [RFC8697], the association group could be manually created by the operator on the PCEP peers, and the LSPs belonging to this association are conveyed via PCEP messages to the PCEP peer; alternately, the association group could be created dynamically by the PCEP speaker, and both the association group information and the LSPs belonging to the association group are conveyed to the PCEP peer. The operator-configured Association Range MUST be set for this Association Type to mark a range of Association Identifiers that are used for operator-configured associations to avoid any Association Identifier clash within the scope of the Association Source (refer to [RFC8697]).
双方向LSPアソシエーションタイプは、動的に構成された動的およびオペレータの両方であると考えられています。[RFC8697]によると、アソシエーショングループはPCEPピア上のオペレータによって手動で作成され、この関連付けに属するLSPはPCEPメッセージを介してPCEPピアに伝えられます。あるいは、アソシエーショングループはPCEPスピーカによって動的に作成され、関連グループ情報と関連グループに属するLSPとの両方がPCEPピアに伝達される。オペレータ設定されたアソシエーション範囲をこのアソシエーションタイプに設定して、アソシエーションソースの範囲内での関連付け識別子衝突を回避するために、オペレータ設定された関連付けに使用される範囲の関連付け識別子をマークする必要があります（[RFC8697]参照）。
Specifically, for the PCE-initiated bidirectional LSPs, these associations are dynamically created by the PCE on the PCE peers. Similarly, for both the PCE-initiated and the PCC-initiated single-sided cases, these associations are also dynamically created on the remote endpoint node using the information received from the RSVP message from the originating node.
具体的には、PCE開始双方向LSPの場合、これらの関連付けはPCEピア上のPCEによって動的に作成されます。同様に、PCE開始とPCC開始された片側ケースの両方で、これらの関連付けもリモートエンドポイントノード上でリモートエンドポイントノード上で動的に作成されます。
The Association ID, Association Source, optional Global Association Source TLV, and optional Extended Association ID TLV in the Bidirectional LSP ASSOCIATION object are initialized using the procedures defined in [RFC8697] and [RFC7551].
双方向LSP Associationオブジェクト内のアソシエーションID、アソシエーションソース、オプションのグローバルアソシエーションソースTLV、およびオプションの拡張アソシエーションID TLVは、[RFC8697]および[RFC7551]で定義されている手順を使用して初期化されます。
[RFC8697] specifies the mechanism for the capability advertisement of the Association Types supported by a PCEP speaker by defining an ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the Bidirectional LSP Association Types MUST be done before using the Bidirectional LSP Association. Thus, the PCEP speaker MUST include the Bidirectional LSP Association Types in the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer before using the Bidirectional LSP Association in PCEP messages.
[RFC8697] Open Object内で搭載されるべきAssoc-Type-List TLVを定義することで、PCEPスピーカーでサポートされているアソシエーション・タイプの機能広告のメカニズムを指定します。双方向LSPアソシエーションタイプに対するこの機能交換は、双方向LSPアソシエーションを使用する前に行わなければなりません。したがって、PCEPスピーカーは、ASC-TYPEリストTLVに双方向LSPアソシエーションタイプを含めなければならず、PCEPメッセージで双方向LSPアソシエーションを使用する前にPCEPピアから同じことを受信する必要があります。
The Bidirectional LSP Association Group TLV is an OPTIONAL TLV for use with Bidirectional LSP Associations (ASSOCIATION object with Association Type 4 for Single-Sided Bidirectional LSP Association or 5 for Double-Sided Bidirectional LSP Association).
双方向LSPアソシエーショングループTLVは、双方向LSPアソシエーション（双方向双方向LSPアソシエーションまたは両面双方向LSP協会のための双方向双方向LSPアソシエーションまたは5）の双方向LSPアソシエーション（アソシエーションタイプ4との関連オブジェクトとの関連オブジェクト）である。
* The Bidirectional LSP Association Group TLV follows the PCEP TLV format from [RFC5440].
* 双方向LSPアソシエーショングループTLVは、[RFC5440]からPCEP TLVフォーマットに従います。
* The Type (16 bits) of the TLV is 54.
* TLVのタイプ（16ビット）は54です。
* The Length is 4 bytes.
* 長さは4バイトです。
* The value comprises of a single field, the Flags field (32 bits), where each bit represents a flag option.
* 値は単一のフィールド、Flagsフィールド（32ビット）を含み、各ビットはフラグオプションを表します。
* If the Bidirectional LSP Association Group TLV is missing, it means the LSP is the forward LSP, and it is not a co-routed LSP.
* 双方向LSPアソシエーショングループTLVが欠落している場合は、LSPが順方向LSPで、共同ルードLSPではありません。
* When the Bidirectional LSP Association Group TLV is present, the R flag MUST be reset for the forward LSP for both co-routed and non-co-routed LSPs.
* 双方向LSPアソシエーショングループTLVが存在する場合は、共同ルーティングLSPと非共同LSPの両方について順方向LSPに対してRフラグをリセットする必要があります。
* For co-routed LSPs, this TLV MUST be present and the C flag set.
* 共同ルードLSPの場合、このTLVが存在し、Cフラグを設定する必要があります。
* For reverse LSPs, this TLV MUST be present and the R flag set.
* リバースLSPの場合、このTLVが存在し、Rフラグセットが必要です。
* The Bidirectional LSP Association Group TLV MUST NOT be present more than once. If it appears more than once, only the first occurrence is processed, and any others MUST be ignored.
* 双方向LSPアソシエーショングループTLVは複数回存在してはいけません。それが複数回表示されている場合は、最初の発生のみが処理され、他のどんなものも無視する必要があります。
The format of the Bidirectional LSP Association Group TLV is shown in Figure 7.
双方向LSPアソシエーショングループTLVのフォーマットを図7に示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 54 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Bidirectional LSP Association Group TLV Format
図7：双方向LSP協会グループTLVフォーマット
Flags for the Bidirectional LSP Association Group TLV are defined as follows.
双方向LSPアソシエーショングループTLVのフラグは次のように定義されています。
R (Reverse LSP, 1 bit, bit number 31): Indicates whether the LSP associated is the reverse LSP of the bidirectional LSP. If this flag is set, the LSP is a reverse LSP. If this flag is not set, the LSP is a forward LSP.
R（リバースLSP、1ビット、ビット番号31）：LSPが双方向LSPの逆LSPかどうかを示します。このフラグが設定されている場合、LSPはリバースLSPです。このフラグが設定されていない場合、LSPは順方向LSPです。
C (Co-routed Path, 1 bit, bit number 30): Indicates whether the bidirectional LSP is co-routed. This flag MUST be set for both the forward and reverse LSPs of a co-routed bidirectional LSP.
C（共ルーテッドパス、1ビット、ビット数30）：双方向LSPが共ルーティングされているかどうかを示します。このフラグは、共同ルード双方向LSPの順方向LSPと逆方向LSPの両方に設定する必要があります。
The C flag is used by the PCE (both stateful and stateless) to compute bidirectional paths of the forward and reverse LSPs of a co-routed bidirectional LSP.
Cフラグは、共同経路付き双方向LSPの順方向および逆方向LSPの双方向経路を計算するためにPCE（ステートフルとステートレスの両方）によって使用されます。
The unassigned flags (bit numbers 0-29) MUST be set to 0 when sent and MUST be ignored when received.
割り当てられていないフラグ（ビット数0~29）は、送信されたときに0に設定され、受信したときに無視される必要があります。
The PCEP procedure defined in this document is applicable to the following three scenarios:
このドキュメントで定義されているPCEプロシージャは、次の3つのシナリオに適用されます。
* Neither unidirectional LSP exists, and both must be established.
* 一方向LSPも存在しない、両方を確立する必要があります。
* Both unidirectional LSPs exist, but the association must be established.
* 一方向LSPの両方が存在しますが、関連付けは確立されなければなりません。
* One LSP exists, but the reverse associated LSP must be established.
* 1つのLSPが存在しますが、逆関連LSPを確立する必要があります。
As specified in [RFC8697], Bidirectional LSP Associations can be created and updated by a stateful PCE.
[RFC8697]で指定されているように、双方向のLSPアソシエーションはステートフルPCEによって作成および更新できます。
* For a Single-Sided Bidirectional LSP Association initiated by the PCE, the PCE MUST send a PCInitiate message to the originating endpoint node with both forward and reverse LSPs. For a Double-Sided Bidirectional LSP Association initiated by the PCE, it MUST send a PCInitiate message to both endpoint nodes with forward LSPs.
* PCEによって開始された片面双方向LSP関連付けの場合、PCEは、順方向LSPとリバースLSPの両方を持つ発信元エンドポイントノードにPCINITIATEメッセージを送信しなければなりません。PCEによって開始された両面の双方向LSP関連付けの場合、それはPCINITIATEメッセージを順方向LSPと一緒に両方のエンドポイントノードに送信する必要があります。
* Both PCCs MUST report the forward and reverse LSPs in the Bidirectional LSP Association to the PCE. A PCC reports via a PCRpt message.
* 両方のPCCは、双方向LSPアソシエーション内の順方向LSPをPCEに報告する必要があります。PCRPTメッセージを介してPCCレポート。
* Stateful PCEs MAY create and update the forward and reverse LSPs independently for the Single-Sided Bidirectional LSP Association on the originating endpoint node.
* ステートフルPCEは、発信エンドポイントノード上の片面双方向LSPアソシエーションに対して、順方向LSPと逆LSPを独立して作成および更新することができます。
* Stateful PCEs MAY create and update the forward LSP independently for the Double-Sided Bidirectional LSP Association on the endpoint nodes.
* ステートフルPCEは、エンドポイントノード上の両面双方向LSPアソシエーションに対して独立して順方向LSPを作成して更新することがあります。
* Stateful PCEs establish and remove the association relationship on a per-LSP basis.
* ステートフルPCEは、LSPごとの関連関係を確立して削除します。
* Stateful PCEs create and update the LSP and the association on PCCs via PCInitiate and PCUpd messages, respectively, using the procedures described in [RFC8697].
* ステートフルのPCES [RFC8697]に記載されている手順を使用して、それぞれPCINITIATEメッセージとPCUPDメッセージを介してLSPとPCCの関連付けを作成および更新します。
As specified in [RFC8697], Bidirectional LSP Associations can also be created and updated by a PCC.
[RFC8697]で指定されているように、双方向LSPアソシエーションもPCCによって作成および更新されます。
* For a Single-Sided Bidirectional LSP Association initiated at a PCC, the PCC MUST send a PCRpt message to the PCE with both forward and reverse LSPs. For a Double-Sided Bidirectional LSP Association initiated at the PCCs, both PCCs MUST send a PCRpt message to the PCE with forward LSPs.
* PCCで開始された片面の双方向LSP関連付けの場合、PCCはPCRPTメッセージをPCEにPCEに送信しなければなりません。PCCSで開始された両面双方向LSP協会の場合、両方のPCCはPCRPTメッセージをPCEに転送LSPに送信する必要があります。
* PCCs on the originating endpoint node MAY create and update the forward and reverse LSPs independently for the Single-Sided Bidirectional LSP Association.
* 発信元エンドポイントノードのPCCは、片面双方向LSPアソシエーションのために独立して順方向および逆LSPを作成および更新することができる。
* PCCs on the endpoint nodes MAY create and update the forward LSP independently for the Double-Sided Bidirectional LSP Association.
* エンドポイントノードのPCCは、両面双方向LSPアソシエーションに対して独立して順方向LSPを作成して更新することができます。
* PCCs establish and remove the association group on a per-LSP basis. PCCs MUST report the change in the association group of an LSP to PCE(s) via a PCRpt message.
* PCCは、関連付けられた関連グループをLSPごとに確立して削除します。PCCSは、PCRPTメッセージを介してLSPのアソシエーショングループの変更をPCEに報告する必要があります。
* PCCs report the forward and reverse LSPs in the Bidirectional LSP Association independently to PCE(s) via a PCRpt message.
* PCCSは、PCRPTメッセージを介してPCEに独立して双方向LSPアソシエーションの順方向および逆LSPを報告します。
* PCCs for the single-sided case MAY delegate the forward and reverse LSPs independently to a stateful PCE, where the PCE would control the LSPs. In this case, the originating (PCC) endpoint node SHOULD delegate both forward and reverse LSPs of a tunnel together to a stateful PCE in order to avoid any race condition.
* 片側ケースのPCCは、PCEがLSPを制御するステートフルPCEに独立して、前方および逆LSPを独立して委任することができます。この場合、発信側（PCC）エンドポイントノードは、競合状態を回避するために、トンネルの前方と逆方向LSPをステートフルPCEに委任する必要があります。
* PCCs for the double-sided case MAY delegate the forward LSPs to a stateful PCE, where the PCE would control the LSPs.
* 両面ケースのPCCは、PCEがLSPを制御する状態で、順方向LSPをステートフルPCEに委任することができます。
* A stateful PCE updates the LSPs in the Bidirectional LSP Association via a PCUpd message, using the procedures described in [RFC8697].
* ステートフルPCEは、[RFC8697]に記載されている手順を使用して、PCUPDメッセージを介して双方向LSPアソシエーションのLSPを更新します。
For a stateless PCE, it might be useful to associate a path computation request to an association group, thus enabling it to associate a common set of configuration parameters or behaviors with the request [RFC8697]. A PCC can request co-routed or non-co-routed forward and reverse paths from a stateless PCE for a Bidirectional LSP Association.
ステートレスPCEの場合、パス計算要求をアソシエーショングループに関連付けるのに役立ちます。したがって、それが要求[RFC8697]と共に共通の構成パラメータまたは動作の共通のセットを関連付けることができます。PCCは、双方向LSPアソシエーションのためにステートレスPCEから共有されていない、または非共同ルーティングの前方および逆の経路を要求することができます。
As defined in [RFC5440], the Bidirectional (B) flag in the Request Parameters (RP) object is set when the PCC specifies that the path computation request is for a bidirectional TE LSP with the same TE requirements in each direction. For an associated bidirectional LSP, the B flag is also set when the PCC makes the path computation request for the same TE requirements for the forward and reverse LSPs.
[RFC5440]で定義されているように、要求パラメータ（RP）オブジェクトの双方向（B）フラグは、PCCがパス計算要求が各方向に同じTE要件を持つ双方向TE LSP用であることを指定したときに設定されます。関連する双方向LSPの場合、PCCが順方向および逆方向LSPに対する同じTE要件に対してパス計算要求を要求するときにもBフラグが設定される。
Note that the B flag defined in a Stateful PCE Request Parameter (SRP) object [STATEFUL-PCE-GMPLS] to indicate "bidirectional co-routed LSP" is used for GMPLS-signaled bidirectional LSPs and is not applicable to the associated bidirectional LSPs.
「双方向共ルードLSP」を示すためのステートフルPCE要求パラメータ（SRP）オブジェクト[ステートフル - PCE - GMPLS]で定義されているBフラグは、GMPLSシグナリング双方向LSPに使用され、関連する双方向LSPには適用されないことに注意してください。
As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is created by a PCC to uniquely identify an LSP, and it remains the same for the lifetime of a PCEP session.
[RFC8231]で定義されているように、PCEP固有のLSP識別子（PLSP-ID）は、LSPを一意に識別するためにPCCによって作成され、PCEPセッションの有効期間は同じままです。
In the case of a Single-Sided Bidirectional LSP Association, the reverse LSP of a bidirectional LSP created on the originating endpoint node is identified by the PCE using two different PLSP-IDs, based on the PCEP session on the ingress or egress node PCCs for the LSP. In other words, the LSP will have a PLSP-ID P2 allocated at the ingress node PCC, while it will have a PLSP-ID P3 allocated at the egress node PCC (as shown in Figures 2 and 3). There is no change in the PLSP-ID allocation procedure for the forward LSP of a single-sided bidirectional LSP created on the originating endpoint node.
片面双方向LSPアソシエーションの場合、発信エンドポイントノードで作成された双方向LSPの逆LSPは、入力または出力ノードPCCのPCEPセッションに基づいて、2つの異なるPLSP-IDを使用してPCEによって識別されます。LSP。言い換えれば、LSPは、入力ノードPCCに割り当てられたPLSP-ID P2を持ち、（図2および3に示すように）出力ノードPCCに割り当てられたPLSP-ID P3を持つでしょう。発信エンドポイントノードで作成された片面双方向LSPの順方向LSPのPLSP-ID割り当て手順には変更はありません。
In the case of a Double-Sided Bidirectional LSP Association, there is no change in the PLSP-ID allocation procedure for the forward LSPs on either PCC.
両面双方向LSPアソシエーションの場合、PCCのどちらのPCC上の順方向LSPのPLSP-ID割り当て手順に変更はありません。
For an associated bidirectional LSP, the LSP-IDENTIFIERS TLV [RFC8231] MUST be included in all forward and reverse LSPs.
関連する双方向LSPの場合、LSP-ID-ID TLV [RFC8231]は、すべての順方向およびリバースLSPに含める必要があります。
During state synchronization, a PCC MUST report all the existing Bidirectional LSP Associations to the stateful PCE, as per [RFC8697]. After the state synchronization, the PCE MUST remove all previous Bidirectional LSP Associations absent in the report.
状態同期中、PCCは、[RFC8697]と同様に、既存の双方向LSPアソシエーションをステートフルPCEに報告する必要があります。状態同期後、PCEはレポートに欠けている以前のすべての双方向LSPアソシエーションを削除する必要があります。
If a PCE speaker receives an LSP with a Bidirectional LSP Association Type that it does not support, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 1 (Association Type is not supported).
PCEスピーカーがサポートされていない双方向LSPアソシエーションタイプでLSPを受信した場合、PCEスピーカーはError-Type = 26（Association Error）とError-Value = 1（アソシエーションタイプはサポートされていません）でPCERRを送信する必要があります。
An LSP (forward or reverse) cannot be part of more than one Bidirectional LSP Association. If a PCE speaker receives an LSP not complying to this rule, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 14 (Association group mismatch).
LSP（前方または逆転）は、複数の双方向LSP協会の一部にすることはできません。PCEスピーカーがこの規則に準拠していないLSPを受信した場合、PCEスピーカーはError-Type = 26（Association Error）とError-Value = 14（Association Group Mismatch）でPCERRを送信する必要があります。
The LSPs (forward or reverse) in a Single-Sided Bidirectional Association MUST belong to the same TE tunnel (as defined in [RFC3209]). If a PCE speaker attempts to add an LSP in a Single-Sided Bidirectional LSP Association for a different tunnel, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 15 (Tunnel mismatch in the association group).
片面双方向協会におけるLSP（前方または逆方向）は、（[RFC3209]で定義されているように）同じTEトンネルに属している必要があります。PCEスピーカーが異なるトンネルの片面双方向LSPアソシエーションでLSPを追加しようとすると、PCEスピーカーはError-Type = 26（Association Error）とError-value = 15（関連付けのトンネルの不一致）でPCERRを送信しなければなりません。グループ）。
The PCEP Path Setup Type (PST) for RSVP-TE is set to "Path is set up using the RSVP-TE signaling protocol" (Value 0) [RFC8408]. If a PCEP speaker receives a different PST value for the Bidirectional LSP Associations defined in this document, the PCE speaker MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-value = 16 (Path Setup Type not supported).
RSVP-TEのPCEPパス設定タイプ（PST）は、「RSVP-TEシグナリングプロトコルを使用してPATHSは設定されています」（VALUE 0）[RFC8408]。このドキュメントで定義されている双方向LSPアソシエーションにPCEPスピーカーが異なるPST値を受信した場合、PCEスピーカーはERROR-TYPE = 26（Association Error）とError-Value = 16でPCERRメッセージを返す必要があります（サポートされていません）。。
A Bidirectional LSP Association cannot have both unidirectional LSPs identified as reverse LSPs or both LSPs identified as forward LSPs. If a PCE speaker receives an LSP not complying to this rule, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 17 (Bidirectional LSP direction mismatch).
双方向LSPアソシエーションは、逆LSPとして識別された一方向LSPの両方を持つこともできません。PCEスピーカーがこの規則に準拠していないLSPを受信した場合、PCEスピーカーはError-Type = 26（Associpery Error）とError-Value = 17（双方向LSP方向の不一致）でPCERRを送信する必要があります。
A Bidirectional LSP Association cannot have one unidirectional LSP identified as co-routed and the other identified as non-co-routed. If a PCE speaker receives an LSP not complying to this rule, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 18 (Bidirectional LSP co-routed mismatch).
双方向LSPアソシエーションは、共同ルーティングとして識別され、もう1つは非共同ルーティングと識別された1つの単方向LSPを持つことはできません。PCEスピーカーがこの規則に準拠していないLSPを受信した場合、PCEスピーカーはERROR-TYPE = 26（Association Error）とError-Value = 18（双方向LSP共ルーズミスマッチ）でPCERRを送信する必要があります。
The unidirectional LSPs forming the Bidirectional LSP Association MUST have matching endpoint nodes in the reverse directions. If a PCE speaker receives an LSP not complying to this rule, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 19 (Endpoint mismatch in the association group).
双方向LSPアソシエーションを構成する一方向LSPは、逆方向に一致するエンドポイントノードを持たなければなりません。PCEスピーカーがこの規則に準拠していないLSPを受信した場合、PCEスピーカーはError-Type = 26（Association Error）とError-Value = 19（アソシエーショングループ内のエンドポイントの不一致）でPCERRを送信する必要があります。
The processing rules as specified in Section 6.4 of [RFC8697] continue to apply to the Association Types defined in this document.
[RFC8697]のセクション6.4で指定されている処理規則は、このドキュメントで定義されている関連タイプに適用されます。
The security considerations described in [RFC5440], [RFC8231], and [RFC8281] apply to the extensions defined in this document as well.
[RFC5440]、[RFC8231]、[RFC8281]で説明されているセキュリティ上の考慮事項もこの文書で定義されている拡張機能にも適用されます。
Two new Association Types for the ASSOCIATION object, Single-Sided Bidirectional LSP Association and Double-Sided Bidirectional LSP Association, are introduced in this document. Additional security considerations related to LSP associations due to a malicious PCEP speaker are described in [RFC8697] and apply to these Association Types. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] is RECOMMENDED.
この文書では、協会オブジェクト、片面双方向LSP協会および両面双方向LSP協会の2つの新しい関連型が導入されています。悪意のあるPCEPスピーカーによるLSPアソシエーションに関連する追加のセキュリティ上の考慮事項は[RFC8697]に記載されており、これらの関連タイプに適用されます。したがって、トランスポートレイヤセキュリティ（TLS）[RFC8253]を使用してPCEPセッションを保護することをお勧めします。
The mechanisms defined in this document do not imply any control or policy requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
この文書で定義されているメカニズムは、[RFC5440]、[RFC8231]、[RFC8281]に記載されているものに加えて、制御またはポリシーの要件を意味しません。
[RFC7420] describes the PCEP MIB; there are no new MIB objects defined for LSP associations.
[RFC7420] PCEP MIBについて説明しています。LSPアソシエーションに対して定義された新しいMIBオブジェクトはありません。
The PCEP YANG module [PCE-PCEP-YANG] defines a data model for LSP associations.
PCEP YANGモジュール[PCE-PCEP-YANG]は、LSPアソシエーションのデータモデルを定義します。
The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
この文書で定義されているメカニズムは、[RFC5440]、[RFC8231]、[RFC8281]にすでにリストされているものに加えて、新しい活性検出および監視要件を意味しません。
The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
この文書で定義されているメカニズムは、[RFC5440]、[RFC8231]、[RFC8281]にすでにリストされているものに加えて、新しい操作検証要件を暗示していません。
The mechanisms defined in this document do not add any new requirements on other protocols.
この文書で定義されているメカニズムは、他のプロトコルに新しい要件を追加しません。
The mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
この文書で定義されているメカニズムは、[RFC5440] [RFC5440]、[RFC8231]、[RFC8281]に記載されているものに加えて、ネットワーク操作には影響しません。
This document defines two new Association Types [RFC8697]. IANA has assigned the following new values in the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path Computation Element Protocol (PCEP) Numbers" registry:
この文書は2つの新しい関連タイプ[RFC8697]を定義しています。IANAは、「Association Type Field」サブリュジスト[RFC8697]に次の新しい値を割り当てました[PATH計算要素プロトコル（PCEP）番号]レジストリ：
+======+============================================+===========+
| Type | Name | Reference |
+======+============================================+===========+
| 4 | Single-Sided Bidirectional LSP Association | RFC 9059 |
+------+--------------------------------------------+-----------+
| 5 | Double-Sided Bidirectional LSP Association | RFC 9059 |
+------+--------------------------------------------+-----------+
Table 1: Additions to ASSOCIATION Type Field Subregistry
表1：協会型フィールドサブレジストの追加
This document defines a new TLV for carrying additional information about LSPs within a Bidirectional LSP Association. IANA has assigned the following value in the "PCEP TLV Type Indicators" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:
このドキュメントは、双方向LSPアソシエーション内のLSPに関する追加情報を持つための新しいTLVを定義します。IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリ内の「PCEP TLVタイプインジケータ」サブレイストに次の値を割り当てました。
+=======+=========================================+===========+
| Value | Meaning | Reference |
+=======+=========================================+===========+
| 54 | Bidirectional LSP Association Group TLV | RFC 9059 |
+-------+-----------------------------------------+-----------+
Table 2: Addition to PCEP TLV Type Indicators Subregistry
表2：PCEP TLVタイプ指標サブレジストへの追加
IANA has created a new subregistry, named "Bidirectional LSP Association Group TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the Bidirectional LSP Association Group TLV. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、「PATH計算要素プロトコル（PCEP演算要素プロトコル（PCEP演算要素プロトコル（PCEP）番号」の範囲内の「双方向LSPアソシエーショングループTLV FLAGフィールド」という新しいサブレジストを作成し、双方向LSPアソシエーショングループTLV内のフラグフィールドを管理する。新しい値は標準アクション[RFC8126]によって割り当てられます。各ビットは次の資質で追跡されるべきです。
* Bit number (count from 0 as the most significant bit)
* ビット数（最上位ビットとして0から数える）
* Description
* description
* Reference
* 参照
The initial contents of this registry are as follows:
このレジストリの初期内容は次のとおりです。
+======+====================+===========+
| Bit | Description | Reference |
+======+====================+===========+
| 0-29 | Unassigned | |
+------+--------------------+-----------+
| 30 | C - Co-routed Path | RFC 9059 |
+------+--------------------+-----------+
| 31 | R - Reverse LSP | RFC 9059 |
+------+--------------------+-----------+
Table 3: New Bidirectional LSP Association Group TLV Flag Field Subregistry
表3：新しい双方向LSP協会グループTLV FLAGフィールドサブレジスト
This document defines new Error-values for Error-Type 26 (Association Error). IANA has allocated the following new Error-values within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
このドキュメントでは、Error-Type 26（Association Error）の新しいエラー値を定義します。IANAは、「PCEP - ERRORオブジェクトエラータイプと値」の「PATH計算要素プロトコル（PCEP）番号」レジストリのサブレジスト内の次の新しいエラー値を割り当てました。
+============+=============+==========================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+=============+==========================+===========+
| 26 | Association | 14: Association group | RFC 9059 |
| | Error | mismatch | |
| | +--------------------------+-----------+
| | | 15: Tunnel mismatch in | RFC 9059 |
| | | the association group | |
| | +--------------------------+-----------+
| | | 16: Path Setup Type not | RFC 9059 |
| | | supported | |
| | +--------------------------+-----------+
| | | 17: Bidirectional LSP | RFC 9059 |
| | | direction mismatch | |
| | +--------------------------+-----------+
| | | 18: Bidirectional LSP | RFC 9059 |
| | | co-routed mismatch | |
| | +--------------------------+-----------+
| | | 19: Endpoint mismatch in | RFC 9059 |
| | | the association group | |
+------------+-------------+--------------------------+-----------+
Table 4: Additions to PCEP-ERROR Object Error Types and Values Subregistry
表4：PCEPエラーオブジェクトエラータイプと値サブリュージストリートへの追加
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] awduche、D.、Berger、L.、GaN、D.、Li、T.、Srinivasan、V.、G.Svp-Te：LSPトンネルのRSVPへの拡張機能、RFC 3209、DOI10.17487 / RFC3209、2001年12月、<https：//www.rfc-editor.org/info/rfc3209>。
[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>.
[RFC5440] Vasseur、JP。、ED。そしてJL。Le Roux、Ed。、「PATH計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https：//www.rfc-editor.org/info/rfc5440>。
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.
[RFC7551] Zhang、F.、Ed。、Jing、R.、R. Gandhi、Ed。、「関連する双方向ラベルスイッチ付きパス（LSP）」、RFC 7551、DOI 10.17487 / RFC7551、2015年5月<https：//www.rfc-editor.org/info/rfc7551>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J.、およびR. Varga、ステートフルPCEの「パス計算要素通信プロトコル（PCEP）拡張機能」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、<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>.
[RFC8253] Lopez、D.、Gonzalez De Deos、O.、Wu、Q.、およびD.Dhody、 "PCEP：パス計算要素通信プロトコル（PCEP）のための安全な輸送（PCEP）"、RFC 8253、DOI 10.17487 / RFC8253、2017年10月、<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>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S.、およびR. Varga、ステートフルPCEモデルにおけるPCE開始LSPセットアップのための「PCEP演算要素通信プロトコル（PCE）拡張」、RFC 8281、DOI2017487 / RFC8281、2017年12月、<https：//www.rfc-editor.org/info/rfc8281>。
[RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)", RFC 8537, DOI 10.17487/RFC8537, February 2019, <https://www.rfc-editor.org/info/rfc8537>.
[RFC8537] Gandhi、R.、Ed。、Shah、H.、およびJ.Whittaker、「共同ルーティング関連双方向ラベルスイッチド経路（LSP）」、RFC 8537、DOI 10.17487 / RFC8537の「高速再ルート手順の更新」、2019年2月、<https：//www.rfc-editor.org/info/rfc8537>。
[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>.
[RFC8697]ミネチ、I.、Crabbe、E.、Sivabalan、S.、Ananthakrishnan、H.、Dhody、D.、およびY。ラベルのセット間の関係を確立するための「PCEP計算要素通信プロトコル（PCE）拡張スイッチパス（LSP） "、RFC 8697、DOI 10.17487 / RFC8697、2020年1月、<https://www.rfc-editor.org/info/rfc8697>。
[BIDIR-PATH] Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-pce-sr-bidir-path-05, 26 January 2021, <https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-05>.
[Bidir-Path] Li、C、Chen、M.、Cheng、W.、Gandhi、R.およびQ. Xiong、関連する双方向セグメントルーティング（SR）パスのための「パス計算要素通信プロトコル（PCE）拡張」、進行中の作業、インターネットドラフト、ドラフト - IETF-PCE-SR-BIDIR-PATH-05,26 1月26日、<https：//tools.ietf.org/html/draft-ietf-pce-sr-bidir-パス-05>。
[PCE-PCEP-YANG] Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-16, 22 February 2021, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16>.
[PCE-PCEP-YANG] Dhody、D.、ED。、Hardwick、J.、Beeram、V.およびJ.Tantsura、「パス計算要素通信プロトコル（PCEP）のYangデータモデル」、進行中の作業、2021年2月22日、<https：//tools.ietf.org/html/draft-ietf-pce-pcep-yang-ietf-pce-pcep-yang-ietf-pce-pcep-yang-ietf-pce-pcep-yang-ietf-pce-pcep-yang-ietf-pce-pcep-yang-16>。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC5654] Nive-Jenkins、B.、ED。、Brungard、D.、ED。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLSトランスポートプロファイルの要求」、RFC 5654、DOI 10.17487 / RFC5654、2009年9月、<https：//www.rfc-editor.org/info/rfc5654>。
[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>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D.、およびJ.Hormwick、「パス計算要素通信プロトコル（PCEP）管理情報ベース（MIB）モジュール」、RFC 7420、DOI10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051] Zhang、X.、ED。そして、「ステートフルパス計算要素（PCE）」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[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>.
[RFC8408] Sivabalan、S.、Tantura、J.、Minei、I.、Varga、R.、およびJ.Horga、R.、「PCE通信プロトコル（PCEコミュニケーションプロトコル（PCE通信プロトコル（PCE通信プロトコル（PCE）メッセージの種類（PCE）メッセージの種類、RFC 8408、DOI 10.17487 / RFC84082018年7月、<https：//www.rfc-editor.org/info/rfc8408>。
[STATEFUL-PCE-GMPLS] Lee, Y., Ed., Zheng, H., Ed., de Dios, O., Lopez, V., and Z. Ali, "Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-stateful-pce-gmpls-14, 28 December 2020, <https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-14>.
[ステートフル - PCE - GMPLS] Lee、Y。、ED。、Zheng、H.、Ed。、De DIO、O.、Lopez、V.、およびZ. ALY、「パス計算要素（PCE）プロトコル拡張GMPLS制御ネットワークにおけるPCEの使用、進行中の作業、インターネットドラフト、ドラフト - IETF-PCE-PCEP-Stateful-PCE-GMPLS-14,28、<https：//tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-14>。
Acknowledgments
謝辞
The authors would like to thank Dhruv Dhody for various discussions on association groups and inputs to this document. The authors would also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and Marina Fizgeer for reviewing this document and providing valuable comments. The authors would like to thank the following IESG members for their review comments and suggestions: Barry Leiba, Éric Vyncke, Benjamin Kaduk, Murray Kucherawy, Martin Duke, and Alvaro Retana.
著者らは、協会グループとこの文書への入力についてさまざまなディスカッションについてDhruv Dhodyに感謝します。著者らは、この文書を見直し、貴重なコメントを提供するために、Mike Taillon、Harish Sitaraman、Al Morton、およびMarina Fizgeerに感謝します。著者らは、レビューのコメントや提案のために次のIESGメンバーに感謝します：Barry Leiba、Eric Vyncke、Benjamin Kaduk、Murray Kucherawy、Martin Duke、Alvaro Retana。
Authors' Addresses
著者の住所
Rakesh Gandhi (editor) Cisco Systems, Inc. Canada
Rakesh Gandhi（編集）Cisco Systems、Inc。カナダ
Email: rgandhi@cisco.com
Colby Barth Juniper Networks
Colby Barth Juniperネットワーク
Email: cbarth@juniper.net
Bin Wen Comcast
Bin Wen Comcast.
Email: Bin_Wen@cable.comcast.com