[要約] RFC 9050は、PCE（Path Computation Element）をLSP（Label Switched Paths）の中央制御装置として使用するためのPCEP（PCE Communication Protocol）手順と拡張機能について記述しています。この文書の目的は、ネットワーク内での経路計算とLSPの設定を効率化し、統合することにあります。主に、大規模ネットワークや複雑なトポロジーを持つ環境での利用が想定されています。
Internet Engineering Task Force (IETF) Z. Li
Request for Comments: 9050 S. Peng
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 M. Negi
RtBrick Inc
Q. Zhao
Etheric Networks
C. Zhou
HPE
July 2021
Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs
LSPの中央コントローラ（PCECC）としてPCEを使用するためのパス計算要素通信プロトコル（PCE）手順と拡張機能
Abstract
概要
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.
PATH計算要素（PCE）は、ソフトウェア定義ネットワーキング（SDN）システムのコアコンポーネントです。
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.
Central Controller（PCECC）としてのPCEは、SDNの要素とブレンドすることによって、必ずしも完全に交換することによって分散制御プレーンの処理を単純化することができる。したがって、ラベル交換経路（LSP）を計算/設定/開始し、ラベル転送エントリを、既存のPCEテクノロジをできるだけ活用しながら、経路に沿って集中PCEサーバを介してダウンロードすることもできる。
This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP.
このドキュメントは、静的LSPの経路に沿ってラベルをプロビジョニングするための中央コントローラとしてPCEを使用するための手順およびパス計算要素通信プロトコル（PCE）拡張子を指定します。
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/rfc9050.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9050で入手できます。
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. Terminology
2.1. Requirements Language
3. Basic PCECC Mode
4. PCEP Requirements
5. Procedures for Using the PCE as a Central Controller (PCECC)
5.1. Stateful PCE Model
5.2. New LSP Functions
5.3. New PCEP Object
5.4. PCECC Capability Advertisement
5.5. LSP Operations
5.5.1. PCE-Initiated PCECC LSP
5.5.2. PCC-Initiated PCECC LSP
5.5.3. Central Controller Instructions
5.5.3.1. Label Download CCI
5.5.3.2. Label Cleanup CCI
5.5.4. PCECC LSP Update
5.5.5. Re-delegation and Cleanup
5.5.6. Synchronization of Central Controller Instructions
5.5.7. PCECC LSP State Report
5.5.8. PCC-Based Allocations
6. PCEP Messages
6.1. The PCInitiate Message
6.2. The PCRpt Message
7. PCEP Objects
7.1. OPEN Object
7.1.1. PCECC Capability Sub-TLV
7.2. PATH-SETUP-TYPE TLV
7.3. CCI Object
7.3.1. Address TLVs
8. Security Considerations
8.1. Malicious PCE
8.2. Malicious PCC
9. Manageability Considerations
9.1. Control of Function and Policy
9.2. Information and Data Models
9.3. Liveness Detection and Monitoring
9.4. Verify Correct Operations
9.5. Requirements on Other Protocols
9.6. Impact on Network Operations
10. IANA Considerations
10.1. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
10.2. PCECC-CAPABILITY Sub-TLV's Flag Field
10.3. PCEP Path Setup Type Registry
10.4. PCEP Object
10.5. CCI Object Flag Field
10.6. PCEP-Error Object
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The Path Computation Element (PCE) [RFC4655] was developed to offload the path computation function from routers in an MPLS traffic-engineered (TE) network. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. Since then, the role and function of the PCE have grown to cover a number of other uses (such as GMPLS [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated use of network resources [RFC8281].
PATH計算要素（PCE）[RFC4655]は、MPLSトラフィックエンジニアリング（TE）ネットワーク内のルータからパス計算機能をオフロードするために開発されました。ネットワーク全体のトラフィックの最適なパスを計算でき、ネットワークまたはトラフィックの要求の変更を反映するようにパスを更新することもできます。それ以来、PCEの役割と機能は、他の多くの用途（GMPLS [RFC7025]など）をカバーし、委任管理[RFC8231]とネットワークリソースのPCEが開始されています[RFC8281]。
According to [RFC7399], Software-Defined Networking (SDN) refers to a separation between the control elements and the forwarding components so that software running in a centralized system, called a controller, can act to program the devices in the network to behave in specific ways. A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place traffic flows within the network given knowledge of the availability of network resources, how other forwarding devices are programmed, and the way that other flows are routed. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system (including an SDN system) is presented in [RFC7491].
[RFC7399]によると、ソフトウェア定義ネットワーキング（SDN）は、制御要素と転送コンポーネントとの間の間隔を指して、コントローラと呼ばれる集中型システムで動作するソフトウェアが行動するように動作するように行動することができる。具体的な方法SDNアーキテクチャ内の必須要素は、ネットワークリソースの使用方法とデバイスのプログラム方法の方法を計画するコンポーネントです。このコンポーネントは、ネットワーク内のトラフィックフローをネットワーク内に配置するために特定の計算を実行すること、他の転送装置がどのようにプログラムされているか、および他のフローがルーティングされる方法を示すことができます。これはPCEの機能と目的、およびPCEがより広いネットワーク制御システム（SDNシステムを含む）に統合されている方法が[RFC7491]に表示されます。
In early PCE implementations, where the PCE was used to derive paths for MPLS Label Switched Paths (LSPs), paths were requested by network elements (known as Path Computation Clients (PCCs)), and the results of the path computations were supplied to network elements using the Path Computation Element Communication Protocol (PCEP) [RFC5440]. This protocol was later extended to allow a PCE to send unsolicited requests to the network for LSP establishment [RFC8281].
PCEがMPLSラベルスイッチ付きパス（LSP）のパスを導出するために使用された初期のPCE実装では、パスはネットワーク要素（PATH計算クライアント（PCC）として知られている）によって要求され、パス計算の結果がネットワークに供給されました。パス計算要素通信プロトコル（PCEP）[RFC5440]を使用する要素。このプロトコルは後でPCEがLSP確立のためのネットワークに迷惑な要求を送信できるように拡張されました[RFC8281]。
The PCE was developed to derive paths for MPLS LSPs, which are supplied to the head end of the LSP using the PCEP. But SDN has a broader applicability than signaled MPLS and GMPLS TE networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
PCEは、PCEPを使用してLSPのヘッドエンドに供給されるMPLS LSPの経路を導出するために開発されました。しかし、SDNはシグナリングされたMPLSおよびGMPLS TEネットワークよりも幅広い適用可能性を持ち、PCEを使用して使用範囲内のパスを決定することができます。PCEは、PCEを中央コントローラとして完全に有効にすることを可能にするために、これらの環境で使用するための制御プロトコルとして提案されています。
[RFC8283] introduces the architecture for the PCE as a central controller as an extension to the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between the PCE and PCC. [RFC8283] further examines the motivations and applicability for PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol. [PCECC] describes the use cases for the PCECC architecture.
[RFC8283] PCEのアーキテクチャは、[RFC4655]に記載されているアーキテクチャの拡張として、PCEとPCCの間で使用されているプロトコルとしてPCEPの使用を継続していると仮定しています。[RFC8283] SouthBound Interface（SBI）としてのPCEPの動機と適用性をさらに調べ、プロトコルへの影響を紹介します。[PCECC] PCECCアーキテクチャのユースケースについて説明しています。
A PCECC can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LSP can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.
PCECCは、SDNの要素とブレンドすることによって、必ずしも完全に交換することによって分散制御プレーンの処理を単純化することができる。したがって、LSPを計算/設定/開始/開始し、ラベル転送エントリを、既存のPCEテクノロジをできるだけ少なくしながら、経路に沿って集中PCEサーバを介してダウンロードすることもできます。
This document specifies the procedures and PCEP extensions for using the PCE as the central controller for static LSPs, where LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCE-based controller keeps a view of the network and determines the paths of the end-to-end LSPs, and the controller uses PCEP to communicate with each router along the path of the end-to-end LSP.
このドキュメントは、静的LSPの中央コントローラとしてPCEを使用するための手順とPCEP拡張機能を指定します。ここで、LSPは、エンドツーエンドパス上の各ホップでの明示的なラベル命令としてプロビジョニングできます。パスに沿った各ルータは、プログラムするラベル転送指示と予約するリソースを指示する必要があります。PCEベースのコントローラはネットワークのビューを保持し、エンドツーエンドLSPのパスを決定し、コントローラはPCEPを使用してエンドツーエンドLSPのパスに沿って各ルータと通信します。
While this document is focused on the procedures for the static LSPs (referred to as the basic PCECC mode in Section 3), the mechanisms and protocol encodings are specified in such a way that extensions for other use cases are easy to achieve. For example, the extensions for the PCECC for Segment Routing (SR) are specified in [PCECC-SR] and [PCECC-SRv6].
この文書は静的LSPの手順（セクション3の基本PCECCモードと呼ばれる）に焦点を当てていますが、他のユースケースの拡張が簡単な方法でメカニズムとプロトコルエンコードが指定されています。たとえば、[PCECC-SR]と[PCECC-SRV6]では、PCECCの拡張（SR）が指定されています。
The terminology used in this document is the same as that described in the [RFC8283].
この文書で使用されている用語は[RFC8283]に記載されているものと同じです。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
In this mode, LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP.
このモードでは、LSPはエンドツーエンドパス上の各ホップで明示的なラベル命令としてプロビジョニングされています。パスに沿った各ルータは、プログラムするラベル転送指示と予約するリソースを指示する必要があります。コントローラは、PCEPを使用して、エンドツーエンドLSPのパスに沿って各ルータと通信します。
[RFC8283] examines the motivations and applicability for the PCECC and use of PCEP as an SBI. Section 3.1.2 of [RFC8283] highlights the use of the PCECC for label allocation along the static LSPs, and it simplifies the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This allows the operator to introduce the advantages of SDN (such as programmability) into the network. Further, Section 3.3 of [PCECC] describes some of the scenarios where the PCECC technique could be useful. Section 4 of [RFC8283] also describes the implications on the protocol when used as an SDN SBI. The operator needs to evaluate the advantages offered by the PCECC against the operational and scalability needs of the PCECC.
[RFC8283] SBIとしてのPCECCの動機と適用性を調べます。[RFC8283]のセクション3.1.2は、スタティックLSPに沿ったラベル割り当てのためのPCECCの使用を強調し、それをSDNの要素とブレンドすることによって分散制御プレーンの処理を簡素化します。必ずしも完全に交換します。これにより、オペレータはネットワークへのSDN（プログラマビリティなど）の利点を導入することができます。さらに、[PCECC]のセクション3.3は、PCECC技術が役立つ可能性があるいくつかのシナリオを説明しています。[RFC8283]のセクション4は、SDN SBIとして使用された場合のプロトコルの意味も説明しています。オペレータは、PCECCの運用上のニーズとスケーラビリティのニーズに比べてPCECCが提供する利点を評価する必要があります。
As per Section 3.1.2 of [RFC8283], the PCE-based controller will take responsibility for managing some part of the MPLS label space for each of the routers that it controls and may take wider responsibility for partitioning the label space for each router and allocating different parts for different uses. The PCC MUST NOT make allocations from the label space set aside for the PCE to avoid overlap and collisions of label allocations. It is RECOMMENDED that the PCE makes allocations (from the label space set aside for the PCE) for all nodes along the path. For the purpose of this document, it is assumed that the exclusive label range to be used by a PCE is known and set on both PCEP peers. A future extension could add the capability to advertise this range via a possible PCEP extension as well (see [PCE-ID]). The rest of the processing is similar to the existing stateful PCE mechanism.
[RFC8283]のセクション3.1.2に従って、PCEベースのコントローラは、それが制御する各ルータのMPLSラベルスペースの一部を管理する責任を負い、ルータごとにラベルスペースを分割することに対してより広い責任を負う可能性があります。さまざまな用途に異なる部品を割り当てる。PCCは、Label Allocationsのオーバーラップと衝突を回避するために、PCEのラベルスペースから割り当てを設定してはなりません。パスに沿ったすべてのノードについて、PCEが（PCEの場合はPCEの場合はラベルスペースから）割り当てを行うことをお勧めします。この文書の目的のために、PCEによって使用される排他的なラベル範囲が知られており、両方のPCEPピアに設定されていると仮定する。将来の拡張は、可能なPCEP拡張によってもこの範囲をアドバタイズする機能を追加する可能性があります（[PCE-ID]を参照）。処理の残りの部分は既存のステートフルPCEメカニズムと似ています。
This document also allows a case where the label space is maintained by the PCC and the labels are allocated by it. In this case, the PCE should request the allocation from the PCC, as described in Section 5.5.8.
この文書では、ラベルスペースがPCCによって維持され、ラベルがそれによって割り当てられる場合もあります。この場合、セクション5.5.8で説明されているように、PCEはPCCから割り当てを要求する必要があります。
The following key requirements should be considered when designing the PCECC-based solution:
PCECCベースのソリューションを設計するときは、次の主要な要件を考慮する必要があります。
1. A PCEP speaker supporting this document needs to have the capability to advertise its PCECC capability to its peers.
1. この文書をサポートするPCEPスピーカーは、PCECC機能をそのピアにアドバタイズする機能を持つ必要があります。
2. A PCEP speaker needs means to identify PCECC-based LSPs in the PCEP messages.
2. PCEPスピーカーは、PCEPメッセージ内のPCECCベースのLSPを識別するための手段を必要とします。
3. PCEP procedures need to allow for PCC-based label allocations.
3. PCEPプロシージャは、PCCベースのラベル割り当てを許可する必要があります。
4. PCEP procedures need to provide a means to update (or clean up) label entries downloaded to the PCC.
4. PCEPプロシージャは、PCCにダウンロードされたラベルエントリを更新（またはクリーンアップ）するための手段を提供する必要があります。
5. PCEP procedures need to provide a means to synchronize the labels between the PCE and the PCC via PCEP messages.
5. PCEPプロシージャは、PCEPメッセージを介してPCEとPCCとの間のラベルを同期させるための手段を提供する必要があります。
Active stateful PCE is described in [RFC8231]. A PCE as a Central Controller (PCECC) reuses the existing active stateful PCE mechanism as much as possible to control LSPs.
アクティブステートフルPCEは[RFC8231]に記載されています。Central Controller（PCECC）としてのPCEは、LSPを制御するためにできるだけ既存のアクティブなステートフルPCEメカニズムを再利用します。
Several new functions are required in PCEP to support the PCECC. This document extends the existing messages to support the new functions required by the PCECC:
PCECをサポートするには、PCEPにいくつかの新しい機能が必要です。このドキュメントは既存のメッセージを拡張してPCECCに必要な新しい機能をサポートします。
PCInitiate: A PCEP message described in [RFC8281]. A PCInitiate message is used to set up a PCE-initiated LSP based on a PCECC mechanism. It is also extended for Central Controller Instructions (CCI) (download or clean up the label-forwarding instructions in the context of this document) on all nodes along the path, as described in Section 6.1.
pcinitiate：[RFC8281]に記載されているPCEPメッセージ。PCINITIATEメッセージは、PCECCメカニズムに基づいてPCE開始LSPを設定するために使用されます。セクション6.1で説明されているように、パスに沿ったすべてのノードで中央コントローラの命令（CCI）（この文書のコンテキストのラベル転送手順をダウンロードまたはクリーンアップする）にも拡張されています。
PCRpt: A PCEP message described in [RFC8231]. A PCRpt message is used to send the PCECC LSP Reports. It is also extended to report the set of CCI (label-forwarding instructions in the context of this document) received from the PCE, as described in Section 6.2. Section 5.5.6 describes the use of a PCRpt message during synchronization.
PCRPT：[RFC8231]に記載されているPCEPメッセージ。PCRPTメッセージは、PCECC LSPレポートを送信するために使用されます。また、セクション6.2に記載されているように、PCEから受信したCCIのセット（この文書のコンテキスト内のラベル転送手順）を報告するように拡張されています。セクション5.5.6は、同期中のPCRPTメッセージの使用を説明しています。
PCUpd: A PCEP message described in [RFC8231]. A PCUpd message is used to send the PCECC LSP Updates.
pcupd：[RFC8231]に記載されているPCEPメッセージ。PCUPDメッセージは、PCECC LSP更新を送信するために使用されます。
The new functions defined in this document are mapped onto the PCEP messages, as shown in Table 1.
この文書で定義されている新しい機能は、表1に示すように、PCEPメッセージにマッピングされます。
+================================+============+
| Function | Message |
+================================+============+
| PCECC Capability advertisement | Open |
+--------------------------------+------------+
| Label entry Add | PCInitiate |
+--------------------------------+------------+
| Label entry Clean up | PCInitiate |
+--------------------------------+------------+
| PCECC-Initiated LSP | PCInitiate |
+--------------------------------+------------+
| PCECC LSP Update | PCUpd |
+--------------------------------+------------+
| PCECC LSP State Report | PCRpt |
+--------------------------------+------------+
| PCECC LSP Delegation | PCRpt |
+--------------------------------+------------+
| PCECC Label Report | PCRpt |
+--------------------------------+------------+
Table 1: Functions Mapped to the PCEP Messages
表1：PCEPメッセージにマッピングされた機能
This document defines a new PCEP object called CCI (Section 7.3) to specify the Central Controller Instructions. In the scope of this document, this is limited to label-forwarding instructions. Future documents can create new CCI object-types for other types of Central Controller Instructions. The CC-ID is the unique identifier for the CCI in PCEP. The PCEP messages are extended in this document to handle the PCECC operations.
このドキュメントは、CCI（7.3）という新しいPCEPオブジェクトを定義して、中央コントローラの命令を指定します。この文書の範囲では、これはラベル転送指示に限定されています。将来の文書は、他のタイプの中央コントローラの指示に新しいCCIオブジェクトタイプを作成できます。CC-IDは、PCEPのCCIの固有の識別子です。PCEPメッセージはこのドキュメントでPCECC操作を処理するために拡張されます。
During the PCEP initialization phase, PCEP speakers (PCE or PCC) advertise their support of and willingness to use PCEP extensions for the PCECC using these elements in the OPEN message:
PCEP初期化フェーズの間、PCEPスピーカー（PCEまたはPCC）は、Openメッセージ内のこれらの要素を使用してPCECCのPCEP拡張機能を使用する意思のサポートを宣伝します。
* a new Path Setup Type (PST) (Section 7.2) in the PATH-SETUP-TYPE-CAPABILITY TLV to indicate support for PCEP extensions for the PCECC - 2 (Traffic engineering path is set up using PCECC mode)
* pcecc - 2のPCEP拡張のサポートを示すためのpath-setup-type-capability TLVの新しいパス設定タイプ（PST）（セクション7.2）（PCECCモードではトラフィックエンジニアリングパスが設定されています）
* a new PCECC-CAPABILITY sub-TLV (Section 7.1.1) with the L bit set to '1' inside the PATH-SETUP-TYPE-CAPABILITY TLV to indicate a willingness to use PCEP extensions for the PCECC-based Central Controller Instructions for label download
* PCECCベースの中央コントローラの命令のPCEP拡張機能を使用する意思を示すために、LビットがPAT-SETUP型機能機能TLVの内側にLビットが '1'に設定された新しいPCECC機能サブTLV（セクション7.1.1）ラベルのダウンロード
* the STATEFUL-PCE-CAPABILITY TLV [RFC8231] (with the I flag set [RFC8281])
* ステートフルPCE機能TLV [RFC8231]（Iフラグを設定した[RFC8281]）
The new PST is to be listed in the PATH-SETUP-TYPE-CAPABILITY TLV by all PCEP speakers that support the PCEP extensions for the PCECC in this document.
新しいPSTは、このドキュメントのPCECCのPCEP拡張機能をサポートするすべてのPCEPスピーカーによって、PATH-SETUP型機能TLVにリストされます。
The new PCECC-CAPABILITY sub-TLV is included in the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object to indicate a willingness to use the PCEP extensions for the PCECC during the established PCEP session. Using the L bit in this TLV, the PCE shows the intention to function as a PCECC server, and the PCC shows a willingness to act as a PCECC client for label download instructions (see Section 7.1.1).
新しいPCECC機能サブTLVは、開いているオブジェクト内のpath-setup-type-capability TLVに含まれています。このTLVのLビットの使用このTLVでは、PCEはPCECCサーバーとして機能する意図を示し、PCCはラベルのダウンロード手順のためのPCECCクライアントとして機能する意思を示します（セクション7.1.1を参照）。
If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE-CAPABILITY TLV is not advertised, or is advertised without the I flag set, in the OPEN object, the receiver MUST:
PCECC機能サブTLVがアドバタイズされ、ステートフルPCE機能TLVがアドバタイズされていない場合、またはIフラグセットなしでアドバタイズされている場合、Openオブジェクトでは、受信者は次のことを行わなければなりません。
* send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=17 (Stateful PCE capability was not advertised) and
* PCRRメッセージをERROR-TYPE = 19（無効な操作）とエラー値= 17（ステートフルPCE機能が宣伝されていません）
* terminate the session.
* セッションを終了します。
If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with the PCECC PST but without the PCECC-CAPABILITY sub-TLV, it MUST:
PCEPスピーカーがPCECC PSTを使用してPCECC PSTを使用してPATEC-SETUP型機能TLVを受信した場合は、次のことが必要です。
* send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=33 (Missing PCECC Capability sub-TLV) and
* PCRRメッセージをERROR-TYPE = 10（無効なオブジェクトの受信）とエラー値= 33（PCECC機能サブTLVを見つかりません）
* terminate the PCEP session.
* PCEPセッションを終了します。
The PCECC-CAPABILITY sub-TLV MUST NOT be used without the corresponding PST being listed in the PATH-SETUP-TYPE-CAPABILITY TLV. If it is present without the corresponding PST listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be ignored.
PCECC機能サブTLVは、パス設定型機能TLVにリストされている対応するPSTがリストされていない必要があります。PATH-SETUP型機能のTLVに対応するPSTが表示されていない場合は、無視する必要があります。
If one or both speakers (PCE and PCC) have not indicated support and willingness to use the PCEP extensions for the PCECC, the PCEP extensions for the PCECC MUST NOT be used. If a PCECC operation is attempted when both speakers have not agreed in the OPEN messages, the receiver of the message MUST:
PCECCのPCEP拡張機能を使用すると、スピーカー（PCEとPCC）の両方がサポートと意欲を示していない場合は、PCECCのPCEP拡張機能を使用してはいけません。両方のスピーカーが開いているメッセージで合意されていないときにPCECC操作が試行された場合、メッセージの受信者は次のようにしてください。
* send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=16 (Attempted PCECC operations when PCECC capability was not advertised) and
* PCRRメッセージをERROR-TYPE = 19（無効な操作）とerror-value = 16（PCECC機能が宣伝されていない場合のPCECC操作を試みた）
* terminate the PCEP session.
* PCEPセッションを終了します。
A legacy PCEP speaker (that does not recognize the PCECC Capability sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and [RFC5440]. As per [RFC8408], the legacy PCEP speaker, on receipt of an unsupported PST in a Request Parameter (RP) / Stateful PCE Request Parameter (SRP) object, will:
レガシーPCEPスピーカー（PCECC機能サブTLVを認識しない）は、[RFC8408]と[RFC5440]に従ってサブTLVを無視します。[RFC8408]、レガシーPCEPスピーカーは、要求パラメータ（RP）/ステートフルPCE要求パラメータ（SRP）オブジェクトでサポートされていないPSTを受信したときに、次のようになります。
* send a PCErr message with Error-Type=21 (Invalid traffic engineering path setup type) and Error-value=1 (Unsupported path setup type) and
* PCerrメッセージをERROR-TYPE = 21（無効なトラフィックエンジニアリングパス設定タイプ）とエラー値= 1（サポートされていないパス設定タイプ）と
* terminate the PCEP session.
* PCEPセッションを終了します。
The PCEP messages pertaining to a PCECC MUST include the PATH-SETUP-TYPE TLV [RFC8408] in the SRP object [RFC8231] with the PST set to '2' to clearly identify that the PCECC LSP is intended.
PCECCに関するPCEPメッセージは、PSTが「2」に設定されているSRPオブジェクト[RFC8231]のPATH-SETUP型TLV [RFC8408]を、PSTECC LSPが意図されていることを明確に識別する必要があります。
The LSP instantiation operation is defined in [RFC8281]. In order to set up a PCE-initiated LSP based on the PCECC mechanism, a PCE sends a PCInitiate message with the PST set to '2' for the PCECC (see Section 7.2) to the ingress PCC.
LSPインスタンス化操作は[RFC8281]で定義されています。PCECCメカニズムに基づいてPCE開始LSPを設定するために、PCEはPCECCのPSTセットをPSTセットと入力PCC（セクション7.2を参照）に送信します。
The label-forwarding instructions (see Section 5.5.3) from the PCECC are sent after the initial PCInitiate and PCRpt message exchange with the ingress PCC, as per [RFC8281] (see Figure 1). This is done so that the PCEP-specific identifier for the LSP (PLSP-ID) and other LSP identifiers can be obtained from the ingress and can be included in the label-forwarding instruction in the next set of PCInitiate messages along the path, as described below.
PCECCのラベル転送手順（5.5.3節参照）は、[RFC8281]と同様に、入力PCCとの最初のPCINITIATEおよびPCRPTメッセージ交換の後に送信されます（図1を参照）。これは、LSP（PLSP-ID）および他のLSP識別子のPCEP固有の識別子を入力から取得することができ、パスに沿って次のPCInitiateメッセージのセット内のラベル転送命令に含めることができるように行われます。以下で説明します。
An LSP-IDENTIFIERS TLV [RFC8231] MUST be included for the PCECC LSPs; it uniquely identifies the LSP in the network. Note that the fields in the LSP-IDENTIFIERS TLV are described for the RSVP-signaled LSPs but are applicable to the PCECC LSP as well. The LSP object is included in the CCI (label download Section 7.3) to identify the PCECC LSP for this instruction. The PLSP-ID is the original identifier used by the ingress PCC, so a transit/egress Label Switching Router (LSR) could have multiple Central Controller Instructions that have the same PLSP-ID. The PLSP-ID in combination with the source (in the LSP-IDENTIFIERS TLV) MUST be unique. The PLSP-ID is included for maintainability reasons to ease debugging. As per [RFC8281], the LSP object could also include the SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these instructions. Also, the CC-ID is unique in each PCEP session, as described in Section 7.3.
PCECC LSPには、LSP識別子TLV [RFC8231]を含める必要があります。ネットワーク内のLSPを一意に識別します。LSP識別子TLV内のフィールドは、RSVPシグナリングLSPについて説明されているが、PCECC LSPにも適用可能であることに注意してください。LSPオブジェクトは、この命令のPCECC LSPを識別するためにCCI（ラベルダウンロードセクション7.3）に含まれています。PLSP-IDは、入力PCCによって使用されるオリジナルの識別子であるため、Transit / Egress Label Switching Router（LSR）は同じPLSP-IDを持つ複数の中央コントローラの命令を持つことができます。SOURCEと組み合わせたPLSP-ID（LSP識別子TLV）は一意である必要があります。PLSP-IDは、デバッグを簡単にするためのメンテナンス性の理由から含まれています。[RFC8281]によると、LSPオブジェクトは、これらの命令を開始したPCEを識別するためのSpeaker-Entity-ID TLVを含み得る。また、CC-IDは、セクション7.3で説明されているように、各PCEPセッションで固有のものです。
On receipt of a PCInitiate message for the PCECC LSP, the PCC responds with a PCRpt message with the status set to 'Going-up' and carrying the assigned PLSP-ID (see Figure 1). The ingress PCC also sets the D (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) in the LSP object. When the PCE receives this PCRpt message with the PLSP-ID, it assigns labels along the path and sets up the path by sending a PCInitiate message to each node along the path of the LSP, as per the PCECC technique. The CC-ID uniquely identifies the Central Controller Instructions within a PCEP session. Each node along the path (PCC) responds with a PCRpt message to acknowledge the CCI with the PCRpt messages including the CCI and LSP objects.
PCECC LSPのPCINITIATEメッセージを受信すると、PCCは、ステータスが「上昇」に設定され、割り当てられたPLSP-IDを持ち運ぶことでPCRPTメッセージで応答します（図1を参照）。Ingress PCCは、LSPオブジェクトのD（Delegate）フラグ（[RFC8231]参照）とC（RFC8231]を参照）（[RFC8281]を参照）を設定します。PCEがPLSP-IDを使用してこのPCRPTメッセージを受信すると、PCECCテクニックに従って、パスに沿ってラベルを割り当て、LSPのパスに沿ってPCInitiateメッセージを送信することによってパスを設定します。CC-IDは、PCEPセッション内の中央コントローラの命令を一意に識別します。パス（PCC）に沿った各ノードは、CCIオブジェクトとLSPオブジェクトを含むPCRPTメッセージを使用してCCIを確認するためのPCRPTメッセージで応答します。
The ingress node would receive one CCI object with the O bit (out-label) set. The transit node(s) would receive two CCI objects with the in-label CCI without the O bit set and the out-label CCI with the O bit set. The egress node would receive one CCI object without the O bit set (see Figure 1). A node can determine its role based on the setting of the O bit in the CCI object(s) and the LSP-IDENTIFIERS TLV in the LSP object.
入力ノードは、Oビット（OUT-LABEL）セットを使用して1つのCCIオブジェクトを受信します。トランジットノードは、Oビットセットを指定せずに、OUT-LABEL CCIがOビットセットされていないCCIを持つ2つのCCIオブジェクトを受信します。出口ノードは、Oビットセットなしで1つのCCIオブジェクトを受信します（図1を参照）。ノードは、CCIオブジェクト内のOビットの設定とLSPオブジェクトのLSP-ID TLVの設定に基づいてその役割を決定できます。
The LSP deletion operation for the PCE-initiated PCECC LSP is the same as defined in [RFC8281]. The PCE should further perform the label entry cleanup operation, as described in Section 5.5.3.2, for the corresponding LSP.
PCE開始PCECC LSPのLSP削除操作は[RFC8281]で定義されているものと同じです。対応するLSPについては、セクション5.5.3.2で説明されているように、PCEはさらにラベル入力クリーンアップ動作を実行する必要があります。
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=2---------| PCECC LSP
|PCC +--------+ | | Initiate
|egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP
+--------+ | | (GOING-UP) |
| | | |
|<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label
| | | | download
|--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI
| | | |
| |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label
| | | | download
| |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI
| | | |
| | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label
| | | | download
| | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI
| | | |
| | |<---PCUpd,PLSP-ID=2,PST=2,D=1---------| PCECC LSP
| | | (UP) | Update
| | |----PCRpt,PLSP-ID=2,D=1,C=1---------->|
| | | (UP) |
Figure 1: PCE-Initiated PCECC LSP
図1：PCE開始PCECC LSP
Once the label operations are completed, the PCE MUST send a PCUpd message to the ingress PCC. As per [RFC8231], the PCUpd message is with the D flag set.
ラベル操作が完了すると、PCEはPCUPDメッセージを入力PCCに送信する必要があります。[RFC8231]によると、PCUPDメッセージはDフラグセットを含むものです。
The PCECC LSPs are considered to be 'up' by default (on receipt of a PCUpd message from the PCE). The ingress could further choose to deploy a data-plane check mechanism and report the status back to the PCE via a PCRpt message to make sure that the correct label instructions are made along the path of the PCECC LSP (and it is ready to carry traffic). The exact mechanism is out of scope of this document.
PCECC LSPは、デフォルトで「up」と見なされます（PCEからPCUPDメッセージの受信時に）。入力は、データプレーンチェックメカニズムをデプロイし、正しいラベル命令がPCECC LSPのパスに沿って行われていることを確認するために、PCRPTメッセージを介してPCEにステータスを報告することを選択できます（そしてトラフィックを運送する準備ができている準備ができている）。）。正確なメカニズムはこの文書の範囲外です。
In the case where the label allocations are made by the PCC itself (see Section 5.5.8), the PCE could request an allocation to be made by the PCC; then, the PCC would send a PCRpt message with the allocated label encoded in the CC-ID object (as shown in Figure 2) in the configuration sequence from the egress towards the ingress along the path.
ラベル割り当てがPCC自体によって行われる場合（セクション5.5.8を参照）、PCEはPCCによって行われるべき割り当てを要求することができる。次に、PCCは、パスに沿って出力からの設定シーケンスにあるCC-IDオブジェクトにエンコードされた割り当てられたラベルを（図2に示すように）符号化されたPCRPTメッセージを出力に沿って出力されます。
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=2,--------| PCECC LSP
|PCC +--------+ | | Initiate
|egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP
+--------+ | | (GOING-UP) |
| | | |
|<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label
| | | C=1,O=0 | download
|--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI
| | | Label=L1 |
| |<------PCInitiate,PLSP-ID=2,----------------| Labels
| | | CC-ID=Y1,C=1,O=0 | download
| | | CC-ID=Y2,C=0,O=1,L1 | CCI
| |-------PCRpt,PLSP-ID=2--------------------->|
| | | CC-ID=Y1,O=0,Label=L2 |
| | | CC-ID=Y2,O=1 |
| | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label
| | | C=0,O=1,L2 | download
| | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI
| | | |
| | |<---PCUpd,PLSP-ID=2,PST=2,D=1---------| PCECC LSP
| | | (UP) | Update
Figure 2: PCE-Initiated PCECC LSP (PCC Allocation)
図2：PCE開始PCECC LSP（PCC割り当て）
In this example, it should be noted that the request is made to the egress node with the C bit set in the CCI object to indicate that the label allocation needs to be done by the egress, and the egress responds with the allocated label to the PCE. The PCE further informs the transit PCC without setting the C bit to '1' in the CCI object for the out-label, but the C bit is set to '1' for the in-label, so the transit node makes the label allocation (for the in-label) and reports to the PCE. Similarly, the C bit is unset towards the ingress to complete all the label allocations for the PCECC LSP.
この例では、ラベル割り当てが出力によって行われる必要があることを示すために、CCIオブジェクトに設定されたCビットがセットされた出力ノードに要求が行われ、出力は割り当てられたラベルで応答することに留意されたい。PCE。PCEは、Out-LabelのCCIオブジェクトのCビットを '1'に設定せずにTransit PCCをさらに通知しますが、Cビットはラベルの場合は '1'に設定されているため、トランジットノードはラベル割り当てを行います。（ラベル内）とPCEに報告します。同様に、Cビットは、PCECC LSPのすべてのラベル割り当てを完了するために入力に停止されていません。
In order to set up an LSP based on the PCECC mechanism where the LSP is configured at the PCC, a PCC MUST delegate the LSP by sending a PCRpt message with the PST set for the PCECC (see Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP object (see Figure 3).
LSPがPCCで構成されているPCCCメカニズムに基づいてLSPを設定するには、PCCはPCRPTメッセージをPSTセットに送信してLSPを代表する必要があります（セクション7.2を参照）、D（Delegate）フラグを参照）LSPオブジェクトに設定した[RFC8231]を参照）（図3を参照）。
When a PCE receives the initial PCRpt message with the D flag and PST set to '2', it SHOULD calculate the path and assign labels along the path in addition to setting up the path by sending a PCInitiate message to each node along the path of the LSP, as per the PCECC technique (see Figure 3). The CC-ID uniquely identifies the CCI within a PCEP session. Each PCC further responds with the PCRpt messages, including the CCI and LSP objects.
PCEがDフラグとPSTを「2」に設定して初期PCRPTメッセージを受信すると、パスを設定し、パスを設定してパスを設定してパスを設定する必要があります。PCECC技術に従ってLSP（図3を参照）。CC-IDは、PCEPセッション内のCCIを一意に識別します。各PCCはさらにCCIオブジェクトとLSPオブジェクトを含むPCRPTメッセージで応答します。
Once the CCI (label operations) are completed, the PCE MUST send the PCUpd message to the ingress PCC. As per [RFC8231], this PCUpd message should include the path information calculated by the PCE.
CCI（ラベル操作）が完了すると、PCEはPCUPDメッセージを入力PCCに送信する必要があります。[RFC8231]によると、このPCUPDメッセージにはPCEによって計算されたパス情報を含める必要があります。
Note that the PCECC LSPs MUST be delegated to a PCE at all times.
PCECC LSPは常にPCEに委任されなければならないことに注意してください。
The LSP deletion operation for the PCECC LSPs is the same as defined in [RFC8231]. If the PCE receives a PCRpt message for LSP deletion, then it does label the cleanup operation, as described in Section 5.5.3.2, for the corresponding LSP.
PCECC LSPのLSP削除操作は[RFC8231]で定義されているものと同じです。PCEがLSP削除用のPCRPTメッセージを受信した場合、対応するLSPのセクション5.5.3.2で説明されているように、クリーンアップ操作にラベルを付けます。
The basic PCECC LSP setup sequence is as shown in Figure 3.
基本的なPCECC LSPセットアップシーケンスは図3に示す通りです。
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |---PCRpt,PLSP-ID=1,PST=2,D=1-------->| PCECC LSP
|PCC +--------+ | |
|egress | | | |
+--------+ | | |
| | | |
|<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label
| | | L1,O=0 | download
|--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI
| | | |
| |<------PCInitiate,PLSP-ID=1,---------------| Labels
| | | CC-ID=Y1,O=0,L2 | download
| | | CC-ID=Y2,O=1,L1 | CCI
| |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->|
| | | |
| | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label
| | | L2,O=1 | download
| | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI
| | | |
| | |<---PCUpd,PLSP-ID=1,PST=2,D=1--------| PCECC LSP
| | | | Update
| | | |
Figure 3: PCC-Initiated PCECC LSP
図3：PCC開始PCECC LSP
In the case where the label allocations are made by the PCC itself (see Section 5.5.8), the PCE could request an allocation to be made by the PCC; then, the PCC would send a PCRpt message with the allocated label encoded in the CC-ID object, as shown in Figure 4.
ラベル割り当てがPCC自体によって行われる場合（セクション5.5.8を参照）、PCEはPCCによって行われるべき割り当てを要求することができる。次に、PCCは、図4に示すように、CC-IDオブジェクトにエンコードされた割り当てラベルを含むPCRPTメッセージを送信します。
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |---PCRpt,PLSP-ID=1,PST=2,D=1-------->| PCECC LSP
|PCC +--------+ | |
|egress | | | |
+--------+ | | |
| | | |
|<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label
| | | C=1 | download
|--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI
| | | Label=L1 |
| |<------PCInitiate,PLSP-ID=1,---------------| Labels
| | | CC-ID=Y1,C=1 | download
| | | CC-ID=Y2,C=0,L1 | CCI
| |-------PCRpt,PLSP-ID=1-------------------->|
| | | CC-ID=Y1,Label=L2 |
| | | CC-ID=Y2 |
| | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label
| | | C=0,L2 | download
| | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI
| | | |
| | |<---PCUpd,PLSP-ID=1,PST=2,D=1--------| PCECC LSP
| | | | Update
| | | |
Figure 4: PCC-Initiated PCECC LSP (PCC Allocation)
図4：PCC開始PCECC LSP（PCC割り当て）
| Note:
|
| The O bit is set as before (and thus not included).
In the case where the label allocations are made by the PCC itself (see Section 5.5.8), the procedure remains the same, with just an additional constraint on the configuration sequence.
ラベル割り当てがPCC自体によって行われる場合（セクション5.5.8を参照）、この手順は同じままであり、構成シーケンスに対する追加の制約だけです。
The rest of the PCC-initiated PCECC LSP setup operations are the same as those described in Section 5.5.1.
PCC開始されたPCECC LSPセットアップ操作の残りの部分は、セクション5.5.1で説明されているものと同じです。
The new CCI for the label operations in PCEP are done via the PCInitiate message (Section 6.1) by defining a new PCEP object for CCI operations. The local label range of each PCC is assumed to be known by both the PCC and the PCE.
PCEPのラベル操作のための新しいCCIは、CCI操作用の新しいPCEPオブジェクトを定義することによってPCINITIATEメッセージ（6.1節）を介して行われます。各PCCのローカルラベル範囲は、PCCとPCEの両方によって知られていると見なされます。
In order to set up an LSP based on the PCECC, the PCE sends a PCInitiate message to each node along the path to download the label instructions, as described in Sections 5.5.1 and 5.5.2.
PCECCに基づいてLSPを設定するために、PCEは、5.5.1と5.5.2のセクションで説明されているように、PCEはパスに沿って各ノードにPCINITITATEメッセージを送信してラベル命令をダウンロードします。
The CCI object MUST be included, along with the LSP object in the PCInitiate message. The LSP-IDENTIFIERS TLV MUST be included in the LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP object.
CCIオブジェクトは、PCInitiateメッセージ内のLSPオブジェクトと共に含める必要があります。LSP識別子TLVはLSPオブジェクトに含める必要があります。Speaker-Entity-ID TLVはLSPオブジェクトに含める必要があります。
If a node (PCC) receives a PCInitiate message that includes a label to download (as part of CCI) that is out of the range set aside for the PCE, it MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=1 (Label out of range) and MUST include the SRP object to specify the error is for the corresponding label update via a PCInitiate message. If a PCC receives a PCInitiate message but fails to download the label entry, it MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=2 (Instruction failed) and MUST include the SRP object to specify the error is for the corresponding label update via a PCInitiate message.
ノード（PCC）がPCEの扱いを除いてダウンロードするラベルを（CCIの一部として）ダウンロードするPCINITIATEメッセージを受信した場合は、ERROR-TYPE = 31（PCECC障害）でPCERRメッセージを送信する必要があります。そしてerror-value = 1（範囲外のラベル）には、PCINITIATEメッセージを介した対応するラベル更新に対するエラーを指定するためのSRPオブジェクトを含める必要があります。PCCがPCINITIATEメッセージを受信したがラベルエントリをダウンロードできない場合は、Error-Type = 31（PCECC障害）とERROR-VALUE = 2（命令に失敗）を使用してPCERRメッセージを送信する必要があり、その指定にSRPオブジェクトを含める必要があります。エラーは、PCInitiateメッセージを介した対応するラベル更新のためのものです。
A new PCEP object for CCI is defined in Section 7.3.
CCI用の新しいPCEPオブジェクトはセクション7.3で定義されています。
In order to delete an LSP based on the PCECC, the PCE sends Central Controller Instructions via a PCInitiate message to each node along the path of the LSP to clean up the label-forwarding instruction.
PCECCに基づいてLSPを削除するために、PCEは、LSPの経路に沿ってPCInitiateメッセージを介して中央コントローラの命令をLSPのパスに沿って送信して、ラベル転送命令をクリーンアップします。
If the PCC receives a PCInitiate message but does not recognize the label in the CCI, the PCC MUST generate a PCErr message with Error-Type=19 (Invalid operation) and Error-value=18 (Unknown Label) and MUST include the SRP object to specify the error is for the corresponding label cleanup (via a PCInitiate message).
PCCがPCINITIATEメッセージを受信したが、CCI内のラベルを認識しない場合、PCCはERROR-TYPE = 19（無効な操作）およびERROR-VALUE = 18（不明なラベル）でPCERRメッセージを生成する必要があり、SRPオブジェクトを含める必要があります。エラーを指定するには、（PCInitiateメッセージを介して）対応するラベルクリーンアップ用です。
The R flag in the SRP object defined in [RFC8281] specifies the deletion of the label entry in the PCInitiate message.
[RFC8281]で定義されているSRPオブジェクト内のRフラグは、PCINITIATEメッセージ内のラベルエントリの削除を指定します。
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | | |
|PCC +--------+ | |
|egress | | | |
+--------+ | | |
| | | |
|<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label
| | | R=1 | cleanup
|--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI
| | | R=1 |
| |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label
| | | R=1 | cleanup
| |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI
| | | R=1 |
| | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label
| | | R=1 | cleanup
| | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI
| | | R=1 |
| | |<--PCInitiate,PLSP-ID=2,PST=2,R=1-----| PCECC LSP
| | | | remove
Figure 5: Label Cleanup
図5：ラベルクリーンアップ
As per [RFC8281], following the removal of the label-forwarding instruction, the PCC MUST send a PCRpt message. The SRP object in the PCRpt message MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R flag in the SRP object MUST be set.
ラベル転送命令の削除後、[RFC8281]に従って、PCRPTメッセージを送信する必要があります。PCRPTメッセージ内のSRPオブジェクトには、削除をトリガーしたPCINITIATEメッセージからSRP-ID番号を含める必要があります。SRPオブジェクトのRフラグを設定する必要があります。
In the case where the label allocation is made by the PCC itself (see Section 5.5.8), the removal procedure remains the same, adding the sequence constraint.
ラベル割り当てがPCC自体によって行われる場合（セクション5.5.8を参照）、除去手順は同じままで、シーケンス制約を追加します。
The update is done as per the make-before-break procedures, i.e., the PCECC first updates new label instructions based on the updated path and then informs the ingress to switch traffic before cleaning up the former instructions. New CC-IDs are used to identify the updated instructions; the identifiers in the LSP object uniquely identify the existing LSP. Once new instructions are downloaded, the PCE further updates the new path at the ingress, which triggers the traffic switch on the updated path. The ingress PCC acknowledges with a PCRpt message, on receipt of the PCRpt message, the PCE does the cleanup operation for the former LSP, as described in Section 5.5.3.2.
更新は、Break前回の手順、すなわちPCECCが更新されたパスに基づいて新しいラベル命令を更新し、以前の指示を整える前にトラフィックを切り替えるように入力を通知する。更新された指示を識別するために新しいCC-IDが使用されます。LSPオブジェクトの識別子は既存のLSPを一意に識別します。新しい命令がダウンロードされると、PCEはさらに新しいパスを更新します。これにより、更新されたパスのトラフィックスイッチがトリガされます。入力PCCは、PCRPTメッセージを受信して、PCEは、セクション5.5.3.2で説明されているように、PCEは前のLSPのクリーンアップ動作を行います。
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | | |
|PCC +--------+ | |
|egress | | | |
+--------+ | | |
| | | | New Path
|<------ PCInitiate,CC-ID=XX,PLSP-ID=1 -------------| for LSP
| | | | trigger
|--------PCRpt,CC-ID=XX,PLSP-ID=1------------------>| new CCI
| | | |
| |<------PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label
| | | | download
| |-------PCRpt,CC-ID=YY1,YY2,PLSP-ID=1------>| CCI
| | | |
| | |<----PCInitiate,CC-ID=ZZ,PLSP-ID=1---| Label
| | | | download
| | |-----PCRpt,CC-ID=ZZ,PLSP-ID=1------->| CCI
| | | |
| | |<---PCUpd,PLSP-ID=1,PST=2,D=1--------| PCECC
| | | SRP=S | LSP Update
| | | |
| | |---PCRpt,PLSP-ID=1,PST=2,D=1-------->| Trigger
| | | (SRP=S) | Delete
| | | | former CCI
| | | |
|<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label
| | | R=1 | cleanup
|--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI
| | | R=1 |
| |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1----| Label
| | | R=1 | cleanup
| |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| CCI
| | | R=1 |
| | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label
| | | R=1 | cleanup
| | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI
| | | R=1 |
Figure 6: PCECC LSP Update
図6：PCECC LSP更新
The modified PCECC LSPs are considered to be 'up' by default. The ingress could further choose to deploy a data-plane check mechanism and report the status back to the PCE via a PCRpt message. The exact mechanism is out of scope of this document.
修正されたPCECC LSPは、デフォルトで「上」と見なされます。入力はさらにデータプレーンチェックメカニズムを展開し、PCRPTメッセージを介してステータスをPCEに報告することができます。正確なメカニズムはこの文書の範囲外です。
In the case where the label allocations are made by the PCC itself (see Section 5.5.8), the procedure remains the same.
ラベル割り当てがPCC自体によって行われる場合（セクション5.5.8を参照）、この手順は同じままです。
As described in [RFC8281], a new PCE can gain control over an orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain control over the CCI in the same way by sending a PCInitiate message that includes the SRP, LSP, and CCI objects and carries the CC-ID and PLSP-ID identifying the instructions that it wants to take control of.
[RFC8281]に記載されているように、新しいPCEは孤立したLSPを制御することができます。PCECC LSPの場合、SRP、LSP、およびCCIオブジェクトを含むPCInitiateメッセージを送信し、命令を識別するCC-IDとPLSP-IDを伝送することで、新しいPCEが同じ方法でCCIを制御する必要があります。それが管理したいこと。
Further, as described in [RFC8281], the State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. Similarly the Central Controller Instructions are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC MUST support the removal of CCI as one of the behaviors applied on expiration of the State Timeout Interval timer.
また、[RFC8281]に記載されているように、状態タイムアウト間隔タイマは、PCEが開始されたLSPを使用しているサービスに対してPCEクラッシュが自動的および即時の混乱を招くことを保証します。同様に、中央コントローラの命令はPCE障害直後には削除されません。代わりに、それらはこのタイマーの満了にクリーンアップされます。これにより、手動の介入なしのネットワーククリーンアップが可能になります。PCCは、状態タイムアウト間隔タイマの有効期限に適用される動作の1つとしてCCIの削除をサポートしなければなりません。
In the case of the PCC-initiated PCECC LSP, the control over the orphaned LSP at the ingress PCC is taken over by the mechanism specified in [RFC8741] to request delegation. The control over the CCI is described above using [RFC8281].
PCC開始PCECC LSPの場合、入力PCCの孤立したLSPの制御は[RFC8741]で指定されたメカニズムによって引き継がれて委任を要求します。CCIの制御は、[RFC8281]を使用して上で説明されています。
The purpose of CCI synchronization (labels in the context of this document) is to make sure that the PCE's view of CCI (labels) matches with the PCC's label allocation. This synchronization is performed as part of the LSP State Synchronization, as described in [RFC8231] and [RFC8232].
CCI同期の目的（この文書のコンテキスト内のラベル）は、PCEのCCI（Labels）のビューがPCCのラベル割り当てと一致することを確認することです。この同期は、[RFC8231]と[RFC8232]で説明されているように、LSP状態の同期の一部として実行されます。
As per LSP State Synchronization [RFC8231], a PCC reports the state of its LSPs to the PCE using PCRpt messages and, as per [RFC8281], the PCE would initiate any missing LSPs and/or remove any LSPs that are not wanted. The same PCEP messages and procedures are also used for the CCI synchronization. The PCRpt message includes the CCI and the LSP object to report the label-forwarding instructions. The PCE would further remove any unwanted instructions or initiate any missing instructions.
LSP状態の同期（RFC8231]によると、PCCはPCRPTメッセージを使用してそのLSPの状態をPCEに報告し、[RFC8281]に従って、PCEは不足しているLSPを開始し、必要ではないLSPを削除します。CCI同期にも同じPCEPメッセージと手順が使用されます。PCRPTメッセージには、ラベル転送命令を報告するためのCCIとLSPオブジェクトが含まれています。PCEはさらに不要な指示を削除したり、欠けている指示を開始します。
As mentioned before, an ingress PCC MAY choose to apply any Operations, Administration, and Maintenance (OAM) mechanism to check the status of the LSP in the data plane and MAY further send its status in a PCRpt message to the PCE.
前述のように、入力PCCは、データプレーン内のLSPの状態を確認するために、すべての操作、管理、およびメンテナンス（OAM）メカニズムを適用することを選択し、さらにPCRPTメッセージでそのステータスをPCEに送信することができます。
The PCE can request the PCC to allocate the label using the PCInitiate message. The C flag in the CCI object is set to '1' to indicate that the allocation needs to be made by the PCC. The PCC MUST try to allocate the label and MUST report to the PCE via a PCRpt or PCErr message.
PCEは、PCCにPCInitiateメッセージを使用してラベルを割り当てるように要求できます。CCIオブジェクトのCフラグは、PCCによって行われる必要があることを示すために「1」に設定されています。PCCはラベルを割り当てて、PCRPTまたはPCERRメッセージを介してPCEに報告する必要があります。
If the value of the label is 0 and the C flag is set to '1', it indicates that the PCE is requesting the allocation to be made by the PCC. If the label is 'n' and the C flag is set to '1' in the CCI object, it indicates that the PCE requests a specific value 'n' for the label. If the allocation is successful, the PCC MUST report via the PCRpt message with the CCI object. If the value of the label in the CCI object is invalid, it MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=3 (Invalid CCI). If it is valid but the PCC is unable to allocate it, it MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=4 (Unable to allocate the specified CCI).
ラベルの値が0で、Cフラグが '1'に設定されている場合、PCEがPCCによって行われるべき割り当てを要求していることを示します。ラベルが「N」で、CフラグがCCIオブジェクトで「1」に設定されている場合、PCEがラベルに特定の値 'n'を要求することを示します。割り当てが成功した場合、PCCはPCRPTメッセージを介してCCIオブジェクトを通知する必要があります。CCIオブジェクト内のラベルの値が無効な場合は、ERROR-TYPE = 31（PCECC障害）とERROR-VALUE = 3（無効なCCI）でPCERRメッセージを送信する必要があります。有効であるがPCCがそれを割り当てることができない場合、それはError-Type = 31（PCECC障害）およびerror-value = 4でPCERRメッセージを送信する必要があります（指定されたCCIを割り当てることができません）。
If the PCC wishes to withdraw or modify the previously assigned label, it MUST send a PCRpt message without any label or with the label containing the new value, respectively, in the CCI object. The PCE would further trigger the label cleanup of the older label, as per Section 5.5.3.2.
PCCが以前に割り当てられたラベルを撤回または変更したい場合は、それぞれのラベルなしでPCRPTメッセージを送信し、それぞれCCIオブジェクト内の新しい値を含むラベルを送信する必要があります。セクション5.5.3.2に従って、PCEはさらに古いラベルのラベルクリーンアップを引き起こします。
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made of a set of objects that can be either mandatory or optional. An object is said to be mandatory in a PCEP message when the object must be included for the message to be considered valid. For each PCEP message type, a set of rules is defined, which specifies the set of objects that the message can carry. An implementation MUST form the PCEP messages using the object ordering specified in this document.
[RFC5440]で定義されているように、PCEPメッセージは共通のヘッダーとそれに続く、必須またはオプションのいずれかのオブジェクトのセットからなる可変長本体からなる。オブジェクトは、オブジェクトが有効と見なされるメッセージのためにオブジェクトが含まれている必要があるときにPCEPメッセージで必須であると言われています。各PCEPメッセージタイプについて、メッセージが持つことができるオブジェクトのセットを指定する一連の規則が定義されています。実装は、このドキュメントで指定されたオブジェクト順序付けを使用してPCEPメッセージを作成する必要があります。
The LSP-IDENTIFIERS TLV MUST be included in the LSP object for the PCECC LSP.
LSP識別子TLVは、PCECC LSPのLSPオブジェクトに含める必要があります。
The message formats in this document are specified using Routing Backus-Naur Form (RBNF) encoding, as specified in [RFC5511].
このドキュメントのメッセージフォーマットは、[RFC5511]で指定されているように、ルーティングバックスナウリック形式（RBNF）エンコーディングを使用して指定されています。
The PCInitiate message [RFC8281] can be used to download or remove the labels; this document extends the message, as shown below.
PCINITIATEメッセージ[RFC8281]は、ラベルをダウンロードまたは削除するために使用できます。この文書は以下のようにメッセージを拡張します。
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
ただし：
* <Common Header> is defined in [RFC5440].
* <一般的なヘッダー>は[RFC5440]で定義されています。
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>|
<PCE-initiated-lsp-central-control>)
<PCE-initiated-lsp-central-control> ::= <SRP>
<LSP>
<cci-list>
<cci-list> ::= <CCI>
[<cci-list>]
Where:
ただし：
* <PCE-initiated-lsp-instantiation> and <PCE-initiated-lsp-deletion> are as per [RFC8281].
* <PCE開始-LSPインスタンス化>および<PCE開始-LSP - 欠失>は、[RFC8281]の通りです。
* The LSP and SRP object is defined in [RFC8231].
* LSPオブジェクトとSRPオブジェクトは[RFC8231]で定義されています。
When a PCInitiate message is used for the CCI (labels), the SRP, LSP, and CCI objects MUST be present. The SRP object is defined in [RFC8231]; if the SRP object is missing, the receiving PCC MUST send a PCErr message with Error-Type=6 (Mandatory Object missing) and Error-value=10 (SRP object missing). The LSP object is defined in [RFC8231], and if the LSP object is missing, the receiving PCC MUST send a PCErr message with Error-Type=6 (Mandatory Object missing) and Error-value=8 (LSP object missing). The CCI object is defined in Section 7.3, and if the CCI object is missing, the receiving PCC MUST send a PCErr message with Error-Type=6 (Mandatory Object missing) and Error-value=17 (CCI object missing). More than one CCI object MAY be included in the PCInitiate message for a transit LSR.
PCI（Labels）にPCInitiateメッセージが使用されている場合は、SRP、LSP、およびCCIオブジェクトが存在している必要があります。SRPオブジェクトは[RFC8231]で定義されています。SRPオブジェクトが欠落している場合、受信PCCはError-Type = 6（必須オブジェクトが見つからない）とERROR-VALUE = 10（SRPオブジェクトが見つからない）でPCERRメッセージを送信する必要があります。LSPオブジェクトは[RFC8231]で定義されており、LSPオブジェクトが欠落している場合、受信側PCCはERROR-TYPE = 6（必須オブジェクトが見つからない）とERROR-VALUE = 8（LSPオブジェクトが見つからない）でPCERRメッセージを送信する必要があります。CCIオブジェクトはセクション7.3で定義されており、CCIオブジェクトが見つからない場合、受信側PCCはError-Type = 6（必須オブジェクトが見つからない）とERROR-VALUE = 17（CCIオブジェクトが見つからない）でPCERRメッセージを送信する必要があります。Transit LSRのPCINITIATEメッセージに複数のCCIオブジェクトを含めることができます。
To clean up entries, the R (remove) bit MUST be set in the SRP object to be encoded along with the LSP and CCI objects.
エントリをクリーンアップするには、LSPおよびCCIオブジェクトとともにエンコードされるSRPオブジェクトにR（削除）ビットを設定する必要があります。
The CCI object received at the ingress node MUST have the O bit (out-label) set. The CCI object received at the egress MUST have the O bit unset. If this is not the case, the PCC MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=3 (Invalid CCI). Other instances of the CCI object, if present, MUST be ignored.
入力ノードで受信されたCCIオブジェクトは、Oビット（OUT-LABEL）を設定する必要があります。出口で受信されたCCIオブジェクトは、Oビットの設定を解除する必要があります。そうでない場合、PCCはERROR-TYPE = 31（PCECC障害）とERROR-VALUE = 3（無効なCCI）でPCERRメッセージを送信する必要があります。存在する場合は、CCIオブジェクトの他のインスタンスは無視する必要があります。
For the point-to-point (P2P) LSP setup via the PCECC technique, at the transit LSR, two CCI objects are expected for incoming and outgoing labels associated with the LSP object. If any other CCI object is included in the PCInitiate message, it MUST be ignored. If the transit LSR did not receive two CCI objects, with one of them having the O bit set and another with the O bit unset, it MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=3 (Invalid CCI).
PCECCテクニックを介したポイントツーポイント（P2P）LSPセットアップは、Transit LSRで、LSPオブジェクトに関連付けられている着信ラベルと発信ラベルに対して2つのCCIオブジェクトが期待されます。PCInitiateメッセージに他のCCIオブジェクトが含まれている場合は、無視する必要があります。Transit LSRが2つのCCIオブジェクトを受信しなかった場合、それらのうちの1つがOビットセットとOビットの設定解除を持つもので、ERROR-TYPE = 31（PCECC障害）とerror-value = 3でPCERRメッセージを送信する必要があります。（無効なCCI）。
Note that, on receipt of the PCInitiate message with CCI object, the ingress, egress, or transit role of the PCC is identified via the ingress and egress IP address encoded in the LSP-IDENTIFIERS TLV.
CCIオブジェクトを使用してPCInitiateメッセージを受信すると、PCCの入力、出力、またはトランジットの役割は、LSP-IDTILVでエンコードされた入力と出力IPアドレスを介して識別されます。
The PCRpt message can be used to report the labels that were allocated by the PCE to be used during the State Synchronization phase or as an acknowledgment to a PCInitiate message.
PCRPTメッセージを使用して、状態同期フェーズ中またはPCINITIATEメッセージへの確認応答として使用されるPCEによって割り当てられたラベルを報告できます。
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
ただし：
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= (<lsp-state-report>|
<central-control-report>)
<lsp-state-report> ::= [<SRP>]
<LSP>
<path>
<central-control-report> ::= [<SRP>]
<LSP>
<cci-list>
<cci-list> ::= <CCI>
[<cci-list>]
Where:
ただし：
* <path> is as per [RFC8231], and the LSP and SRP objects are also defined in [RFC8231].
* <PATH>は[RFC8231]によると、LSPオブジェクトとSRPオブジェクトは[RFC8231]でも定義されています。
When a PCRpt message is used to report the CCI (labels), the LSP and CCI objects MUST be present. The LSP object is defined in [RFC8231], and if the LSP object is missing, the receiving PCE MUST send a PCErr message with Error-Type=6 (Mandatory Object missing) and Error-value=8 (LSP object missing). The CCI object is defined in Section 7.3, and if the CCI object is missing, the receiving PCE MUST send a PCErr message with Error-Type=6 (Mandatory Object missing) and Error-value=17 (CCI object missing). Two CCI objects can be included in the PCRpt message for a transit LSR.
PCRPTメッセージを使用してCCI（ラベル）を報告する場合、LSPおよびCCIオブジェクトが存在している必要があります。LSPオブジェクトは[RFC8231]で定義されており、LSPオブジェクトが欠落している場合、受信側PCEはERROR-TYPE = 6（必須オブジェクトが見つからない）とERROR-VALUE = 8（LSPオブジェクトが見つからない）でPCERRメッセージを送信する必要があります。CCIオブジェクトはセクション7.3で定義されており、CCIオブジェクトが見つからない場合、受信側PCEはError-Type = 6（必須オブジェクトが見つからない）とERROR-VALUE = 17（CCIオブジェクトが見つからない）でPCERRメッセージを送信する必要があります。Transit LSRのPCRPTメッセージには、2つのCCIオブジェクトを含めることができます。
The PCEP objects defined in this document are compliant with the PCEP object format defined in [RFC5440].
この文書で定義されているPCEPオブジェクトは、[RFC5440]で定義されているPCEPオブジェクト形式に準拠しています。
This document defines a new PST (2) to be included in the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object. Further, a new sub-TLV for the PCECC capability exchange is also defined.
このドキュメントでは、Openオブジェクトのpath-setup-type-capability TLVに含まれる新しいPST（2）を定義します。さらに、PCECC機能交換のための新しいサブTLVも定義されています。
The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN object in the PATH-SETUP-TYPE-CAPABILITY TLV when the Path Setup Type list includes the PCECC Path Setup Type 2. A PCECC-CAPABILITY sub-TLV MUST be ignored if the PST list does not contain PST=2.
PCECC機能サブTLVは、PATHセットアップタイプリストにPCECCパス設定タイプ2を含む場合、PATH-SETUP型機能TLVでオープンオブジェクトで使用するためのオプションのTLVです.PCECC-CAPABILY SUB-TLVはPSTリストにPST = 2が含まれていない場合は無視されます。
Its format is shown in Figure 7.
そのフォーマットは図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=1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCECC Capability Sub-TLV
図7：PCECC機能サブTLV
The type of the TLV is 1, and it has a fixed length of 4 octets.
TLVの種類は1で、固定長が4オクテットです。
The value comprises a single field: Flags (32 bits). Currently, the following flag bit is defined:
値は単一のフィールド：フラグ（32ビット）を含む。現在、次のフラグビットが定義されています。
L bit (Label): If set to '1' by a PCEP speaker, the L flag indicates that the PCEP speaker will support and is willing to handle the PCEC-based Central Controller Instructions for label download. The bit MUST be set to '1' by both a PCC and a PCE for the PCECC label download/report on a PCEP session.
Lビット（ラベル）：PCEPスピーカーで '1'に設定すると、LフラグはPCEPスピーカーがサポートしていることを示し、ラベルのダウンロードのためのPCECベースの中央コントローラの命令を処理します。PCEPセッションでPCCラベルのダウンロード/レポートのPCCとPCEの両方でビットを「1」に設定する必要があります。
Unassigned bits MUST be set to '0' on transmission and MUST be ignored on receipt.
未割り当てビットは、送信時に「0」に設定する必要があり、受信時に無視されなければなりません。
The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document defines a new PST value:
path-setup-type tlvは[RFC8408]で定義されています。この文書は新しいPST値を定義します。
PST=2: Path is set up via the PCECC mode.
PST = 2：PACECCモードを介して設定されます。
On a PCRpt/PCUpd/PCInitiate message, the PST=2 in the PATH-SETUP-TYPE TLV in the SRP object MUST be included for an LSP set up via the PCECC-based mechanism.
PCRPT / PCUPD / PCINITIATEメッセージでは、SRPオブジェクト内のPATH-SETUP型TLVのPST = 2をPCECCベースのメカニズムを介して設定する必要があります。
The CCI object is used by the PCE to specify the forwarding instructions (label information in the context of this document) to the PCC and MAY be carried within a PCInitiate or PCRpt message for label download/report.
CCIオブジェクトは、PCEによってPCCに転送命令（この文書のコンテキストのラベル情報）をPCCに指定するために使用され、ラベルダウンロード/レポートのためのPCINITIATEまたはPCRPTメッセージ内で運ばれてもよい。
CCI Object-Class is 44.
CCIオブジェクトクラスは44です。
CCI Object-Type is 1 for the MPLS label.
MPLSラベルには、CCIオブジェクトタイプが1です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |C|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: CCI Object
図8：CCIオブジェクト
The fields in the CCI object are as follows:
CCIオブジェクトのフィールドは次のとおりです。
CC-ID: A PCEP-specific identifier for the CCI information. A PCE creates a CC-ID for each instruction; the value is unique within the scope of the PCE and is constant for the lifetime of a PCEP session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Note that [SECURITY-ID] gives advice on assigning transient numeric identifiers, such as the CC-ID, so as to minimize security risks.
CC-ID：CCI情報のPCEP固有の識別子PCEは各命令にCC-IDを作成します。値はPCEの範囲内で一意であり、PCEPセッションの存続期間で一定です。値0と0xFFFFFFFFが予約されており、使用しないでください。[Security-ID]は、セキュリティリスクを最小限に抑えるために、CC-IDなどの一時的な数値識別子の割り当てに関するアドバイスを行います。
Reserved1 (16 bit): Set to 'zero' while sending; ignored on receipt.
Reserved1（16ビット）：送信中に「ゼロ」に設定します。領収書で無視されます。
Flags (16 bit): A field used to carry any additional information pertaining to the CCI. Currently, the following flag bits are defined:
フラグ（16ビット）：CCIに関する追加情報を搬送するために使用されるフィールド。現在、次のフラグビットが定義されています。
* O bit (out-label) : If the bit is set to '1', it specifies the label is the out-label, and it is mandatory to encode the next-hop information (via Address TLVs (Section 7.3.1) in the CCI object). If the bit is not set, it specifies the label is the in-label, and it is optional to encode the local interface information (via Address TLVs in the CCI object).
* oビット（out-label）：ビットが '1'に設定されている場合、ラベルはアウトラベルであり、次のホップ情報をエンコードすることは必須です（アドレスTLV（セクション7.3.1））。CCIオブジェクト）。ビットが設定されていない場合は、ラベルがin-labelであり、ローカルインターフェイス情報（CCIオブジェクト内のアドレスTLVSを介してエンコードするためのオプションです。
* C Bit (PCC allocation): If the bit is set to '1', it indicates that the label allocation needs to be done by the PCC for the Central Controller Instruction. A PCE sets this bit to request the PCC to make an allocation from its label space. A PCC would set this bit to indicate that it has allocated the label and report it to the PCE.
* Cビット（PCC割り当て）：ビットが '1'に設定されている場合、ラベル割り当ては、Central Controller命令のPCCによって実行される必要があることを示しています。PCEはこのビットを設定してPCCに割り当てをラベル空間から割り当てます。PCCはこのビットを設定してラベルを割り当て、それをPCEに報告することを示します。
* All unassigned bits MUST be set to 'zero' at transmission and ignored at receipt.
* 割り当てられていないビットはすべて、送信時に「ゼロ」に設定する必要があり、受信時に無視されます。
Label (20-bit): The label information.
ラベル（20ビット）：ラベル情報。
Reserved2 (12 bit): Set to 'zero' while sending; ignored on receive.
Reserved2（12ビット）：送信中に「ゼロ」に設定します。受信時に無視されます。
[RFC8779] defines the IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT TLVs for the use of Generalized Endpoint. The same TLVs can also be used in the CCI object to associate the next-hop information in the case of an outgoing label and local interface information in the case of an incoming label. The next-hop information encoded in these TLVs needs to be a directly connected IP address/interface information. If the PCC is not able to resolve the next-hop information, it MUST reject the CCI and respond with a PCErr message with Error-Type=31 (PCECC failure) and Error-value=5 (Invalid next-hop information).
[RFC8779]一般化エンドポイントを使用するためのIPv4アドレス、IPv6アドレス、およびhonumbered-endpoint TLVを定義します。受信ラベルの場合には、発信ラベルとローカルインタフェース情報とを関連付けるには、CCIオブジェクトでも同じTLVを使用することもできます。これらのTLVで符号化されたネクストホップ情報は、直接接続されているIPアドレス/インタフェース情報である必要があります。PCCがネクストホップ情報を解決できない場合は、CCIを拒否し、Error-Type = 31（PCECC障害）とERROR-VALUE = 5（無効なネクストホップ情報）を使用してPCERRメッセージで応答する必要があります。
As per [RFC8283], the security considerations for a PCE-based controller are a little different from those for any other PCE system. That is, the operation relies heavily on the use and security of PCEP, so consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253]. It further lists the vulnerability of a central controller architecture, such as a central point of failure, denial of service, and a focus for interception and modification of messages sent to individual Network Elements (NEs).
[RFC8283]によると、PCEベースのコントローラのセキュリティ上の考慮事項は、他のPCEシステムのためのものとは少し異なります。つまり、PCEPの使用とセキュリティに大きく依存しているため、[RFC5440]で説明したセキュリティ機能と[RFC8253]に記載されているセキュリティ機能を考慮する必要があります。さらに、中心的な障害点、サービス拒否などの中央コントローラアーキテクチャの脆弱性、および個々のネットワーク要素（NES）に送信されたメッセージの傍受およびメッセージの変更の焦点をさらに列挙します。
In the PCECC operations, the PCEP sessions are also required to the internal routers, thus increasing the resources required for the session management at the PCE.
PCECC操作では、PCEPセッションも内部ルータに必要であるため、PCEでのセッション管理に必要なリソースが増えます。
The PCECC extension builds on the existing PCEP messages; thus, the security considerations described in [RFC5440], [RFC8231], and [RFC8281] continue to apply. [RFC8253] specifies the support of Transport Layer Security (TLS) in PCEP, as it provides support for peer authentication, message encryption, and integrity. It further provides mechanisms for associating peer identities with different levels of access and/or authoritativeness via an attribute in X.509 certificates or a local policy with a specific accept-list of X.509 certificates. This can be used to check the authority for the PCECC operations. Additional considerations are discussed in following sections.
PCECC拡張機能は既存のPCEPメッセージに構築されています。したがって、[RFC5440]、[RFC8231]、[RFC8281]で説明されているセキュリティ上の考慮事項は適用され続けます。[RFC8253]ピア認証、メッセージ暗号化、および整合性のサポートを提供するため、PCEPのトランスポート層セキュリティ（TLS）のサポートを指定します。それはさらに、X.509証明書またはX.509証明書の特定のaccept-listを持つローカルポリシーの属性またはローカルポリシーを介して、異なるレベルのアクセスおよび/または権限を異なるアクセスおよび/または権限に関連付けるメカニズムを提供します。これはPCECC操作の権限を確認するために使用できます。その他の考慮事項については、以下のセクションで説明します。
In this extension, the PCE has complete control over the PCC to download/remove the labels and can cause the LSPs to behave inappropriately and cause a major impact to the network. As a general precaution, it is RECOMMENDED that this PCEP extension be activated on mutually authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using TLS [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525].
この拡張では、PCEはPCCを完全に制御してラベルをダウンロード/削除し、LSPを不適切に行動させ、ネットワークに大きな影響を与える可能性があります。一般的な予防措置として、このPCEPは、TLS [RFC8253]を使用して、TLS [RFC8253]を使用して、BCP 195 [RFC7525]では、TLS [RFC8253]を使用して、このPCEP拡張機能を推奨することをお勧めします。]。
Further, an attacker may flood the PCC with the PCECC-related messages at a rate that exceeds either the PCC's ability to process them or the network's ability to send them, by either spoofing messages or compromising the PCE itself. [RFC8281] provides a mechanism to protect the PCC by imposing a limit. The same can be used for the PCECC operations as well.
さらに、攻撃者は、PCCのPCCのプロセス能力またはネットワークのメッセージをスプーフィングしたり、PCE自体を損なうことによって、PCC関連のメッセージをPCCにあふれさせる可能性があります。[RFC8281]制限を課すことによってPCCを保護するためのメカニズムを提供します。PCECC操作にも同じことが使用できます。
As specified in Section 5.5.3.1, a PCC needs to check if the label in the CCI object is in the range set aside for the PCE; otherwise, it MUST send a PCErr message with Error-Type=31 (PCECC failure) and Error-value=1 (Label out of range).
セクション5.5.3.1で指定されているように、PCCはCCIオブジェクト内のラベルがPCEの場合は扱う範囲内にあるかどうかを確認する必要があります。それ以外の場合は、ERROR-TYPE = 31（PCECC障害）とERROR-VALUE = 1（範囲外のラベル）を使用してPCERRメッセージを送信する必要があります。
The PCECC mechanism described in this document requires the PCE to keep labels (CCI) that it downloads and relies on the PCC responding (with either an acknowledgment or an error message) to request for LSP instantiation. This is an additional attack surface by placing a requirement for the PCE to keep a CCI/label replica for each PCC. It is RECOMMENDED that PCE implementations provide a limit on resources (in this case the CCI) a single PCC can occupy. [RFC8231] provides a notification mechanism when such threshold is reached.
この文書に記載されているPCECCメカニズムでは、LABELS（CCI）がダウンロードし、LSPのインスタンス化を要求するためのPCC応答（確認応答またはエラーメッセージのいずれか）に依存していることが必要です。PCEに必要な要件を配置して、各PCCにCCI /ラベルレプリカを保持することで、追加の攻撃面です。PCE実装は、リソース（この場合はCCI）に単一のPCCが占有できるリソースに制限を与えることをお勧めします。[RFC8231]そのようなしきい値に達すると通知メカニズムを提供します。
A PCE or PCC implementation SHOULD allow the PCECC capability to be enabled/disabled as part of the global configuration. Section 6.1 of [RFC8664] list various controlling factors regarding the Path Setup Type. They are also applicable to the PCECC Path Setup Types. Further, Section 6.2 of [RFC8664] describes the migration steps when the Path Setup Type of an existing LSP is changed.
PCEまたはPCC実装では、グローバル構成の一部としてPCECC機能を有効/無効にする必要があります。[RFC8664]のセクション6.1は、パス設定の種類に関するさまざまな制御要素を示しています。PCECCパス設定タイプにも適用されます。また、[RFC8664]のセクション6.2は、既存のLSPのパス設定タイプが変更されたときの移行手順について説明しています。
[RFC7420] describes the PCEP MIB; this MIB can be extended to get the PCECC capability status.
[RFC7420] PCEP MIBについて説明しています。このMIBは、PCECC機能のステータスを取得するために拡張できます。
The PCEP YANG module [PCEP-YANG] could be extended to enable/disable the PCECC capability.
PCEP YANGモジュール[PCEP-YANG]は、PCECC機能を有効/無効にするように拡張できます。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
この文書で定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出および監視要件を意味しません。
The operator needs the following information to verify that PCEP is operating correctly with respect to the PCECC Path Setup Type.
オペレータは、PCEPがPCECCパス設定タイプに関して正しく動作していることを確認するために以下の情報を必要とします。
* An implementation SHOULD allow the operator to view whether the PCEP speaker sent the PCECC PST capability to its peer.
* 実装により、オペレータはPCEPスピーカーがPCECC PST機能をそのピアに送信したかどうかを表示できるようにする必要があります。
* An implementation SHOULD allow the operator to view whether the peer sent the PCECC PST capability.
* 実装では、操作者がピアがPCECC PST機能を送信したかどうかを表示できるようにする必要があります。
* An implementation SHOULD allow the operator to view whether the PCECC PST is enabled on a PCEP session.
* 実装では、PCECC PSTがPCEPセッションで有効になっているかどうかをオペレータに表示できるようにする必要があります。
* If one PCEP speaker advertises the PCECC PST capability, but the other does not, then the implementation SHOULD create a log to inform the operator of the capability mismatch.
* 1つのPCEPスピーカーがPCECC PST機能をアドバタイズしたが、他方がそうではない場合、実装は機能不一致のオペレータに通知するログを作成する必要があります。
* If a PCEP speaker rejects a CCI, then it SHOULD create a log to inform the operator, giving the reason for the decision (local policy, label issues, etc.).
* PCEPスピーカーがCCIを拒否した場合、それはオペレータに知らせるログを作成し、決定の理由（地域のポリシー、ラベルの問題など）を与えます。
PCEP extensions defined in this document do not put new requirements on other protocols.
この文書で定義されているPCEP拡張機能は、他のプロトコルに新しい要件を入力しません。
PCEP extensions defined in this document do not put new requirements on network operations.
この文書で定義されているPCEP拡張機能は、ネットワーク操作に新しい要件を入力しません。
[RFC8408] detailed the creation of the "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators" subregistry. Further, IANA has allocated the following codepoint:
[RFC8408]「PATH-SETUP型機能サブTLVタイプインジケーター」サブリュージストリートの作成について詳しく説明します。さらに、IANAは次のコードポイントを割り当てています。
+=======+==================+===========+
| Value | Meaning | Reference |
+=======+==================+===========+
| 1 | PCECC-CAPABILITY | RFC 9050 |
+-------+------------------+-----------+
Table 2: PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators Subregistry Addition
表2：パス設定型機能サブTLVタイプインジケータサブレジスト追加
This document defines the PCECC-CAPABILITY sub-TLV; IANA has created a new subregistry to manage the value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
このドキュメントはPCECC機能サブTLVを定義します。IANAは、PCECC機能サブTLVの32ビットフラグフィールドの値を管理するための新しいサブレジストを作成しました。新しい値は標準アクション[RFC8126]によって割り当てられます。各ビットは次の資質で追跡されるべきです。
* bit number (counting from bit 0 as the most significant bit)
* ビット数（最上位ビットとしてのビット0からのカウント）
* capability description
* 機能の説明
* defining RFC
* RFCを定義する
Currently, there is one allocation in this registry.
現在、このレジストリに1つの割り当てがあります。
+======+============+===========+
| Bit | Name | Reference |
+======+============+===========+
| 0-30 | Unassigned | RFC 9050 |
+------+------------+-----------+
| 31 | Label | RFC 9050 |
+------+------------+-----------+
Table 3: Initial Contents of the PCECC-CAPABILITY Sub-TLV Subregistry
表3：PCECC能力サブTLVサブリュージストリートの初期内容
[RFC8408] created a subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". IANA has allocated a new codepoint within this registry, as follows:
[RFC8408]「PCEPパス設定タイプ」という「PATH計算要素プロトコル（PCEP）番号」のレジストリ内でサブレジストを作成しました。次のように、IANAはこのレジストリ内に新しいコードポイントを割り当てました。
+=======+============================+===========+
| Value | Description | Reference |
+=======+============================+===========+
| 2 | Traffic engineering path | RFC 9050 |
| | is set up using PCECC mode | |
+-------+----------------------------+-----------+
Table 4: Path Setup Type Registry Codepoint Addition
表4：パス設定型レジストリコードポイント追加
IANA has allocated new codepoints in the "PCEP Objects" subregistry for the CCI object as follows:
IANAは、次のようにCCIオブジェクトの「PCEPオブジェクト」サブレイストに新しいコードポイントを割り当てました。
+==============+=============+=====================+===========+
| Object-Class | Name | Object-Type | Reference |
| Value | | | |
+==============+=============+=====================+===========+
| 44 | CCI Object- | 0: Reserved | RFC 9050 |
| | Type | 1: MPLS Label | |
| | | 2-15: Unassigned | |
+--------------+-------------+---------------------+-----------+
Table 5: PCEP Objects Subregistry Additions
表5：PCEPオブジェクトサブレジスト追加
IANA has created a new subregistry to manage the Flag field of the CCI object called "CCI Object Flag Field for MPLS Label". New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、「MPLSラベルのCCIオブジェクトフラグフィールド」というCCIオブジェクトのFlagフィールドを管理するための新しいサブレジストを作成しました。新しい値は標準アクション[RFC8126]によって割り当てられます。各ビットは次の資質で追跡されるべきです。
* bit number (counting from bit 0 as the most significant bit)
* ビット数（最上位ビットとしてのビット0からのカウント）
* capability description
* 機能の説明
* defining RFC
* RFCを定義する
Two bits are defined for the CCI Object flag field in this document as follows:
この文書のCCIオブジェクトフラグフィールドには、次の2ビットが定義されています。
+======+======================================+===========+
| Bit | Description | Reference |
+======+======================================+===========+
| 0-13 | Unassigned | |
+------+--------------------------------------+-----------+
| 14 | C Bit - PCC allocation | RFC 9050 |
+------+--------------------------------------+-----------+
| 15 | O Bit - Specifies label is out-label | RFC 9050 |
+------+--------------------------------------+-----------+
Table 6: CCI Object Flag Field for MPLS Label Initial Contents
表6：MPLSラベルの初期内容のためのCCIオブジェクトフラグフィールド
IANA has allocated new error types and error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry for the following errors:
次のエラーについては、「PCEPエラーオブジェクトエラータイプと値」レジストリの「PCEPエラーオブジェクトエラータイプと値」レジストリ内の新しいエラータイプとエラー値が割り当てられています。
+============+===========+=======================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+===========+=======================+===========+
| 6 | Mandatory | 17: CCI object | RFC 9050 |
| | Object | missing | |
| | missing | | |
+------------+-----------+-----------------------+-----------+
| 10 | Reception | 33: Missing PCECC | RFC 9050 |
| | of an | Capability sub-TLV | |
| | invalid | | |
| | object | | |
+------------+-----------+-----------------------+-----------+
| 19 | Invalid | 16: Attempted PCECC | RFC 9050 |
| | Operation | operations when PCECC | |
| | | capability was not | |
| | | advertised | |
| | | | |
| | | 17: Stateful PCE | |
| | | capability was not | |
| | | advertised | |
| | | | |
| | | 18: Unknown Label | |
+------------+-----------+-----------------------+-----------+
| 31 | PCECC | 1: Label out of range | RFC 9050 |
| | failure | | |
| | | 2: Instruction failed | |
| | | | |
| | | 3: Invalid CCI | |
| | | | |
| | | 4: Unable to allocate | |
| | | the specified CCI | |
| | | | |
| | | 5: Invalid next-hop | |
| | | information | |
+------------+-----------+-----------------------+-----------+
Table 7: PCEP-ERROR Object Error Types and Values Additions
表7：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>。
[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>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「ルーティングバックス - ナウルフォーム（RBNF）：さまざまなルーティングプロトコル仕様の符号化規則を形成するための構文、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。rfc-editor.org/info/rfc5511>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[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>。
[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>。
[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>.
[RFC8664] Sivabalan、S、Filsfils、C、Tantura、J.、HenderickX、W.、およびJ.Hormwick、セグメントルーティングのためのPATH計算要素通信プロトコル（PCE）拡張（PCE）、RFC 8664、DOI 10.17487 / RFC86642019年12月、<https：//www.rfc-editor.org/info/rfc8664>。
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F. Zhang, Ed., "Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS", RFC 8779, DOI 10.17487/RFC8779, July 2020, <https://www.rfc-editor.org/info/rfc8779>.
[RFC8779]マーガリア、C、ED。、GONZALEZ DE DIOS、O.、ED。、およびF。Zhang、ED。、「PATH計算要素通信プロトコル（GMPLS用）、RFC 8779、DOI 10.17487 / RFC87792020年7月、<https：//www.rfc-editor.org/info/rfc8779>。
[RFC4655] Farrel, A., Vasseur, JP., 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>.
[RFC4655] Farrel、A.、Vasseur、JP、J.Ash、「PATH計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc-editor.org/info/rfc4655>。
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, DOI 10.17487/RFC7025, September 2013, <https://www.rfc-editor.org/info/rfc7025>.
[RFC7025] OTANI、T.、小垣、K。、Caviglia、D.、Zhang、F.、およびC.マーガリア、「PCEのGMPLSアプリケーションの要求」、RFC 7025、DOI 10.17487 / RFC7025、2013年9月、<HTTPS//www.rfc-editor.org/info/rfc7025>。
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7399] Farrel、A.およびD. King、「パス計算要素のアーキテクチャにおける未回答の質問」、RFC 7399、DOI 10.17487 / RFC7399、2014年10月、<https://www.rfc-editor.org/info/rfc7399>。
[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>。
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.
[RFC7491] King、D.およびA. Farrel、「アプリケーションベースのネットワーク事業のためのPCEベースのアーキテクチャ」、RFC 7491、DOI 10.17487 / RFC7491、2015年3月、<https：//www.rfc-editor.org/情報/ RFC7491>。
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>.
[RFC8232] Crabbe、E.、Minei、I。、Medived、J.、Varga、R.、Zhang、X.、およびD.D.Dhody、「ラベルスイッチパス状態の最適化：ステートフルPCEのための最適化」、RFC 8232、DOI 10.17487 / RFC8232、2017年9月、<https：//www.rfc-editor.org/info/rfc8232>。
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.
[RFC8283] Farrel、A.、ED。、Zhao、Q、ED。、LI、Z.、およびC. Zhou、「PCEの使用およびCENTIAL CONTROLを備えたネットワーク内のPCE通信プロトコル（PCE）「、RFC 8283、DOI 10.17487 / RFC8283、2017年12月、<https://www.rfc-editor.org/info/rfc8283>。
[RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and M. Negi, "Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, <https://www.rfc-editor.org/info/rfc8741>.
[RFC8741] Raghuram、A.、Goddard、A.、Karthik、J.、Sivabalan、S.、M.Negi、「ステートフルパス計算要素（PCE）の制御を要求して取得する能力（PCE）LSP） "、RFC 8741、DOI 10.17487 / RFC8741、2020年3月、<https://www.rfc-editor.org/info/rfc8741>。
[PCECC] Li, Z. (., Dhody, D., Zhao, Q., Ke, K., Khasanov, B., Fang, L., Zhou, C., Zhang, B., Rachitskiy, A., and A. Gulida, "The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC).", Work in Progress, Internet-Draft, draft-ietf-teas-pcecc-use-cases-07, 8 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-pcecc-use-cases-07>.
[PCECC] Li、Z.（。、Dhody、D.、Zhao、K、K.、Khasanov、B.、Fang、L.、Zhou、Zhang、B.、Rachitskiy、A.、A. Gulida「パス計算要素（PCE）の中央コントローラ（PCECC）のユースケース（PCECC）」、進行中の作業、インターネットドラフト、ドラフト - IETF-TEAS-PCECC-use-ecase-07,8,82021、<https://datatracker.ietf.org/doc/html/draft-ietf-teas-pcecc-use-cases-07>。
[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://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-16>.
[PCEP-YANG] Dhody、D.、ED。、Hardwick、J.、Beeram、V.およびJ.Tantsura、「パス計算要素通信プロトコル（PCEP）のYangデータモデル」、進行中、インターネット - ドラフト、ドラフト-IETF-PCE-PCE-YANG-16,221月22日、<https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-16>。
[PCECC-SR] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution.", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-extension-pce-controller-sr-02, 25 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-sr-02>.
[PCECC-SR] Li、Z.、Peng、S.、NEGI、MS、Zhao、Q.、C.Zhou、セグメントルーティングのためのCENTRY CONTROLLES（PCECC）としてPCEを使用するためのPCEP手順とプロトコル拡張（SR）「MPLSセグメント識別子（SID）割り振りと配布」、進行中の取り組み、インターネットドラフト、ドラフト - IETF-PCE-PCEP-Extension-PCE-CONTROLLECTION-SR-02,25,25 3月25日、<https：// DataTracker。ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-sr-02>。
[PCECC-SRv6] Li, Z., Peng, S., Geng, X., and M. S. Negi, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6", Work in Progress, Internet-Draft, draft-dhody-pce-pcep-extension-pce-controller-srv6-06, 21 February 2021, <https://datatracker.ietf.org/doc/html/draft-dhody-pce-pcep-extension-pce-controller-srv6-06>.
[PCECC-SRV6] Li、Z.、Peng、S.、Geng、X.、およびMS NEGI、「PCEの使用のためのPCEP手順とプロトコル拡張」（SRV6の中央コントローラ（PCECC）としてのPCECC）、進行中、インターネット - ドラフト、ドラフト - DHODY-PCE-PCEP-Extension-PCE-CONTROLLECT-SRV6-06,2021、<https://datatracker.ietf.org/doc/html/draft-dhody-pce-pcep-extension-pce-controller-srv6-06>。
[PCE-ID] Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE Controlled ID Space", Work in Progress, Internet-Draft, draft-li-pce-controlled-id-space-08, 22 February 2021, <https://datatracker.ietf.org/doc/html/draft-li-pce-controlled-id-space-08>.
[PCE-ID] Li、C。、Chen、M.、Wang、A.、Cheng、W。、およびC.Zhou、「PCE制御IDスペース」、進行中の作業、インターネットドラフト、ドラフトLI-PCE-controlled-id-space-08,2021、<https://datatracker.ietf.org/doc/html/draft-li-pce-controlled-id-space-08>。
[SECURITY-ID] Gont, F. and I. Arce, "Security Considerations for Transient Numeric Identifiers Employed in Network Protocols", Work in Progress, Internet-Draft, draft-gont-numeric-ids-sec-considerations-06, 5 December 2020, <https://datatracker.ietf.org/doc/html/draft-gont-numeric-ids-sec-considerations-06>.
[Security-ID] Gont、F.およびI. Arce、「ネットワークプロトコルで採用されている一時的な数値識別子のセキュリティ上の考慮事項」、進行中の作業、インターネットドラフト、ドラフトGont-Numeric-IDS-SEC-SEC - 6,5,52020年12月、<https：//datatracker.ietf.org/doc/html/draft-gont-numeric-ids-sec-consididerations-06>。
Acknowledgments
謝辞
We would like to thank Robert Tao, Changjing Yan, Tieying Huang, Avantika, and Aijun Wang for their useful comments and suggestions.
Robert Tao、Changjing Yan、Wiewing Huang、Avantika、Aijun Wangに役立つコメントや提案に感謝します。
Thanks to Julien Meuric for shepherding this document and providing valuable comments. Thanks to Deborah Brungard for being the responsible AD.
この文書を羊飼いにし、貴重なコメントを提供するためのJulien Meuriicに感謝します。責任ある広告であることのためのDeborah Brungardのおかげで。
Thanks to Victoria Pritchard for a very detailed RTGDIR review. Thanks to Yaron Sheffer for the SECDIR review. Thanks to Gyan Mishra for the Gen-ART review.
非常に詳細なRTGDIRレビューのためにVictoria Pritchardに感謝します。Secdirレビューのためのヤロンシェフォハーのおかげで。Gen-Art ReviewのためにGyan Mishraのおかげで。
Thanks to Alvaro Retana, Murray Kucherawy, Benjamin Kaduk, Roman Danyliw, Robert Wilton, Éric Vyncke, and Erik Kline for the IESG review.
Alvaro Retana、Murray Kucherawy、Benjamin Kaduk、Robert Wilton、Erik Vyncke、およびIESGレビューのためのErik Klineのおかげでください。
Contributors
貢献者
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Dhruv Dhody Huawei Technologies Divyashree Techno Park、Whitefield Bangalore 560066 Karnataka India
Email: dhruv.ietf@gmail.com
Satish Karunanithi Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Satish Karunanithi Huawei Technologies Divyashree Techno Park、Whitefield Bangalore 560066 Karnataka India
Email: satishk@huawei.com
Adrian Farrel Old Dog Consulting United Kingdom
アドリアンファーレルオールドドッグコンサルティングイギリス
Email: adrian@olddog.co.uk
Xuesong Geng Huawei Technologies China
Xuesong Geng Huawei Technologies China.
Email: gengxuesong@huawei.com
Udayasree Palle
UdaySree Palle
Email: udayasreereddy@gmail.com
Katherine Zhao Futurewei Technologies
キャサリンZhao Futurewei Technologies
Email: katherine.zhao@futurewei.com
Boris Zhang Telus Ltd. Toronto Canada
Boris Zhang Telus Ltd. Toronto Canada.
Email: boris.zhang@telus.com
Alex Tokar Cisco Systems Slovakia
Alex Tokar Cisco Systemsスロバキア
Email: atokar@cisco.com
Authors' Addresses
著者の住所
Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China
Zhenbin Li Huawei Technologies Huawei BLD、No.156北緯RD。北京100095中国
Email: lizhenbin@huawei.com
Shuping Peng Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China
Peng Huawei Technologies Huawei Bld、No.156北緯RD。北京100095中国
Email: pengshuping@huawei.com
Mahendra Singh Negi RtBrick Inc N-17L, 18th Cross Rd, HSR Layout Bangalore 560102 Karnataka India
Mahendra Singh Negi Rtbrick Inc N-17L、18日クロスRD、HSRレイアウトバンガロール560102カルナタカインド
Email: mahend.ietf@gmail.com
Quintin Zhao Etheric Networks 1009 S Claremont St. San Mateo, CA 94402 United States of America
クイントンZhao Etheric Networks 1009 S Claremont St. San Mateo、CA 94402アメリカ合衆国
Email: qzhao@ethericnetworks.com
Chao Zhou HPE
チャオズハフペ
Email: chaozhou_us@yahoo.com