[要約] RFC 8623は、Point-to-Multipoint TE Label Switched Paths（LSPs）と一緒に使用するためのStateful Path Computation Element（PCE）プロトコルの拡張に関するものです。このRFCの目的は、PCEとLSPの組み合わせにおいて、状態を保持するPCEの機能を提供することです。
Internet Engineering Task Force (IETF) U. Palle
Request for Comments: 8623 D. Dhody
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 Y. Tanaka
NTT Communications
V. Beeram
Juniper Networks
June 2019
Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
ポイントツーマルチポイントTEラベルスイッチドパス（LSP）で使用するためのステートフルパス計算要素（PCE）プロトコル拡張
Abstract
概要
The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.
パス計算エレメント（PCE）は、ポイントツーマルチポイント（P2MP）TEラベルスイッチドパス（LSP）のパスを決定するための適切なテクノロジーとして識別されています。このドキュメントでは、P2MP TE LSPのサポートにおけるステートフルPCE機能の使用を可能にするために、パス計算要素通信プロトコル（PCEP）に必要な拡張機能を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8623.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8623で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Supporting P2MP TE LSPs for Stateful PCE . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5
4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5
5. Architectural Overview of Protocol Extensions . . . . . . . . 6
5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6
5.2. Capability Advertisement . . . . . . . . . . . . . . . . 7
5.3. IGP Extensions for Stateful PCE P2MP Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 7
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9
5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 9
5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9
5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9
5.6.3.1. P2MP TE LSPs Instantiation . . . . . . . . . . . 9
5.6.3.2. P2MP TE LSPs Deletion . . . . . . . . . . . . . . 10
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10
5.6.3.4. P2MP TE LSPs Delegation and Cleanup . . . . . . . 10
6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 11
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 15
6.5. The PCInitiate Message . . . . . . . . . . . . . . . . . 16
6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.6.1. P2MP TE LSPs Update Request . . . . . . . . . . . . . 17
6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17
6.6.3. P2MP TE LSPs Initiation Request . . . . . . . . . . . 18
7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 19
7.1. LSP Object Extension . . . . . . . . . . . . . . . . . . 19
7.1.1. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . 19
7.2. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23
8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23
8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23
8.3. PCInitiate Fragmentation Procedure . . . . . . . . . . . 24
9. Nonsupport of P2MP TE LSPs for Stateful PCE . . . . . . . . . 24
10. Manageability Considerations . . . . . . . . . . . . . . . . 25
10.1. Control of Function and Policy . . . . . . . . . . . . . 25
10.2. Information and Data Models . . . . . . . . . . . . . . 25
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 26
10.5. Requirements on Other Protocols . . . . . . . . . . . . 26
10.6. Impact on Network Operations . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26
11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26
11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27
11.4. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . 27
11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28
11.6. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28
11.7. S2LS Object . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
As per [RFC4655], the Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4655]によると、パス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算制約を適用できるエンティティです。パス計算クライアント（PCC）は、パスを計算するようにPCEに要求する場合があります。
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. [RFC5671] examines the applicability of PCE for the path computation for P2MP TE LSPs.
[RFC4875]は、マルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークで使用するポイントツーマルチポイント（P2MP）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）を設定する方法を説明しています。 [RFC5671]は、P2MP TE LSPのパス計算に対するPCEの適用性を調べます。
The PCEP is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. The extensions of PCEP to request path computation for P2MP TE LSPs are described in [RFC8306].
PCEPは、ポイントツーポイント（P2P）パス計算のためのPCCとPCE間の通信プロトコルとして設計されており、[RFC5440]で定義されています。 P2MP TE LSPのパス計算を要求するためのPCEPの拡張は、[RFC8306]で説明されています。
Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [RFC8051]. These scenarios apply equally to P2P and P2MP TE LSPs. [RFC8231] provides the fundamental extensions to PCEP needed for stateful PCE to support general functionality for P2P TE LSP. [RFC8281] provides extensions to PCEP needed for stateful PCE-initiated P2P TE LSP. This document complements that work by focusing on PCEP extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs. This document describes the setup, maintenance, and teardown of PCE-initiated P2MP LSPs under the stateful PCE model.
[RFC8051]に示されているように、ステートフルPCEは、MPLSネットワークとGMPLSネットワークの両方で、多くのアプリケーションシナリオで役立つことが示されています。これらのシナリオは、P2PおよびP2MP TE LSPに等しく適用されます。 [RFC8231]は、ステートフルPCEがP2P TE LSPの一般的な機能をサポートするために必要なPCEPの基本的な拡張機能を提供します。 [RFC8281]は、ステートフルPCEによって開始されるP2P TE LSPに必要なPCEPの拡張機能を提供します。このドキュメントは、ステートフルPCEの展開がP2MP TE LSPをサポートするために必要なPCEP拡張に焦点を当てることにより、その機能を補足します。このドキュメントでは、ステートフルPCEモデルでのPCEによって開始されるP2MP LSPのセットアップ、メンテナンス、およびティアダウンについて説明します。
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]で説明されているように解釈されます。
Terminology used in this document is the same as terminology used in [RFC8231], [RFC8281], and [RFC8306].
このドキュメントで使用されている用語は、[RFC8231]、[RFC8281]、および[RFC8306]で使用されている用語と同じです。
[RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc., which are equally applicable to P2MP TE LSPs. [RFC8231] defines the extensions to PCEP needed for stateful operation of P2P TE LSPs. This document complements the previous work by focusing on extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs.
[RFC8051]は、P2MP TE LSPに等しく適用できる、最適化、リカバリなどを含むステートフルPCEの展開からメリットを得るシナリオを示すいくつかの使用例を示しています。 [RFC8231]は、P2P TE LSPのステートフル操作に必要なPCEPへの拡張を定義しています。このドキュメントは、ステートフルPCEの展開がP2MP TE LSPをサポートするために必要な拡張に焦点を当てることにより、以前の作業を補足します。
In addition to that, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via a PCEP-specific LSP identifier (PLSP-ID) ([RFC8231]). For P2MP, where the size of the message is much larger, this is an added advantage. When using a stateless PCE, a request to modify an existing P2MP tree requires that all the leaves are presented in the PCEP messages along with all the path information. But when using a stateful PCE, the PCEP messages can use a PLSP-ID to represent all information about the LSP that has previously been exchanged in PCEP messages, and it is only necessary to encode the modifications (such as new or removed leaf nodes). The PLSP-ID provides an index into the LSP-DB at the PCE and identifies the LSP at the PCC.
さらに、PCEP固有のLSP識別子（PLSP-ID）（[RFC8231]）を介してLSPを参照できるため、PCEのステートフルな性質により、PCEPメッセージで伝達される情報が簡略化されます。メッセージのサイズがはるかに大きいP2MPの場合、これは追加の利点です。ステートレスPCEを使用する場合、既存のP2MPツリーを変更する要求では、すべてのリーフがすべてのパス情報とともにPCEPメッセージで提示される必要があります。ただし、ステートフルPCEを使用する場合、PCEPメッセージはPLSP-IDを使用して、以前にPCEPメッセージで交換されたLSPに関するすべての情報を表すことができ、変更（新しいリーフノードや削除されたリーフノードなど）をエンコードするだけで済みます。 。 PLSP-IDは、PCEでLSP-DBへのインデックスを提供し、PCCでLSPを識別します。
In environments where the P2MP TE LSPs placement needs to change in response to application demands, it is useful to support dynamic creation and tear down of P2MP TE LSPs. The ability for a PCE to trigger the creation of P2MP TE LSPs on demand can be seamlessly integrated into a controller-based network architecture where intelligence in the controller can determine when and where to set up paths. Section 3 of [RFC8281] further describes the motivation behind the PCE-Initiation capability, which is equally applicable to P2MP TE LSPs.
アプリケーションの要求に応じてP2MP TE LSPの配置を変更する必要がある環境では、P2MP TE LSPの動的な作成と破棄をサポートすると便利です。 PCEがオンデマンドでP2MP TE LSPの作成をトリガーする機能は、コントローラーベースのネットワークアーキテクチャにシームレスに統合でき、コントローラーのインテリジェンスがパスをセットアップするタイミングと場所を決定できます。 [RFC8281]のセクション3では、PCE-Initiation機能の背後にある動機についてさらに説明しています。これは、P2MP TE LSPにも同様に適用できます。
The objectives for the protocol extensions to support P2MP TE LSPs for stateful PCE are the same as the objectives described in Section 3.2 of [RFC8231].
ステートフルPCEのP2MP TE LSPをサポートするためのプロトコル拡張の目的は、[RFC8231]のセクション3.2で説明されている目的と同じです。
[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 P2MP TE LSPs:
このドキュメントでは、これらの機能を拡張してP2MP TE LSPをサポートします。
Capability Advertisement (E-C,C-E): Both the PCC and the PCE must announce during PCEP session establishment that they support Stateful PCE extensions for P2MP using mechanisms defined in Section 5.2.
ケイパビリティアドバタイズメント（E-C、C-E）：PCCとPCEの両方が、PCEPセッションの確立中に、セクション5.2で定義されたメカニズムを使用してP2MPのステートフルPCE拡張をサポートすることを通知する必要があります。
LSP State Synchronization (C-E): After the session between the PCC and a stateful PCE with P2MP capability is initialized, the PCE must learn the state of a PCC's P2MP TE LSPs before it can perform path computations or update LSP attributes in a PCC.
LSP状態同期（C-E）：PCCとP2MP機能を持つステートフルPCE間のセッションが初期化された後、PCEは、PCCでパス計算を実行したり、LSP属性を更新したりする前に、PCCのP2MP TE LSPの状態を学習する必要があります。
LSP Update Request (E-C): A stateful PCE with P2MP capability requests modification of attributes on a PCC's P2MP TE LSPs.
LSP更新要求（E-C）：P2MP機能を持つステートフルPCEは、PCCのP2MP TE LSPの属性の変更を要求します。
LSP State Report (C-E): A PCC sends an LSP state report to a PCE whenever the state of a P2MP TE LSP changes.
LSP状態レポート（C-E）：PCCは、P2MP TE LSPの状態が変化するたびにLSP状態レポートをPCEに送信します。
LSP Control Delegation (C-E,E-C): A PCC grants to a PCE the right to update LSP attributes on one or more P2MP TE LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (See Section 5.7 of [RFC8231]); the PCC may withdraw the delegation or the PCE may give up the delegation at any time.
LSP制御委任（C-E、E-C）：PCCは、1つ以上のP2MP TE LSPのLSP属性を更新する権利をPCEに付与します。 PCEは、委任が有効である限り、LSPの属性の信頼できるソースになります（[RFC8231]のセクション5.7を参照）。 PCCは委任を撤回する場合があり、PCEはいつでも委任を放棄する場合があります。
PCE-initiated LSP instantiation (E-C): A PCE sends an LSP Initiate Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281].
PCEによって開始されるLSPインスタンス化（E-C）：PCEは、LSC開始メッセージをPCCに送信して、P2MP TE LSP [RFC8281]をインスタンス化または削除します。
Two new PCEP messages are defined in [RFC8231] to support stateful PCE for P2P TE LSPs. In this document, these messages are extended as follows to support P2MP TE LSPs.
P2P TE LSPのステートフルPCEをサポートするために、2つの新しいPCEPメッセージが[RFC8231]で定義されています。このドキュメントでは、P2MP TE LSPをサポートするために、これらのメッセージが次のように拡張されています。
Path Computation State Report (PCRpt): Each P2MP TE LSP State Report in a PCRpt message contains the actual P2MP TE LSP path attributes, the LSP status, etc. An LSP State Report carried in a PCRpt message is also used in delegation or revocation of control of a P2MP TE LSP to/from a PCE. The extension of PCRpt messages is described in Section 6.1.
パス計算状態レポート（PCRpt）：PCRptメッセージ内の各P2MP TE LSP状態レポートには、実際のP2MP TE LSPパス属性、LSPステータスなどが含まれます。PCRptメッセージで伝送されるLSP状態レポートは、委任または取り消しにも使用されます。 PCEとの間のP2MP TE LSPの制御。 PCRptメッセージの拡張については、セクション6.1で説明します。
Path Computation Update Request (PCUpd): Each P2MP TE LSP Update Request in a PCUpd message MUST contain all LSP parameters that a PCE wishes to set for a given P2MP TE LSP. An LSP Update Request carried in a PCUpd message is also used to return LSP delegations if at any point the PCE no longer desires control of a P2MP TE LSP. The PCUpd message is described in Section 6.2.
パス計算更新要求（PCUpd）：PCUpdメッセージ内の各P2MP TE LSP更新要求には、PCEが特定のP2MP TE LSPに設定したいすべてのLSPパラメータが含まれている必要があります。 PCUpdメッセージで伝送されるLSP更新要求は、PCEがP2MP TE LSPの制御を必要としなくなった場合に、LSP委任を返すためにも使用されます。 PCUpdメッセージについては、セクション6.2で説明します。
Further, a new PCEP message is defined in [RFC8281] to support stateful PCE instantiation of P2P TE LSPs. In this document, this message is extended as follows to support P2MP TE LSPs.
さらに、P2P TE LSPのステートフルPCEインスタンス化をサポートするために、新しいPCEPメッセージが[RFC8281]で定義されています。このドキュメントでは、このメッセージはP2MP TE LSPをサポートするために次のように拡張されています。
Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a PCEP message sent by a PCE to a PCC to trigger the instantiation or deletion of a P2MP TE LSP. The PCInitiate message is described in Section 6.5.
パス計算LSP開始メッセージ（PCInitiate）：PCInitiateは、PCEからPCCに送信されるPCEPメッセージで、P2MP TE LSPのインスタンス化または削除をトリガーします。 PCInitiateメッセージについては、セクション6.5で説明します。
The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages are also extended to support passive stateful PCE for P2P TE LSPs in [RFC8231]. In this document, these messages are extended to support P2MP TE LSPs as well.
[RFC8231]のP2P TE LSPのパッシブステートフルPCEをサポートするために、パス計算要求（PCReq）およびパス計算応答（PCRep）メッセージも拡張されています。このドキュメントでは、これらのメッセージはP2MP TE LSPもサポートするように拡張されています。
During the PCEP initialization phase, as per Section 7.1.1 of [RFC8231], PCEP speakers advertise Stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. Various flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in [RFC8281] and [RFC8232].
PCEPの初期化フェーズでは、[RFC8231]のセクション7.1.1に従って、PCEPスピーカーがOPENオブジェクトのSTATEFUL-PCE-CAPABILITY TLVを介してステートフル機能をアドバタイズします。 [RFC8231]で定義され、[RFC8281]と[RFC8232]で更新されたSTATEFUL-PCE-CAPABILITY TLVにはさまざまなフラグが定義されています。
Three new flags, N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY), are added in this document:
このドキュメントには、N（P2MP-CAPABILITY）、M（P2MP-LSP-UPDATE-CAPABILITY）、およびP（P2MP-LSP-INSTANTIATION-CAPABILITY）の3つの新しいフラグが追加されています。
N (P2MP-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the N Flag indicates that the PCC is willing to send P2MP LSP State Reports whenever there's a change to the parameters or operational status of the P2MP LSP; if set to 1 by a PCE, the N Flag indicates that the PCE is interested in receiving LSP State Reports whenever there is a parameter or operational status change to the P2MP LSP. The P2MP-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCRpt messages to be allowed on a PCEP session.
N（P2MP-CAPABILITYフラグ-1ビット）：PCCによって1に設定されている場合、Nフラグは、P2MP LSPのパラメーターまたは動作ステータスが変更されるたびにPCCがP2MP LSP状態レポートを送信する用意があることを示します。 PCEによって1に設定されている場合、Nフラグは、P2MP LSPへのパラメーターまたは動作ステータスの変更があるたびに、PCEがLSP状態レポートの受信に関心があることを示します。 P2MP-CAPABILITYフラグは、PCCセッションで許可されるPCRptメッセージのP2MP拡張機能（このドキュメントのとおり）のために、PCCとPCEの両方によって通知される必要があります。
M (P2MP-LSP-UPDATE-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the M Flag indicates that the PCC allows modification of P2MP LSP parameters; if set to 1 by a PCE, the M Flag indicates that the PCE is capable of updating P2MP LSP parameters. The P2MP-LSP-UPDATE-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCUpd messages to be allowed on a PCEP session.
M（P2MP-LSP-UPDATE-CAPABILITYフラグ-1ビット）：PCCによって1に設定されている場合、MフラグはPCCがP2MP LSPパラメーターの変更を許可することを示します。 PCEによって1に設定されている場合、Mフラグは、PCEがP2MP LSPパラメータを更新できることを示します。 P2MP-LSP-UPDATE-CAPABILITYフラグは、PCEPセッションで許可されるPCUpdメッセージのP2MP拡張機能（このドキュメントによる）のために、PCCとPCEの両方によって通知されなければなりません（MUST）。
P (P2MP-LSP-INSTANTIATION-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the P Flag indicates that the PCC allows instantiation of a P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION-CAPABILITY flag MUST be set by both PCC and PCE in order to support PCE-initiated P2MP LSP instantiation.
P（P2MP-LSP-INSTANTIATION-CAPABILITYフラグ-1ビット）：PCCによって1に設定された場合、PフラグはPCCがPCEによるP2MP LSPのインスタンス化を許可することを示します。 PCEによって1に設定されている場合、Pフラグは、PCEがP2MP LSPインスタンス化をサポートしていることを示します。 P2MP-LSP-INSTANTIATION-CAPABILITYフラグは、PCEによって開始されるP2MP LSPインスタンス化をサポートするために、PCCとPCEの両方で設定する必要があります。
A PCEP speaker should continue to advertise the basic P2MP capability via mechanisms as described in [RFC8306].
PCEPスピーカーは、[RFC8306]で説明されているメカニズムを使用して、基本的なP2MP機能を引き続きアドバタイズする必要があります。
When the PCC is a Label Switching Router (LSR) participating in the IGP (either OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements. Extensions for the advertisement of PCE discovery information are defined for OSPF and for IS-IS in [RFC5088] and [RFC5089], respectively.
PCCがIGP（OSPFまたはIS-ISのいずれか）に参加しているラベルスイッチングルーター（LSR）であり、PCEがLSRまたはサーバーもIGPに参加している場合、IGPルーティングドメイン内のPCE検出の効果的なメカニズムは、 IGPアドバタイズメントを利用する。 PCEディスカバリー情報のアドバタイズメントの拡張は、OSPFとIS-ISでそれぞれ[RFC5088]と[RFC5089]で定義されています。
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-TLV used to advertise PCE capabilities. It MAY be present within the PCE Discovery (PCED) TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively.
[RFC5089]で定義されているPCE-CAP-FLAGSサブTLVは、PCE機能をアドバタイズするために使用されるオプションのサブTLVです。 OSPFまたはIS-ISによって伝送されるPCE検出（PCED）TLV内に存在する場合があります。 [RFC5088]と[RFC5089]は、それぞれOSPFとIS-IS内で伝送される場合のこのサブTLVの説明と処理ルールを提供します。
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy reference:
PCE-CAP-FLAGSサブTLVのフォーマットは、簡単に参照できるように以下に含まれています。
Type: 5
タイプ：5
Length: Multiple of 4
長さ：4の倍数
Value: This contains an array of units of 32-bit flags with the most significant bit as 0. Each bit represents one PCE capability.
値：これには、最上位ビットが0である32ビットフラグのユニットの配列が含まれます。各ビットは1つのPCE機能を表します。
PCE capability bit flags are defined in [RFC5088]. This document defines new capability bits for the stateful PCE with P2MP as follows:
PCE機能ビットフラグは[RFC5088]で定義されています。このドキュメントでは、P2MPを使用したステートフルPCEの新しい機能ビットを次のように定義しています。
Bit Capability 13 Active Stateful PCE with P2MP 14 Passive Stateful PCE with P2MP 15 PCE-Initiation with P2MP
ビット機能13 P2MPを使用したアクティブステートフルPCE 14 P2MPを使用したパッシブステートフルPCE 15 P2MPを使用したPCE開始
Note that, while active, passive, or initiation stateful PCE capabilities for P2MP may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP for P2MP TE LSPs MUST advertise stateful PCEP capabilities during PCEP session setup, as specified in the current document. A PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP session setup even if it did not receive any IGP PCE capability advertisements.
P2MPのアクティブ、パッシブ、または開始のステートフルPCE機能は検出中にアドバタイズされる可能性がありますが、P2MP TE LSPにステートフルPCEPを使用することを望むPCEPスピーカーは、現在のドキュメントで指定されているように、PCEPセッションのセットアップ中にステートフルPCEP機能をアドバタイズする必要があります。 PCCは、IGP PCE機能アドバタイズを受信していなくても、PCEPセッションのセットアップ時にステートフルPCEP P2MP機能アドバタイズを開始する場合があります。
State Synchronization operations (described in Section 5.6 of [RFC8231]) are applicable for the P2MP TE LSPs as well. The optimizations described in [RFC8232] can also be applied for P2MP TE LSPs.
状態同期操作（[RFC8231]のセクション5.6で説明）は、P2MP TE LSPにも適用できます。 [RFC8232]で説明されている最適化は、P2MP TE LSPにも適用できます。
LSP delegation operations (described in Section 5.7 of [RFC8231]) are applicable for P2MP TE LSPs as well.
LSP委任操作（[RFC8231]のセクション5.7で説明）は、P2MP TE LSPにも適用できます。
LSP operations for passive stateful PCE (described in Section 5.8.1 of [RFC8231]) are applicable for P2MP TE LSPs as well.
パッシブステートフルPCEのLSP操作（[RFC8231]のセクション5.8.1で説明）は、P2MP TE LSPにも適用できます。
The PCReq and PCRep message format for P2MP TE LSPs is described in Sections 3.4 and 3.5 of [RFC8306], respectively.
P2MP TE LSPのPCReqおよびPCRepメッセージフォーマットは、[RFC8306]のセクション3.4および3.5でそれぞれ説明されています。
The PCReq and PCRep message for P2MP TE LSPs are extended to support encoding of the LSP object so that it is possible to refer to an LSP with a unique identifier and simplify the PCEP message exchange. For example, in case of modification of one leaf in a P2MP tree, there should be no need to carry the full P2MP tree in a PCReq message.
P2MP TE LSPのPCReqおよびPCRepメッセージは、LSPオブジェクトのエンコードをサポートするように拡張されているため、一意の識別子でLSPを参照し、PCEPメッセージ交換を簡素化できます。たとえば、P2MPツリーの1つのリーフが変更された場合、PCReqメッセージで完全なP2MPツリーを運ぶ必要はありません。
The extensions for the Request and Response message for passive stateful operations on P2MP TE LSPs are described in Sections 6.3 and 6.4. The extension for the Path Computation LSP State Report (PCRpt) message is described in Section 6.1.
P2MP TE LSPでのパッシブステートフル操作の要求および応答メッセージの拡張については、セクション6.3および6.4で説明しています。パス計算LSP状態レポート（PCRpt）メッセージの拡張については、セクション6.1で説明します。
LSP operations for active stateful PCE (described in Section 5.8.2 of [RFC8231]) are applicable for P2MP TE LSPs as well.
アクティブなステートフルPCEのLSP操作（[RFC8231]のセクション5.8.2で説明）は、P2MP TE LSPにも適用できます。
The extension for the Path Computation LSP Update (PCUpd) message for active stateful operations on P2MP TE LSPs is described in Section 6.2.
P2MP TE LSPでのアクティブなステートフル操作のPath Computation LSP Update（PCUpd）メッセージの拡張については、セクション6.2で説明しています。
As per Section 5.1 of [RFC8281], the PCE sends a Path Computation LSP Initiate Request (PCInitiate) message to the PCC to suggest instantiation or deletion of a P2P TE LSP. This document extends the PCInitiate message to support P2MP TE LSPs (see details in Section 6.5).
[RFC8281]のセクション5.1に従って、PCEはパス計算LSP開始要求（PCInitiate）メッセージをPCCに送信して、P2P TE LSPのインスタンス化または削除を提案します。このドキュメントでは、PCInitiateメッセージを拡張してP2MP TE LSPをサポートします（詳細はセクション6.5を参照）。
The instantiation and deletion operations for P2MP TE LSPs are the same as for P2P LSPs as described in Sections 5.3 and 5.4 of [RFC8281].
[RFC8281]のセクション5.3および5.4で説明されているように、P2MP TE LSPのインスタンス化および削除操作はP2P LSPの場合と同じです。
The instantiation operation of P2MP TE LSPs is the same as the LSP instantiation operation defined in Section 5.3 of [RFC8281]; this includes the handling of the PLSP-ID, SYMBOLIC-PATH-NAME TLV, etc. The processing rules and use of error codes remain unchanged. The N (P2MP) flag (Section 7.1) MUST be set in the LSP object in the PCInitiate message by the PCE to specify that the instantiation is for P2MP TE LSPs. Like the PLSP-ID (as per [RFC8281]), the P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be included in the LSP object in PCInitiate messages and MUST be ignored on receipt. These identifiers are generated by the PCC on receipt of the PCInitiate message and reported via a PCRpt message to the PCE.
P2MP TE LSPのインスタンス化操作は、[RFC8281]のセクション5.3で定義されているLSPインスタンス化操作と同じです。これには、PLSP-ID、SYMBOLIC-PATH-NAME TLVなどの処理が含まれます。処理ルールとエラーコードの使用は変更されていません。 N（P2MP）フラグ（セクション7.1）は、インスタンス化がP2MP TE LSPに対するものであることを指定するために、PCEによってPCInitiateメッセージのLSPオブジェクトに設定する必要があります。 PLSP-ID（[RFC8281]による）と同様に、P2MP-LSP-IDENTIFIERS TLVはPCInitiateメッセージのLSPオブジェクトに含めるべきではなく（SHOULD NOT）、受信時に無視する必要があります。これらの識別子は、PCInitiateメッセージの受信時にPCCによって生成され、PCRptメッセージを介してPCEに報告されます。
The deletion operation of P2MP TE LSPs is the same as the LSP deletion operation defined in Section 5.4 of [RFC8281]; this entails sending an LSP Initiate Message with an LSP object carrying the PLSP-ID of the LSP to be removed as well as a Stateful PCE Request Parameter (SRP) object with the R flag set (LSP-REMOVE as per Section 5.2 of [RFC8281]). The processing rules and error codes remain unchanged.
P2MP TE LSPの削除操作は、[RFC8281]のセクション5.4で定義されているLSP削除操作と同じです。これには、削除するLSPのPLSP-IDを運ぶLSPオブジェクト、およびRフラグが設定されたステートフルPCE要求パラメーター（SRP）オブジェクト（LSF-REMOVE [RFC8281 ]）。処理ルールとエラーコードは変更されません。
The adding of new leaves and pruning of old leaves for the PCE-initiated P2MP TE LSP MUST be carried in a PCUpd message as per Section 6.2 for P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 is used for adding new leaves, and leaf type = 2 is used for pruning old leaves of P2MP END-POINTS Objects.
PCEによって開始されたP2MP TE LSPの新しいリーフの追加と古いリーフのプルーニングは、P2MP TE LSP拡張のセクション6.2に従って、PCUpdメッセージで伝送する必要があります。 [RFC8306]で定義されているように、リーフタイプ= 1は新しいリーフの追加に使用され、リーフタイプ= 2はP2MP END-POINTSオブジェクトの古いリーフのプルーニングに使用されます。
PCC MAY use the Incremental State Update mechanism as described in [RFC4875] to signal the adding and pruning of leaves.
PCCは、[RFC4875]で説明されているように、インクリメンタルステートアップデートメカニズムを使用して、葉の追加と剪定を通知することができます。
Section 3.10 of [RFC8306] defines the error-handling procedures when adding new leaves to or removing old leaves from the existing P2MP tree for PCReq messages. The same error handling and error codes are also applicable to the stateful PCE messages as described in this document.
[RFC8306]のセクション3.10では、PCReqメッセージの既存のP2MPツリーに新しい葉を追加したり、既存のP2MPツリーから古い葉を削除したりする場合のエラー処理手順を定義しています。このドキュメントで説明されているように、同じエラー処理とエラーコードがステートフルPCEメッセージにも適用されます。
P2MP TE LSPs delegation and cleanup operations are the same as the LSP delegation and cleanup operations defined in Section 6 of [RFC8281]. The processing rules and error codes remain unchanged.
P2MP TE LSPの委任およびクリーンアップ操作は、[RFC8281]のセクション6で定義されているLSPの委任およびクリーンアップ操作と同じです。処理ルールとエラーコードは変更されません。
Message formats in this section, as those in [RFC8231], [RFC8281], and [RFC5440], are presented using Routing Backus-Naur Format (RBNF) as specified in [RFC5511].
このセクションのメッセージ形式は、[RFC8231]、[RFC8281]、および[RFC5440]のメッセージ形式と同様に、[RFC5511]で指定されているRouting Backus-Naur Format（RBNF）を使用して表示されます。
As per Section 6.1 of [RFC8231], a PCRpt message is used to report the current state of a P2P TE LSP. This document extends the PCRpt message in reporting the status of P2MP TE LSPs.
[RFC8231]のセクション6.1に従って、PCRptメッセージはP2P TE LSPの現在の状態を報告するために使用されます。このドキュメントでは、P2MP TE LSPのステータスを報告するPCRptメッセージを拡張します。
The format of a PCRpt message is as follows:
PCRptメッセージの形式は次のとおりです。
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path> ::= <end-point-intended-path-pair-list>
[<actual-attribute-list>
<end-point-actual-path-pair-list>]
[<intended-attribute-list>]
<end-point-intended-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<intended-path>
[<end-point-intended-path-pair-list>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<actual-path>
[<end-point-actual-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>]
<intended-attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
<intended-attribute-list>は[RFC5440]で定義され、PCEP拡張によって拡張されています。
<actual-attribute-list> consists of the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440].
<actual-attribute-list>は、[RFC5440]で定義されている<BANDWIDTH>オブジェクトと<metric-lists>オブジェクトの実際の計算値と信号値で構成されます。
The P2MP END-POINTS object defined in [RFC8306] is mandatory for specifying the address of P2MP leaves, grouped by leaf types.
[RFC8306]で定義されているP2MP END-POINTSオブジェクトは、リーフタイプでグループ化されたP2MPリーフのアドレスを指定するために必須です。
o New leaves to add (leaf type = 1)
o 追加する新しい葉（葉の種類= 1）
o Old leaves to remove (leaf type = 2)
o 削除する古い葉（葉の種類= 2）
o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o パスを変更/再最適化できる古い葉（葉のタイプ= 3）
o Old leaves whose path must be left unchanged (leaf type = 4)
o パスを変更しないでおく必要がある古い葉（葉のタイプ= 4）
When reporting the status of a P2MP TE LSP, the destinations MUST be grouped in the END-POINTS object based on the operational status (O field in S2LS objects) and leaf type (in END-POINTS objects). This way, leaves of the same type that share the same operational status can be grouped together. For reporting the status of delegated P2MP TE LSPs, leaf type = 3 is used, whereas for nondelegated P2MP TE LSPs, leaf type = 4 is used.
P2MP TE LSPのステータスを報告する場合、宛先は、運用ステータス（S2LSオブジェクトのOフィールド）およびリーフタイプ（END-POINTSオブジェクト内）に基づいてEND-POINTSオブジェクトにグループ化する必要があります。このようにして、同じ操作ステータスを共有する同じタイプのリーフをグループ化できます。委任されたP2MP TE LSPのステータスを報告するには、リーフタイプ= 3が使用されますが、委任されていないP2MP TE LSPには、リーフタイプ= 4が使用されます。
For a delegated P2MP TE LSP, configuration changes are reported via a PCRpt message. For example, for adding new leaves, leaf type = 1 is used in the END-POINTS object, and for removing old leaves, leaf type = 2 is used.
委任されたP2MP TE LSPの場合、構成の変更はPCRptメッセージを介して報告されます。たとえば、新しい葉を追加する場合は、END-POINTSオブジェクトで葉タイプ= 1が使用され、古い葉を削除する場合は、葉タイプ= 2が使用されます。
Note that the compatibility with the [RFC8231] definition of <state-report> is preserved. At least one instance of <END-POINTS> MUST be present in this message for P2MP LSP.
<state-report>の[RFC8231]定義との互換性が保持されていることに注意してください。 <END-POINTS>の少なくとも1つのインスタンスが、P2MP LSPのこのメッセージに存在する必要があります。
Note that the ordering of <end-point-intended-path-pair-list>, <actual-attribute-list>, <end-point-actual-path-pair-list>, and <intended-attribute-list> is done to retain compatibility with state reports for the P2P LSPs as per [RFC8231].
<end-point-intended-path-pair-list>、<actual-attribute-list>、<end-point-actual-path-pair-list>、および<intended-attribute-list>の順序は次のとおりです。 [RFC8231]に従って、P2P LSPの状態レポートとの互換性を維持するために行われました。
During state synchronization, the PCRpt message reports the status of the full P2MP tree.
状態の同期中、PCRptメッセージは完全なP2MPツリーのステータスを報告します。
The S2LS object MUST be carried in a PCRpt message along with the END-POINTS object when an N (P2MP) flag is set in an LSP object for P2MP TE LSPs. If the S2LS object is missing, the receiving PCE MUST send a PCEP Error (PCErr) message with Error-type=6 ("Mandatory Object missing") and Error-value=13 ("S2LS object missing"). If the END-POINTS object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS object missing") (defined in [RFC5440].
P2MP TE LSPのLSPオブジェクトにN（P2MP）フラグが設定されている場合、S2LSオブジェクトはEND-POINTSオブジェクトとともにPCRptメッセージで搬送される必要があります。 S2LSオブジェクトが欠落している場合、受信側のPCEは、Error-type = 6（ "Mandatory Object missing"）およびError-value = 13（ "S2LS object missing"）を含むPCEPエラー（PCErr）メッセージを送信する必要があります。 END-POINTSオブジェクトがない場合、受信側のPCEは、Error-type = 6（ "Mandatory Object missing"）およびError-value = 3（ "END-POINTS object missing"）（[RFC5440 ]。
The S2LS object could be used in conjunction with the intended-path (EXPLICIT_ROUTE object or ERO) as well as the actual-path (RECORD_ROUTE object or RRO); for the same leaf, the state encoded in the S2LS object associated with the actual-path MUST be used over the intended-path.
S2LSオブジェクトは、実際のパス（RECORD_ROUTEオブジェクトまたはRRO）と同様に、目的のパス（EXPLICIT_ROUTEオブジェクトまたはERO）と組み合わせて使用できます。同じリーフの場合、実際のパスに関連付けられたS2LSオブジェクトでエンコードされた状態を、意図されたパスで使用する必要があります。
If the E-bit (ERO-Compress bit) was set to 1 in the report, then the path will be formed by an ERO followed by a list of SECONDARY_EXPLICIT_ROUTE Objects (SEROs), or an RRO followed by a list of SECONDARY_RECORD_ROUTE Objects (SRROs).
レポートでEビット（ERO圧縮ビット）が1に設定されている場合、パスは、EROに続くSECONDARY_EXPLICIT_ROUTEオブジェクト（SERO）のリスト、またはRROに続くSECONDARY_RECORD_ROUTEオブジェクトのリスト（ SRRO）。
As per Section 6.2 of [RFC8231], a PCUpd message is used to update P2P TE LSP attributes. This document extends the PCUpd message in updating the attributes of a P2MP TE LSP.
[RFC8231]のセクション6.2に従って、PCUpdメッセージはP2P TE LSP属性を更新するために使用されます。このドキュメントでは、P2MP TE LSPの属性を更新する際のPCUpdメッセージを拡張します。
The format of a PCUpd message is as follows:
PCUpdメッセージの形式は次のとおりです。
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
ただし：
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path> ::= <end-point-path-pair-list>
<intended-attribute-list>
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<intended-attribute-list> is the attribute-list defined in [RFC5440] and extended by PCEP extensions.
<intended-attribute-list>は、[RFC5440]で定義され、PCEP拡張機能によって拡張された属性リストです。
Note that the compatibility with the [RFC8231] definition of <update-request> is preserved.
<update-request>の[RFC8231]定義との互換性が維持されることに注意してください。
The PCC SHOULD use the make-before-break or sub-group-based procedures described in [RFC4875] based on a local policy decision.
PCCは、ローカルポリシーの決定に基づいて、[RFC4875]で説明されているmake-before-breakまたはサブグループベースの手順を使用する必要があります（SHOULD）。
The END-POINTS object MUST be carried in a PCUpd message when the N flag is set in the LSP object for a P2MP TE LSP. If the END-POINTS object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS object missing") (defined in [RFC5440]).
P2MP TE LSPのLSPオブジェクトでNフラグが設定されている場合は、END-POINTSオブジェクトをPCUpdメッセージで伝達する必要があります。 END-POINTSオブジェクトがない場合、受信側のPCCは、Error-type = 6（ "Mandatory Object missing"）およびError-value = 3（ "END-POINTS object missing"）（[RFC5440 ]）。
As per Section 3.4 of [RFC8306], a PCReq message is used for a P2MP Path Computation Request. This document extends the PCReq message such that a PCC MAY include the LSP object in the PCReq message if the stateful PCE P2MP capability has been negotiated on a PCEP session between the PCC and a PCE.
[RFC8306]のセクション3.4に従って、PCReqメッセージはP2MPパス計算リクエストに使用されます。このドキュメントはPCReqメッセージを拡張して、PCCとPCE間のPCEPセッションでステートフルPCE P2MP機能がネゴシエートされている場合、PCCがLSPオブジェクトをPCReqメッセージに含めることができるようにします。
The format of a PCReq message is as follows:
PCReqメッセージのフォーマットは次のとおりです。
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
ただし：
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<end-point-rro-pair-list>::= <END-POINTS>
[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
As per Section 3.5 of [RFC8306], a PCRep message is used for a P2MP Path Computation Reply. This document extends the PCRep message such that a PCE MAY include the LSP object in the PCRep message if the stateful PCE P2MP capability has been negotiated on a PCEP session between the PCC and a PCE.
[RFC8306]のセクション3.5に従って、PCRepメッセージはP2MPパス計算応答に使用されます。このドキュメントはPCRepメッセージを拡張して、PCCとPCE間のPCEPセッションでステートフルPCE P2MP機能がネゴシエートされている場合、PCEがPCRepメッセージにLSPオブジェクトを含めることができるようにします。
The format of a PCRep message is as follows:
PCRepメッセージの形式は次のとおりです。
<PCRep Message>::= <Common Header>
<response-list>
where:
ただし：
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list>::= [<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
As defined in section 5.1 of [RFC8281], a PCE sends a PCInitiate message to a PCC to recommend instantiation of a P2P TE LSP. This document extends the format of a PCInitiate message for the creation of P2MP TE LSPs, but the creation and deletion operations of P2MP TE LSPs are the same to the P2P TE LSPs.
[RFC8281]のセクション5.1で定義されているように、PCEはPCInitiateメッセージをPCCに送信して、P2P TE LSPのインスタンス化を推奨します。このドキュメントでは、P2MP TE LSPを作成するためのPCInitiateメッセージのフォーマットを拡張していますが、P2MP TE LSPの作成および削除操作はP2P TE LSPと同じです。
The format of a PCInitiate message is as follows:
PCInitiateメッセージの形式は次のとおりです。
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<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-instantiation> ::= <SRP>
<LSP>
<end-point-path-pair-list>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
ただし：
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
<attribute-list>は[RFC5440]で定義され、PCEP拡張機能によって拡張されます。
The PCInitiate message with an LSP object with the N flag (P2MP) set is used to convey operation on a P2MP TE LSP. The SRP object is used to correlate between initiation requests sent by the PCE, and the error reports and state reports sent by the PCC as described in [RFC8231].
Nフラグ（P2MP）が設定されたLSPオブジェクトを含むPCInitiateメッセージは、P2MP TE LSPでの操作を伝えるために使用されます。 [RFC8231]で説明されているように、SRPオブジェクトは、PCEによって送信された開始要求と、PCCによって送信されたエラーレポートおよび状態レポートを関連付けるために使用されます。
The END-POINTS object MUST be carried in a PCInitiate message when the N flag is set in an LSP object for a P2MP TE LSP. If the END-POINTS object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS object missing") (defined in [RFC5440]).
P2MP TE LSPのLSPオブジェクトでNフラグが設定されている場合は、END-POINTSオブジェクトをPCInitiateメッセージで伝達する必要があります。 END-POINTSオブジェクトがない場合、受信側のPCCは、Error-type = 6（ "Mandatory Object missing"）およびError-value = 3（ "END-POINTS object missing"）（[RFC5440 ]）。
An LSP Update Request message is sent by an active stateful PCE to update the P2MP TE LSPs parameters or attributes. An example of a PCUpd message for P2MP TE LSPs is described below:
LSP更新要求メッセージは、アクティブなステートフルPCEによって送信され、P2MP TE LSPパラメータまたは属性を更新します。 P2MP TE LSPのPCUpdメッセージの例を以下に示します。
Common Header SRP LSP with P2MP flag set END-POINTS for leaf type 3 ERO list
リーフタイプ3 EROリストのP2MPフラグセットEND-POINTSを持つ共通ヘッダーSRP LSP
In this example, a stateful PCE requests an update of the path taken to some of the leaves in a P2MP tree. The update request uses the END-POINT type 3 (modified/reoptimized). The ERO list represents the source-to-leaves path after modification. The update message does not need to encode the full P2MP tree in this case.
この例では、ステートフルPCEは、P2MPツリー内の一部の葉へのパスの更新を要求します。更新要求は、END-POINTタイプ3（変更/再最適化）を使用します。 EROリストは、変更後のソースからリーフへのパスを表します。この場合、更新メッセージは完全なP2MPツリーをエンコードする必要はありません。
The LSP State Report message is sent by a PCC to report or delegate the P2MP TE LSP. The leaves of the P2MP TE LSP are grouped in the END-POINTS object based on the operational status and the leaf type. An example of a PCRpt message is described below for a delegated P2MP TE LSP to add new leaves to an existing P2MP TE LSP:
LSP状態レポートメッセージは、P2MP TE LSPを報告または委任するためにPCCによって送信されます。 P2MP TE LSPのリーフは、動作ステータスとリーフタイプに基づいてEND-POINTSオブジェクトにグループ化されます。委任されたP2MP TE LSPが既存のP2MP TE LSPに新しいリーフを追加するためのPCRptメッセージの例を以下に示します。
Common Header LSP with P2MP flag set END-POINTS for leaf type 1 (add) S2LS (O=DOWN) ERO list (empty)
リーフタイプ1のP2MPフラグセットEND-POINTSを持つ共通ヘッダーLSP（追加）S2LS（O = DOWN）EROリスト（空）
An example of a PCRpt message for a P2MP TE LSP is described below to prune leaves from an existing P2MP TE LSP:
既存のP2MP TE LSPからリーフをプルーニングするために、P2MP TE LSPのPCRptメッセージの例を以下に説明します。
Common Header LSP with P2MP flag set END-POINTS for leaf type 2 (remove) S2LS (O=UP) ERO list (empty)
リーフタイプ2のP2MPフラグセットEND-POINTSを持つ共通ヘッダーLSP（削除）S2LS（O = UP）EROリスト（空）
An example of a PCRpt message for a delegated P2MP TE LSP is described below to report the status of leaves in an existing P2MP TE LSP:
委任されたP2MP TE LSPのPCRptメッセージの例を以下に説明して、既存のP2MP TE LSPのリーフのステータスを報告します。
Common Header SRP LSP with P2MP flag set END-POINTS for leaf type 3 (modify) S2LS (O=UP) RRO list END-POINTS for leaf type 3 (modify) S2LS (O=DOWN) ERO list (empty)
P2MPフラグが設定された共通ヘッダーSRP LSPリーフタイプ3のEND-POINTS（変更）S2LS（O = UP）RROリストリーフタイプ3のEND-POINTS（変更）S2LS（O = DOWN）EROリスト（空）
In this example, the PCRpt message is in response to a PCUpd message. The PCRpt message includes the corresponding SRP object and indicates that some leaves are up (with the actual path) and some are down.
この例では、PCRptメッセージはPCUpdメッセージへの応答です。 PCRptメッセージには、対応するSRPオブジェクトが含まれ、一部のリーフが（実際のパスで）稼働し、一部がダウンしていることを示します。
An example of a PCRpt message for a nondelegated P2MP TE LSP is described below to report status of leaves:
委任されていないP2MP TE LSPのPCRptメッセージの例を、リーフのステータスを報告するために以下に説明します。
Common Header LSP with P2MP flag set END-POINTS for leaf type 4 (unchanged) S2LS (O=ACTIVE) RRO list END-POINTS for leaf type 4 (unchanged) S2LS (O=DOWN) ERO list (empty)
P2MPフラグが設定された共通ヘッダーLSPリーフタイプ4のEND-POINTS（変更なし）S2LS（O = ACTIVE）RROリストリーフタイプ4のEND-POINTS（変更なし）S2LS（O = DOWN）EROリスト（空）
An LSP Initiation Request message is sent by a stateful PCE to create a P2MP TE LSP. An example of a PCInitiate message for a P2MP TE LSP is described below:
LSP開始要求メッセージは、P2MP TE LSPを作成するためにステートフルPCEによって送信されます。 P2MP TE LSPのPCInitiateメッセージの例を以下に示します。
Common Header SRP LSP with P2MP flag set END-POINTS for leaf type 1 (add) ERO list
リーフタイプ1のP2MPフラグセットEND-POINTSを持つ共通ヘッダーSRP LSP（追加）EROリスト
In this example, a stateful PCE requests the creation of a P2MP TE LSP. The initiation request uses the END-POINT type 1 (new leaves). The ERO list represents the source-to-leaves path. The initiate message encodes the full P2MP tree in this case.
この例では、ステートフルPCEがP2MP TE LSPの作成を要求します。開始要求は、END-POINTタイプ1（新しい葉）を使用します。 EROリストは、ソースからリーフへのパスを表します。この場合、開始メッセージは完全なP2MPツリーをエンコードします。
The new PCEP TLVs defined in this document are in compliance with the PCEP TLV format defined in [RFC5440].
このドキュメントで定義されている新しいPCEP TLVは、[RFC5440]で定義されているPCEP TLV形式に準拠しています。
The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies the PLSP-ID to uniquely identify an LSP that is constant for the life time of a PCEP session. Similarly, for a P2MP tunnel, the PLSP-ID uniquely identifies a P2MP TE LSP. This document adds the following flags to the LSP Object:
LSPオブジェクトは、[RFC8231]のセクション7.3で定義されています。 PLEP-IDを指定して、PCEPセッションの存続期間中一定であるLSPを一意に識別します。同様に、P2MPトンネルの場合、PLSP-IDはP2MP TE LSPを一意に識別します。このドキュメントでは、LSPオブジェクトに次のフラグを追加します。
N (P2MP flag - 1 bit): If the N flag is set to 1, it indicates that the message is for a P2MP TE LSP.
N（P2MPフラグ-1ビット）：Nフラグが1に設定されている場合は、メッセージがP2MP TE LSP用であることを示します。
F (Fragmentation flag - 1 bit): If the F flag is unset (0), it indicates that the LSP is not fragmented or that it is the last piece of the fragmented LSP. If the F flag is set to 1, it indicates that the LSP is fragmented and that it is not the last piece of the fragmented LSP. The receiver needs to wait for additional fragments until it receives an LSP with the same PLSP-ID and with the F-bit set to 0. See Section 8 for further details.
F（フラグメンテーションフラグ-1ビット）：Fフラグが設定されていない（0）場合、LSPがフラグメント化されていないか、フラグメント化されたLSPの最後のピースであることを示します。 Fフラグが1に設定されている場合は、LSPがフラグメント化されており、フラグメント化されたLSPの最後のピースではないことを示しています。受信機は、同じPLSP-IDとFビットが0に設定されたLSPを受信するまで、追加のフラグメントを待つ必要があります。詳細については、セクション8を参照してください。
E (ERO-compression flag - 1 bit): If the E flag is set to 1, it indicates the route is in compressed format (that is, Secondary Explicit Route Object (SERO) and Secondary Record Route Object (SRRO) objects [RFC8306] are in use).
E（ERO圧縮フラグ-1ビット）：Eフラグが1に設定されている場合、ルートが圧縮形式（つまり、セカンダリ明示ルートオブジェクト（SERO）およびセカンダリレコードルートオブジェクト（SRRO）オブジェクトであることを示します[RFC8306 ]は使用中です）。
The flags defined in this section (N, F, and E) are used in PCRpt, PCUpd, or PCInitiate messages. In the case of PCReq and PCRep messages, these flags have no meaning and thus MUST be ignored. The corresponding flags in the RP (Request Parameters) object are used as described in [RFC8306].
このセクションで定義されているフラグ（N、F、およびE）は、PCRpt、PCUpd、またはPCInitiateメッセージで使用されます。 PCReqおよびPCRepメッセージの場合、これらのフラグは意味を持たないため、無視する必要があります。 RP（Request Parameters）オブジェクトの対応するフラグは、[RFC8306]で説明されているように使用されます。
[RFC8231] specifies the LSP-IDENTIFIERS TLVs to be included in the LSP object. For P2MP TE LSP, this document defines P2MP-LSP-IDENTIFIERS TLVs for the LSP object. There are two P2MP-LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6. The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object in a PCRpt message for P2MP TE LSPs. If the N bit is set in the LSP object in the PCRpt message but the P2MP-LSP-IDENTIFIER TLV is absent, the PCE MUST respond with a PCErr message carrying error-type 6 ("mandatory object missing") and error-value 14 ("P2MP-LSP-IDENTIFIERS TLV missing") and close the PCEP session.
[RFC8231]は、LSPオブジェクトに含まれるLSP-IDENTIFIERS TLVを指定します。 P2MP TE LSPの場合、このドキュメントでは、LSPオブジェクトのP2MP-LSP-IDENTIFIERS TLVを定義します。 2つのP2MP-LSP-IDENTIFIERS TLVがあり、1つはIPv4用、もう1つはIPv6用です。 P2MP-LSP-IDENTIFIERS TLVは、P2MP TE LSPのPCRptメッセージのLSPオブジェクトに含める必要があります。 PCRptメッセージのLSPオブジェクトにNビットが設定されているが、P2MP-LSP-IDENTIFIER TLVが存在しない場合、PCEは、エラータイプ6（「必須オブジェクトがありません」）およびエラー値14を伝えるPCErrメッセージで応答する必要があります。 （「P2MP-LSP-IDENTIFIERS TLV missing」）、PCEPセッションを閉じます。
The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the PCUpd message for P2MP TE LSPs. The special value of all zeros for all the fields in the value portion of the TLV is used to refer to all paths pertaining to a particular PLSP-ID. The length of the TLV remains fixed based on the IP version.
P2MP-LSP-IDENTIFIERS TLVは、P2MP TE LSPのPCUpdメッセージのLSPオブジェクトに含めることができます。 TLVの値の部分にあるすべてのフィールドのすべてがゼロの特別な値は、特定のPLSP-IDに関連するすべてのパスを参照するために使用されます。 TLVの長さは、IPバージョンに基づいて固定されたままです。
The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be used in a PCInitiate message (see Section 5.6.3.1) and MAY optionally be included in the LSP object in the PCReq and the PCRep message for P2MP TE LSP.
P2MP-LSP-IDENTIFIERS TLVは、PCInitiateメッセージ（セクション5.6.3.1を参照）で使用してはならず（SHOULD NOT）、オプションで、P2MP TE LSPのPCReqおよびPCRepメッセージのLSPオブジェクトに含めることができます。
The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in Figure 1:
IPV4-P2MP-LSP-IDENTIFIERS TLVのフォーマットを図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=32 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPV4-P2MP-LSP-IDENTIFIERS TLV Format
図1：IPV4-P2MP-LSP-IDENTIFIERS TLV形式
The type (16 bits) of the TLV is 32. The length (16 bits) has a fixed value of 16 octets. The value contains the following fields:
TLVのタイプ（16ビット）は32です。長さ（16ビット）は16オクテットの固定値です。値には次のフィールドが含まれます。
IPv4 Tunnel Sender Address: Contains the sender node's IPv4 address, as defined in [RFC3209]. See Section 4.6.2.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Sender Template Object.
IPv4トンネル送信者アドレス：[RFC3209]で定義されている送信者ノードのIPv4アドレスが含まれます。 LSP_TUNNEL_IPv4送信者テンプレートオブジェクトについては、[RFC3209]のセクション4.6.2.1を参照してください。
LSP ID: Contains the 16-bit 'LSP ID' identifier defined in [RFC3209]. See Section 4.6.2.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Sender Template Object.
LSP ID：[RFC3209]で定義されている16ビットの 'LSP ID'識別子が含まれています。 LSP_TUNNEL_IPv4送信者テンプレートオブジェクトについては、[RFC3209]のセクション4.6.2.1を参照してください。
Tunnel ID: Contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Session Object.
トンネルID：[RFC3209]で定義されている16ビットの「トンネルID」識別子が含まれています。 LSP_TUNNEL_IPv4セッションオブジェクトについては、[RFC3209]のセクション4.6.1.1をご覧ください。
Extended Tunnel ID: Contains the 32-bit 'Extended Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Session Object.
拡張トンネルID：[RFC3209]で定義されている32ビットの「拡張トンネルID」識別子が含まれています。 LSP_TUNNEL_IPv4セッションオブジェクトについては、[RFC3209]のセクション4.6.1.1をご覧ください。
P2MP ID: Contains the 32-bit 'P2MP ID' identifier defined in Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION Object.
P2MP ID：[RFC4875]のセクション19.1.1でP2MP LSPトンネルIPv4 SESSIONオブジェクトに対して定義された32ビットの「P2MP ID」識別子が含まれています。
The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in Figure 2:
IPV6-P2MP-LSP-IDENTIFIERS TLVのフォーマットを図2に示します。
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=33 | Length=40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPV6-P2MP-LSP-IDENTIFIERS TLV Format
図2：IPV6-P2MP-LSP-IDENTIFIERS TLV形式
The type (16 bits) of the TLV is 33. The length (16 bits) has a fixed length of 40 octets. The value contains the following fields:
TLVのタイプ（16ビット）は33です。長さ（16ビット）は、40オクテットの固定長です。値には次のフィールドが含まれます。
IPv6 Tunnel Sender Address: Contains the sender node's IPv6 address, as defined in [RFC3209]. See Section 4.6.2.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Sender Template Object.
IPv6トンネル送信者アドレス：[RFC3209]で定義されている送信ノードのIPv6アドレスが含まれています。 LSP_TUNNEL_IPv6送信者テンプレートオブジェクトについては、[RFC3209]のセクション4.6.2.2を参照してください。
LSP ID: Contains the 16-bit 'LSP ID' identifier defined in [RFC3209]. See Section 4.6.2.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Sender Template Object.
LSP ID：[RFC3209]で定義されている16ビットの 'LSP ID'識別子が含まれています。 LSP_TUNNEL_IPv6送信者テンプレートオブジェクトについては、[RFC3209]のセクション4.6.2.2を参照してください。
Tunnel ID: Contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Session Object.
トンネルID：[RFC3209]で定義されている16ビットの「トンネルID」識別子が含まれています。 LSP_TUNNEL_IPv6セッションオブジェクトについては、[RFC3209]のセクション4.6.1.2を参照してください。
Extended Tunnel ID: Contains the 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Session Object.
拡張トンネルID：[RFC3209]で定義されている128ビットの「拡張トンネルID」識別子が含まれています。 LSP_TUNNEL_IPv6セッションオブジェクトについては、[RFC3209]のセクション4.6.1.2を参照してください。
P2MP ID: Defined above under Figure 1.
P2MP ID：上記の図1で定義。
Tunnel ID: Remains constant over the lifetime of a tunnel.
トンネルID：トンネルの存続期間中、一定のままです。
The S2LS (Source-to-Leaves) Object is used to report the state of one or more destinations (leaves) encoded within the END-POINTS object for a P2MP TE LSP. It MUST be carried in a PCRpt message along with an END-POINTS object when the N flag is set in an LSP object.
S2LS（Source-to-Leaves）オブジェクトは、P2MP TE LSPのEND-POINTSオブジェクト内にエンコードされた1つ以上の宛先（葉）の状態を報告するために使用されます。 LSPオブジェクトでNフラグが設定されている場合、それはEND-POINTSオブジェクトと共にPCRptメッセージで運ばれる必要があります。
S2LS Object-Class is 41.
S2LSオブジェクトクラスは41です。
S2LS Object-Types is 1.
S2LS Object-Typesは1です。
The format of the S2LS object is shown in the following figure:
S2LSオブジェクトのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: S2LS Object Format
図3：S2LSオブジェクト形式
Flags (32 bits): The following flag is currently defined:
フラグ（32ビット）：現在、次のフラグが定義されています。
O (Operational - 3 bits) The O field represents the operational status of the group of destinations. The values are as per the Operational field in the LSP object defined in Section 7.3 of [RFC8231].
O（運用-3ビット）Oフィールドは、宛先グループの運用ステータスを表します。値は、[RFC8231]のセクション7.3で定義されているLSPオブジェクトのOperationalフィールドに準拠しています。
Unassigned bits are reserved for future uses. They MUST be set to 0 on transmission and MUST be ignored on receipt.
割り当てられていないビットは、将来の使用のために予約されています。送信時には0に設定し、受信時には無視する必要があります。
When the N flag is set in an LSP object, the O field in the LSP object represents the operational status of the full P2MP TE LSP, and the O field in the S2LS object represents the operational status of a group of destinations encoded within the END-POINTS object. If there is a conflict between the O field in the LSP and the S2LS object (for example, the O field in the LSP corresponds to down whereas the O field in the S2LS is up), the PCEP speaker MUST generate an error with error-type 10 ("Reception of an invalid object") and error-value 22 ("Mismatch of O field in S2LS and LSP object").
LSPオブジェクトでNフラグが設定されている場合、LSPオブジェクトのOフィールドは完全なP2MP TE LSPの動作ステータスを表し、S2LSオブジェクトのOフィールドはEND内でエンコードされた宛先グループの動作ステータスを表します-POINTSオブジェクト。 LSPのOフィールドとS2LSオブジェクトの間に矛盾がある場合（たとえば、LSPのOフィールドはダウンに対応し、S2LSのOフィールドはアップになっている）、PCEPスピーカーはエラーでエラーを生成する必要があります-タイプ10（「無効なオブジェクトの受信」）およびエラー値22（「S2LSおよびLSPオブジェクトのOフィールドの不一致」）。
Future documents might define optional TLVs that could be included in the S2LS Object.
今後のドキュメントでは、S2LSオブジェクトに含めることができるオプションのTLVを定義する可能性があります。
The total PCEP message length, including the common header, is (2^16)-1 bytes. In certain scenarios, the P2MP report and update request may not fit into a single PCEP message (e.g., initial report or update). The F flag is used in the LSP object to signal that the initial report, update, or initiate request was too large to fit into a single PCEP message and will be fragmented into multiple messages. In order to identify the single report or update, each message will use the same PLSP-ID. In order to identify that a series of PCInitiate messages represents a single Initiate, each message will use the same PLSP-ID (in this case 0) and SRP-ID-number.
共通ヘッダーを含むPCEPメッセージの全長は、（2 ^ 16）-1バイトです。特定のシナリオでは、P2MPレポートと更新要求が単一のPCEPメッセージ（たとえば、初期レポートまたは更新）に収まらない場合があります。 FフラグはLSPオブジェクトで使用され、最初のレポート、更新、または開始要求が大きすぎて単一のPCEPメッセージに収まらず、複数のメッセージにフラグメント化されることを通知します。単一のレポートまたは更新を識別するために、各メッセージは同じPLSP-IDを使用します。一連のPCInitiateメッセージが単一のInitiateを表すことを識別するために、各メッセージは同じPLSP-ID（この場合は0）とSRP-ID-numberを使用します。
The fragmentation procedure described below for report or update messages is similar to [RFC8306], which describes request and response message fragmentation.
レポートまたは更新メッセージについて以下で説明する断片化手順は、[RFC8306]に似ています。これは、要求および応答メッセージの断片化について説明しています。
If the initial report is too large to fit into a single report message, the PCC will split the report over multiple messages. Each message sent to the PCE, except the last one, will have the F flag set in the LSP object to signify that the report has been fragmented into multiple messages. In order to identify that a series of report messages represents a single report, each message will use the same PLSP-ID.
最初のレポートが大きすぎて1つのレポートメッセージに収まらない場合、PCCはレポートを複数のメッセージに分割します。最後のメッセージを除いて、PCEに送信される各メッセージには、LSPオブジェクトにFフラグが設定され、レポートが複数のメッセージにフラグメント化されていることを示します。一連のレポートメッセージが単一のレポートを表すことを識別するために、各メッセージは同じPLSP-IDを使用します。
The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 2 indicates "Fragmented report failure" and is used if a PCE does not receive the last part of the fragmented message.
Error-Type値18（「P2MPフラグメンテーションエラー」）は、P2MP PCEPメッセージのフラグメンテーションに関連するエラーを報告するために使用されます。新しいエラー値2は「断片化レポートの失敗」を示し、PCEが断片化されたメッセージの最後の部分を受信しない場合に使用されます。
Once the PCE computes and updates a path for some or all leaves in a P2MP TE LSP, an update message is sent to the PCC. If the update is too large to fit into a single update message, the PCE will split the update over multiple messages. Each update message sent by the PCE, except the last one, will have the F flag set in the LSP object to signify that the update has been fragmented into multiple messages. In order to identify that a series of update messages represents a single update, each message will use the same PLSP-ID and SRP-ID-number.
PCEがP2MP TE LSPの一部またはすべてのリーフのパスを計算して更新すると、更新メッセージがPCCに送信されます。更新が大きすぎて1つの更新メッセージに収まらない場合、PCEは更新を複数のメッセージに分割します。 PCEによって送信された各更新メッセージは、最後のものを除いて、更新が複数のメッセージにフラグメント化されていることを示すために、LSPオブジェクトにFフラグが設定されています。一連の更新メッセージが単一の更新を表すことを識別するために、各メッセージは同じPLSP-IDとSRP-ID-numberを使用します。
The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 3 indicates "Fragmented update failure" and is used if a PCC does not receive the last part of the fragmented message.
Error-Type値18（「P2MPフラグメンテーションエラー」）は、P2MP PCEPメッセージのフラグメンテーションに関連するエラーを報告するために使用されます。新しいエラー値3は「断片化された更新の失敗」を示し、PCCが断片化されたメッセージの最後の部分を受信しない場合に使用されます。
Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message is sent to the PCC. If the initiate request is too large to fit into a single PCInitiate message, the PCE will split the initiate request over multiple messages. Each PCInitiate message sent by the PCE, except the last one, will have the F flag set in the LSP object to signify that the PCInitiate has been fragmented into multiple messages. In order to identify that a series of PCInitiate messages represents a single Initiate, each message will use the same PLSP-ID (in this case 0) and SRP-ID-number.
PCEがP2MP TE LSPのセットアップを開始すると、PCInitiateメッセージがPCCに送信されます。開始要求が大きすぎて単一のPCInitiateメッセージに収まらない場合、PCEは開始要求を複数のメッセージに分割します。 PCEによって送信された各PCInitiateメッセージ（最後のものを除く）には、LSPオブジェクトでFフラグが設定され、PCInitiateが複数のメッセージにフラグメント化されていることを示します。一連のPCInitiateメッセージが単一のInitiateを表すことを識別するために、各メッセージは同じPLSP-ID（この場合は0）とSRP-ID-numberを使用します。
The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 4 indicates "Fragmented instantiation failure" and is used if a PCC does not receive the last part of the fragmented message.
Error-Type値18（「P2MPフラグメンテーションエラー」）は、P2MP PCEPメッセージのフラグメンテーションに関連するエラーを報告するために使用されます。新しいエラー値4は「断片化されたインスタンス化の失敗」を示し、PCCが断片化されたメッセージの最後の部分を受信しない場合に使用されます。
The PCEP extensions described in this document for stateful PCEs with P2MP capability MUST NOT be used if the PCE has not advertised its stateful capability with P2MP as per Section 5.2. If the PCC supports the extensions as per this document (understands the N (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) flags in the LSP object) but did not advertise this capability, then upon receipt of a PCUpd message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 12 ("Attempted LSP Update Request for P2MP if active stateful PCE capability for P2MP was not advertised"), and terminate the PCEP session. If the PCE supports the extensions as per this document (understands the N (P2MP-CAPABILITY) flag in the LSP object) but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 11 ("Attempted LSP State Report for P2MP if stateful PCE capability for P2MP was not advertised"), and it SHOULD terminate the PCEP session.
PCEがセクション5.2に従ってP2MPでステートフル機能を通知していない場合は、P2MP機能を持つステートフルPCEについてこのドキュメントで説明されているPCEP拡張を使用してはなりません。 PCCがこのドキュメントに従って拡張機能をサポートしている（LSPオブジェクトのN（P2MP-CAPABILITY）およびM（P2MP-LSP-UPDATE-CAPABILITY）フラグを理解している）が、この機能をアドバタイズしなかった場合、PCUpdメッセージの受信時にPCEから、エラータイプ19（「無効な操作」）、エラー値12（「P2MPのアクティブなステートフルPCE機能が通知されなかった場合にP2MPのLSP更新要求が試行された」）のPCErrを生成し、PCEPを終了する必要があります。セッション。 PCEがこのドキュメントのように拡張機能をサポートしている（LSPオブジェクトのN（P2MP-CAPABILITY）フラグを理解している）が、この機能をアドバタイズしなかった場合、PCCからPCRptメッセージを受信すると、エラーのあるPCErrを生成する必要があります（SHOULD）。 -type 19（「無効な操作」）、エラー値11（「P2MPのステートフルPCE機能が通知されなかった場合のP2MPのLSP状態レポートの試行」）、およびPCEPセッションを終了する必要があります（SHOULD）。
If a Stateful PCE receives a P2MP TE LSP report message and the PCE does not understand the N (P2MP-CAPABILITY) flag in the LSP object, and therefore the PCEP extensions described in this document, then the Stateful PCE would act as per Section 6.1 of [RFC8231] (and consider the PCRpt message as invalid).
ステートフルPCEがP2MP TE LSPレポートメッセージを受信し、PCEがLSPオブジェクトのN（P2MP-CAPABILITY）フラグを理解していないため、このドキュメントで説明されているPCEP拡張機能を理解していない場合、ステートフルPCEはセクション6.1に従って動作します。 [RFC8231]（およびPCRptメッセージを無効と見なす）。
The PCEP extensions described in this document for PCC or PCE with the PCE-Initiation capability for P2MP TE LSPs MUST NOT be used if the PCC or PCE has not advertised its stateful capability with Instantiation and P2MP capability as per Section 5.2. If the PCC supports the extensions as per this document (understands the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag) but did not advertise this capability, then upon receipt of a PCInitiate message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 13 ("Attempted LSP Instantiation Request for P2MP if stateful PCE instantiation capability for P2MP was not advertised"), and terminate the PCEP session.
PCCまたはPCEがインスタンス化およびP2MP機能を備えたステートフル機能をセクション5.2に従って通知していない場合、P2MP TE LSPのPCE-Initiation機能を備えたPCCまたはPCEについてこのドキュメントで説明するPCEP拡張機能を使用してはなりません。 PCCがこのドキュメントのように拡張機能をサポートしている（P（P2MP-LSP-INSTANTIATION-CAPABILITY）フラグを理解している）が、この機能をアドバタイズしなかった場合、PCEからPCInitiateメッセージを受信すると、エラーのあるPCErrを生成する必要があります（SHOULD）。 -type 19（「無効な操作」）、エラー値13（「P2MPのステートフルPCEインスタンス化機能がアドバタイズされなかった場合、P2MPのLSPインスタンス化要求が試行されました」）、およびPCEPセッションを終了します。
All manageability requirements and considerations listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]、[RFC8306]、[RFC8231]、および[RFC8281]にリストされているすべての管理要件と考慮事項は、このドキュメントで定義されているPCEP拡張に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
A PCE or PCC implementation MUST allow configuration of the stateful PCEP capability, the LSP Update capability, and the LSP Initiation capability for P2MP LSPs.
PCEまたはPCC実装では、P2MP LSPのステートフルPCEP機能、LSP更新機能、およびLSP開始機能の構成を許可する必要があります。
The PCEP YANG module [PCE-PCEP-YANG] can be extended to include advertised P2MP stateful capabilities, P2MP synchronization status, and the delegation status of a P2MP LSP, etc. The statistics module should also count data related to P2MP LSPs.
PCEP YANGモジュール[PCE-PCEP-YANG]を拡張して、アドバタイズされたP2MPステートフル機能、P2MP同期ステータス、P2MP LSPの委任ステータスなどを含めることができます。統計モジュールは、P2MP LSPに関連するデータもカウントする必要があります。
Mechanisms defined in this document do not imply any new liveness detection and 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], [RFC8306], [RFC8231], and [RFC8281].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8306]、[RFC8231]、および[RFC8281]にすでにリストされているメカニズムに加えて、新しい動作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルに対する新しい要件を意味するものではありません。
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8306]、[RFC8231]、および[RFC8281]にすでにリストされているメカニズムに加えて、ネットワーク操作に影響を与えません。
Stateful PCE features for P2MP LSPs would help with network operations.
P2MP LSPのステートフルPCE機能は、ネットワーク操作に役立ちます。
IANA has registered the code points for the protocol elements defined in this document.
IANAは、このドキュメントで定義されているプロトコル要素のコードポイントを登録しています。
IANA has registered the new bits in the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry, as follows:
IANAは、次のように、OSPFパラメータの「パス計算要素（PCE）機能フラグ」レジストリに新しいビットを登録しました。
Bit Capability Description Reference
ビット機能説明リファレンス
13 Active Stateful PCE with P2MP RFC 8623 14 Passive Stateful PCE with P2MP RFC 8623 15 Stateful PCE Initiation with P2MP RFC 8623
13 P2MP RFC 8623を使用したアクティブステートフルPCE 14 P2MP RFC 8623を使用したパッシブステートフルPCE 15 P2MP RFC 8623を使用したステートフルPCE開始
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231], and the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry was created to manage the flags in the TLV. IANA has registered the following code points in the aforementioned registry.
STATEFUL-PCE-CAPABILITY TLVは[RFC8231]で定義されており、TLVのフラグを管理するために「STATEFUL-PCE-CAPABILITY TLVフラグフィールド」サブレジストリが作成されました。 IANAは、前述のレジストリに次のコードポイントを登録しています。
Bit Description Reference
ビット説明リファレンス
23 P2MP-LSP-INSTANTIATION-CAPABILITY RFC 8623 24 P2MP-LSP-UPDATE-CAPABILITY RFC 8623 25 P2MP-CAPABILITY RFC 8623
23 P2MP-LSP-INSTANTIATION-CAPABILITY RFC 8623 24 P2MP-LSP-UPDATE-CAPABILITY RFC 8623 25 P2MP-CAPABILITY RFC 8623
The LSP object is defined in [RFC8231], and the "LSP Object Flag Field" subregistry was created to manage the Flags field of the LSP object.
LSPオブジェクトは[RFC8231]で定義されており、LSPオブジェクトのFlagsフィールドを管理するために "LSP Object Flag Field"サブレジストリが作成されました。
IANA has registered the following code points in the aforementioned registry.
IANAは、前述のレジストリに次のコードポイントを登録しています。
Bit Description Reference
ビット説明リファレンス
1 ERO-compression RFC 8623 2 Fragmentation RFC 8623 3 P2MP RFC 8623
1 ERO圧縮RFC 8623 2フラグメンテーションRFC 8623 3 P2MP RFC 8623
IANA has registered the new error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry, as follows:
IANAは、PCEP番号レジストリの「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリ内に、次のように新しいエラー値を登録しました。
Error-Type Meaning
6 Mandatory Object missing [RFC5440]
Error-value = 13: S2LS object missing
Error-value = 14: P2MP-LSP-IDENTIFIERS TLV missing
10 Reception of an invalid object [RFC5440]
Error-value = 22: Mismatch of O field in S2LS
and LSP object
18 P2MP Fragmentation Error [RFC8306]
Error-value = 2: Fragmented Report failure
Error-value = 3: Fragmented Update failure
Error-value = 4: Fragmented Instantiation failure
19 Invalid Operation [RFC8231]
Error-value = 11: Attempted LSP State Report
for P2MP if stateful PCE capability
for P2MP was not advertised
Error-value = 12: Attempted LSP Update Request
for P2MP if active stateful PCE capability
for P2MP was not advertised
Error-value = 13: Attempted LSP Instantiation
Request for P2MP if stateful PCE
instantiation capability for P2MP was not
advertised
The reference for all new Error-values above is RFC 8623.
上記のすべての新しいエラー値のリファレンスはRFC 8623です。
IANA has registered the following code points in the existing "PCEP TLV Type Indicators" registry as follows:
IANAは、既存の「PCEP TLV Type Indicators」レジストリに次のコードポイントを次のように登録しました。
Value Description Reference
値説明リファレンス
32 P2MP-IPV4-LSP-IDENTIFIERS RFC 8623 33 P2MP-IPV6-LSP-IDENTIFIERS RFC 8623
32 P2MP-IPV4-LSP-IDENTIFIERS RFC 8623 33 P2MP-IPV6-LSP-IDENTIFIERS RFC 8623
IANA has registered the new object-class values and object types within the "PCEP Objects" subregistry of the PCEP Numbers registry, as follows.
IANAは、以下のように、PCEP番号レジストリの「PCEPオブジェクト」サブレジストリ内に新しいオブジェクトクラス値とオブジェクトタイプを登録しました。
Object-Class Value Name Reference
オブジェクトクラス値の名前のリファレンス
41 S2LS RFC 8623 Object-Type 0: Reserved 1: S2LS
41 S2LS RFC 8623オブジェクトタイプ0：予約済み1：S2LS
A new subregistry, named "S2LS Object Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the 32-bit flag field of the S2LS object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
S2LSオブジェクトの32ビットフラグフィールドを管理するために、「Path Computation Element Protocol（PCEP）Numbers」レジストリ内に「S2LS Object Flag Field」という名前の新しいサブレジストリが作成されました。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（ビット0を最上位ビットとして数えます）
o Capability description
o 機能の説明
o Defining RFC
o RFCの定義
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
Bit Description Reference
ビット説明リファレンス
0-28 Unassigned 29-31 Operational (3 bits) RFC 8623
0-28未割り当て29-31動作（3ビット）RFC 8623
The stateful operations on P2MP TE LSPs are more CPU intensive and also utilize more bandwidth on the wire (in comparison to P2P TE LSPs). If a rogue PCC were able to request unauthorized stateful PCE operations, then it may be able to mount a DoS attack against a PCE, which would disrupt the network and deny service to other PCCs. Similarly, an attacker may flood the PCC with PCUpd messages at a rate that exceeds either the PCC's ability to process them or the network's ability to signal the changes by either spoofing messages or compromising the PCE itself.
P2MP TE LSPでのステートフル操作は、CPUをより集中的に使用し、（P2P TE LSPと比較して）回線でより多くの帯域幅を利用します。不正なPCCが無許可のステートフルPCE操作を要求できた場合、PCEに対してDoS攻撃を仕掛けることができる可能性があります。これにより、ネットワークが中断し、他のPCCへのサービスが拒否されます。同様に、攻撃者は、PCCがそれらを処理する能力、またはメッセージを偽装するか、PCE自体を危険にさらすことによって変更を通知するネットワークの能力を超える速度でPCUpdメッセージでPCCをフラッディングする可能性があります。
Consequently, it is important that implementations conform to the relevant security requirements as listed below:
したがって、以下にリストするように、実装は関連するセキュリティ要件に準拠することが重要です。
o As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]).
o [RFC8231]に従い、これらのPCEP拡張機能は、推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ（TLS）[RFC8253]を使用して、同じ管理機関に属するPCEとPCC間で認証および暗号化されたセッションでのみアクティブ化することをお勧めします[RFC7525]で（[RFC8253]で明示的に除外しない限り）。
o Security considerations for path computation requests and responses are as per [RFC8306].
o パス計算の要求と応答のセキュリティに関する考慮事項は、[RFC8306]によるものです。
o Security considerations for stateful operations (such as state report, synchronization, delegation, update, etc.) are as per [RFC8231].
o ステートフル操作（状態レポート、同期、委任、更新など）のセキュリティに関する考慮事項は、[RFC8231]のとおりです。
o Security considerations for the LSP instantiation mechanism are as per [RFC8231].
o LSPのインスタンス化メカニズムのセキュリティに関する考慮事項は、[RFC8231]のとおりです。
o Security considerations as stated in Sections 10.1, 10.6, and 10.7 of [RFC5440] continue to apply.
o [RFC5440]のセクション10.1、10.6、および10.7に記載されているセキュリティの考慮事項が引き続き適用されます。
[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>。
[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>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<https://www.rfc-editor.org/info/rfc4875>。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5088] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、DOI 10.17487 / RFC5088、2008年1月、<https://www.rfc-editor.org/info/rfc5088>。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5089] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、DOI 10.17487 / RFC5089、2008年1月、<https://www.rfc-editor.org/info/rfc5089>。
[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編、「Path Computation Element（PCE）Communication Protocol（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。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、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、「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>。
[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>。
[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>。
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017, <https://www.rfc-editor.org/info/rfc8306>.
[RFC8306] Zhao、Q.、Dhody、D.、Ed。、Palleti、R。、およびD. King、「ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパスのPath Computation Element Communication Protocol（PCEP）への拡張」 、RFC 8306、DOI 10.17487 / RFC8306、2017年11月、<https://www.rfc-editor.org/info/rfc8306>。
[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, draft-ietf-pce-pcep-yang-11, March 2019.
[PCE-PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V.、J。Tantsura、「A Path Data Model for Path Computation Element Communications Protocol（PCEP）」、Work in Progress、draft-ietf -pce-pcep-yang-11、2019年3月。
[RFC4655] Farrel, A., Vasseur, J., 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。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, <https://www.rfc-editor.org/info/rfc5671>.
[RFC5671]安川S.およびA.ファレル編、「ポイントツーマルチポイント（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）へのパス計算要素（PCE）の適用性」、RFC 5671、DOI 10.17487 / RFC5671、2009年10月、<https://www.rfc-editor.org/info/rfc5671>。
[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、編、「ステートフルパス計算要素（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[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。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgments
謝辞
Thanks to Quintin Zhao, Avantika, and Venugopal Reddy for the review comments.
レビューコメントを提供してくれたQuintin Zhao、Avantika、Venugopal Reddyに感謝します。
Thanks to Adrian Farrel (and Jonathan Hardwick) for the review as document shepherds.
ドキュメントシェパードとしてレビューしてくれたAdrian Farrel（およびJonathan Hardwick）に感謝します。
Thanks to Andy Malis for the RTG-DIR review. Thanks to Donald Eastlake for the SEC-DIR review. Thanks to David Schinazi for the GEN-ART review.
RTG-DIRのレビューをしてくれたAndy Malisに感謝します。 SEC-DIRレビューを提供してくれたDonald Eastlakeに感謝します。 GEN-ARTレビューをしてくれたDavid Schinaziに感謝します。
Thanks to Suresh Krishnan, Mirja Kuhlewind, Roman Danyliw, and Benjamin Kaduk for the IESG reviews.
IESGのレビューを提供してくれたSuresh Krishnan、Mirja Kuhlewind、Roman Danyliw、Benjamin Kadukに感謝します。
Contributors
貢献者
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan
ゆじ かみて んっｔ こっむにかちおんｓ こｒぽらちおん Ｇらんぱｒｋ とうぇｒ ３ー４ー１ しばうら、 みなとーく ときょ １０８ー８１１８ じゃぱん
Email: y.kamite@ntt.com
Authors' Addresses
著者のアドレス
Udayasree Palle Huawei Technologies
Udayasari Palle Huawei Technologies
Email: udayasreereddy@gmail.com
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Dhruv Dhodai Huawei Technologies Divyashari Techno Park、Wheatfished Bangalore、Karnataka 2008インド
Email: dhruv.ietf@gmail.com
Yosuke Tanaka NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan
よすけ たなか んっｔ こっむにかちおんｓ こｒぽらちおん Ｇらんぱｒｋ とうぇｒ ３ー４ー１ しばうら、 みなとーく ときょ １０８ー８１１８ じゃぱん
Email: yosuke.tanaka@ntt.com
Vishnu Pavan Beeram Juniper Networks
Vishnu Pavan Beeram Juniper Networks
Email: vbeeram@juniper.net