Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 8306 D. Dhody, Ed.
Obsoletes: 6006 R. Palleti
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 D. King
Old Dog Consulting
November 2017
Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 8306 D. Dhody, Ed.
Obsoletes: 6006 R. Palleti
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 D. King
Old Dog Consulting
November 2017
Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
点对多点流量工程标签交换路径的路径计算元素通信协议（PCEP）扩展
Abstract
摘要
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
可以使用信令技术建立点对点多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程标签交换路径（TE LSP），但可能首先需要确定它们的路径。路径计算元件（PCE）已被确定为确定点对多点（P2MP）TE LSP路径的合适技术。
This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.
本文档描述了PCE通信协议（PCEP）的扩展，以处理P2MP TE LSP路径计算的请求和响应。
This document obsoletes RFC 6006.
本文件淘汰RFC 6006。
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/rfc8306.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8306.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................7
3.1.1. IGP Extensions for P2MP Capability Advertisement ....7
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................8
3.3. P2MP Path Computation Request/Reply Message Extensions .....9
3.3.1. The Extension of the RP Object ......................9
3.3.2. The P2MP END-POINTS Object .........................11
3.4. Request Message Format ....................................13
3.5. Reply Message Format ......................................15
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................7
3.1.1. IGP Extensions for P2MP Capability Advertisement ....7
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................8
3.3. P2MP Path Computation Request/Reply Message Extensions .....9
3.3.1. The Extension of the RP Object ......................9
3.3.2. The P2MP END-POINTS Object .........................11
3.4. Request Message Format ....................................13
3.5. Reply Message Format ......................................15
3.6. P2MP Objective Functions and Metric Types .................16
3.6.1. Objective Functions ................................16
3.6.2. METRIC Object-Type Values ..........................17
3.7. Non-Support of P2MP Path Computation ......................17
3.8. Non-Support by Back-Level PCE Implementations .............17
3.9. P2MP TE Path Reoptimization Request .......................17
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........18
3.11. Discovering Branch Nodes .................................22
3.11.1. Branch Node Object ................................22
3.12. Synchronization of P2MP TE Path Computation Requests .....22
3.13. Request and Response Fragmentation .......................23
3.13.1. Request Fragmentation Procedure ...................24
3.13.2. Response Fragmentation Procedure ..................24
3.13.3. Fragmentation Example .............................24
3.14. UNREACH-DESTINATION Object ...............................25
3.15. P2MP PCEP-ERROR Objects and Types ........................27
3.16. PCEP NO-PATH Indicator ...................................28
4. Manageability Considerations ...................................28
4.1. Control of Function and Policy ............................28
4.2. Information and Data Models ...............................28
4.3. Liveness Detection and Monitoring .........................29
4.4. Verifying Correct Operation ...............................29
4.5. Requirements for Other Protocols and Functional
Components ................................................29
4.6. Impact on Network Operation ...............................29
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
6.1. PCEP TLV Type Indicators ..................................31
6.2. Request Parameter Bit Flags ...............................31
6.3. Objective Functions .......................................31
6.4. METRIC Object-Type Values .................................32
6.5. PCEP Objects ..............................................32
6.6. PCEP-ERROR Objects and Types ..............................34
6.7. PCEP NO-PATH Indicator ....................................35
6.8. SVEC Object Flag ..........................................35
6.9. OSPF PCE Capability Flag ..................................35
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Summary of Changes from RFC 6006 ......................39
Appendix A.1. RBNF Changes from RFC 6006 ..........................39
Acknowledgements ..................................................41
Contributors ......................................................42
Authors' Addresses ................................................43
3.6. P2MP Objective Functions and Metric Types .................16
3.6.1. Objective Functions ................................16
3.6.2. METRIC Object-Type Values ..........................17
3.7. Non-Support of P2MP Path Computation ......................17
3.8. Non-Support by Back-Level PCE Implementations .............17
3.9. P2MP TE Path Reoptimization Request .......................17
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........18
3.11. Discovering Branch Nodes .................................22
3.11.1. Branch Node Object ................................22
3.12. Synchronization of P2MP TE Path Computation Requests .....22
3.13. Request and Response Fragmentation .......................23
3.13.1. Request Fragmentation Procedure ...................24
3.13.2. Response Fragmentation Procedure ..................24
3.13.3. Fragmentation Example .............................24
3.14. UNREACH-DESTINATION Object ...............................25
3.15. P2MP PCEP-ERROR Objects and Types ........................27
3.16. PCEP NO-PATH Indicator ...................................28
4. Manageability Considerations ...................................28
4.1. Control of Function and Policy ............................28
4.2. Information and Data Models ...............................28
4.3. Liveness Detection and Monitoring .........................29
4.4. Verifying Correct Operation ...............................29
4.5. Requirements for Other Protocols and Functional
Components ................................................29
4.6. Impact on Network Operation ...............................29
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
6.1. PCEP TLV Type Indicators ..................................31
6.2. Request Parameter Bit Flags ...............................31
6.3. Objective Functions .......................................31
6.4. METRIC Object-Type Values .................................32
6.5. PCEP Objects ..............................................32
6.6. PCEP-ERROR Objects and Types ..............................34
6.7. PCEP NO-PATH Indicator ....................................35
6.8. SVEC Object Flag ..........................................35
6.9. OSPF PCE Capability Flag ..................................35
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Summary of Changes from RFC 6006 ......................39
Appendix A.1. RBNF Changes from RFC 6006 ..........................39
Acknowledgements ..................................................41
Contributors ......................................................42
Authors' Addresses ................................................43
The Path Computation Element (PCE) as defined in [RFC4655] 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.
[RFC4875]描述了如何设置点对多点（P2MP）流量工程标签交换路径（TE LSP），以用于多协议标签交换（MPLS）和通用MPLS（GMPLS）网络。
The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671].
PCE已被确定为P2MP TE LSP路径计算的合适应用[RFC5671]。
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. However, that specification does not provide a mechanism to request path computation of P2MP TE LSPs.
PCE通信协议（PCEP）设计为PCC和PCE之间的通信协议，用于点对点（P2P）路径计算，并在[RFC5440]中定义。然而，该规范没有提供请求P2MP TE lsp的路径计算的机制。
A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between ingress and egress Label Switching Routers (LSRs) and are appropriately overlaid to construct a P2MP TE LSP. During path computation, the P2MP TE LSP may be determined as a set of S2L sub-LSPs that are computed separately and combined to give the path of the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP tree in a single computation.
P2MP LSP由多个源到叶（S2L）子LSP组成。这些S2L子LSP设置在入口和出口标签交换路由器（LSR）之间，并适当覆盖以构建P2MP TE LSP。在路径计算期间，可以将P2MP TE LSP确定为单独计算并组合以给出P2MP LSP的路径的一组S2L子LSP，或者可以在单个计算中将整个P2MP TE LSP确定为P2MP树。
This document relies on the mechanisms of PCEP to request path computation for P2MP TE LSPs. One Path Computation Request message from a PCC may request the computation of the whole P2MP TE LSP, or the request may be limited to a subset of the S2L sub-LSPs. In the extreme case, the PCC may request the S2L sub-LSPs to be computed individually; the PCC is responsible for deciding whether to signal individual S2L sub-LSPs or combine the computation results to signal the entire P2MP TE LSP. Hence, the PCC may use one Path Computation Request message or may split the request across multiple path computation messages.
本文档依赖于PCEP的机制为P2MP TE LSP请求路径计算。来自PCC的一条路径计算请求消息可以请求计算整个P2MP TE LSP，或者该请求可以限于S2L子LSP的子集。在极端情况下，PCC可请求单独计算S2L子lsp；PCC负责决定是向单个S2L子LSP发送信号，还是结合计算结果向整个P2MP TE LSP发送信号。因此，PCC可以使用一条路径计算请求消息，或者可以跨多条路径计算消息分割请求。
This document obsoletes [RFC6006] and incorporates the following errata:
本文件废除[RFC6006]，并包含以下勘误表：
o Erratum IDs 3819, 3830, 3836, 4867, and 4868 for [RFC6006]
o [RFC6006]的勘误表IDs 3819、3830、3836、4867和4868
o Erratum ID 4956 for [RFC5440]
o [RFC5440]的勘误表ID 4956
All changes from [RFC6006] are listed in Appendix A.
附录A中列出了[RFC6006]的所有变更。
Terminology used in this document:
本文件中使用的术语：
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
LSR: Label Switching Router.
标签交换路由器。
OF: Objective Function. A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization) or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization).
目标函数。用于计算单个路径（例如，路径成本最小化）或用于同步计算一组路径（例如，总带宽消耗最小化）的一组或多个优化标准。
P2MP: Point-to-Multipoint.
P2MP：点对多点。
P2P: Point-to-Point.
P2P：点对点。
This document also uses the terminology defined in [RFC4655], [RFC4875], and [RFC5440].
本文件还使用了[RFC4655]、[RFC4875]和[RFC5440]中定义的术语。
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]所述进行解释。
This section summarizes the PCC-PCE communication requirements as met by the protocol extension specified in this document for P2MP MPLS-TE LSPs. The numbering system in the list below corresponds to the requirement numbers (e.g., R1, R2) used in [RFC5862].
本节总结了本文件中规定的P2MP MPLS-TE LSP协议扩展所满足的PCC-PCE通信要求。下表中的编号系统对应于[RFC5862]中使用的需求编号（如R1、R2）。
1. The PCC MUST be able to specify that the request is a P2MP path computation request.
1. PCC必须能够指定该请求为P2MP路径计算请求。
2. The PCC MUST be able to specify that objective functions are to be applied to the P2MP path computation request.
2. PCC必须能够指定将目标函数应用于P2MP路径计算请求。
3. The PCE MUST have the capability to reject a P2MP path computation request and indicate non-support of P2MP path computation.
3. PCE必须能够拒绝P2MP路径计算请求并指示不支持P2MP路径计算。
4. The PCE MUST provide an indication of non-support of P2MP path computation by back-level PCE implementations.
4. PCE必须提供不支持后台PCE实现的P2MP路径计算的指示。
5. A P2MP path computation request MUST be able to list multiple destinations.
5. P2MP路径计算请求必须能够列出多个目的地。
6. A P2MP path computation response MUST be able to carry the path of a P2MP LSP.
6. P2MP路径计算响应必须能够承载P2MP LSP的路径。
7. By default, the path returned by the PCE SHOULD use the compressed format.
7. 默认情况下，PCE返回的路径应使用压缩格式。
8. It MUST be possible for a single P2MP path computation request or response to be conveyed by a sequence of messages.
8. 单个P2MP路径计算请求或响应必须能够通过一系列消息传递。
9. It MUST NOT be possible for a single P2MP path computation request to specify a set of different constraints, traffic parameters, or quality-of-service requirements for different destinations of a P2MP LSP.
9. 单个P2MP路径计算请求不能为P2MP LSP的不同目的地指定一组不同的约束、流量参数或服务质量要求。
10. P2MP path modification and P2MP path diversity MUST be supported.
10. 必须支持P2MP路径修改和P2MP路径分集。
11. It MUST be possible to reoptimize existing P2MP TE LSPs.
11. 必须能够重新优化现有P2MP TE LSP。
12. It MUST be possible to add and remove P2MP destinations from existing paths.
12. 必须能够从现有路径中添加和删除P2MP目标。
13. It MUST be possible to specify a list of applicable branch nodes to use when computing the P2MP path.
13. 在计算P2MP路径时，必须能够指定要使用的适用分支节点列表。
14. It MUST be possible for a PCC to discover P2MP path computation capability.
14. PCC必须能够发现P2MP路径计算能力。
15. The PCC MUST be able to request diverse paths when requesting a P2MP path.
15. 在请求P2MP路径时，PCC必须能够请求不同的路径。
The following section describes the protocol extensions required to satisfy the requirements specified in Section 2 ("PCC-PCE Communication Requirements") of this document.
以下章节描述了满足本文件第2节（“PCC-PCE通信要求”）规定要求所需的协议扩展。
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF Router Information Link State Advertisement (LSA) as defined in [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be added to the PCED TLV. This document defines a flag in the OSPF PCE Capability Flags to indicate the capability of P2MP computation.
[RFC5088]定义了OSPF路由器信息链路状态公告（LSA）中携带的PCE发现（PCED）TLV，如[RFC7770]中所定义，以便于使用OSPF进行PCE发现。[RFC5088]规定不得向PCED TLV添加新的子TLV。本文件在OSPF PCE能力标志中定义了一个标志，以指示P2MP计算能力。
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE discovery using IS-IS. This document will use the same flag for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate the capability of P2MP computation.
类似地，[RFC5089]定义了PCE子TLV，用于使用IS-IS的PCE发现。本文件将对OSPF PCE能力标志子TLV使用相同的标志，以允许IS-IS指示P2MP计算能力。
The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag is documented in Section 6.9 ("OSPF PCE Capability Flag") of this document.
共享OSPF和IS-IS P2MP能力标志的IANA分配记录在本文件第6.9节（“OSPF PCE能力标志”）中。
PCEs wishing to advertise that they support P2MP path computation would set the bit (10) accordingly. PCCs that do not understand this bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not support P2MP will leave the bit clear (per the default behavior defined in [RFC5088] and [RFC5089]).
希望公布其支持P2MP路径计算的PCE将相应地设置位（10）。不理解该位的PCC将忽略该位（根据[RFC5088]和[RFC5089]）。不支持P2MP的PCE将保留位清除（根据[RFC5088]和[RFC5089]中定义的默认行为）。
PCEs that set the bit to indicate support of P2MP path computation MUST follow the procedures in Section 3.3.2 ("The P2MP END-POINTS Object") to further qualify the level of support.
设置位以指示支持P2MP路径计算的PCE必须遵循第3.3.2节（“P2MP端点对象”）中的程序，以进一步限定支持水平。
Based on the Capabilities Exchange requirement described in [RFC5862], if a PCE does not advertise its P2MP capability during discovery, PCEP should be used to allow a PCC to discover, during the Open Message Exchange, which PCEs are capable of supporting P2MP path computation.
根据[RFC5862]中描述的能力交换要求，如果PCE在发现期间未公布其P2MP能力，则应使用PCEP允许PCC在开放消息交换期间发现哪些PCE能够支持P2MP路径计算。
To satisfy this requirement, we extend the PCEP OPEN object by defining an optional TLV to indicate the PCE's capability to perform P2MP path computations.
为了满足这一要求，我们通过定义可选的TLV来扩展PCEP开放对象，以指示PCE执行P2MP路径计算的能力。
IANA has allocated value 6 from the "PCEP TLV Type Indicators" subregistry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). The description is "P2MP capable", and the length value is 2 bytes. The value field is set to default value 0.
IANA已根据第6.1节（“PCEP TLV类型指标”）的规定，从“PCEP TLV类型指标”子区域分配了值6。描述为“支持P2MP”，长度值为2字节。值字段设置为默认值0。
The inclusion of this TLV in an OPEN object indicates that the sender can perform P2MP path computations.
在开放对象中包含此TLV表示发送方可以执行P2MP路径计算。
The capability TLV is meaningful only for a PCE, so it will typically appear only in one of the two Open messages during PCE session establishment. However, in the case of PCE cooperation (e.g., inter-domain), when a PCE behaving as a PCC initiates a PCE session it SHOULD also indicate its path computation capabilities.
功能TLV仅对PCE有意义，因此在PCE会话建立期间，它通常仅出现在两条打开的消息之一中。然而，在PCE协作（例如域间）的情况下，当作为PCC的PCE发起PCE会话时，它还应指示其路径计算能力。
When specifying additional leaves or when optimizing existing P2MP TE LSPs as specified in [RFC5862], it may be necessary to pass existing P2MP LSP route information between the PCC and PCE in the request and reply messages. In each of these scenarios, we need path objects for efficiently passing the existing P2MP LSP between the PCE and PCC.
当按照[RFC5862]中的规定指定其他叶或优化现有P2MP TE LSP时，可能需要在请求和回复消息中在PCC和PCE之间传递现有P2MP LSP路由信息。在这些场景中，我们都需要路径对象，以便在PCE和PCC之间高效地传递现有的P2MP LSP。
We specify the use of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to encode the explicit route of a TE LSP through the network. PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. The format and content of the ERO are defined in [RFC3209] and [RFC3473].
我们指定使用资源预留协议流量工程（RSVP-TE）扩展显式路由对象（ERO）编码TE LSP通过网络的显式路由。PCEP ERO子对象类型对应于RSVP-TE ERO子对象类型。ERO的格式和内容见[RFC3209]和[RFC3473]。
The Secondary Explicit Route Object (SERO) is used to specify the explicit route of an S2L sub-LSP. The path of each subsequent S2L sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. The format of the SERO is the same as the format of an ERO as defined in [RFC3209] and [RFC3473].
次要显式路由对象（SERO）用于指定S2L子LSP的显式路由。每个后续S2L子LSP的路径编码在P2MP_次要_显式_路由对象SERO中。SERO的格式与[RFC3209]和[RFC3473]中定义的ERO格式相同。
The Secondary Record Route Object (SRRO) is used to record the explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the same as the class of the SRRO as defined in [RFC4873].
辅助记录路由对象（SRRO）用于记录S2L子LSP的显式路由。P2MP SRRO的等级与[RFC4873]中定义的SRRO等级相同。
The SERO and SRRO are used to report the route of an existing TE LSP for which a reoptimization is desired. The format and content of the SERO and SRRO are defined in [RFC4875].
SERO和SRRO用于报告需要重新优化的现有TE LSP路线。SERO和SRRO的格式和内容见[RFC4875]。
PCEP Object-Class and Object-Type values for the SERO and SRRO have been assigned:
已为SERO和SRRO分配PCEP对象类和对象类型值：
Object-Class Value 29 Name SERO Object-Type 0: Reserved 1: SERO 2-15: Unassigned Reference RFC 8306
对象类值29名称血清对象类型0:保留1:血清2-15:未分配引用RFC 8306
Object-Class Value 30 Name SRRO Object-Type 0: Reserved 1: SRRO 2-15: Unassigned Reference RFC 8306
对象类值30名称SRRO对象类型0:保留1:SRRO 2-15:未分配参考RFC 8306
The IANA assignments are documented in Section 6.5 ("PCEP Objects").
IANA分配记录在第6.5节（“PCEP对象”）中。
Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO.
由于显式路径可用于MPLS或GMPLS控制平面的即时信令，因此该对象中所有子对象和字段的含义与为ERO定义的含义相同。
This document extends the existing P2P RP (Request Parameters) object so that a PCC can signal a P2MP path computation request to the PCE receiving the PCEP request. The END-POINTS object is also extended to improve the efficiency of the message exchange between the PCC and PCE in the case of P2MP path computation.
本文档扩展了现有的P2P RP（请求参数）对象，以便PCC可以向接收PCEP请求的PCE发送P2MP路径计算请求的信号。端点对象也被扩展，以在P2MP路径计算的情况下提高PCC和PCE之间的消息交换效率。
The PCE path computation request and reply messages will need the following additional parameters to indicate to the receiving PCE (1) that the request and reply messages have been fragmented across multiple messages, (2) that they have been requested for a P2MP path, and (3) whether the route is represented in the compressed or uncompressed format.
PCE路径计算请求和应答消息将需要以下附加参数来向接收PCE指示（1）请求和应答消息已在多个消息中分段，（2）它们已被请求用于P2MP路径，以及（3）路由是以压缩格式还是未压缩格式表示。
This document adds the following flags to the RP object:
本文档向RP对象添加以下标志：
The F-bit is added to the flag bits of the RP object to indicate to the receiver that the request is part of a fragmented request or is not a fragmented request.
将F位添加到RP对象的标志位，以向接收方指示该请求是分段请求的一部分或不是分段请求。
o F (RP fragmentation bit - 1 bit):
o F（RP碎片位-1位）：
0: This indicates that the RP is not fragmented or it is the last piece of the fragmented RP.
0：这表示RP未碎片化或是碎片化RP的最后一块。
1: This indicates that the RP is fragmented and this is not the last piece of the fragmented RP. The receiver needs to wait for additional fragments until it receives an RP with the same RP-ID and with the F-bit set to 0.
1：这表示RP已分段，并且这不是分段RP的最后一个片段。接收器需要等待其他片段，直到接收到具有相同RP-ID且F位设置为0的RP。
The N-bit is added in the flag bits field of the RP object to signal the receiver of the message that the request/reply is for P2MP or is not for P2MP.
将N位添加到RP对象的标志位字段中，以向消息接收器发送信号，表明请求/回复针对P2MP或不针对P2MP。
o N (P2MP bit - 1 bit):
o N（P2MP位-1位）：
0: This indicates that this is not a Path Computation Request (PCReq) or Path Computation Reply (PCRep) message for P2MP.
0：这表示这不是P2MP的路径计算请求（PCReq）或路径计算回复（PCRep）消息。
1: This indicates that this is a PCReq or PCRep message for P2MP.
1：这表示这是P2MP的PCReq或PCRep消息。
The E-bit is added in the flag bits field of the RP object to signal the receiver of the message that the route is in the compressed format or is not in the compressed format. By default, the path returned by the PCE SHOULD use the compressed format.
将E位添加到RP对象的标志位字段中，以向消息接收器发出信号，表明路由为压缩格式或不为压缩格式。默认情况下，PCE返回的路径应使用压缩格式。
o E (ERO-compression bit - 1 bit):
o E（ERO压缩位-1位）：
0: This indicates that the route is not in the compressed format.
0：这表示路由不是压缩格式。
1: This indicates that the route is in the compressed format.
1：表示路由为压缩格式。
The IANA assignments are documented in Section 6.2 ("Request Parameter Bit Flags") of this document.
IANA分配记录在本文件第6.2节（“请求参数位标志”）中。
The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. To represent the end points for a P2MP path efficiently, we define two types of END-POINTS objects for the P2MP path:
端点对象在PCReq消息中用于指定请求路径计算的路径的源IP地址和目标IP地址。为了有效地表示P2MP路径的端点，我们为P2MP路径定义了两种类型的端点对象：
o Old leaves whose path can be modified/reoptimized.
o 路径可以修改/重新优化的旧叶。
o Old leaves whose path must be left unchanged.
o 路径必须保持不变的老叶子。
With the P2MP END-POINTS object, the PCE Path Computation Request message is expanded in a way that allows a single request message to list multiple destinations.
通过P2MP端点对象，PCE路径计算请求消息以允许单个请求消息列出多个目的地的方式展开。
In total, there are now four possible types of leaves in a P2MP request:
现在，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）
A given END-POINTS object gathers the leaves of a given type. The type of leaf in a given END-POINTS object is identified by the END-POINTS object leaf type field.
给定端点对象收集给定类型的叶子。给定端点对象中的叶类型由端点对象叶类型字段标识。
Using the P2MP END-POINTS object, the END-POINTS portion of a request message for the multiple destinations can be reduced by up to 50% for a P2MP path where a single source address has a very large number of destinations.
使用P2MP END-POINTS对象，对于单个源地址具有大量目的地的P2MP路径，多个目的地的请求消息的端点部分最多可以减少50%。
Note that a P2MP path computation request can mix the different types of leaves by including several END-POINTS objects per RP object as shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format in Section 3.4 ("Request Message Format").
请注意，P2MP路径计算请求可以通过包括每个RP对象的多个端点对象来混合不同类型的叶子，如第3.4节（“请求消息格式”）中的PCReq路由Backus Naur Form（RBNF）[RFC5511]格式所示。
The format of the P2MP END-POINTS object body for IPv4 (Object-Type 3) is as follows:
IPv4的P2MP端点对象体（对象类型3）的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The P2MP END-POINTS Object Body Format for IPv4
图1:IPv4的P2MP端点对象体格式
The format of the END-POINTS object body for IPv6 (Object-Type 4) is as follows:
IPv6端点对象体（对象类型4）的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The P2MP END-POINTS Object Body Format for IPv6
图2:IPv6的P2MP端点对象体格式
The END-POINTS object body has a variable length. These are
端点对象主体具有可变长度。这些是
o multiples of 4 bytes for IPv4
o IPv4的4字节倍数
o multiples of 16 bytes, plus 4 bytes, for IPv6
o IPv6为16字节加4字节的倍数
As per [RFC5440], a Path Computation Request message (also referred to as a PCReq message) is a PCEP message sent by a PCC to a PCE to request a path computation. A PCReq message may carry more than one path computation request.
根据[RFC5440]，路径计算请求消息（也称为PCReq消息）是由PCC发送到PCE以请求路径计算的PCEP消息。PCReq消息可以承载多个路径计算请求。
As per [RFC5541], the OF object MAY be carried within a PCReq message. If an objective function is to be applied to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC (Synchronization Vector) object and MUST NOT be repeated for each elementary request.
根据[RFC5541]，可在PCReq消息中携带对象的名称。如果要将目标函数应用于一组同步路径计算请求，则必须在对应的SVEC（同步向量）对象之后携带对象的值，并且不得对每个基本请求重复该值。
The PCReq message is encoded as follows using RBNF as defined in [RFC5511].
PCReq消息使用[RFC5511]中定义的RBNF进行如下编码。
Below is the message format for the request message:
以下是请求消息的消息格式：
<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>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<request> ::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
where:
哪里：
<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>]
Figure 3: The Message Format for the Request Message
图3：请求消息的消息格式
Note that we preserve compatibility with the definition of <request> provided in [RFC5440]. At least one instance of <END-POINTS> MUST be present in this message.
请注意，我们保留了与[RFC5440]中提供的<request>定义的兼容性。此消息中必须至少存在一个<END-POINTS>实例。
We have documented the IANA assignment of additional END-POINTS Object-Type values in Section 6.5 ("PCEP Objects") of this document.
我们已在本文件第6.5节（“PCEP对象”）中记录了附加端点对象类型值的IANA分配。
The PCEP Path Computation Reply message (also referred to as a PCRep message) is a PCEP message sent by a PCE to a requesting PCC in response to a previously received PCReq message. PCEP supports the bundling of multiple replies to a set of path computation requests within a single PCRep message.
PCEP路径计算应答消息（也称为PCRep消息）是由PCE向请求PCC发送的PCEP消息，以响应先前接收到的PCReq消息。PCEP支持在单个PCRep消息中捆绑对一组路径计算请求的多个回复。
The PCRep message is encoded as follows using RBNF as defined in [RFC5511].
PCRep消息使用[RFC5511]中定义的RBNF进行如下编码。
Below is the message format for the reply message:
以下是回复消息的消息格式：
<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>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<response> ::= <RP>
[<end-point-path-pair-list>]
[<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>]
where:
哪里：
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Figure 4: The Message Format for the Reply Message
图4：回复消息的消息格式
The optional END-POINTS object in the reply message is used to specify which paths are removed, changed, not changed, or added for the request. The path is only needed for the end points that are added or changed.
回复消息中的可选端点对象用于指定为请求删除、更改、未更改或添加的路径。路径仅用于添加或更改的端点。
If the E-bit (ERO-Compress bit) was set to 1 in the request, then the path will be formed by an ERO followed by a list of SEROs.
如果请求中的E位（ERO压缩位）设置为1，则路径将由ERO和血清列表组成。
Note that we preserve compatibility with the definition of <response> provided in [RFC5440] and with the optional <end-point-path-pair-list> and <path>.
请注意，我们保留了与[RFC5440]中提供的<response>定义以及可选的<endpoint path pair list>和<path>的兼容性。
Six objective functions have been defined in [RFC5541] for P2P path computation.
[RFC5541]中定义了用于P2P路径计算的六个目标函数。
This document defines two additional objective functions -- namely, SPT (Shortest-Path Tree) and MCT (Minimum-Cost Tree) -- that apply to P2MP path computation. Hence, two objective function codes are defined as follows:
本文档定义了两个附加的目标函数——即SPT（最短路径树）和MCT（最小成本树）——用于P2MP路径计算。因此，两个目标函数代码定义如下：
Objective Function Code: 7
目标函数代码：7
Name: Shortest-Path Tree (SPT)
名称：最短路径树（SPT）
Description: Minimize the maximum source-to-leaf cost with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified (e.g., TE or IGP metric).
描述：当未指定指标（例如，TE或IGP指标）时，将特定指标或用作默认指标的TE指标的最大源到叶成本降至最低。
Objective Function Code: 8
目标函数代码：8
Name: Minimum-Cost Tree (MCT)
名称：最小成本树（MCT）
Description: Minimize the total cost of the tree (i.e., the sum of the costs of tree links) with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified.
描述：在未指定度量的情况下，针对特定度量或用作默认度量的TE度量，最小化树的总成本（即树链接的成本总和）。
Processing these two objective functions is subject to the rules defined in [RFC5541].
处理这两个目标函数应遵守[RFC5541]中定义的规则。
There are three types defined for the METRIC object in [RFC5440] -- namely, the IGP metric, the TE metric, and Hop Counts. This document defines three additional types for the METRIC object: the P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. They encode the sum of the metrics of all links of the tree. The following values for these metric types have been assigned; see Section 6.4.
[RFC5440]中为度量对象定义了三种类型，即IGP度量、TE度量和跃点计数。本文档为度量对象定义了三种附加类型：P2MP IGP度量、P2MP TE度量和P2MP跃点计数度量。它们对树的所有链接的度量的总和进行编码。已为这些度量类型指定了以下值：；见第6.4节。
o P2MP IGP metric: T=8
o P2MP IGP指标：T=8
o P2MP TE metric: T=9
o P2MP TE公制：T=9
o P2MP hop count metric: T=10
o P2MP跃点计数度量：T=10
o If a PCE receives a P2MP path computation request and it understands the P2MP flag in the RP object, but the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR object and corresponding Error-value. The request MUST then be cancelled at the PCC. The Error-Types and Error-values have been assigned; see Section 6 ("IANA Considerations") of this document.
o 如果PCE接收到P2MP路径计算请求，并且它理解RP对象中的P2MP标志，但PCE不能进行P2MP计算，则PCE必须发送带有PCEP-ERROR对象和相应错误值的PCErr消息。然后必须在PCC取消该请求。已指定错误类型和错误值；见本文件第6节（“IANA注意事项”）。
o If the PCE does not understand the P2MP flag in the RP object, then the PCE would send a PCErr message with Error-Type=2 (Capability not supported) as per [RFC5440].
o 如果PCE不理解RP对象中的P2MP标志，则PCE将根据[RFC5440]发送错误类型为2（不支持功能）的PCErr消息。
If a PCE receives a P2MP request and the PCE does not understand the P2MP flag in the RP object, and therefore the PCEP P2MP extensions, then the PCE SHOULD reject the request.
如果PCE接收到P2MP请求，并且PCE不理解RP对象中的P2MP标志，因此不理解PCEP P2MP扩展，则PCE应拒绝该请求。
A reoptimization request for a P2MP TE path is specified by the use of the R-bit within the RP object as defined in [RFC5440] and is similar to the reoptimization request for a P2P TE path. The only difference is that the PCC MUST insert the list of Record Route Objects (RROs) and SRROs after each instance of the END-POINTS object in the PCReq message, as described in Section 3.4 ("Request Message Format") of this document.
P2MP TE路径的重新优化请求通过使用[RFC5440]中定义的RP对象内的R位来指定，类似于P2P TE路径的重新优化请求。唯一的区别是，PCC必须在PCReq消息中端点对象的每个实例之后插入记录路由对象（RRO）和SRRO列表，如本文件第3.4节（“请求消息格式”）所述。
An example of a reoptimization request and subsequent PCReq message is described below:
重新优化请求和后续PCReq消息的示例如下所述：
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 3 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置了叶类型3 RRO列表的端点（可选）
Figure 5: PCReq Message Example 1 for Optimization
图5：用于优化的PCReq消息示例1
In this example, we request reoptimization of the path to all leaves without adding or pruning leaves. The reoptimization request would use an END-POINTS object with leaf type 3. The RRO list would represent the P2MP LSP before the optimization, and the modifiable path leaves would be indicated in the END-POINTS object.
在本例中，我们请求在不添加或修剪叶的情况下重新优化所有叶的路径。重新优化请求将使用叶类型为3的端点对象。RRO列表将表示优化前的P2MP LSP，可修改的路径叶子将在端点对象中指示。
It is also possible to specify distinct leaves whose path cannot be modified. An example of the PCReq message in this scenario would be:
还可以指定路径无法修改的不同叶子。此场景中的PCReq消息示例如下：
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置了叶类型3 RRO的端点列表叶类型4 RRO的端点列表（可选）
Figure 6: PCReq Message Example 2 for Optimization
图6：用于优化的PCReq消息示例2
When adding new leaves to or removing old leaves from the existing P2MP tree, by supplying a list of existing leaves, it is possible to optimize the existing P2MP tree. This section explains the methods for adding new leaves to or removing old leaves from the existing P2MP tree.
向现有P2MP树添加新叶或从中删除旧叶时，通过提供现有叶列表，可以优化现有P2MP树。本节介绍向现有P2MP树添加新叶或从中删除旧叶的方法。
To add new leaves, the PCC MUST build a P2MP request using END-POINTS with leaf type 1.
要添加新叶，PCC必须使用叶类型为1的端点构建P2MP请求。
To remove old leaves, the PCC MUST build a P2MP request using END-POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE MUST send Error-Type 17, Error-value 1: the PCE cannot satisfy the request due to no END-POINTS with leaf type 2.
要删除旧叶，PCC必须使用叶类型为2的端点构建P2MP请求。如果不存在类型2端点，则PCE必须发送错误类型17，错误值1：由于没有叶类型2的端点，PCE无法满足请求。
When adding new leaves to or removing old leaves from the existing P2MP tree, the PCC MUST also provide the list of old leaves, if any, including END-POINTS with leaf type 3, leaf type 4, or both. Specific PCEP-ERROR objects and types are used when certain conditions are not satisfied (i.e., when there are no END-POINTS with leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 or 2). A generic "Inconsistent END-POINTS" error will be used if a PCC receives a request that has an inconsistent END-POINTS setting (i.e., if a leaf specified as type 1 already exists). These IANA assignments are documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this document.
在向现有P2MP树添加新叶或从中移除旧叶时，PCC还必须提供旧叶列表（如有），包括叶类型3、叶类型4或两者的端点。特定PCEP-ERROR对象和类型在某些条件不满足时使用（即，当没有叶类型3或4的端点，或存在叶类型1或2的端点时）。如果PCC收到具有不一致端点设置的请求（即，如果指定为类型1的叶已经存在），则将使用通用的“不一致端点”错误。这些IANA分配记录在本文件第6.6节（“PCEP-ERROR对象和类型”）中。
For old leaves, the PCC MUST provide the old path as a list of RROs that immediately follows each END-POINTS object. This document specifies Error-values when specific conditions are not satisfied.
对于旧叶，PCC必须提供旧路径作为紧跟在每个端点对象之后的RRO列表。本文件规定了不满足特定条件时的错误值。
The following examples demonstrate full and partial reoptimization of existing P2MP LSPs:
以下示例演示了现有P2MP LSP的全部和部分重新优化：
Case 1: Adding leaves with full reoptimization of existing paths
案例1：添加叶，对现有路径进行完全重新优化
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 RRO list END-POINTS for leaf type 3 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置叶类型1的RRO列表端点叶类型3的RRO列表端点（可选）
Case 2: Adding leaves with partial reoptimization of existing paths
案例2：添加叶，部分重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置叶类型1的端点叶类型3的端点RRO列表叶类型4的端点RRO列表（可选）
Case 3: Adding leaves without reoptimization of existing paths
案例3：添加叶而不重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置叶类型1的终结点RRO列表叶类型4的终结点RRO列表（可选）
Case 4: Pruning leaves with full reoptimization of existing paths
案例4：修剪树叶，完全重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置了叶类型2 RRO的端点列表叶类型3 RRO的端点列表（可选）
Case 5: Pruning leaves with partial reoptimization of existing paths
案例5：修剪树叶，部分重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置了叶类型2的端点RRO列出了叶类型3的端点RRO列出了叶类型4的端点RRO列表（可选）
Case 6: Pruning leaves without reoptimization of existing paths
案例6：修剪树叶而不重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置了叶类型2 RRO的端点列表叶类型4 RRO的端点列表（可选）
Case 7: Adding and pruning leaves with full reoptimization of existing paths
案例7：添加和修剪树叶，完全重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置1类叶的端点2类叶的端点RRO列表3类叶的端点RRO列表（可选）
Case 8: Adding and pruning leaves with partial reoptimization of existing paths
案例8：添加和修剪树叶，部分重新优化现有路径
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置了叶类型1的端点叶类型2的端点RRO列出了叶类型3的端点RRO列出了叶类型4的端点RRO的列表（可选）
Case 9: Adding and pruning leaves without reoptimization of existing paths
案例9：在不重新优化现有路径的情况下添加和修剪树叶
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
带有P2MP标志/R位的公共标头RP设置叶类型1的端点叶类型2的端点RRO列表叶类型4的端点RRO列表（可选）
Before computing the P2MP path, a PCE may need to be provided means to know which nodes in the network are capable of acting as branch LSRs. A PCE can discover such capabilities by using the mechanisms defined in [RFC5073].
在计算P2MP路径之前，可能需要提供PCE以了解网络中哪些节点能够充当分支lsr的手段。PCE可以通过使用[RFC5073]中定义的机制发现此类功能。
The PCC can specify a list of nodes that can be used as branch nodes or a list of nodes that cannot be used as branch nodes by using the Branch Node Capability (BNC) object. The BNC object has the same format as the Include Route Object (IRO) as defined in [RFC5440], except that it only supports IPv4 and IPv6 prefix sub-objects. Two Object-Type parameters are also defined:
PCC可以使用branch Node Capability（BNC）对象指定可以用作分支节点的节点列表或不能用作分支节点的节点列表。BNC对象的格式与[RFC5440]中定义的包含路由对象（IRO）的格式相同，只是它仅支持IPv4和IPv6前缀子对象。还定义了两个对象类型参数：
o Branch node list: List of nodes that can be used as branch nodes.
o 分支节点列表：可以用作分支节点的节点列表。
o Non-branch node list: List of nodes that cannot be used as branch nodes.
o 非分支节点列表：不能用作分支节点的节点列表。
The object can only be carried in a PCReq message. A path computation request may carry at most one Branch Node object.
对象只能在PCReq消息中携带。路径计算请求最多可携带一个分支节点对象。
The Object-Class and Object-Type values have been allocated by IANA. The IANA assignments are documented in Section 6.5 ("PCEP Objects").
IANA已分配对象类和对象类型值。IANA分配记录在第6.5节（“PCEP对象”）中。
There are cases when multiple P2MP LSPs' computations need to be synchronized. For example, one P2MP LSP is the designated backup of another P2MP LSP. In this case, path diversity for these dependent LSPs may need to be considered during the path computation.
有时需要同步多个P2MP LSP的计算。例如，一个P2MP LSP是另一个P2MP LSP的指定备份。在这种情况下，在路径计算期间可能需要考虑这些依赖lsp的路径分集。
The synchronization can be done by using the existing SVEC functionality as defined in [RFC5440].
同步可以通过使用[RFC5440]中定义的现有SVEC功能来完成。
An example of synchronizing two P2MP LSPs, each having two leaves for Path Computation Request messages, is illustrated below:
同步两个P2MP LSP的示例如下所示，每个LSP具有两个用于路径计算请求消息的叶子：
Common Header SVEC for sync of LSP1 and LSP2 OF (optional) RP for LSP1 END-POINTS1 for LSP1 RRO1 list RP for LSP2 END-POINTS2 for LSP2 RRO2 list
LSP1端点S1 LSP1 RRO1列表RP LSP2端点S2 LSP2 RRO2列表（可选）RP的LSP1和LSP2同步的公共头SVEC
Figure 7: PCReq Message Example for Synchronization
图7：用于同步的PCReq消息示例
This specification also defines two flags for the SVEC Object Flag Field for P2MP path-dependent computation requests. The first flag allows the PCC to request that the PCE should compute a secondary P2MP path tree with partial path diversity for specific leaves or a specific S2L sub-path to the primary P2MP path tree. The second flag allows the PCC to request that partial paths should be link direction diverse.
本规范还为P2MP路径相关计算请求的SVEC对象标志字段定义了两个标志。第一个标志允许PCC请求PCE计算具有特定叶的部分路径分集的辅助P2MP路径树或主P2MP路径树的特定S2L子路径。第二个标志允许PCC请求部分路径应该是链路方向不同的。
The following flags are added to the SVEC object body in this document:
以下标志添加到本文档中的SVEC对象体：
o P (Partial Path Diverse bit - 1 bit):
o P（部分路径多样化位-1位）：
When set, this would indicate a request for path diversity for a specific leaf, a set of leaves, or all leaves.
设置时，这将指示对特定叶、一组叶或所有叶的路径多样性的请求。
o D (Link Direction Diverse bit - 1 bit):
o D（链路方向变化位-1位）：
When set, this would indicate a request that a partial path or paths should be link direction diverse.
设置时，这将指示一个或多个部分路径应为链接方向多样化的请求。
The IANA assignments are referenced in Section 6.8 of this document.
本文件第6.8节引用了IANA分配。
The total PCEP message length, including the common header, is 16 bytes. In certain scenarios, the P2MP computation request may not fit into a single request or response message. For example, if a tree has many hundreds or thousands of leaves, then the request or response may need to be fragmented into multiple messages.
PCEP消息的总长度（包括公共标头）为16字节。在某些情况下，P2MP计算请求可能不适合单个请求或响应消息。例如，如果一棵树有成百上千的叶子，那么请求或响应可能需要分割成多条消息。
The F-bit is outlined in Section 3.3.1 ("The Extension of the RP Object") of this document. The F-bit is used in the RP object to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. In order to identify the single request or response, each message will use the same request ID.
本文件第3.3.1节（“RP对象的扩展”）概述了F-bit。在RP对象中使用F位来表示初始请求或响应太大，无法放入单个消息，将被分割为多个消息。为了识别单个请求或响应，每条消息将使用相同的请求ID。
If the initial request is too large to fit into a single request message, the PCC will split the request over multiple messages. Each message sent to the PCE, except the last one, will have the F-bit set in the RP object to signify that the request has been fragmented into multiple messages. In order to identify that a series of request messages represents a single request, each message will use the same request ID.
如果初始请求太大，无法放入单个请求消息中，PCC会将请求拆分为多个消息。发送到PCE的每条消息（最后一条除外）都将在RP对象中设置F位，以表示请求已被分割成多条消息。为了确定一系列请求消息表示单个请求，每条消息将使用相同的请求ID。
The assumption is that request messages are reliably delivered and in sequence, since PCEP relies on TCP.
由于PCEP依赖于TCP，因此假设请求消息可靠地按顺序传递。
Once the PCE computes a path based on the initial request, a response is sent back to the PCC. If the response is too large to fit into a single response message, the PCE will split the response over multiple messages. Each message sent by the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. In order to identify that a series of response messages represents a single response, each message will use the same response ID.
一旦PCE根据初始请求计算出路径，则将响应发送回PCC。如果响应太大，无法装入单个响应消息，则PCE会将响应拆分为多个消息。PCE发送的每条消息（最后一条除外）都将在RP对象中设置F位，以表示响应已被分割为多条消息。为了确定一系列响应消息表示单个响应，每条消息将使用相同的响应ID。
Again, the assumption is that response messages are reliably delivered and in sequence, since PCEP relies on TCP.
同样，由于PCEP依赖于TCP，因此假设响应消息可靠地按顺序传递。
The following example illustrates the PCC sending a request message with Req-ID1 to the PCE, in order to add one leaf to an existing tree with 1200 leaves. The assumption used for this example is that one request message can hold up to 800 leaves. In this scenario, the original single message needs to be fragmented and sent using two smaller messages, which have Req-ID1 specified in the RP object, and with the F-bit set on the first message and the F-bit cleared on the second message.
以下示例说明了PCC向PCE发送带有Req-ID1的请求消息，以便将一个叶添加到带有1200个叶的现有树中。本例中使用的假设是，一条请求消息最多可以容纳800个叶子。在这种情况下，原始的单个消息需要分段并使用两条较小的消息发送，这两条消息在RP对象中指定了Req-ID1，并且在第一条消息上设置了F位，在第二条消息上清除了F位。
Common Header RP1 with Req-ID1 and P2MP=1 and F-bit=1 OF (optional) END-POINTS1 for P2MP RRO1 list
P2MP RRO1列表的（可选）端点1的Req-ID1和P2MP=1且F位=1的公共标头RP1
Common Header RP2 with Req-ID1 and P2MP=1 and F-bit=0 OF (optional) END-POINTS1 for P2MP RRO1 list
P2MP RRO1列表的（可选）端点1的Req-ID1和P2MP=1且F位=0的公共标头RP2
Figure 8: PCReq Message Fragmentation Example
图8:PCReq消息碎片示例
To handle a scenario where the last fragmented message piece is lost, the receiver side of the fragmented message may start a timer once it receives the first piece of the fragmented message. If the timer expires and it still has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message. The relevant error message is documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types").
为了处理最后一条分段消息丢失的情况，分段消息的接收方可以在接收到第一条分段消息后启动计时器。如果计时器过期，但仍未收到最后一条分段消息，则应向发送方发送错误消息，以表明其已收到不完整的消息。相关错误信息记录在第3.15节（“P2MP PCEP-error对象和类型”）。
The PCE path computation request may fail because all or a subset of the destinations are unreachable.
PCE路径计算请求可能会失败，因为所有或部分目的地都无法到达。
In such a case, the UNREACH-DESTINATION object allows the PCE to optionally specify the list of unreachable destinations.
在这种情况下，UNREACH-DESTINATION对象允许PCE选择性地指定不可到达目的地的列表。
This object can be present in PCRep messages. There can be up to one such object per RP.
此对象可以出现在PCRep消息中。每个RP最多可以有一个这样的对象。
The following UNREACH-DESTINATION objects (for IPv4 and IPv6) are defined:
定义了以下未访问的目标对象（用于IPv4和IPv6）：
UNREACH-DESTINATION Object-Class is 28. UNREACH-DESTINATION Object-Type for IPv4 is 1. UNREACH-DESTINATION Object-Type for IPv6 is 2.
未读目标对象类为28。IPv4的未读目标对象类型为1。IPv6的未访问目标对象类型为2。
The format of the UNREACH-DESTINATION object body for IPv4 (Object-Type=1) is as follows:
IPv4（对象类型=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UNREACH-DESTINATION Object Body for IPv4
图9:IPv4的未读目标对象正文
The format of the UNREACH-DESTINATION object body for IPv6 (Object-Type=2) is as follows:
IPv6（对象类型=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: UNREACH-DESTINATION Object Body for IPv6
图10:IPv6的未读目标对象体
To indicate an error associated with a policy violation, the Error-value "P2MP Path computation is not allowed" has been added to the existing error code for Error-Type 5 ("Policy violation") as defined in [RFC5440] (see also Section 6.6 of this document):
为指示与策略冲突相关的错误，已将错误值“P2MP路径计算不允许”添加到[RFC5440]中定义的错误类型5（“策略冲突”）的现有错误代码中（另请参见本文件第6.6节）：
Error-Type=5; Error-value=7: if a PCE receives a P2MP path computation request that is not compliant with administrative privileges (i.e., "The PCE policy does not support P2MP path computation"), the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5) and an Error-value of 7. The corresponding P2MP path computation request MUST also be cancelled.
错误类型=5；错误值=7：如果PCE接收到不符合管理权限的P2MP路径计算请求（即，“PCE策略不支持P2MP路径计算”），则PCE必须发送带有PCEP-Error对象（错误类型=5）和错误值为7的PCErr消息。还必须取消相应的P2MP路径计算请求。
To indicate capability errors associated with the P2MP path computation request, Error-Type (16) and subsequent Error-values are defined as follows for inclusion in the PCEP-ERROR object:
为了指示与P2MP路径计算请求相关的能力错误，错误类型（16）和后续错误值定义如下，以包含在PCEP-Error对象中：
Error-Type=16; Error-value=1: if a PCE receives a P2MP path computation request and the PCE is not capable of satisfying the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error-value of 1. The corresponding P2MP path computation request MUST also be cancelled.
错误类型=16；错误值=1：如果PCE接收到P2MP路径计算请求，并且PCE由于内存不足而无法满足该请求，则PCE必须发送带有PCEP-Error对象（错误类型=16）和错误值为1的PCErr消息。还必须取消相应的P2MP路径计算请求。
Error-Type=16; Error-value=2: if a PCE receives a P2MP path computation request and the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error-value of 2. The corresponding P2MP path computation request MUST also be cancelled.
错误类型=16；错误值=2：如果PCE接收到P2MP路径计算请求，且PCE无法进行P2MP计算，则PCE必须发送PCErr消息，其中包含PCEP-Error对象（错误类型=16）和错误值2。还必须取消相应的P2MP路径计算请求。
To indicate P2MP message fragmentation errors associated with a P2MP path computation request, Error-Type (18) and subsequent Error-values are defined as follows for inclusion in the PCEP-ERROR object:
为了指示与P2MP路径计算请求相关联的P2MP消息碎片错误，错误类型（18）和后续错误值定义如下，以包含在PCEP-Error对象中：
Error-Type=18; Error-value=1: if a PCE has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented request failure"). The PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=18) and an Error-value of 1.
错误类型=18；错误值=1：如果PCE没有收到最后一条分段消息，它应该向发送方发送一条错误消息，表明它收到了一条不完整的消息（即“分段请求失败”）。PCE必须发送带有PCEP-ERROR对象（错误类型=18）和错误值为1的PCErr消息。
To communicate the reasons for not being able to find a P2MP path computation, the NO-PATH object can be used in the PCRep message.
为了说明无法找到P2MP路径计算的原因，可以在PCRep消息中使用NO-path对象。
One bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH object:
在NO-PATH对象中携带的NO-PATH向量TLV中定义一位：
bit 24: when set, the PCE indicates that there is a reachability problem with all or a subset of the P2MP destinations. Optionally, the PCE can specify the destination or list of destinations that are not reachable using the UNREACH-DESTINATION object defined in Section 3.14.
位24：设置时，PCE指示所有或部分P2MP目的地存在可达性问题。或者，PCE可以指定使用第3.14节中定义的UNREACH-destination对象无法到达的目的地或目的地列表。
[RFC5862] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how manageability requirements mentioned in [RFC5862] are supported in the context of PCEP extensions specified in this document.
[RFC5862]描述了应用PCEP时支持P2MP路径计算的各种可管理性要求。本节描述了[RFC5862]中提到的可管理性要求如何在本文档中指定的PCEP扩展上下文中得到支持。
Note that [RFC5440] describes various manageability considerations for PCEP, and most of the manageability requirements mentioned in [RFC5862] are already covered there.
请注意，[RFC5440]描述了PCEP的各种可管理性注意事项，[RFC5862]中提到的大多数可管理性要求已在此处介绍。
In addition to PCE configuration parameters listed in [RFC5440], the following additional parameters might be required:
除了[RFC5440]中列出的PCE配置参数外，可能还需要以下附加参数：
o The PCE may be configured to enable or disable P2MP path computations.
o PCE可被配置为启用或禁用P2MP路径计算。
o The PCE may be configured to enable or disable the advertisement of its P2MP path computation capability. A PCE can advertise its P2MP capability via the IGP discovery mechanism discussed in Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement") or during the Open Message Exchange discussed in Section 3.1.2 ("Open Message Extension").
o PCE可被配置为启用或禁用其P2MP路径计算能力的通告。PCE可以通过第3.1.1节（“P2MP能力公告的IGP扩展”）中讨论的IGP发现机制或在第3.1.2节（“开放消息扩展”）中讨论的开放消息交换期间公布其P2MP能力。
A number of MIB objects have been defined in [RFC7420] for general PCEP control and monitoring of P2P computations. [RFC5862] specifies that MIB objects will be required to support the control and monitoring of the protocol extensions defined in this document. A new document will be required to define MIB objects for PCEP control and monitoring of P2MP computations.
[RFC7420]中定义了许多MIB对象，用于对P2P计算进行一般PCEP控制和监控。[RFC5862]规定需要MIB对象来支持本文档中定义的协议扩展的控制和监视。需要一份新文件来定义用于PCEP控制和P2MP计算监控的MIB对象。
The "ietf-pcep" PCEP YANG module is specified in [PCEP-YANG]. The P2MP capability of a PCEP entity or a configured peer can be set using this YANG module. Also, support for P2MP path computation can be learned using this module. The statistics are maintained in the "ietf-pcep-stats" YANG module as specified in [PCEP-YANG]. This YANG module will be required to be augmented to also include the P2MP-related statistics.
[pcep-YANG]中规定了“ietf pcep”pcep-YANG模块。可使用此模块设置PCEP实体或配置对等方的P2MP能力。此外，还可以使用此模块学习对P2MP路径计算的支持。统计数据保存在[pcep-YANG]中规定的“ietf pcep统计”模块中。需要对该模块进行扩充，以包括P2MP相关统计数据。
There are no additional considerations beyond those expressed in [RFC5440], since [RFC5862] does not address any additional requirements.
除[RFC5440]中所述内容外，没有其他考虑因素，因为[RFC5862]没有提出任何其他要求。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCEP sessions. It is expected that future MIB objects will facilitate verification of correct operation and reporting of P2MP PCEP requests, responses, and errors.
除了[RFC4657]中规定的要求外，没有其他要求用于验证PCEP会话的正确操作。预计未来的MIB对象将有助于验证P2MP PCEP请求、响应和错误的正确操作和报告。
The method for the PCE to obtain information about a PCE capable of P2MP path computations via OSPF and IS-IS is discussed in Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement") of this document.
本文件第3.1.1节（“P2MP能力广告的IGP扩展”）讨论了PCE通过OSPF和IS-IS获取能够进行P2MP路径计算的PCE信息的方法。
The relevant IANA assignment is documented in Section 6.9 ("OSPF PCE Capability Flag") of this document.
相关IANA分配记录在本文件第6.9节（“OSPF PCE能力标志”）中。
It is expected that the use of PCEP extensions specified in this document will not significantly increase the level of operational traffic. However, computing a P2MP tree may require more PCE state compared to a P2P computation. In the event of a major network failure and multiple recovery P2MP tree computation requests being sent to the PCE, the load on the PCE may also be significantly increased.
预计本文件中规定的PCEP扩展的使用不会显著提高运营流量水平。然而，与P2P计算相比，计算P2MP树可能需要更多的PCE状态。在发生重大网络故障和向PCE发送多个恢复P2MP树计算请求的情况下，PCE上的负载也可能显著增加。
As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also utilize more link bandwidth. In the event of an unauthorized P2MP path computation request or a denial-of-service attack, the subsequent PCEP requests and processing may be disruptive to the network. Consequently, it is important that implementations conform to the relevant security requirements that specifically help to minimize or negate unauthorized P2MP path computation requests and denial-of-service attacks. These mechanisms include the following:
如[RFC5862]中所述，P2MP路径计算请求更占用CPU，并且还利用了更多链路带宽。如果发生未经授权的P2MP路径计算请求或拒绝服务攻击，后续PCEP请求和处理可能会中断网络。因此，实现符合相关安全要求非常重要，这些要求特别有助于最小化或消除未经授权的P2MP路径计算请求和拒绝服务攻击。这些机制包括：
o Securing the PCEP session requests and responses is RECOMMENDED using TCP security techniques such as the TCP Authentication Option (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525].
o 根据[RFC7525]中的建议和最佳实践，建议使用TCP安全技术（如TCP身份验证选项（TCP-AO）[RFC5925]或使用传输层安全（TLS）[RFC8253]来保护PCEP会话请求和响应的安全。
o Authenticating the PCEP requests and responses to ensure that the message is intact and sent from an authorized node using the TCP-AO or TLS is RECOMMENDED.
o 建议对PCEP请求和响应进行身份验证，以确保消息完好无损，并使用TCP-AO或TLS从授权节点发送。
o Policy control could be provided by explicitly defining which PCCs are allowed to send P2MP path computation requests to the PCE via IP access lists.
o 可以通过明确定义允许哪些PCC通过IP访问列表向PCE发送P2MP路径计算请求来提供策略控制。
PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks.
PCEP通过TCP运行，因此保护PCE和PCC免受TCP拒绝服务攻击也很重要。
As stated in [RFC6952], PCEP implementations SHOULD support the TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known vulnerabilities and weakness.
如[RFC6952]所述，PCEP实现应支持TCP-AO[RFC5925]，而不使用TCP MD5，因为TCP MD5存在已知的漏洞和弱点。
IANA maintains a registry of PCEP parameters. A number of IANA considerations have been highlighted in previous sections of this document. IANA made the allocations as per [RFC6006].
IANA维护PCEP参数的注册表。本文件前几节已重点介绍了IANA的一些注意事项。IANA按照[RFC6006]进行了分配。
As described in Section 3.1.2, the P2MP capability TLV allows the PCE to advertise its P2MP path computation capability.
如第3.1.2节所述，P2MP能力TLV允许PCE公布其P2MP路径计算能力。
IANA had previously made an allocation from the "PCEP TLV Type Indicators" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从“PCEP TLV类型指示器”子区域进行分配，其中RFC 6006为参考。IANA已更新参考资料如下，以指向本文件。
Value Description Reference
值描述参考
6 P2MP capable RFC 8306
6支持P2MP的RFC 8306
As described in Section 3.3.1, three RP Object Flags have been defined.
如第3.3.1节所述，定义了三个RP对象标志。
IANA had previously made allocations from the PCEP "RP Object Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从PCEP“RP对象标志字段”子区进行分配，其中RFC 6006为参考。IANA已更新参考资料如下，以指向本文件。
Bit Description Reference
位描述参考
18 Fragmentation (F-bit) RFC 8306 19 P2MP (N-bit) RFC 8306 20 ERO-compression (E-bit) RFC 8306
18分段（F位）RFC 8306 19 P2MP（N位）RFC 8306 20 ERO压缩（E位）RFC 8306
As described in Section 3.6.1, this document defines two objective functions.
如第3.6.1节所述，本文件定义了两个目标函数。
IANA had previously made allocations from the PCEP "Objective Function" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从PCEP“目标函数”子区域进行分配，其中RFC 6006为参考。IANA已更新参考资料如下，以指向本文件。
Code Point Name Reference
代码点名称引用
7 SPT RFC 8306 8 MCT RFC 8306
7 SPT RFC 8306 8 MCT RFC 8306
As described in Section 3.6.2, three METRIC object T fields have been defined.
如第3.6.2节所述，定义了三个公制对象T字段。
IANA had previously made allocations from the PCEP "METRIC Object T Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从PCEP“公制对象T字段”子区域进行分配，其中RFC 6006为参考。IANA已更新参考资料如下，以指向本文件。
Value Description Reference
值描述参考
8 P2MP IGP metric RFC 8306 9 P2MP TE metric RFC 8306 10 P2MP hop count metric RFC 8306
8 P2MP IGP度量值RFC 8306 9 P2MP TE度量值RFC 8306 10 P2MP跃点计数度量值RFC 8306
As discussed in Section 3.3.2, two END-POINTS Object-Type values are defined.
如第3.3.2节所述，定义了两个端点对象类型值。
IANA had previously made the Object-Type allocations from the "PCEP Objects" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前从“PCEP对象”子区域进行对象类型分配，其中RFC 6006是参考。IANA已更新参考资料如下，以指向本文件。
Object-Class Value 4 Name END-POINTS Object-Type 3: IPv4 4: IPv6 5-15: Unassigned Reference RFC 8306
对象类值4名称端点对象类型3:IPv4 4:IPv6 5-15:未分配引用RFC 8306
As described in Sections 3.2, 3.11.1, and 3.14, four PCEP Object-Class values and six PCEP Object-Type values have been defined.
如第3.2、3.11.1和3.14节所述，定义了四个PCEP对象类值和六个PCEP对象类型值。
IANA had previously made allocations from the "PCEP Objects" subregistry, where RFC 6006 was the reference. IANA has updated the reference to point to this document.
IANA之前曾从“PCEP对象”子区域进行分配，其中RFC 6006为参考。IANA已更新了指向本文件的参考。
Also, for the following four PCEP objects, codepoint 0 for the Object-Type field is marked "Reserved", as per Erratum ID 4956 for RFC 5440. IANA has updated the reference to point to this document.
此外，对于以下四个PCEP对象，根据RFC 5440的勘误表ID 4956，对象类型字段的代码点0标记为“保留”。IANA已更新了指向本文件的参考。
Object-Class Value 28 Name UNREACH-DESTINATION Object-Type 0: Reserved 1: IPv4 2: IPv6 3-15: Unassigned Reference RFC 8306
对象类值28名称未访问-目标对象类型0:保留1:IPv4 2:IPv6 3-15:未分配引用RFC 8306
Object-Class Value 29 Name SERO Object-Type 0: Reserved 1: SERO 2-15: Unassigned Reference RFC 8306
对象类值29名称血清对象类型0:保留1:血清2-15:未分配引用RFC 8306
Object-Class Value 30 Name SRRO Object-Type 0: Reserved 1: SRRO 2-15: Unassigned Reference RFC 8306
对象类值30名称SRRO对象类型0:保留1:SRRO 2-15:未分配参考RFC 8306
Object-Class Value 31 Name BNC Object-Type 0: Reserved 1: Branch node list 2: Non-branch node list 3-15: Unassigned Reference RFC 8306
对象类值31名称BNC对象类型0:保留1:分支节点列表2:非分支节点列表3-15:未分配参考RFC 8306
As described in Section 3.15, a number of PCEP-ERROR Object Error-Types and Error-values have been defined.
如第3.15节所述，已定义了许多PCEP-ERROR对象错误类型和错误值。
IANA had previously made allocations from the PCEP "PCEP-ERROR Object Error Types and Values" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从PCEP“PCEP-ERROR对象错误类型和值”子区域进行分配，其中RFC 6006是参考。IANA已更新参考资料如下，以指向本文件。
Error Type Meaning Reference
错误类型含义引用
5 Policy violation Error-value=7: RFC 8306 P2MP Path computation is not allowed
5策略冲突错误值=7:RFC 8306 P2MP路径计算不允许
16 P2MP Capability Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 The PCE cannot satisfy the request due to insufficient memory Error-value=2: RFC 8306 The PCE is not capable of P2MP computation
16 P2MP能力错误值=0：未分配的RFC 8306错误值=1:RFC 8306由于内存不足，PCE无法满足请求错误值=2:RFC 8306 PCE无法进行P2MP计算
17 P2MP END-POINTS Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 2 Error-value=2: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 3 Error-value=3: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 4 Error-value=4: RFC 8306 The PCE cannot satisfy the request due to inconsistent END-POINTS
17 P2MP端点错误值=0：未分配RFC 8306错误值=1:RFC 8306由于没有叶类型2的端点错误值=2:RFC 8306 PCE无法满足请求由于没有叶类型3的端点错误值=3:RFC 8306 PCE无法满足请求由于没有叶类型的端点4错误值=4:RFC 8306由于端点不一致，PCE无法满足请求
18 P2MP Fragmentation Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 Fragmented request failure
18 P2MP碎片错误值=0:未分配RFC 8306错误值=1:RFC 8306碎片请求失败
As discussed in Section 3.16, the NO-PATH-VECTOR TLV Flag Field has been defined.
如第3.16节所述，已定义无路径向量TLV标志字段。
IANA had previously made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从PCEP“无路径向量TLV标志场”子区进行分配，其中RFC 6006为参考。IANA已更新参考资料如下，以指向本文件。
Bit Description Reference
位描述参考
24 P2MP Reachability Problem RFC 8306
24 P2MP可达性问题RFC 8306
As discussed in Section 3.12, two SVEC Object Flags are defined.
如第3.12节所述，定义了两个SVEC对象标志。
IANA had previously made allocations from the PCEP "SVEC Object Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前曾从PCEP“SVEC对象标志字段”子区域进行分配，其中RFC 6006为参考。IANA已更新参考资料如下，以指向本文件。
Bit Description Reference
位描述参考
19 Partial Path Diverse RFC 8306 20 Link Direction Diverse RFC 8306
19部分路径多样性RFC 8306 20链路方向多样性RFC 8306
As discussed in Section 3.1.1, the OSPF Capability Flag is defined to indicate P2MP path computation capability.
如第3.1.1节所述，定义OSPF能力标志以指示P2MP路径计算能力。
IANA had previously made an assignment from the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANA之前从OSPF参数“路径计算元素（PCE）能力标志”注册表中进行了分配，其中RFC6006是参考。IANA已更新参考资料如下，以指向本文件。
Bit Description Reference
位描述参考
10 P2MP path computation RFC 8306
10 P2MP路径计算RFC 8306
[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>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<https://www.rfc-editor.org/info/rfc3473>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，DOI 10.17487/RFC4873，2007年5月<https://www.rfc-editor.org/info/rfc4873>.
[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>.
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <https://www.rfc-editor.org/info/rfc5073>.
[RFC5073]Vasseur，J.，Ed.，和J.Le Roux，Ed.，“发现流量工程节点能力的IGP路由协议扩展”，RFC 5073，DOI 10.17487/RFC5073，2007年12月<https://www.rfc-editor.org/info/rfc5073>.
[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>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 5541，DOI 10.17487/RFC55412009年6月<https://www.rfc-editor.org/info/rfc5541>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7770]Lindem，A.，Ed.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 7770，DOI 10.17487/RFC7770，2016年2月<https://www.rfc-editor.org/info/rfc7770>.
[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>.
[PCEP-YANG] Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, July 2017.
[PCEP-YANG]Dhody，D.，Ed.，Hardwick，J.，Beeram，V.，和J.Tantsura，“路径计算元素通信协议（PCEP）的YANG数据模型”，正在进行的工作，草稿-ietf-pce-PCEP-YANG-052017年7月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.“路径计算元件（PCE）通信协议通用要求”，RFC 4657，DOI 10.17487/RFC4657，2006年9月<https://www.rfc-editor.org/info/rfc4657>.
[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>.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/RFC5862, June 2010, <https://www.rfc-editor.org/info/rfc5862>.
[RFC5862]Yasukawa，S.和A.Farrel，“点对多点MPLS-TE的路径计算客户端（PCC）-路径计算元件（PCE）要求”，RFC 5862，DOI 10.17487/RFC5862，2010年6月<https://www.rfc-editor.org/info/rfc5862>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<https://www.rfc-editor.org/info/rfc5925>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, <https://www.rfc-editor.org/info/rfc6006>.
[RFC6006]Zhao，Q.，Ed.，King，D.，Ed.，Verhaeghe，F.，Takeda，T.，Ali，Z.，和J.Meuria，“点对多点流量工程标签交换路径的路径计算元素通信协议（PCEP）扩展”，RFC 6006，DOI 10.17487/RFC6006，2010年9月<https://www.rfc-editor.org/info/rfc6006>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，DOI 10.17487/RFC6952，2013年5月<https://www.rfc-editor.org/info/rfc6952>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素通信协议（PCEP）管理信息库（MIB）模块”，RFC 7420，DOI 10.17487/RFC7420，2014年12月<https://www.rfc-editor.org/info/rfc7420>.
[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>.
[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>.
o Updated the text to use the term "PCC" instead of "user" while describing the encoding rules in Section 3.10.
o 更新文本，在描述第3.10节中的编码规则时，使用术语“PCC”而不是“用户”。
o Updated the example in Figure 7 to explicitly include the RP object.
o 更新了图7中的示例，以显式地包含RP对象。
o Corrected the description of the F-bit in the RP object in Section 3.13, as per Erratum ID 3836.
o 根据勘误表ID 3836，更正了第3.13节中RP对象中的F位描述。
o Corrected the description of the fragmentation procedure for the response in Section 3.13.2, as per Erratum ID 3819.
o 根据勘误表ID 3819，更正了第3.13.2节中响应的分段程序说明。
o Corrected the Error-Type for fragmentation in Section 3.15, as per Erratum ID 3830.
o 根据勘误表ID 3830更正了第3.15节中碎片的错误类型。
o Updated the references for the OSPF Router Information Link State Advertisement (LSA) [RFC7770] and the PCEP MIB [RFC7420].
o 更新了OSPF路由器信息链路状态公告（LSA）[RFC7770]和PCEP MIB[RFC7420]的参考。
o Added current information and references for PCEP YANG [PCEP-YANG] and PCEPS [RFC8253].
o 增加了PCEP YANG[PCEP-YANG]和PCEP[RFC8253]的当前信息和参考资料。
o Updated the Security Considerations section to include the TCP-AO and TLS.
o 更新了安全注意事项部分，以包括TCP-AO和TLS。
o Updated the IANA Considerations section (Section 6.5) to mark codepoint 0 as "Reserved" for the Object-Type defined in this document, as per Erratum ID 4956 for [RFC5440]. IANA references have also been updated to point to this document.
o 根据[RFC5440]的勘误表ID 4956，更新了IANA注意事项部分（第6.5节），将代码点0标记为本文件中定义的对象类型的“保留”。IANA参考文献也已更新，以指向本文件。
Appendix A.1. RBNF Changes from RFC 6006
附录A.1。RFC 6006的RBNF变化
o Updates to the RBNF for the request message format, per Erratum ID 4867:
o 根据勘误表ID 4867更新请求消息格式的RBNF：
* Updated the request message to allow for the bundling of multiple path computation requests within a single PCReq message.
* 更新了请求消息，以允许在单个PCReq消息中捆绑多路径计算请求。
* Added <svec-list> in PCReq messages. This object was missed in [RFC6006].
* 在PCReq消息中添加了<svec list>。[RFC6006]中缺少此对象。
* Added the BNC object in PCReq messages. This object is required to support P2MP. The BNC object shares the same format as the IRO, but it only supports IPv4 and IPv6 prefix sub-objects.
* 在PCReq消息中添加了BNC对象。此对象是支持P2MP所必需的。BNC对象与IRO共享相同的格式，但它仅支持IPv4和IPv6前缀子对象。
* Updated the <RRO-List> format to also allow the SRRO. This object was missed in [RFC6006].
* 更新了<RRO List>格式以允许SRRO。[RFC6006]中缺少此对象。
* Removed the BANDWIDTH object followed by the RRO from <RRO-List>. The BANDWIDTH object was included twice in RFC 6006 -- once as part of <end-point-path-pair-list> and also as part of <RRO-List>. The latter has been removed, and the RBNF is backward compatible with [RFC5440].
* 已从<RRO List>中删除带宽对象，后跟RRO。带宽对象在RFC 6006中包含了两次，一次作为<end point path pair list>的一部分，另一次作为<RRO list>的一部分。后者已被移除，RBNF与[RFC5440]向后兼容。
* Updated the <end-point-rro-pair-list> to allow an optional BANDWIDTH object only if <RRO-List> is included.
* 更新了<end point rro pair list>，仅当包含<rro list>时才允许可选带宽对象。
o Updates to the RBNF for the reply message format, per Erratum ID 4868:
o 根据勘误表ID 4868更新回复消息格式的RBNF：
* Updated the reply message to allow for bundling of multiple path computation replies within a single PCRep message.
* 已更新回复消息，以允许在单个PCRep消息中捆绑多个路径计算回复。
* Added the UNREACH-DESTINATION object in PCRep messages. This object was missed in [RFC6006].
* 在PCRep消息中添加了未访问的目标对象。[RFC6006]中缺少此对象。
Acknowledgements
致谢
The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, Autumn Liu, Huaimo Chen, Eiji Oki, Nic Neate, Suresh Babu K, Gaurav Agrawal, Vishwas Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean Turner for their valuable comments and input on this document.
作者感谢Adrian Farrel、Young Lee、Dan Tappan、Fauth Liu、Huamimo Chen、Eiji Oki、Nic Neate、Suresh Babu K、Gaurav Agrawal、Vishwas Manral、Dan Romascanu、Tim Polk、Stewart Bryant、David Harrington和Sean Turner对本文件的宝贵意见和投入。
Thanks to Deborah Brungard for handling related errata for RFC 6006.
感谢Deborah Brungard处理RFC 6006的相关勘误表。
The authors would like to thank Jonathan Hardwick and Adrian Farrel for providing review comments with suggested text for this document.
作者要感谢Jonathan Hardwick和Adrian Farrel为本文件提供了审查意见和建议文本。
Thanks to Jonathan Hardwick for being the document shepherd and for providing comments and guidance.
感谢Jonathan Hardwick担任文档守护者并提供评论和指导。
Thanks to Ben Niven-Jenkins for RTGDIR reviews.
感谢Ben Niven Jenkins的RTGDIR评论。
Thanks to Roni Even for GENART reviews.
感谢Roni对GENART的评论。
Thanks to Fred Baker for the OPSDIR review.
感谢弗雷德·贝克的OPSDIR评论。
Thanks to Deborah Brungard for being the responsible AD and guiding the authors.
感谢Deborah Brungard作为负责任的广告和指导作者。
Thanks to Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Adam Roach, Benoit Claise, Suresh Krishnan, and Eric Rescorla for their IESG review and comments.
感谢Mirja Kuehlewind、Alvaro Retana、Ben Campbell、Adam Roach、Benoit Claise、Suresh Krishnan和Eric Rescorla对IESG的评论和评论。
Contributors
贡献者
Fabien Verhaeghe Thales Communication France 160 boulevard Valmy 92700 Colombes France Email: fabien.verhaeghe@gmail.com
Fabien Verhaeghe Thales Communication France 160 boulevard Valmy 92700 Colombes France电子邮件：Fabien。verhaeghe@gmail.com
Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email: tomonori.takeda@ntt.com
武田NTT公司3-9-11，日本东京武藏市中岛町180-8585电子邮件：Tomonori。takeda@ntt.com
Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: zali@cisco.com
Zafar Ali Cisco Systems，Inc.安大略省卡纳塔市创新大道2000号K2K 3E8加拿大电子邮件：zali@cisco.com
Julien Meuric Orange 2, Avenue Pierre Marzin 22307 Lannion Cedex France Email: julien.meuric@orange.com
Julien Meuria Orange 2，Pierre Marzin大街22307 Lannion Cedex法国电子邮件：Julien。meuric@orange.com
Jean-Louis Le Roux Orange 2, Avenue Pierre Marzin 22307 Lannion Cedex France Email: jeanlouis.leroux@orange.com
Jean-Louis Le Roux Orange 2，Pierre Marzin 22307 Lannion Cedex France电子邮件：jeanlouis。leroux@orange.com
Mohamad Chaitou France Email: mohamad.chaitou@gmail.com
Mohamad Chaitou法国电子邮件：Mohamad。chaitou@gmail.com
Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: udayasreereddy@gmail.com
Udayasree Palle华为技术部位于卡纳塔克邦Whitefield Bangalore技术园，邮编560066印度电子邮件：udayasreereddy@gmail.com
Authors' Addresses
作者地址
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States of America
Quintin Zhao华为技术125美国马萨诸塞州阿克顿市纳戈科技园01719
Email: quintin.zhao@huawei.com
Email: quintin.zhao@huawei.com
Dhruv Dhody (editor) Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Dhruv Dhody（编辑）华为技术部，印度卡纳塔克邦班加罗尔怀特菲尔德科技园，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Ramanjaneya Reddy Palleti Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Ramanjaneya Reddy Palleti Huawei Technologies Divyashree Techno Park，印度卡纳塔克邦Whitefield Bangalore 560066
Email: ramanjaneya.palleti@huawei.com
Email: ramanjaneya.palleti@huawei.com
Daniel King Old Dog Consulting United Kingdom
丹尼尔·金英国老狗咨询公司
Email: daniel@olddog.co.uk
Email: daniel@olddog.co.uk