[要約] RFC 8751は、階層状の状態保持型パス計算要素（PCE）に関する規格であり、階層的なネットワーク環境でのパス計算をサポートします。目的は、ネットワークの効率性とスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8751 Huawei Technologies
Category: Informational Y. Lee
ISSN: 2070-1721 Samsung Electronics
D. Ceccarelli
Ericsson
J. Shin
SK Telecom
D. King
Lancaster University
March 2020
Hierarchical Stateful Path Computation Element (PCE)
階層型ステートフルパス計算要素（PCE）
Abstract
概要
A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.
ステートフルパス計算要素（PCE）は、計算されたラベルスイッチドパス（LSP）、ネットワーク内の予約済みリソース、保留中のパス計算要求など、パス計算クライアント（PCC）から受信した現在のネットワーク状態に関する情報を保持します。その後、この情報は、新しいトラフィックエンジニアリングLSPまたは関連する/依存するLSPのパスを計算するときに考慮されます。 PCEからのパス計算応答は、PCCが計算されたLSPを適切に確立するのに役立ちます。
The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.
階層パス計算要素（H-PCE）アーキテクチャでは、相互接続されたドメインの最適なシーケンスを選択し、PCE間の階層関係を使用して、必要に応じてネットワークポリシーを適用できます。
Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.
ステートフルPCEと階層PCEの機能を組み合わせると有利です。このドキュメントでは、階層型PCEアーキテクチャを使用したステートフルではなくステートレスPCEの展開に関する一般的な考慮事項と使用例について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8751.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8751で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Background
1.2. Use Cases and Applicability of Hierarchical Stateful PCE
1.2.1. Applicability to ACTN
1.2.2. End-to-End Contiguous LSP
1.2.3. Applicability of a Stateful P-PCE
2. Terminology
2.1. Requirements Language
3. Hierarchical Stateful PCE
3.1. Passive Operations
3.2. Active Operations
3.3. PCE Initiation of LSPs
3.3.1. Per-Domain Stitched LSP
4. Security Considerations
5. Manageability Considerations
5.1. Control of Function and Policy
5.2. Information and Data Models
5.3. Liveness Detection and Monitoring
5.4. Verification of Correct Operations
5.5. Requirements on Other Protocols
5.6. Impact on Network Operations
5.7. Error Handling between PCEs
6. Other Considerations
6.1. Applicability to Interlayer Traffic Engineering
6.2. Scalability Considerations
6.3. Confidentiality
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The Path Computation Element communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to the requests of Path Computation Clients (PCCs).
パス計算要素通信プロトコル（PCEP）[RFC5440]は、パス計算要素（PCE）がパス計算クライアント（PCC）の要求に応じてパス計算を実行するためのメカニズムを提供します。
A stateful PCE is capable of considering, for the purposes of path computation, not only the network state in terms of links and nodes (referred to as the Traffic Engineering Database or TED) but also the status of active services (previously computed paths, and currently reserved resources, stored in the Label Switched Paths Database (LSPDB).
ステートフルPCEは、パス計算の目的で、リンクおよびノードに関するネットワーク状態（Traffic Engineering DatabaseまたはTEDと呼ばれる）だけでなく、アクティブなサービス（以前に計算されたパス、およびラベルスイッチドパスデータベース（LSPDB）に保存されている、現在予約されているリソース。
[RFC8051] describes general considerations for a stateful PCE deployment; it also examines its applicability and benefits as well as its challenges and limitations through a number of use cases.
[RFC8051]は、ステートフルPCE展開の一般的な考慮事項について説明しています。また、多くのユースケースを通じて、その適用性と利点、および課題と制限についても検討します。
[RFC8231] describes a set of extensions to PCEP to provide stateful control. For its computations, a stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model.
[RFC8231]は、ステートフルコントロールを提供するPCEPの一連の拡張機能について説明しています。その計算では、ステートフルPCEは、ネットワークのInterior Gateway Protocol（IGP）によって伝達される情報だけでなく、アクティブパスのセットとそれらの予約済みリソースにもアクセスできます。追加の状態により、PCEは個別のLSPとその相互作用を考慮しながら、制約されたパスを計算できます。 [RFC8281]は、ステートフルPCEモデルでのPCEによって開始されたLSPのセットアップ、メンテナンス、およびティアダウンについて説明しています。
[RFC8231] also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP, make changes to the attributes of an existing LSP, or delegate control of specific LSPs to a new PCE.
[RFC8231]はアクティブなステートフルPCEについても説明しています。 PCEはアクティブなPCE機能を使用して、既存のLSPを再ルーティングしたり、既存のLSPの属性を変更したり、特定のLSPの制御を新しいPCEに委任したりできます。
The ability to compute constrained paths for Traffic Engineering (TE) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development. [RFC6805] describes a Hierarchical PCE (H-PCE) architecture that can be used for computing end-to-end paths for interdomain MPLS TE and GMPLS Label Switched Paths (LSPs). Within the H-PCE architecture [RFC6805], the Parent PCE (P-PCE) is used to compute a multidomain path based on the domain connectivity information. A Child PCE (C-PCE) may be responsible for a single domain or multiple domains. The C-PCE is used to compute the intradomain path based on its domain topology information.
複数のドメインにまたがるマルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークでトラフィックエンジニアリング（TE）LSPの制約されたパスを計算する機能は、PCE開発の主要な動機として特定されています。 [RFC6805]は、ドメイン間MPLS TEおよびGMPLSラベルスイッチドパス（LSP）のエンドツーエンドパスの計算に使用できる階層型PCE（H-PCE）アーキテクチャについて説明しています。 H-PCEアーキテクチャ[RFC6805]内では、親PCE（P-PCE）を使用して、ドメイン接続情報に基づいてマルチドメインパスを計算します。子PCE（C-PCE）は、単一のドメインまたは複数のドメインを担当する場合があります。 C-PCEは、ドメイントポロジ情報に基づいてドメイン内パスを計算するために使用されます。
This document presents general considerations for stateful PCEs, and not stateless PCEs, in the hierarchical PCE architecture. It focuses on the behavior changes and additions to the existing stateful PCE mechanisms (including PCE-initiated LSP setup and active stateful PCE usage) in the context of networks using the H-PCE architecture.
このドキュメントでは、階層型PCEアーキテクチャにおけるステートレスPCEではなく、ステートフルPCEに関する一般的な考慮事項について説明します。 H-PCEアーキテクチャを使用するネットワークのコンテキストで、動作の変更と既存のステートフルPCEメカニズム（PCEによって開始されるLSPセットアップとアクティブなステートフルPCEの使用を含む）への追加に焦点を当てています。
In this document, Sections 3.1 and 3.2 focus on end-to-end (E2E) interdomain TE LSP. Section 3.3.1 describes the operations for stitching per-domain LSPs.
このドキュメントでは、セクション3.1および3.2でエンドツーエンド（E2E）のドメイン間TE LSPに焦点を当てています。セクション3.3.1では、ドメインごとのLSPをステッチする操作について説明します。
As per [RFC6805], in the hierarchical PCE architecture, a P-PCE maintains a domain topology map that contains the child domains and their interconnections. Usually, the P-PCE has no information about the content of the child domains. But, if the PCE is applied to the Abstraction and Control of TE Networks (ACTN) [RFC8453] as described in [RFC8637], the Provisioning Network Controller (PNC) can provide an abstract topology to the Multi-Domain Service Coordinator (MDSC). Thus, the P-PCE in MDSC could be aware of topology information in much more detail than just the domain topology.
[RFC6805]のとおり、階層PCEアーキテクチャでは、P-PCEは子ドメインとその相互接続を含むドメイントポロジマップを維持します。通常、P-PCEには子ドメインのコンテンツに関する情報はありません。ただし、[RFC8637]で説明されているように、PCEがTEネットワークの抽象化および制御（ACTN）[RFC8453]に適用されている場合、プロビジョニングネットワークコントローラ（PNC）はマルチドメインサービスコーディネータ（MDSC）に抽象的なトポロジを提供できます。 。したがって、MDSCのP-PCEは、ドメイントポロジだけでなく、より詳細にトポロジ情報を認識することができます。
In a PCEP session between a PCC (ingress) and a C-PCE, the C-PCE acts as per the stateful PCE operations described in [RFC8231] and [RFC8281]. The same C-PCE behaves as a PCC on the PCEP session towards the P-PCE. The P-PCE is stateful in nature; thus, it maintains the state of the interdomain LSPs that are reported to it. The interdomain LSP could also be delegated by the C-PCE to the P-PCE, so that the P-PCE could update the interdomain path. The trigger for this update could be the LSP state change reported for this LSP or any other LSP. It could also be a change in topology at the P-PCE, such as interdomain link status change. In case of use of stateful H-PCE in ACTN, a change in abstract topology learned by the P-PCE could also trigger the update. Some other external factors (such as a measurement probe) could also be a trigger at the P-PCE. Any such update would require an interdomain path recomputation as described in [RFC6805].
PCC（入力）とC-PCE間のPCEPセッションでは、C-PCEは、[RFC8231]および[RFC8281]で説明されているステートフルPCE操作に従って動作します。同じC-PCEは、P-PCEへのPCEPセッションでPCCとして動作します。 P-PCEは本質的にステートフルです。したがって、報告されるドメイン間LSPの状態を維持します。ドメイン間LSPは、C-PCEからP-PCEに委任することもできるため、P-PCEはドメイン間パスを更新できます。この更新のトリガーは、このLSPまたは他のLSPについて報告されたLSP状態の変更である可能性があります。また、ドメイン間リンクステータスの変更など、P-PCEでのトポロジの変更である可能性もあります。 ACTNでステートフルH-PCEを使用する場合、P-PCEによって学習された抽象的なトポロジの変更も更新をトリガーする可能性があります。他のいくつかの外部要因（測定プローブなど）も、P-PCEでトリガーになる可能性があります。そのような更新は、[RFC6805]で説明されているように、ドメイン間パスの再計算を必要とします。
The end-to-end interdomain path computation and setup is described in [RFC6805]. Additionally, a per-domain stitched-LSP model is also applicable in a P-PCE initiation model. Sections 3.1, 3.2, and 3.3 describe the end-to-end contiguous LSP setup, whereas Section 3.3.1 describes the per-domain stitching.
エンドツーエンドのドメイン間パスの計算と設定は、[RFC6805]で説明されています。さらに、ドメインごとのステッチLSPモデルは、P-PCE開始モデルにも適用できます。セクション3.1、3.2、および3.3では、エンドツーエンドの隣接LSP設定について説明し、セクション3.3.1では、ドメインごとのステッチについて説明します。
[RFC8453] describes a framework for the Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service Coordinator (MDSC). The per-domain stitched LSP is well suited for ACTN deployments, as per the hierarchical PCE architecture described in Section 3.3.1 of this document and Section 4.1 of [RFC8453].
[RFC8453]は、TEネットワークの抽象化と制御（ACTN）のフレームワークについて説明しています。各プロビジョニングネットワークコントローラ（PNC）はC-PCEと同等であり、P-PCEはマルチドメインサービスコーディネータ（MDSC）です。このドキュメントのセクション3.3.1と[RFC8453]のセクション4.1で説明されている階層PCEアーキテクチャに従って、ドメインごとのスティッチLSPはACTN展開に適しています。
[RFC8637] examines the applicability of PCE to the ACTN framework. To support the function of multidomain coordination via hierarchy, the hierarchy of stateful PCEs plays a crucial role.
[RFC8637]は、PCTNのACTNフレームワークへの適用性を調べます。階層を介したマルチドメイン調整の機能をサポートするには、ステートフルPCEの階層が重要な役割を果たします。
In the ACTN framework, a Customer Network Controller (CNC) can request the MDSC to check whether there is a possibility to meet Virtual Network (VN) requirements before requesting that the VN be provisioned. The H-PCE architecture as described in [RFC6805] can support this function using Path Computation Request and Reply (PCReq and PCRep, respectively) messages between the P-PCE and C-PCEs. When the CNC requests VN provisioning, the MDSC decomposes this request into multiple interdomain LSP provisioning requests, which might be further decomposed into per-domain path segments. This is described in Section 3.3.1. The MDSC uses the LSP initiate request (PCInitiate) message from the P-PCE towards the C-PCE, and the C-PCE reports the state back to the P-PCE via a Path Computation State Report (PCRpt) message. The P-PCE could make changes to the LSP via the use of a Path Computation Update Request (PCUpd) message.
ACTNフレームワークでは、カスタマーネットワークコントローラ（CNC）は、VNのプロビジョニングを要求する前に、仮想ネットワーク（VN）の要件を満たす可能性があるかどうかを確認するようにMDSCに要求できます。 [RFC6805]で説明されているH-PCEアーキテクチャは、P-PCEとC-PCEの間のパス計算要求と応答（それぞれPCReqとPCRep）メッセージを使用してこの機能をサポートできます。 CNCがVNプロビジョニングを要求すると、MDSCはこの要求を複数のドメイン間LSPプロビジョニング要求に分解します。これは、ドメインごとのパスセグメントにさらに分解される場合があります。これについては、セクション3.3.1で説明します。 MDSCは、P-PCEからC-PCEへのLSP開始要求（PCInitiate）メッセージを使用し、C-PCEはパス計算状態レポート（PCRpt）メッセージを介して状態をP-PCEに報告します。 P-PCEは、Path Computation Update Request（PCUpd）メッセージを使用してLSPを変更できます。
In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as PNCs) along the interdomain path of the LSP.
この場合、P-PCE（MDSCとして）は、LSPのドメイン間パスに沿って複数のC-PCE（PNCとして）と対話します。
Different signaling options for interdomain RSVP-TE are identified in [RFC4726]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. [RFC6805] describes the technique for establishing the optimum path when the sequence of domains is not known in advance.
ドメイン間RSVP-TEのさまざまなシグナリングオプションが[RFC4726]で識別されています。連続LSPは、[RFC3209]および[RFC3473]の手順を使用して実現され、すべてのドメインにまたがる単一のエンドツーエンドLSPを作成します。 [RFC6805]は、ドメインのシーケンスが事前にわからない場合に最適なパスを確立するための手法について説明しています。
That document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived.
そのドキュメントは、PCEアーキテクチャを拡張して、ドメインの最適なシーケンスを選択し、最適なエンドツーエンドパスを導出できるようにする方法を示しています。
A stateful P-PCE has to be aware of the interdomain LSPs for it to consider them during path computation. For instance, when a domain-diverse path is required from another LSP, the P-PCE needs to be aware of the LSP. This is the passive stateful P-PCE, as described in Section 3.1. Additionally, the interdomain LSP could be delegated to the P-PCE, so that P-PCE could trigger an update via a PCUpd message. The update could be triggered on receipt of the PCRpt message that indicates a status change of this LSP or some other LSP. The other LSP could be an associated LSP (such as a protection LSP [RFC8745]) or an unrelated LSP whose resource change leads to reoptimization at the P-PCE. This is the active stateful operation, as described in Section 3.2. Further, the P-PCE could be instructed to create an interdomain LSP on its own using the PCInitiate message for an E2E contiguous LSP. The P-PCE would send the PCInitiate message to the ingress domain C-PCE, which would further instruct the ingress PCC.
ステートフルP-PCEは、パス計算時にドメイン間LSPを考慮するために、ドメイン間LSPを認識する必要があります。たとえば、別のLSPからドメインの多様なパスが必要な場合、P-PCEはLSPを認識する必要があります。これは、セクション3.1で説明されているように、パッシブステートフルP-PCEです。さらに、ドメイン間LSPをP-PCEに委任できるため、P-PCEはPCUpdメッセージを介して更新をトリガーできます。このLSPまたは他のLSPのステータス変更を示すPCRptメッセージを受信すると、更新がトリガーされる可能性があります。他のLSPは、関連するLSP（保護LSP [RFC8745]など）またはリソースの変更がP-PCEでの再最適化につながる無関係なLSPである可能性があります。セクション3.2で説明されているように、これはアクティブなステートフル操作です。さらに、P-PCEは、E2E隣接LSPのPCInitiateメッセージを使用して、独自にドメイン間LSPを作成するように指示できます。 P-PCEはPCInitiateメッセージを入力ドメインC-PCEに送信し、さらに入力PCCに指示します。
In this document, for the contiguous LSP, the above interactions are only between the ingress domain C-PCE and the P-PCE. The use of stateful operations for an interdomain LSP between the transit/egress domain C-PCEs and the P-PCE is out of the scope of this document.
このドキュメントでは、隣接するLSPの場合、上記の相互作用は入力ドメインのC-PCEとP-PCEの間のみです。中継/出口ドメインC-PCEとP-PCE間のドメイン間LSPのステートフル操作の使用は、このドキュメントの範囲外です。
[RFC8051] describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. These are also applicable to the stateful P-PCE when used for the interdomain LSP path computation and setup. It should be noted that though the stateful P-PCE has limited direct visibility inside the child domain, it could still trigger reoptimization with the help of child PCEs based on LSP state changes, abstract topology changes, or some other external factors.
[RFC8051]は、ステートフルPCE展開の一般的な考慮事項を説明し、その適用性と利点、およびその課題と制限を、いくつかのユースケースを通じて検証します。これらは、ドメイン間LSPパスの計算と設定に使用される場合、ステートフルP-PCEにも適用されます。ステートフルP-PCEは子ドメイン内での直接的な可視性が制限されていますが、LSP状態の変更、抽象的なトポロジの変更、またはその他の外部要因に基づく子PCEの助けを借りて再最適化をトリガーできることに注意してください。
The C-PCE would delegate control of the interdomain LSP to the P-PCE so that the P-PCE can make changes to it. Note that, if the C-PCE becomes aware of a topology change that is hidden from the P-PCE, it could take back the delegation from the P-PCE to act on it itself. Similarly, a P-PCE could also request delegation if it needs to make a change to the LSP (refer to [RFC8741]).
C-PCEは、ドメイン間LSPの制御をP-PCEに委任し、P-PCEが変更できるようにします。 C-PCEがP-PCEから隠されているトポロジ変更を認識した場合、それ自体に作用するためにP-PCEからの委任を取り戻すことに注意してください。同様に、LSPを変更する必要がある場合、P-PCEは委任を要求することもできます（[RFC8741]を参照）。
The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8051], [RFC8231], and [RFC8281].
用語は、[RFC4655]、[RFC5440]、[RFC6805]、[RFC8051]、[RFC8231]、および[RFC8281]のとおりです。
Some key terms are listed below for easy reference.
簡単に参照できるように、いくつかの重要な用語を以下に示します。
ACTN: Abstraction and Control of Traffic Engineering Networks
ACTN：トラフィックエンジニアリングネットワークの抽象化と制御
CNC: Customer Network Controller
CNC：カスタマーネットワークコントローラー
C-PCE: Child Path Computation Element
C-PCE：子パス計算要素
H-PCE: Hierarchical Path Computation Element
H-PCE：階層パス計算要素
IGP: Interior Gateway Protocol
IGP：Interior Gateway Protocol
LSP: Label Switched Path
LSP：ラベルスイッチドパス
LSPDB: Label Switched Path Database
LSPDB：ラベルスイッチドパスデータベース
LSR: Label Switching Router
LSR：ラベルスイッチングルーター
MDSC: Multi-Domain Service Coordinator
MDSC：マルチドメインサービスコーディネーター
PCC: Path Computation Client
PCC：パス計算クライアント
PCE: Path Computation Element
PCE：パス計算要素
PCEP: Path Computation Element communication Protocol
PCEP：パス計算要素通信プロトコル
PNC: Provisioning Network Controller
PNC：ネットワークコントローラのプロビジョニング
P-PCE: Parent Path Computation Element
P-PCE：親パス計算要素
TED: Traffic Engineering Database
TED：交通工学データベース
VN: Virtual Network
VN：仮想ネットワーク
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
As described in [RFC6805], in the hierarchical PCE architecture, a P-PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology). Usually, the P-PCE has no information about the content of the child domains. Each child domain has at least one PCE capable of computing paths across the domain. These PCEs are known as Child PCEs (C-PCEs) [RFC6805] and have a direct relationship with the P-PCE. The P-PCE builds the domain topology map either via direct configuration or from learned information received from each C-PCE. The network policy could be applied while building the domain topology map. This has been described in detail in [RFC6805].
[RFC6805]で説明されているように、階層PCEアーキテクチャでは、P-PCEは子トポロジー（トポロジーの頂点として表示）とそれらの相互接続（トポロジーのリンク）を含むドメイントポロジーマップを保持します。通常、P-PCEには子ドメインのコンテンツに関する情報はありません。各子ドメインには、ドメイン全体のパスを計算できるPCEが少なくとも1つあります。これらのPCEは子PCE（C-PCE）[RFC6805]と呼ばれ、P-PCEと直接的な関係があります。 P-PCEは、直接構成を介して、または各C-PCEから受信した学習情報からドメイントポロジマップを構築します。ドメイントポロジマップの構築中にネットワークポリシーを適用できます。これは[RFC6805]で詳細に説明されています。
Note that, in the scope of this document, both the C-PCEs and the P-PCE are stateful in nature.
このドキュメントの範囲では、C-PCEとP-PCEの両方が本質的にステートフルであることに注意してください。
[RFC8231] specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C).
[RFC8231]は、ステートフルPCEをサポートする新しい関数を指定します。また、PCCからPCE（C-E）に向けて、またはPCEからPCC（E-C）に向けて機能を開始できることも指定しています。
This document extends these functions to support H-PCE Architecture from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE (EP-EC). All PCE types herein (EC-EP and EP-EC) are assumed to be "stateful PCE".
このドキュメントでは、これらの機能を拡張して、H-PCEアーキテクチャをC-PCEからP-PCE（EC-EP）に向けて、またはP-PCEからC-PCE（EP-EC）に向けてサポートします。ここでのすべてのPCEタイプ（EC-EPおよびEP-EC）は、「ステートフルPCE」であると見なされます。
A number of interactions are expected in the hierarchical stateful PCE architecture. These include:
階層的なステートフルPCEアーキテクチャでは、多くの相互作用が予想されます。これらには以下が含まれます：
LSP State Report (EC-EP): A child stateful PCE sends an LSP state report to a parent stateful PCE to indicate the state of an LSP.
LSP状態レポート（EC-EP）：子ステートフルPCEは、LSP状態レポートを親ステートフルPCEに送信して、LSPの状態を示します。
LSP State Synchronization (EC-EP): After the session between the child and parent stateful PCEs is initialized, the P-PCE must learn the state of the C-PCE's TE LSPs.
LSP状態同期（EC-EP）：子と親のステートフルPCE間のセッションが初期化された後、P-PCEはC-PCEのTE LSPの状態を学習する必要があります。
LSP Control Delegation (EC-EP, EP-EC): A C-PCE grants to the P-PCE the right to update LSP attributes on one or more LSPs; at any time, the C-PCE may withdraw the delegation or the P-PCE may give up the delegation.
LSP制御委任（EC-EP、EP-EC）：C-PCEは、1つ以上のLSPのLSP属性を更新する権利をP-PCEに付与します。いつでも、C-PCEが委任を撤回するか、P-PCEが委任を放棄する場合があります。
LSP Update Request (EP-EC): A stateful P-PCE requests modification of attributes on a C-PCE's TE LSP.
LSP更新要求（EP-EC）：ステートフルP-PCEは、C-PCEのTE LSPの属性の変更を要求します。
PCE LSP Initiation Request (EP-EC): A stateful P-PCE requests a C-PCE to initiate a TE LSP.
PCE LSP開始要求（EP-EC）：ステートフルP-PCEがC-PCEにTE LSPの開始を要求します。
Note that this hierarchy is recursive, so a Label Switching Router (LSR), as a PCC, could delegate control to a PCE. That PCE may, in turn, delegate to its parent, which may further delegate to its parent (if it exists). Similarly, update operations can also be applied recursively.
この階層は再帰的であるため、PCCとしてのラベルスイッチングルーター（LSR）がPCEに制御を委任できることに注意してください。そのPCEは、次にその親に委任することができ、さらにその親に（それが存在する場合）委任することができます。同様に、更新操作も再帰的に適用できます。
[RFC8685] defines the H-PCE-CAPABILITY TLV that is used in the Open message to advertise the H-PCE capability. [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV used in the Open message to indicate stateful support. To indicate the support for stateful H-PCE operations described in this document, a PCEP speaker MUST include both TLVs in an Open message. It is RECOMMENDED that any implementation that supports stateful operations [RFC8231] and H-PCE [RFC8685] also implement the stateful H-PCE operations as described in this document.
[RFC8685]は、OpenメッセージでH-PCE機能をアドバタイズするために使用されるH-PCE-CAPABILITY TLVを定義します。 [RFC8231]は、ステートフルサポートを示すためにOpenメッセージで使用されるSTATEFUL-PCE-CAPABILITY TLVを定義します。このドキュメントで説明されているステートフルH-PCE操作のサポートを示すために、PCEPスピーカーはOpenメッセージに両方のTLVを含める必要があります。ステートフル操作[RFC8231]とH-PCE [RFC8685]をサポートする実装も、このドキュメントで説明されているステートフルH-PCE操作を実装することをお勧めします。
Further consideration may be made for optional procedures for stateful communication coordination between PCEs, including procedures to minimize computational loops. The procedures described in [PCE-STATE-SYNC] facilitate stateful communication between PCEs for various use cases. The procedures and extensions as described in Section 3 of [PCE-STATE-SYNC] are also applicable to child and parent PCE communication. The SPEAKER-IDENTITY-ID TLV (defined in [RFC8232]) is included in the LSP object to identify the ingress (PCC). The PCEP-specific identifier for the LSP (PLSP-ID [RFC8231]) used in the forwarded PCRpt by the C-PCE to the P-PCE is the same as the original one used by the PCC.
計算ループを最小化する手順を含む、PCE間のステートフル通信調整のオプションの手順について、さらに検討することができます。 [PCE-STATE-SYNC]で説明されている手順は、さまざまなユースケースでPCE間のステートフル通信を容易にします。 [PCE-STATE-SYNC]のセクション3で説明されている手順と拡張は、子と親のPCE通信にも適用できます。 SPEAKER-IDENTITY-ID TLV（[RFC8232]で定義）は、入力（PCC）を識別するためにLSPオブジェクトに含まれています。 C-PCEからP-PCEに転送されたPCRptで使用されるLSPのPCEP固有の識別子（PLSP-ID [RFC8231]）は、PCCで使用される元のIDと同じです。
Procedures described in [RFC6805] are applied, where the ingress PCC triggers a path computation request for the destination towards the C-PCE in the domain where the LSP originates. The C-PCE further forwards the request to the P-PCE. The P-PCE selects a set of candidate domain paths based on the domain topology and the state of the interdomain links. It then sends computation requests to the C-PCEs responsible for each of the domains on the candidate domain paths. Each C-PCE computes a set of candidate path segments across its domain and sends the results to the P-PCE. The P-PCE uses this information to select path segments and concatenate them to derive the optimal end-to-end interdomain path. The end-to-end path is then sent to the C-PCE that received the initial path request, and this C-PCE passes the path on to the PCC that issued the original request.
[RFC6805]で説明されている手順が適用されます。ここで、入力PCCは、LSPが発生するドメインのC-PCEへの宛先のパス計算要求をトリガーします。 C-PCEはさらに要求をP-PCEに転送します。 P-PCEは、ドメイントポロジとドメイン間リンクの状態に基づいて、候補ドメインパスのセットを選択します。次に、候補ドメインパス上の各ドメインを担当するC-PCEに計算要求を送信します。各C-PCEは、そのドメイン全体の一連の候補パスセグメントを計算し、その結果をP-PCEに送信します。 P-PCEはこの情報を使用してパスセグメントを選択し、それらを連結して最適なエンドツーエンドのドメイン間パスを導き出します。エンドツーエンドパスは、最初のパス要求を受信したC-PCEに送信され、このC-PCEは元の要求を発行したPCCにパスを渡します。
As per [RFC8231], the PCC sends an LSP State Report carried on a PCRpt message to the C-PCE, indicating the LSP's status. The C-PCE may further propagate the State Report to the P-PCE. A local policy at the C-PCE may dictate which LSPs are reported to the P-PCE. The PCRpt message is sent from C-PCE to P-PCE.
[RFC8231]のとおり、PCCはLPTのステータスを示すPCRptメッセージで伝送されるLSP状態レポートをC-PCEに送信します。 C-PCEは、状態レポートをP-PCEにさらに伝達できます。 C-PCEのローカルポリシーにより、どのLSPがP-PCEに報告されるかが決まります。 PCRptメッセージはC-PCEからP-PCEに送信されます。
State synchronization mechanisms as described in [RFC8231] and [RFC8232] are applicable to a PCEP session between C-PCE and P-PCE as well.
[RFC8231]と[RFC8232]で説明されている状態同期メカニズムは、C-PCEとP-PCE間のPCEPセッションにも適用できます。
We use the hierarchical domain topology example from [RFC6805] as the reference topology for the entirety of this document. It is shown in Figure 1.
このドキュメント全体の参照トポロジとして、[RFC6805]の階層ドメイントポロジの例を使用します。これを図1に示します。
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
-----------------------------------------------------------------
Figure 1: Hierarchical Domain Topology Example
図1：階層型ドメイントポロジの例
Steps 1 to 11 are exactly as described in Section 4.6.2 of [RFC6805] ("Hierarchical PCE End-to-End Path Computation Procedure"); the following additional steps are added for stateful PCE, to be executed at the end:
ステップ1〜11は、[RFC6805]のセクション4.6.2（「階層型PCEエンドツーエンドパス計算手順」）で説明されているとおりです。最後に実行されるステートフルPCEのために、次の追加ステップが追加されます。
(A) The ingress LSR initiates the setup of the LSP as per the path and reports the LSP status to PCE1 ("GOING-UP").
（A）入力LSRは、パスに従ってLSPのセットアップを開始し、LSPステータスをPCE1（ "GOING-UP"）に報告します。
(B) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（B）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
(C) The ingress LSR notifies PCE1 of the LSP state when the state is "UP".
（C）状態が「UP」の場合、入力LSRはPCE1にLSP状態を通知します。
(D) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（D）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
The ingress LSR could trigger path reoptimization by sending the path computation request as described in [RFC6805]; at this time, it can include the LSP object in the PCReq message, as described in [RFC8231].
[RFC6805]で説明されているように、入力LSRはパス計算要求を送信することにより、パスの再最適化をトリガーできます。このとき、[RFC8231]で説明されているように、PCReqメッセージにLSPオブジェクトを含めることができます。
[RFC8231] describes the case of an active stateful PCE. The active PCE functionality uses two specific PCEP messages:
[RFC8231]は、アクティブなステートフルPCEのケースを説明しています。アクティブなPCE機能は、2つの特定のPCEPメッセージを使用します。
* Update Request (PCUpd)
* 更新リクエスト（PCUpd）
* State Report (PCRpt)
* 状態レポート（PCRpt）
The first is sent by the PCE to a PCC for modifying LSP attributes. The PCC sends back a PCRpt to acknowledge the requested operation or report any change in the LSP's state.
1つ目は、LSE属性を変更するためにPCEからPCCに送信されます。 PCCはPCRptを送り返し、要求された操作を確認するか、LSPの状態の変化を報告します。
As per [RFC8051], delegation is an operation to grant a PCE temporary rights to modify a subset of LSP parameters on the LSPs of one or more PCCs. The C-PCE may further choose to delegate to its P-PCE based on a local policy. The PCRpt message with the "D" (delegate) flag is sent from C-PCE to P-PCE.
[RFC8051]によると、委任は、1つ以上のPCCのLSP上のLSPパラメータのサブセットを変更するための一時的なPCE権限を付与する操作です。 C-PCEはさらに、ローカルポリシーに基づいてP-PCEに委任することを選択できます。 「D」（デリゲート）フラグが付いたPCRptメッセージは、C-PCEからP-PCEに送信されます。
To update an LSP, a PCE sends an LSP Update Request to the PCC using a PCUpd message. For an LSP delegated to a P-PCE via the C-PCE, the P-PCE can use the same PCUpd message to request a change to the C-PCE (the ingress domain PCE). The C-PCE further propagates the update request to the PCC.
LSPを更新するために、PCEはPCUpdメッセージを使用してLSP更新要求をPCCに送信します。 C-PCEを介してP-PCEに委任されたLSPの場合、P-PCEは同じPCUpdメッセージを使用してC-PCE（入力ドメインPCE）への変更を要求できます。 C-PCEはさらに、更新要求をPCCに伝搬します。
The P-PCE uses the same mechanism described in Section 3.1 to compute the end-to-end path using PCReq and PCRep messages.
P-PCEは、セクション3.1で説明したのと同じメカニズムを使用して、PCReqおよびPCRepメッセージを使用するエンドツーエンドパスを計算します。
For active operations, the following steps are required when delegating the LSP, again using the reference architecture described in Figure 1 ("Hierarchical Domain Topology Example").
アクティブな操作の場合、LSPを委任するときは、図1で説明したリファレンスアーキテクチャ（「階層型ドメイントポロジの例」）を使用して、次の手順が必要です。
(A) The ingress LSR delegates the LSP to PCE1 via a PCRpt message with D flag set.
（A）入力LSRは、Dフラグが設定されたPCRptメッセージを介してLSPをPCE1に委任します。
(B) PCE1 further delegates the LSP to the P-PCE (PCE5).
（B）PCE1はさらに、LSPをP-PCE（PCE5）に委任します。
(C) Steps 4 to 10 in Section 4.6.2 of [RFC6805] are executed at P-PCE (PCE5) to determine the end-to-end path.
（C）[RFC6805]のセクション4.6.2のステップ4〜10は、P-PCE（PCE5）で実行され、エンドツーエンドパスを決定します。
(D) The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) via PCUpd message.
（D）P-PCE（PCE5）は、PCUpdメッセージを介して更新要求をC-PCE（PCE1）に送信します。
(E) PCE1 further updates the LSP to the ingress LSR (PCC).
（E）PCE1はさらに、LSPを入力LSR（PCC）に更新します。
(F) The ingress LSR initiates the setup of the LSP as per the path and reports the LSP status to PCE1 ("GOING-UP").
（F）入力LSRは、パスに従ってLSPのセットアップを開始し、LSPステータスをPCE1（ "GOING-UP"）に報告します。
(G) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（G）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
(H) The ingress LSR notifies PCE1 of the LSP state when the state is "UP".
（H）状態が「UP」の場合、入力LSRはPCE1にLSP状態を通知します。
(I) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（I）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
[RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. To instantiate or delete an LSP, the PCE sends the Path Computation LSP initiate request (PCInitiate) message to the PCC. In the case of an interdomain LSP in hierarchical PCE architecture, the initiation operations can be carried out at the P-PCE. In that case, after the P-PCE finishes the E2E path computation, it can send the PCInitiate message to the C-PCE (the ingress domain PCE), and the C-PCE further propagates the initiate request to the PCC.
[RFC8281]は、PCCでのローカル構成を必要とせず、ステートフルPCEモデルでのPCEによって開始されたLSPのセットアップ、メンテナンス、およびティアダウンについて説明し、中央で制御および展開される動的ネットワークを可能にします。 LSPをインスタンス化または削除するために、PCEはパス計算LSP開始要求（PCInitiate）メッセージをPCCに送信します。階層PCEアーキテクチャのドメイン間LSPの場合、開始操作はP-PCEで実行できます。その場合、P-PCEはE2Eパス計算を終了した後、PCInitiateメッセージをC-PCE（入力ドメインPCE）に送信でき、C-PCEはさらに開始要求をPCCに伝達します。
The following steps are performed for PCE-initiated operations, again using the reference architecture described in Figure 1 ("Hierarchical Domain Topology Example"):
次の手順は、PCEによって開始された操作に対して実行されます。これも、図1で説明されているリファレンスアーキテクチャ（「階層型ドメイントポロジの例」）を使用しています。
(A) The P-PCE (PCE5) is requested to initiate an LSP. Steps 4 to 10 in Section 4.6.2 of [RFC6805] are executed to determine the end-to-end path.
（A）P-PCE（PCE5）はLSPを開始するように要求されます。 [RFC6805]のセクション4.6.2のステップ4〜10を実行して、エンドツーエンドパスを決定します。
(B) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE1) via PCInitiate message.
（B）P-PCE（PCE5）は、PCInitiateメッセージを介して子PCE（PCE1）に開始要求を送信します。
(C) PCE1 further propagates the initiate message to the ingress LSR (PCC).
（C）PCE1はさらに、開始メッセージを入力LSR（PCC）に伝播します。
(D) The ingress LSR initiates the setup of the LSP as per the path and reports to PCE1 the LSP status ("GOING-UP").
（D）入力LSRはパスに従ってLSPのセットアップを開始し、LSEステータス（ "GOING-UP"）をPCE1に報告します。
(E) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（E）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
(F) The ingress LSR notifies PCE1 of the LSP state when the state is "UP".
（F）状態が「UP」の場合、入力LSRはPCE1にLSP状態を通知します。
(G) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（G）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
The ingress LSR (PCC) generates the PLSP-ID for the LSP and inform the C-PCE, which is propagated to the P-PCE.
入力LSR（PCC）はLSPのPLSP-IDを生成し、C-PCEに通知します。これはP-PCEに伝達されます。
The hierarchical PCE architecture, as per [RFC6805], is primarily used for E2E LSP. With PCE-initiated capability, another mode of operation is possible, where multiple intradomain LSPs are initiated in each domain and are further stitched to form an E2E LSP. The P-PCE sends PCInitiate message to each C-PCE separately to initiate individual LSP segments along the domain path. These individual per-domain LSPs are stitched together by some mechanism, which is out of the scope of this document (Refer to [STATEFUL-INTERDOMAIN]).
[RFC6805]による階層PCEアーキテクチャは、主にE2E LSPに使用されます。 PCEによって開始される機能では、別の動作モードが可能で、複数のドメイン内LSPが各ドメインで開始され、さらに結合されてE2E LSPを形成します。 P-PCEはPCInitiateメッセージを各C-PCEに個別に送信して、ドメインパスに沿って個々のLSPセグメントを開始します。これらの個別のドメインごとのLSPは、このドキュメントの範囲外であるメカニズムによってステッチされています（[STATEFUL-INTERDOMAIN]を参照）。
The following steps are performed for the per-domain stitched LSP operation, again using the reference architecture described in Figure 1 ("Hierarchical Domain Topology Example"):
次の手順は、図1で説明したリファレンスアーキテクチャ（「階層的なドメイントポロジの例」）を使用して、ドメインごとのステッチLSP操作に対して実行されます。
(A) The P-PCE (PCE5) is requested to initiate an LSP. Steps 4 to 10 in Section 4.6.2 of [RFC6805] are executed to determine the end-to-end path, which is broken into per-domain LSPs. For example:
（A）P-PCE（PCE5）はLSPを開始するように要求されます。 [RFC6805]のセクション4.6.2のステップ4〜10を実行して、ドメインごとのLSPに分割されたエンドツーエンドパスを決定します。例えば：
* S-BN41
* S-BN41
* BN41-BN33
* Bin41-ベナ
* BN33-D
* 数える
It should be noted that the P-PCE may use other mechanisms to determine the suitable per-domain LSPs (apart from [RFC6805]).
P-PCEは他のメカニズムを使用して、適切なドメインごとのLSPを決定できることに注意してください（[RFC6805]を除く）。
For LSP (BN33-D):
LSP（BN33-D）の場合：
(B) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE3) via a PCInitiate message for the LSP (BN33-D).
（B）P-PCE（PCE5）は、LSP（BN33-D）のPCInitiateメッセージを介して子PCE（PCE3）に開始要求を送信します。
(C) PCE3 further propagates the initiate message to BN33.
（C）PCE3はさらに、開始メッセージをBN33に伝搬します。
(D) BN33 initiates the setup of the LSP as per the path and reports to PCE3 the LSP status ("GOING-UP").
（D）BN33は、パスに従ってLSPのセットアップを開始し、PCE3にLSPステータス（「GOING-UP」）を報告します。
(E) PCE3 further reports the status of the LSP to the P-PCE (PCE5).
（E）PCE3はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
(F) The node BN33 notifies PCE3 of the LSP state when the state is "UP".
（Ｆ）ノードＢＮ３３は、状態が「ＵＰ」の場合、ＬＳＰ状態をＰＣＥ３に通知する。
(G) PCE3 further reports the status of the LSP to the P-PCE (PCE5).
（G）PCE3はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
For LSP (BN41-BN33):
LSP（BN41-BN33）の場合：
(H) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE4) via PCInitiate message for LSP (BN41-BN33).
（H）P-PCE（PCE5）は、LSP（BN41-BN33）のPCInitiateメッセージを介して子PCE（PCE4）に開始要求を送信します。
(I) PCE4 further propagates the initiate message to BN41.
（I）PCE4はさらに開始メッセージをBN41に伝搬します。
(J) BN41 initiates the setup of the LSP as per the path and reports to PCE4 the LSP status ("GOING-UP").
（J）BN41はパスに従ってLSPのセットアップを開始し、PCE4にLSPステータス（「GOING-UP」）を報告します。
(K) PCE4 further reports the status of the LSP to the P-PCE (PCE5).
（K）PCE4はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
(L) The node BN41 notifies PCE4 of the LSP state when the state is "UP".
（Ｌ）ノードＢＮ４１は、状態が「ＵＰ」の場合、ＬＳＰ状態をＰＣＥ４に通知する。
(M) PCE4 further reports the status of the LSP to the P-PCE (PCE5).
（M）PCE4はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
For LSP (S-BN41):
LSP（S-BN41）の場合：
(N) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE1) via a PCInitiate message for the LSP (S-BN41).
（N）P-PCE（PCE5）は、LSP（S-BN41）のPCInitiateメッセージを介して子PCE（PCE1）に開始要求を送信します。
(O) PCE1 further propagates the initiate message to node S.
（O）PCE1はさらに、開始メッセージをノードSに伝播します。
(P) S initiates the setup of the LSP as per the path and reports to PCE1 the LSP status ("GOING-UP").
（P）Sは、パスに従ってLSPのセットアップを開始し、PCE1にLSPステータス（「GOING-UP」）を報告します。
(Q) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（Q）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
(R) The node S notifies PCE1 of the LSP state when the state is "UP".
（Ｒ）ノードＳは、状態が「ＵＰ」の場合、ＬＳＰ状態をＰＣＥ１に通知する。
(S) PCE1 further reports the status of the LSP to the P-PCE (PCE5).
（S）PCE1はさらに、LSPのステータスをP-PCE（PCE5）に報告します。
Additionally:
さらに：
(T) Once the P-PCE receives a report of each per-domain LSP, it should use a suitable stitching mechanism, which is out of the scope of this document. In this step, the P-PCE (PCE5) could also initiate an E2E LSP (S-D) by sending the PCInitiate message to the ingress C-PCE (PCE1).
（T）P-PCEが各ドメインLSPのレポートを受信すると、適切なスティッチングメカニズムを使用する必要がありますが、これはこのドキュメントの範囲外です。このステップでは、P-PCE（PCE5）は、PCInitiateメッセージを入力C-PCE（PCE1）に送信することにより、E2E LSP（S-D）を開始することもできます。
Note that each per-domain LSP can be set up in parallel. Further, it is also possible to stitch the per-domain LSP at the same time as the per-domain LSPs are initiated. This option is defined in [STATEFUL-INTERDOMAIN].
ドメインごとの各LSPを並行して設定できることに注意してください。さらに、ドメインごとのLSPが開始されると同時に、ドメインごとのLSPをステッチすることもできます。このオプションは、[STATEFUL-INTERDOMAIN]で定義されています。
The security considerations listed in [RFC8231], [RFC6805], and [RFC5440] apply to this document, as well. As per [RFC6805], it is expected that the parent PCE will require all child PCEs to use full security (i.e., the highest security mechanism available for PCEP) when communicating with the parent.
[RFC8231]、[RFC6805]、および[RFC5440]に記載されているセキュリティの考慮事項は、このドキュメントにも適用されます。 [RFC6805]によると、親PCEは、親との通信時にすべての子PCEが完全なセキュリティ（つまり、PCEPで利用可能な最高のセキュリティメカニズム）を使用することを要求することが予想されます。
Any multidomain operation necessarily involves the exchange of information across domain boundaries. This is bound to represent a significant security and confidentiality risk, especially when the child domains are controlled by different commercial concerns. PCEP allows individual PCEs to maintain the confidentiality of their domain-path information using path-keys [RFC5520], and the hierarchical PCE architecture is specifically designed to enable as much isolation of information about domain topology and capabilities as is possible. The LSP state in the PCRpt message must continue to maintain the internal domain confidentiality when required.
マルチドメイン操作では、必ずドメイン境界を越えた情報の交換が必要です。これは、特に子ドメインがさまざまな商業的関心事によって制御されている場合、重大なセキュリティと機密性のリスクを表すことになります。 PCEPは、個々のPCEがパスキー[RFC5520]を使用してドメインパス情報の機密性を維持できるようにします。階層PCEアーキテクチャは、ドメイントポロジと機能に関する情報を可能な限り分離できるように特別に設計されています。 PCRptメッセージのLSP状態は、必要に応じて内部ドメインの機密性を維持し続ける必要があります。
The security considerations for PCE-initiated LSP in [RFC8281] are also applicable from P-PCE to C-PCE.
[RFC8281]のPCEによって開始されるLSPのセキュリティに関する考慮事項は、P-PCEからC-PCEにも適用できます。
Further, Section 6.3 describes the use of a path-key [RFC5520] for confidentiality between C-PCE and P-PCE.
さらに、セクション6.3では、C-PCEとP-PCE間の機密性のためのパスキー[RFC5520]の使用について説明しています。
Thus, it is RECOMMENDED to secure the PCEP session (between the P-PCE and the C-PCE) using Transport Layer Security (TLS) [RFC8446] (per the recommendations and best current practices in BCP 195 [RFC7525]) and/or TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for implementing PCEP with TLS can be found in [RFC8253].
したがって、トランスポート層セキュリティ（TLS）[RFC8446]（BCP 195 [RFC7525]の推奨事項と現在のベストプラクティスに従って）を使用してPCEPセッション（P-PCEとC-PCEの間）を保護することをお勧めします。 TCP認証オプション（TCP-AO）[RFC5925]。 TLSでPCEPを実装するためのガイダンスは、[RFC8253]にあります。
In the case of TLS, due care needs to be taken while exposing the parameters of the X.509 certificate -- such as subjectAltName:otherName, which is set to Speaker Entity Identifier [RFC8232] as per [RFC8253] -- to ensure uniqueness and avoid any mismatch.
TLSの場合、X.509証明書のパラメーター（subjectAltName：otherNameなど）を公開する際には十分な注意を払う必要があります。subjectAltName：otherNameは、[RFC8253]に従ってSpeaker Entity Identifier [RFC8232]に設定されています。ミスマッチを避けます。
All manageability requirements and considerations listed in [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to stateful H-PCE defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]、[RFC6805]、[RFC8231]、および[RFC8281]にリストされているすべての管理要件と考慮事項は、このドキュメントで定義されているステートフルH-PCEに適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
Support of the hierarchical procedure will be controlled by the management organization responsible for each child PCE. The parent PCE must only accept path-computation requests from authorized child PCEs. If a parent PCE receives a report from an unauthorized child PCE, the report should be dropped. All mechanisms described in [RFC8231] and [RFC8281] continue to apply.
階層的手順のサポートは、各子PCEを担当する管理組織によって制御されます。親PCEは、許可された子PCEからのパス計算要求のみを受け入れる必要があります。親PCEが無許可の子PCEからレポートを受け取った場合、そのレポートはドロップする必要があります。 [RFC8231]と[RFC8281]で説明されているすべてのメカニズムが引き続き適用されます。
An implementation should allow the operator to view the stateful and H-PCE capabilities advertised by each peer. The "ietf-pcep" PCEP YANG module is specified in [PCE-PCEP-YANG]. This YANG module will be required to be augmented to also include details for stateful H-PCE deployment and operation. The exact model and attributes are out of scope for this document.
実装では、オペレーターが各ピアによってアドバタイズされるステートフルおよびH-PCE機能を表示できるようにする必要があります。 "ietf-pcep" PCEP YANGモジュールは[PCE-PCEP-YANG]で指定されています。このYANGモジュールは、ステートフルH-PCEの展開と操作の詳細も含めるように拡張する必要があります。正確なモデルと属性は、このドキュメントの範囲外です。
Mechanisms defined in this document do not imply any new liveness-detection or monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出または監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation-verification requirements in addition to those already listed in [RFC5440] and [RFC8231].
このドキュメントで定義されているメカニズムは、[RFC5440]と[RFC8231]にすでにリストされているものに加えて、新しい動作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルに対する新しい要件を意味するものではありません。
Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document.
[RFC5440]と[RFC8231]で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張にも適用されます。
The stateful H-PCE technique brings the applicability of stateful PCE (described in [RFC8051]) to the LSP traversing multiple domains.
ステートフルH-PCE技法は、ステートフルPCE（[RFC8051]で説明）の適用可能性を、複数のドメインを横断するLSPにもたらします。
As described in Section 3, a PCEP speaker includes both the H-PCE-CAPABILITY TLV [RFC8685] and STATEFUL-PCE-CAPABILITY TLV [RFC8231] to indicate support for stateful H-PCE. Note that there is a possibility of a PCEP speaker that does not support the stateful H-PCE feature but does provide support for stateful-PCE [RFC8231] and H-PCE [RFC8685] features. This PCEP speaker will also include both the TLVs; in this case, a PCEP peer could falsely assume that the stateful H-PCE feature is also supported. On further PCEP message exchange, the stateful messages will not be propagated further (as described in this document), and a stateful H-PCE-based "parent" control of the LSP will not happen. A PCEP peer should be prepared for this eventuality as a part of normal procedures.
セクション3で説明したように、PCEPスピーカーにはH-PCE-CAPABILITY TLV [RFC8685]とSTATEFUL-PCE-CAPABILITY TLV [RFC8231]の両方が含まれ、ステートフルH-PCEのサポートを示します。ステートフルH-PCE機能をサポートしないが、ステートフルPCE [RFC8231]およびH-PCE [RFC8685]機能をサポートするPCEPスピーカーの可能性があることに注意してください。このPCEPスピーカーには、両方のTLVも含まれます。この場合、PCEPピアは、ステートフルH-PCE機能もサポートされていると誤って想定する可能性があります。以降のPCEPメッセージ交換では、ステートフルメッセージはそれ以上伝播されず（このドキュメントで説明されています）、LSPのステートフルH-PCEベースの「親」制御は行われません。 PCEPピアは、通常の手順の一部として、このような事態に備えて準備する必要があります。
Apart from the basic error handling described in this document, an implementation could also use the enhanced error and notification mechanism for stateful H-PCE operations described in [PCE-ENHANCED-ERRORS]. Enhanced features such as error-behavior propagation, notification, and error-criticality level are further defined in [PCE-ENHANCED-ERRORS].
このドキュメントで説明されている基本的なエラー処理とは別に、実装では、[PCE-ENHANCED-ERRORS]で説明されているステートフルH-PCE操作の拡張エラーおよび通知メカニズムを使用することもできます。エラー動作の伝播、通知、エラーの重要度レベルなどの拡張機能は、[PCE-ENHANCED-ERRORS]でさらに定義されています。
[RFC5623] describes a framework for applying the PCE-based architecture to interlayer (G)MPLS traffic engineering. The H-PCE stateful architecture with stateful P-PCE coordinating with the stateful C-PCEs of higher and lower layer is shown in Figure 2.
[RFC5623]は、PCEベースのアーキテクチャを中間層（G）MPLSトラフィックエンジニアリングに適用するためのフレームワークについて説明しています。上位層と下位層のステートフルC-PCEと連携するステートフルP-PCEを備えたH-PCEステートフルアーキテクチャを図2に示します。
+----------+
| Parent |
/| PCE |
/ +----------+
/ / Stateful
/ / P-PCE
/ /
/ /
Stateful+-----+ / /
C-PCE | PCE |/ /
Hi | Hi | /
+-----+ /
+---+ +---+ / +---+ +---+
+ LSR +--+ LSR +........................+ LSR +--+ LSR +
+ H1 + + H2 + / + H3 + + H4 +
+---+ +---+\ +-----+/ /+---+ +---+
\ | PCE | /
\ | Lo | /
Stateful \ +-----+ /
C-PCE \ /
Lo \+---+ +---+/
+ LSR +--+ LSR +
+ L1 + + L2 +
+---+ +---+
Figure 2: Sample Interlayer Topology
図2：サンプルインターレイヤートポロジ
All procedures described in Section 3 are also applicable to interlayer path setup, and therefore to separate domains.
セクション3で説明されているすべての手順は、層間パスの設定にも適用できるため、ドメインを分離することもできます。
It should be noted that if all the C-PCEs were to report all the LSPs in their domain, it could lead to scalability issues for the P-PCE. Thus, it is recommended to only report the LSPs that are involved in H-PCE -- i.e., the LSPs that are either delegated to the P-PCE or initiated by the P-PCE. Scalability considerations for PCEP as per [RFC8231] continue to apply for the PCEP session between child and parent PCE.
すべてのC-PCEがドメイン内のすべてのLSPを報告すると、P-PCEのスケーラビリティの問題につながる可能性があることに注意してください。したがって、H-PCEに関係するLSP、つまりP-PCEに委任された、またはP-PCEによって開始されたLSPのみを報告することをお勧めします。 [RFC8231]によるPCEPのスケーラビリティの考慮事項は、子PCEと親PCE間のPCEPセッションに引き続き適用されます。
As described in Section 4.2 of [RFC6805], information about the content of child domains is not shared, for both scaling and confidentiality reasons. The child PCE could also conceal the path information during path computation. A C-PCE may replace a path segment with a path-key [RFC5520], effectively hiding the content of a segment of a path.
[RFC6805]のセクション4.2で説明されているように、子ドメインのコンテンツに関する情報は、スケーリングと機密保持の両方の理由で共有されません。子PCEは、パス計算中にパス情報を隠すこともできます。 C-PCEは、パスセグメントをパスキー[RFC5520]に置き換えて、パスのセグメントのコンテンツを効果的に隠すことができます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。
[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 Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、DOI 10.17487 / RFC5440、March 2009、<https://www.rfc-editor.org/info/rfc5440>
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<https://www.rfc-editor.org/info/rfc5520>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info / rfc5925>。
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド。およびA.ファレル編、「MPLSおよびGMPLSにおける一連のドメインの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、DOI 10.17487 / RFC6805、2012年11月、<https：//www.rfc -editor.org/info/rfc6805>。
[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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[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、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、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 Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（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）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<https://www.rfc-editor.org/info/rfc8281>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[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. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, <https://www.rfc-editor.org/info/rfc4726>.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「A Interframe for Inter-domain Multiprotocol Label Switching Traffic Engineering」、RFC 4726、DOI 10.17487 / RFC4726、2006年11月、<https：/ /www.rfc-editor.org/info/rfc4726>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖E.、武田T.、ルルーJL、およびA.ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、DOI 10.17487 / RFC5623、2009年9月、<https://www.rfc-editor.org/info/rfc5623>。
[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]張、X。、エド。 I. Minei、編、「Stateful Path Computation Element（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[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.、Medved、J.、Varga、R.、Zhang、X。、およびD. Dhody、「ステートフルPCEのラベルスイッチドパスステート同期手順の最適化」、RFC 8232 、DOI 10.17487 / RFC8232、2017年9月、<https://www.rfc-editor.org/info/rfc8232>。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、Ed。 Y.リー、編、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453> 。
[RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", RFC 8637, DOI 10.17487/RFC8637, July 2019, <https://www.rfc-editor.org/info/rfc8637>.
[RFC8637] Dhody、D.、Lee、Y。、およびD. Ceccarelli、「パス計算要素（PCE）のTEネットワークの抽象化および制御（ACTN）への適用性」、RFC 8637、DOI 10.17487 / RFC8637、7月2019、<https://www.rfc-editor.org/info/rfc8637>。
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, "Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture", RFC 8685, DOI 10.17487/RFC8685, December 2019, <https://www.rfc-editor.org/info/rfc8685>.
[RFC8685] Zhang、F.、Zhao、Q.、Gonzalez de Dios、O.、Casellas、R.、and D. King、 "Path Computation Element Communication Protocol（PCEP）Extensions for the Hierarchical Path Computation Element（H-PCE ）アーキテクチャ」、RFC 8685、DOI 10.17487 / RFC8685、2019年12月、<https://www.rfc-editor.org/info/rfc8685>。
[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.、and M. Negi、 "Ability for a Stateful Path Computation Element（PCE）to Request and Control of a Label Switched Path（ LSP）」、RFC 8741、DOI 10.17487 / RFC8741、2020年3月、<https://www.rfc-editor.org/info/rfc8741>。
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE", RFC 8745, DOI 10.17487/RFC8745, March 2020, <https://www.rfc-editor.org/info/rfc8745>.
[RFC8745] Ananthakrishnan、H.、Sivabalan、S.、Barth、C.、Minei、I。、およびM. Negi、「作業および保護ラベルスイッチドパス（LSP）を関連付けるためのパス計算要素通信プロトコル（PCEP）拡張機能ステートフルPCE」、RFC 8745、DOI 10.17487 / RFC8745、2020年3月、<https://www.rfc-editor.org/info/rfc8745>。
[PCE-ENHANCED-ERRORS] Poullyau, H., Theillaud, R., Meuric, J., Zheng, H., and X. Zhang, "Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications", Work in Progress, Internet-Draft, draft-ietf-pce-enhanced-errors-06, 14 August 2019, <https://tools.ietf.org/html/draft-ietf-pce-enhanced-errors-06>.
[PCE-ENHANCED-ERRORS] Poullyau、H.、Theillaud、R.、Meuric、J.、Zheng、H。、およびX. Zhang、「拡張エラーと通知のためのパス計算要素通信プロトコルの拡張」、Work in Progress、Internet-Draft、draft-ietf-pce-enhanced-errors-06、2019年8月14日、<https://tools.ietf.org/html/draft-ietf-pce-enhanced-errors-06>。
[PCE-PCEP-YANG] Dhody, D., 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-13, 31 October 2019, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[PCE-PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V.、J。Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、インターネットドラフト、draft-ietf-pce-pcep-yang-13、2019年10月31日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>。
[PCE-STATE-SYNC] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Work in Progress, Internet-Draft, draft-litkowski-pce-state-sync-07, 11 January 2020, <https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07>.
[PCE-STATE-SYNC] Litkowski、S.、Sivabalan、S.、Li、C。、およびH. Zheng、「Inter Stateful Path Computation Element（PCE）Communication Procedures。」、Work in Progress、Internet-Draft、draft -litkowski-pce-state-sync-07、2020年1月11日、<https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07>。
[STATEFUL-INTERDOMAIN] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Extension for Stateful Inter-Domain Tunnels", Work in Progress, Internet-Draft, draft-dugeon-pce-stateful-interdomain-02, 4 March 2019, <https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-02>.
[STATEFUL-INTERDOMAIN] Dugeon、O.、Meuric、J.、Lee、Y。、およびD. Ceccarelli、「ステートフルドメイン間トンネルのPCEP拡張機能」、進行中の作業、インターネットドラフト、draft-dugeon-pce- stateful-interdomain-02、2019年3月4日、<https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-02>。
Acknowledgments
謝辞
Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel, and Haomian Zheng for their reviews and suggestions.
Manuela Scarella、Haomian Zheng、Sergio Marmo、Stefano Parodi、Giacomo Agostini、Jeff Tantsura、Rajan Rao、Adrian Farrel、Haomian Zhengのレビューと提案に感謝します。
Thanks to Tal Mazrahi for the RTGDIR review, Paul Kyzivat for the GENART review, and Stephen Farrell for the SECDIR review.
RTGDIRのレビューはTal Mazrahi、GENARTのレビューはPaul Kyzivat、SECDIRのレビューはStephen Farrellに感謝します。
Thanks to Barry Leiba, Martin Vigoureux, Benjamin Kaduk, and Roman Danyliw for the IESG review.
IESGのレビューを提供してくれたBarry Leiba、Martin Vigoureux、Benjamin Kaduk、Roman Danyliwに感謝します。
Contributors
貢献者
Avantika ECI Telecom India
Avantika ECI Telecom India
Email: avantika.srm@gmail.com
Xian Zhang Huawei Technologies Bantian, Longgang District Guangdong Shenzhen, 518129 China
X Ian Zhang hu Aは技術禁止日、長いギャング地区関G建物Sは非常に現実的です、518129中国
Email: zhang.xian@huawei.com
Udayasree Palle
うだささりパレ
Email: udayasreereddy@gmail.com
Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz 82-84 28045 Madrid Spain
オスカーゴンザレスデディオステレフォニカI + Dドンラモンデラクルス82-84 28045マドリードスペイン
Phone: +34913128832
Email: oscar.gonzalezdedios@telefonica.com
Authors' Addresses
著者のアドレス
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Dhruv Dhodoi Huawei Technologies Divyashari Techno Park、Whitfished Bangalore 2008 Karnataka India
Email: dhruv.ietf@gmail.com
Young Lee Samsung Electronics
ヤングリーサムスンエレクトロニクス
Email: younglee.tx@gmail.com
Daniele Ceccarelli Ericsson Torshamnsgatan, 48 SE- Stockholm Sweden
Daniele Ceccarelli Ericsson Torshamnsgatan、48 SE-ストックホルムスウェーデン
Email: daniele.ceccarelli@ericsson.com
Jongyoon Shin SK Telecom 6 Hwangsaeul-ro, 258 beon-gil Bundang-gu, Seongnam-si, Gyeonggi-do 463-784 Republic of Korea
Jongyoon Shin SK Telecom 6 Hwangsaeul-ro、258 beon-gil盆唐区京畿道城南市463-784韓国
Email: jongyoon.shin@sk.com
Daniel King Lancaster University United Kingdom
ダニエルキングランカスター大学イギリス
Email: d.king@lancaster.ac.uk