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
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）路径的合适技术。本文档提供了路径计算元素通信协议（PCEP）所需的扩展，以便能够在支持P2MP TE LSP时使用有状态PCE功能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/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.
版权（c）2019 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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]描述了如何设置点对多点（P2MP）流量工程标签交换路径（TE LSP），以用于多协议标签交换（MPLS）和通用MPLS（GMPLS）网络。[RFC5671]检查PCE对P2MP TE LSP路径计算的适用性。
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设计为PCC和PCE之间的通信协议，用于点对点（P2P）路径计算，并在[RFC5440]中定义。[RFC8306]中描述了PCEP对P2MP TE LSP请求路径计算的扩展。
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.
有状态PCE在MPLS和GMPLS网络中的许多应用场景中都很有用，如[RFC8051]所示。这些场景同样适用于P2P和P2MP TE LSP。[RFC8231]提供了有状态PCE所需的PCEP的基本扩展，以支持P2P TE LSP的一般功能。[RFC8281]提供有状态PCE启动的P2P TE LSP所需的PCEP扩展。本文档通过关注PCEP扩展来补充这项工作，PCEP扩展是部署有状态PCE以支持P2MP TE LSP所必需的。本文档描述了在有状态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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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]介绍了几个用例，演示了从部署有状态PCE中获益的场景，包括优化、恢复等，这些场景同样适用于P2MP TE LSP。[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
除此之外，PCE的有状态性质简化了在PCEP消息中传送的信息，因为可以通过PCEP特定LSP标识符（PLSP-ID）（[RFC8231]）引用LSP。对于P2MP，消息的大小要大得多，这是一个额外的优势。当使用无状态PCE时，修改现有P2MP树的请求要求所有叶子与所有路径信息一起显示在PCEP消息中。但是当使用
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.
在有状态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启动能力背后的动机，该能力同样适用于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的P2MP TE LSP的状态，然后才能执行路径计算或更新PCC中的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）：只要P2MP TE LSP的状态发生变化，PCC就会向PCE发送LSP状态报告。
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授予PCE更新一个或多个P2MP TE LSP上的LSP属性的权利；只要委托有效，PCE就成为LSP属性的权威来源（见[RFC8231]第5.7节）；PCC可随时撤回授权或放弃授权。
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向PCC发送LSP初始化消息，以实例化或删除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.
[RFC8231]中定义了两条新的PCEP消息，以支持P2P TE LSP的有状态PCE。在本文档中，这些消息扩展如下，以支持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状态报告还用于将P2MP TE LSP的控制权委托给PCE或从PCE中撤销。第6.1节描述了PCRpt消息的扩展。
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参数。如果PCE不再希望控制P2MP TE LSP，则PCUpd消息中携带的LSP更新请求也用于返回LSP委派。第6.2节描述了PCUpd消息。
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.
此外，[RFC8281]中定义了新的PCEP消息，以支持P2P TE LSP的有状态PCE实例化。在本文档中，此消息扩展如下，以支持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的实例化或删除。第6.5节描述了PCInitiate消息。
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]中还扩展了路径计算请求（PCReq）和路径计算回复（PCRep）消息，以支持P2P TE LSP的被动有状态PCE。在本文档中，这些消息也扩展为支持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扬声器通过开放对象中的Stateful-PCE-capability TLV发布有状态能力。[RFC8231]中定义并在[RFC8281]和[RFC8232]中更新的有状态PCE能力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）：
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 flag-1位）：如果PCC设置为1，则N标志表示PCC愿意在P2MP LSP的参数或运行状态发生变化时发送P2MP LSP状态报告；如果PCE设置为1，则N标志表示PCE有兴趣在P2MP LSP发生参数或运行状态更改时接收LSP状态报告。PCC和PCE必须公布P2MP-CAPABILITY标志，以便PCRpt消息的P2MP扩展（根据本文件）在PCEP会话上被允许。
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 flag-1位）：如果PCC设置为1，则M标志表示PCC允许修改P2MP LSP参数；如果PCE设置为1，则M标志表示PCE能够更新P2MP LSP参数。PCC和PCE必须公布P2MP-LSP-UPDATE-CAPABILITY标志，以便在PCEP会话上允许PCUpd消息的P2MP扩展（根据本文档）。
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 flag-1位）：如果PCC设置为1，则P标志表示PCC允许PCE实例化P2MP LSP。如果PCE设置为1，则P标志表示PCE支持P2MP LSP实例化。PCC和PCE必须设置P2MP-LSP-INSTANTIATION-CAPABILITY标志，以支持PCE启动的P2MP LSP实例化。
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
当PCC是参与IGP（OSPF或is-is）的标签交换路由器（LSR）并且PCE是也参与IGP的LSR或服务器时，IGP路由域内PCE发现的有效机制包括利用IGP
advertisements. Extensions for the advertisement of PCE discovery information are defined for OSPF and for IS-IS in [RFC5088] and [RFC5089], respectively.
广告。[RFC5088]和[RFC5089]中分别为OSPF和IS-IS定义了PCE发现信息发布的扩展。
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.
值：包含32位标志的单位数组，最高有效位为0。每一位代表一个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功能可能会在发现期间公布，但希望将状态PCEP用于P2MP TE LSP的PCEP扬声器必须在PCEP会话设置期间公布状态PCEP功能，如当前文档中所述。PCC可以在PCEP会话设置时启动有状态PCEP P2MP能力播发，即使它没有收到任何IGP PCE能力播发。
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.
[RFC8306]第3.4节和第3.5节分别描述了P2MP TE LSP的PCReq和PCRep消息格式。
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树中的一个叶子的情况下，应该不需要在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.
第6.3节和第6.4节描述了P2MP TE LSP上被动有状态操作的请求和响应消息的扩展。第6.1节描述了路径计算LSP状态报告（PCRpt）消息的扩展。
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.
第6.2节描述了P2MP TE LSP上活动有状态操作的路径计算LSP更新（PCUpd）消息的扩展。
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向PCC发送路径计算LSP启动请求（PCInitiate）消息，以建议实例化或删除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].
P2MP TE LSP的实例化和删除操作与[RFC8281]第5.3节和第5.4节中描述的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 TE LSP的实例化操作与[RFC8281]第5.3节中定义的LSP实例化操作相同；这包括PLSP-ID、SYMBOL-PATH-NAME TLV等的处理。处理规则和错误代码的使用保持不变。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.
PCE必须在PCInitiate消息中的LSP对象中设置（P2MP）标志（第7.1节），以指定实例化用于P2MP TE LSP。与PLSP-ID一样（根据[RFC8281]），P2MP-LSP-IDENTIFIERS TLV不应包含在PCInitiate消息中的LSP对象中，并且在收到时必须忽略。PCC在收到PCInitiate消息时生成这些标识符，并通过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 Initiate消息，其中包含一个LSP对象，该对象携带要删除的LSP的PLSP-ID，以及一个设置了R标志的有状态PCE请求参数（SRP）对象（根据[RFC8281]第5.2节的LSP-REMOVE）。处理规则和错误代码保持不变。
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.
根据第6.2节关于P2MP TE LSP扩展的规定，PCE启动的P2MP TE LSP的新叶添加和旧叶修剪必须在PCUpd消息中进行。如[RFC8306]中所定义，叶类型=1用于添加新叶，叶类型=2用于修剪P2MP端点对象的旧叶。
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树中添加新叶或删除旧叶时的错误处理过程。如本文档所述，相同的错误处理和错误代码也适用于有状态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]中规定的路由Backus-Naur格式（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:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
<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>]
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-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>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<actual-path>
[<end-point-actual-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>]
<actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>]
<intended-attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
<预期属性列表>在[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 list>对象的实际计算值和信号值组成。
The P2MP END-POINTS object defined in [RFC8306] is mandatory for specifying the address of P2MP leaves, grouped by leaf types.
[RFC8306]中定义的P2MP端点对象对于指定按叶类型分组的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字段）和叶类型（端点对象中的叶类型）在端点对象中对目的地进行分组。这样，共享相同操作状态的相同类型的叶可以组合在一起。对于报告委派的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消息报告配置更改。例如，对于添加新叶，在端点对象中使用叶类型=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]定义的兼容性被保留。对于P2MP LSP，此消息中必须至少存在一个<END-POINTS>实例。
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].
请注意，<端点预期路径对列表>、<实际属性列表>、<端点实际路径对列表>和<预期属性列表>的排序是为了按照[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
当在P2MP TE LSP的LSP对象中设置N（P2MP）标志时，S2LS对象必须与端点对象一起在PCRpt消息中携带。如果S2LS对象丢失，接收PCE必须发送PCEP错误（PCErr）消息，错误类型为6（“强制对象丢失”），错误值为13（“S2LS对象丢失”）。如果
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].
端点对象缺失，接收PCE必须发送错误类型为6（“强制对象缺失”）且错误值为3（“端点对象缺失”）的PCErr消息（在[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对象可与预期路径（显式路由对象或ERO）以及实际路径（记录路由对象或RRO）一起使用；对于同一个叶，与实际路径关联的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，后跟一个次级\u显式\u路由对象列表（SERO）或一个RRO，后跟一个次级\u记录\u路由对象列表（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>
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
哪里：
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path> ::= <end-point-path-pair-list>
<intended-attribute-list>
Where:
<path> ::= <end-point-path-pair-list>
<intended-attribute-list>
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<intended-attribute-list> is the attribute-list defined in [RFC5440] and extended by PCEP extensions.
<destined 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]中所述的先接通后断或基于子组的程序。
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标志时，端点对象必须在PCUpd消息中携带。如果端点对象缺失，则接收PCC必须发送错误类型为6（“强制对象缺失”）且错误值为3（“端点对象缺失”）（在[RFC5440]中定义）的PCErr消息。
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可以在PCReq消息中包括LSP对象。
The format of a PCReq message is as follows:
PCReq消息的格式如下所示：
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
哪里：
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<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>]
<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>]
<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>
<PCRep Message>::= <Common Header>
<response-list>
where:
哪里：
<response-list>::=<response>[<response-list>]
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-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>]
<end-point-path-pair-list>::= [<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<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向PCC发送PCInitiate消息，以建议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:
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<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-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-instantiation> ::= <SRP>
<LSP>
<end-point-path-pair-list>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
哪里：
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<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上的操作。SRP对象用于将PCE发送的启动请求与PCC发送的错误报告和状态报告关联起来，如[RFC8231]所述。
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标志时，端点对象必须在PCInitiate消息中携带。如果端点对象缺失，则接收PCC必须发送错误类型为6（“强制对象缺失”）且错误值为3（“端点对象缺失”）（在[RFC5440]中定义）的PCErr消息。
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 LSPs参数或属性。P2MP TE LSP的PCUpd消息示例如下所述：
Common Header SRP LSP with P2MP flag set END-POINTS for leaf type 3 ERO list
具有P2MP标志的公共标头SRP LSP为叶类型3 ERO列表设置端点
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树中某些叶子的路径。更新请求使用端点类型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状态报告消息由PCC发送，以报告或委派P2MP TE LSP。P2MP TE LSP的叶根据运行状态和叶类型在端点对象中分组。PCRpt消息的示例如下所述，用于委托P2MP TE LSP向现有P2MP TE LSP添加新叶：
Common Header LSP with P2MP flag set END-POINTS for leaf type 1 (add) S2LS (O=DOWN) ERO list (empty)
带有P2MP标志的公共标头LSP为叶类型1（添加）S2LS（O=向下）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的PCRpt消息示例如下所述，用于从现有P2MP TE LSP修剪树叶：
Common Header LSP with P2MP flag set END-POINTS for leaf type 2 (remove) S2LS (O=UP) ERO list (empty)
带有P2MP标志的公共标头LSP为叶类型2（删除）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的端点（修改）S2LS（O=向上）RRO列表叶类型3的端点（修改）S2LS（O=向下）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的端点（未更改）S2LS（O=活动）RRO列表叶类型4的端点（未更改）S2LS（O=向下）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:
有状态PCE发送LSP启动请求消息以创建P2MP TE LSP。P2MP TE LSP的PCInitiate消息示例如下所述：
Common Header SRP LSP with P2MP flag set END-POINTS for leaf type 1 (add) ERO list
具有P2MP标志的公共标头SRP LSP为叶类型1（添加）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。发起请求使用端点类型1（新叶）。ERO列表表示要离开的源路径。在这种情况下，initiate消息对完整的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节中定义。它指定PLSP-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（请求参数）对象中的相应标志如[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标识符TLV。对于P2MP TE LSP，本文档定义了LSP对象的P2MP-LSP-TLV标识符。有两个P2MP-LSP-TLV标识符，一个用于IPv4，一个用于IPv6。P2MP-LSP标识符TLV必须包含在P2MP TE LSP的PCRpt消息中的LSP对象中。如果在PCRpt消息的LSP对象中设置了N位，但缺少P2MP-LSP-IDENTIFIER TLV，则PCE必须使用带有错误类型6（“强制对象缺失”）和错误值14（“P2MP-LSP-IDENTIFIERS TLV缺失”）的PCErr消息进行响应，并关闭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节），并且可以选择性地包括在PCReq中的LSP对象和P2MP TE LSP的PCRep消息中。
The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in Figure 1:
IPV4-P2MP-LSP-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-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隧道发送方地址：包含发送方节点的IPv4地址，如[RFC3209]中所定义。有关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会话对象定义的32位“P2MP ID”标识符。
The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in Figure 2:
IPV6-P2MP-LSP-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-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隧道发送方地址：包含发送方节点的IPv6地址，如[RFC3209]中所定义。有关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（源到叶）对象用于报告P2MP TE LSP的端点对象中编码的一个或多个目的地（叶）的状态。当在LSP对象中设置N标志时，它必须与端点对象一起在PCRpt消息中携带。
S2LS Object-Class is 41.
S2LS对象类是41。
S2LS Object-Types is 1.
S2LS对象类型为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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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对象中的操作字段。
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
当在LSP对象中设置N标志时，LSP对象中的O字段表示完整P2MP TE LSP的操作状态，而S2LS对象中的O字段表示在端点对象中编码的一组目的地的操作状态。如果LSP中的O字段与S2LS对象之间存在冲突（例如
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中的O字段对应于down，而S2LS中的O字段是up），PCEP扬声器必须生成错误类型为10（“接收无效对象”）和错误值为22（“S2LS中的O字段与LSP对象不匹配”）的错误。
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消息（例如，初始报告或更新）。LSP对象中使用F标志来表示初始报告、更新或启动请求太大，无法放入单个PCEP消息中，并且将被分割为多个消息。为了识别单个报告或更新，每条消息将使用相同的PLSP-ID。为了识别一系列PCInitiate消息代表单个Initiate，每条消息将使用相同的PLSP-ID（在本例中为0）和SRP ID号。
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.
如果初始报告太大，无法放入单个报告消息中，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.
错误类型值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
一旦PCE为P2MP TE LSP中的部分或全部叶计算并更新路径，则会向PCC发送更新消息。如果更新太大，无法放入单个更新消息中，则PCE会将更新拆分为多个消息。PCE发送的每个更新消息（最后一个消息除外）都将在LSP对象中设置F标志，以
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.
表示更新已分为多条消息。为了确定一系列更新消息表示单个更新，每条消息将使用相同的PLSP-ID和SRP 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 3 indicates "Fragmented update failure" and is used if a PCC does not receive the last part of the fragmented message.
错误类型值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，PCE将向PCC发送PCInitiate消息。如果启动请求太大，无法放入单个PCInitiate消息中，PCE会将启动请求拆分为多个消息。由PCE发送的每个PCInitiate消息（最后一个消息除外）都将在LSP对象中设置F标志，以表示PCInitiate已分为多个消息。为了确定一系列PCInitiate消息表示一次启动，每条消息将使用相同的PLSP-ID（在本例中为0）和SRP 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 4 indicates "Fragmented instantiation failure" and is used if a PCC does not receive the last part of the fragmented message.
错误类型值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能力的状态PCE，则不得使用本文件中描述的具有P2MP能力的状态PCE的PCEP扩展。如果PCC支持本文件规定的扩展（理解LSP对象中的N（P2MP-CAPABILITY）和M（P2MP-LSP-UPDATE-CAPABILITY）标志），但未公布此功能，则在收到PCE的PCUpd消息后，应生成错误类型为19（“无效操作”）的PCErr，错误值为12(“如果P2MP的活动有状态PCE功能未公布，则尝试对P2MP进行LSP更新请求”），并终止PCEP会话。如果PCE支持本文档中的扩展（理解LSP对象中的N（P2MP-capability）标志）但未公布此功能，则在收到来自PCC的PCRpt消息后，应生成错误类型为19（“无效操作”）的PCErr，错误值为11（“如果未公布P2MP的有状态PCE功能，则P2MP的尝试LSP状态报告”），并应终止PCEP会话。
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接收到一个PMP TE LSP报告消息，并且PCE不理解LSP对象中的N（2MP-能力）标志，因此不理解该文档中描述的PCEP扩展，那么状态PCE将充当[FRC8212]的第6.1节（并且考虑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未按照第5.2节的规定公布其实例化状态能力和P2MP能力，则不得使用本文件中描述的PCC或PCE的PCE扩展，以及P2MP TE LSP的PCE启动能力。如果PCC支持本文件规定的扩展（理解P（P2MP-LSP-INSTANTIATION-CAPABILITY）标志），但未公布该功能，则在收到PCE的PCInitiate消息后，应生成错误类型为19（“无效操作”）的PCErr，错误值为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.
[RFC8231]中定义了STATEFUL-PCE-CAPABILITY TLV，并创建了“STATEFUL-PCE-CAPABILITY TLV标志字段”子域以管理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-实例化-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对象标志字段”子域以管理LSP对象的标志字段。
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
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类型指示器”注册表中注册了以下代码点，如下所示：
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:
在“路径计算元素协议（PCEP）编号”注册表中创建了一个名为“S2LS对象标志字段”的新子区，以管理S2LS对象的32位标志字段。新值将由标准行动[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处理PCUpd消息的能力或网络通过欺骗消息或损害PCE本身发出更改信号的能力的速率向PCC发送PCUpd消息。
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]，建议根据[RFC7525]中的建议和最佳当前实践，使用传输层安全性（TLS）[RFC8253]仅在属于同一管理机构的PCE和PCC之间经过身份验证和加密的会话上激活这些PCEP扩展（除非[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：LSP隧道RSVP的扩展”，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.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，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.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，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.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，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主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，DOI 10.17487/RFC5511，2009年4月<https://www.rfc-editor.org/info/rfc5511>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的路径计算元素通信协议（PCEP）扩展”，RFC 8231，DOI 10.17487/RFC82312017年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，“PCEP：使用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，“点对多点流量工程标签交换路径的路径计算元素通信协议（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，“路径计算元素通信协议（PCEP）的YANG数据模型”，正在进行的工作，草案-ietf-PCE-PCEP-YANG-112019年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，“基于路径计算元素（PCE）的体系结构”，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]Yasukawa，S.和A.Farrel，Ed.“路径计算元素（PCE）对点对多点（P2MP）MPLS和GMPLS流量工程（TE）的适用性”，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]Zhang，X.，Ed.和I.Minei，Ed.“有状态路径计算元素（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]Cotton，M.，Leiba，B.，和T.Narten，“在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.
感谢Andy Malis的RTG-DIR评论。感谢Donald Eastlake的SEC-DIR审查。感谢David Schinazi的GEN-ART评论。
Thanks to Suresh Krishnan, Mirja Kuhlewind, Roman Danyliw, and Benjamin Kaduk for the IESG reviews.
感谢Suresh Krishnan、Mirja Kuhlewind、Roman Danyliw和Benjamin Kaduk对IESG的评论。
Contributors
贡献者
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura，Minato ku东京108-8118
Email: y.kamite@ntt.com
Email: y.kamite@ntt.com
Authors' Addresses
作者地址
Udayasree Palle Huawei Technologies
华为技术公司Udayasree Palle
Email: udayasreereddy@gmail.com
Email: udayasreereddy@gmail.com
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
印度卡纳塔克邦班加罗尔Whitefield Bangalore Dhruv Dhody华为技术分部，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Yosuke Tanaka NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan
日本东京弥敦区Shibaura 3-4-1号Granpark大厦108-8118
Email: yosuke.tanaka@ntt.com
Email: yosuke.tanaka@ntt.com
Vishnu Pavan Beeram Juniper Networks
毗瑟奴-帕万-比拉姆杜松网络
Email: vbeeram@juniper.net
Email: vbeeram@juniper.net