Internet Engineering Task Force (IETF) Q. Zhao, Ed.
Request for Comments: 6006 Huawei Technology
Category: Standards Track D. King, Ed.
ISSN: 2070-1721 Old Dog Consulting
F. Verhaeghe
Thales Communication France
T. Takeda
NTT Corporation
Z. Ali
Cisco Systems, Inc.
J. Meuric
France Telecom
September 2010
Internet Engineering Task Force (IETF) Q. Zhao, Ed.
Request for Comments: 6006 Huawei Technology
Category: Standards Track D. King, Ed.
ISSN: 2070-1721 Old Dog Consulting
F. Verhaeghe
Thales Communication France
T. Takeda
NTT Corporation
Z. Ali
Cisco Systems, Inc.
J. Meuric
France Telecom
September 2010
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路径计算的请求和响应。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6006.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6006.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://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 ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................6
3.1.1. P2MP Computation TLV in the Existing PCE
Discovery Protocol ..................................6
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................7
3.3. P2MP Path Computation Request/Reply Message Extensions .....8
3.3.1. The Extension of the RP Object ......................8
3.3.2. The New P2MP END-POINTS Object ......................9
3.4. Request Message Format ....................................12
3.5. Reply Message Format ......................................12
3.6. P2MP Objective Functions and Metric Types .................13
3.6.1. New Objective Functions ............................13
3.6.2. New Metric Object Types ............................14
3.7. Non-Support of P2MP Path Computation ......................14
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................6
3.1.1. P2MP Computation TLV in the Existing PCE
Discovery Protocol ..................................6
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................7
3.3. P2MP Path Computation Request/Reply Message Extensions .....8
3.3.1. The Extension of the RP Object ......................8
3.3.2. The New P2MP END-POINTS Object ......................9
3.4. Request Message Format ....................................12
3.5. Reply Message Format ......................................12
3.6. P2MP Objective Functions and Metric Types .................13
3.6.1. New Objective Functions ............................13
3.6.2. New Metric Object Types ............................14
3.7. Non-Support of P2MP Path Computation ......................14
3.8. Non-Support by Back-Level PCE Implementations .............15
3.9. P2MP TE Path Reoptimization Request .......................15
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16
3.11. Discovering Branch Nodes .................................19
3.11.1. Branch Node Object ................................19
3.12. Synchronization of P2MP TE Path Computation Requests .....19
3.13. Request and Response Fragmentation .......................20
3.13.1. Request Fragmentation Procedure ...................21
3.13.2. Response Fragmentation Procedure ..................21
3.13.3. Fragmentation Examples ............................21
3.14. UNREACH-DESTINATION Object ...............................22
3.15. P2MP PCEP-ERROR Objects and Types ........................23
3.16. PCEP NO-PATH Indicator ...................................24
4. Manageability Considerations ...................................25
4.1. Control of Function and Policy ............................25
4.2. Information and Data Models ...............................25
4.3. Liveness Detection and Monitoring .........................25
4.4. Verifying Correct Operation ...............................25
4.5. Requirements for Other Protocols and Functional
Components ................................................26
4.6. Impact on Network Operation ...............................26
5. Security Considerations ........................................26
6. IANA Considerations ............................................27
6.1. PCEP TLV Type Indicators ..................................27
6.2. Request Parameter Bit Flags ...............................27
6.3. Objective Functions .......................................27
6.4. Metric Object Types .......................................27
6.5. PCEP Objects ..............................................28
6.6. PCEP-ERROR Objects and Types ..............................29
6.7. PCEP NO-PATH Indicator ....................................30
6.8. SVEC Object Flag ..........................................30
6.9. OSPF PCE Capability Flag ..................................30
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................32
3.8. Non-Support by Back-Level PCE Implementations .............15
3.9. P2MP TE Path Reoptimization Request .......................15
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16
3.11. Discovering Branch Nodes .................................19
3.11.1. Branch Node Object ................................19
3.12. Synchronization of P2MP TE Path Computation Requests .....19
3.13. Request and Response Fragmentation .......................20
3.13.1. Request Fragmentation Procedure ...................21
3.13.2. Response Fragmentation Procedure ..................21
3.13.3. Fragmentation Examples ............................21
3.14. UNREACH-DESTINATION Object ...............................22
3.15. P2MP PCEP-ERROR Objects and Types ........................23
3.16. PCEP NO-PATH Indicator ...................................24
4. Manageability Considerations ...................................25
4.1. Control of Function and Policy ............................25
4.2. Information and Data Models ...............................25
4.3. Liveness Detection and Monitoring .........................25
4.4. Verifying Correct Operation ...............................25
4.5. Requirements for Other Protocols and Functional
Components ................................................26
4.6. Impact on Network Operation ...............................26
5. Security Considerations ........................................26
6. IANA Considerations ............................................27
6.1. PCEP TLV Type Indicators ..................................27
6.2. Request Parameter Bit Flags ...............................27
6.3. Objective Functions .......................................27
6.4. Metric Object Types .......................................27
6.5. PCEP Objects ..............................................28
6.6. PCEP-ERROR Objects and Types ..............................29
6.7. PCEP NO-PATH Indicator ....................................30
6.8. SVEC Object Flag ..........................................30
6.9. OSPF PCE Capability Flag ..................................30
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................32
The Path Computation Element (PCE) 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 sub-set of the S2L sub-LSPs. In the extreme case, the PCC may request the S2L sub-LSPs to be computed individually with it being the PCC's responsibility to decide 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可以使用一条路径计算请求消息，或者可以将请求分割成多条路径计算消息。
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).
OF：目标函数：用于计算单个路径（例如，路径成本最小化）或用于同步计算一组路径（例如，总带宽消耗最小化）的一组或多个优化标准。
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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section summarizes the PCC-PCE communication requirements for P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system corresponds to the requirement numbers used in [RFC5862].
本节总结了[RFC5862]中描述的P2MP MPLS-TE LSP的PCC-PCE通信要求。编号系统对应于[RFC5862]中使用的要求编号。
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 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) defined in [RFC4970] to facilitate PCE discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be added to the PCED TLV. This document defines a new flag in the OSPF PCE Capability Flags to indicate the capability of P2MP computation.
[RFC5088]定义了在[RFC4970]中定义的OSPF路由器信息链路状态公告（LSA）中携带的PCE发现（PCED）TLV，以便于使用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 requested 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 New 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 a new 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" sub-registry, 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已从“PCEP TLV类型指标”子注册表中分配了值6，如第6.1节（“PCEP TLV类型指标”）所述。描述为“支持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 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 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 new 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 object 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 a 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 an ERO 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 SRRO 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]。
A new PCEP object class and type are requested for SERO and SRRO.
SERO和SRRO需要一个新的PCEP对象类和类型。
Object-Class Value 29 Name SERO Object-Type 1: SERO 2-15: Unassigned Reference RFC 6006
对象类值29名称SERO对象类型1:SERO 2-15:未分配参考RFC 6006
Object-Class Value 30 Name SRRO Object-Type 1: SRRO 2-15: Unassigned Reference RFC 6006
对象类值30名称SRRO对象类型1:SRRO 2-15:未分配参考RFC 6006
The IANA assignment is 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 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 that the request and reply messages have been fragmented across multiple messages, that they have been requested for a P2MP path, and whether the route is represented in the compressed or uncompressed format.
PCE路径计算请求和回复消息将需要以下附加参数，以向接收PCE指示请求和回复消息已在多个消息中分段，它们已被请求用于P2MP路径，以及路由是以压缩格式还是未压缩格式表示。
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 PCReq or 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 assignment is 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 new 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 new END-POINTS object, the PCE path computation request message is expanded in a way that allows a single request message to list multiple destinations.
通过新的端点对象，PCE路径计算请求消息以允许单个请求消息列出多个目的地的方式展开。
In total, there are now 4 possible types of leaves in a P2MP request:
现在，P2MP请求中总共有4种可能的叶子类型：
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 new 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.
使用新的END-POINTS对象，对于一个源地址有大量目的地的P2MP路径，多个目的地的请求消息的END-POINTS部分最多可以减少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 new END-POINTS object body for IPv4 (Object-Type 3) is as follows:
IPv4的新端点对象体（对象类型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 New 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 New P2MP END-POINTS Object Body Format for IPv6
图2。IPv6的新P2MP端点对象体格式
The END-POINTS object body has a variable length. These are multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 bytes, for IPv6.
端点对象主体具有可变长度。IPv4是4字节的倍数，IPv6是16字节加4字节的倍数。
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>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<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>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 3. The Message Format for the Request Message
图3。请求消息的消息格式
Note that we preserve compatibility with the [RFC5440] definition of <request>. At least one instance of <endpoints> MUST be present in this message.
请注意，我们保留了与<request>的[RFC5440]定义的兼容性。此消息中必须至少存在一个<endpoints>实例。
We have documented the IANA assignment of additional END-POINTS Object-Types in Section 6.5 ("PCEP Objects") of this document.
我们已在本文件第6.5节（“PCEP对象”）中记录了附加端点对象类型的IANA分配。
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>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
哪里：
<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>]
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 [RFC5440] definition of <response> and the optional <end-point-path-pair-list> and <path>.
注意，我们保留了与<response>的[RFC5440]定义以及可选的<end point 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 new objective function codes have to be defined.
本文档定义了两个附加的目标函数——即SPT（最短路径树）和MCT（最小成本树），用于P2MP路径计算。因此，必须定义两个新的目标函数码。
The description of the two new objective functions is as follows.
两个新目标函数的描述如下。
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, that is 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 new 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 the hop count metric. 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. We propose the following values for these new metric types:
[RFC5440]中为<METRIC>对象定义了三种类型，即IGP度量、TE度量和跃点计数度量。本文档为<METRIC>对象定义了三种附加类型：P2MP IGP度量、P2MP TE度量和P2MP跃点计数度量。它们对树的所有链接的度量的总和进行编码。我们为这些新的度量类型提出以下值：
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 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. New Error-Types and Error-Values are requested in Section 6 ("IANA Considerations") of this document.
o 如果PCE接收到P2MP path请求，并且它理解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 MUST send a PCErr message with Error-value=2 (capability not supported).
o 如果PCE不理解RP对象中的P2MP标志，则PCE必须发送错误值为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 user MUST insert the list of RROs and SRROs after each type of END-POINTS in the PCReq message, as described in the "Request Message Format" section (Section 3.4) of this document.
P2MP TE路径的重新优化请求通过使用[RFC5440]中定义的RP对象内的R位来指定，类似于P2P TE路径的重新优化请求。唯一的区别是，用户必须在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-POINT 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 SHOULD be 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树。本节介绍向现有P2MP树添加新叶或从中删除旧叶的方法。
To add new leaves, the user MUST build a P2MP request using END-POINTS with leaf type 1.
要添加新叶，用户必须使用叶类型为1的端点构建P2MP请求。
To remove old leaves, the user must build a P2MP request using END-POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE MUST send an error type 17, value=1: The PCE is not capable of satisfying the request due to no END-POINTS with leaf type 2.
要删除旧叶，用户必须使用叶类型为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. New PCEP-ERROR objects and types are necessary for reporting 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-POINT" error will be used if a PCC receives a request that has an inconsistent END-POINT (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或两者的端点。当某些条件不满足时（即，没有叶类型3或4的端点，或存在叶类型1或2的端点），报告需要新的PCEP-ERROR对象和类型。如果PCC收到具有不一致端点的请求（即，如果指定为类型1的叶已经存在），则将使用通用的“不一致端点”错误。这些IANA分配记录在本文件第6.6节（“PCEP-ERROR对象和类型”）中。
For old leaves, the user 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.
对于旧叶，用户必须提供旧路径作为紧跟在每个端点对象之后的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) defined in [RFC5440], except that it only supports IPv4 and IPv6 prefix sub-objects. Two Object-types 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 Request may carry at most one Branch Node Object.
对象只能在PCReq消息中携带。路径请求最多可以携带一个分支节点对象。
The Object-Class and Object-types have been allocated by IANA. The IANA assignment is 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 Synchronization VECtor (SVEC) functionality 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) END-POINTS1 for P2MP RRO1 list END-POINTS2 for P2MP RRO2 list
用于同步P2MP RRO1列表的（可选）端点S1的LSP1和LSP2的公共标头SVEC P2MP RRO2列表的端点S2
Figure 7. PCReq Message Example for Synchronization
图7。用于同步的PCReq消息示例
This specification also defines two new flags to the SVEC Object Flag Field for P2MP path dependent computation requests. The first new flag is to allow 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, would allow 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 assignment is 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 has been outlined in "The Extension of the RP Object" (Section 3.3.1) of this document. The F-bit is used in the RP object header 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.
本文件“RP对象的扩展”（第3.3.1节）中概述了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 to 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 the Req-ID1 specified in the RP object, and with the F-bit set on the first message, and cleared on the second message.
以下示例说明了PCC向PCE发送带有Req-ID1的请求消息，以便将一个叶添加到带有1200个叶的现有树中。本例中使用的假设是，一条请求消息最多可以容纳800个叶子。在这种情况下，原始单个消息需要分段，并使用两条较小的消息发送，这两条消息在RP对象中指定了Req-ID1，并且在第一条消息上设置了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. When the timer expires and it 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 will be required:
需要以下未访问的目标对象：
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 policy violation, a new error value "P2MP Path computation not allowed" should be added to the existing error code for policy violation (Error-Type=5) as defined in [RFC5440]:
要指示与策略冲突相关的错误，应将新的错误值“P2MP路径计算不允许”添加到[RFC5440]中定义的策略冲突（错误类型=5）的现有错误代码中：
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 (Error-Value=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 request, a new 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 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 (Error-Value=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 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 (Error-Value=2). The corresponding P2MP path computation request MUST also be cancelled.
错误类型=16；错误值=2：如果PCE接收到P2MP路径请求，且PCE无法进行P2MP计算，则PCE必须发送带有PCEP-Error对象（错误类型=16）和错误值（错误值=2）的PCErr消息。还必须取消相应的P2MP路径计算请求。
To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (17) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object:
为了指示与P2MP路径请求相关联的P2MP消息碎片错误，新的错误类型（17）和后续错误值定义如下，以包含在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 (Error-Value=1).
错误类型=18；错误值=1：如果PCE没有收到最后一条分段消息，它应该向发送方发送一条错误消息，表明它收到了一条不完整的消息（即“分段请求失败”）。PCE必须发送带有PCEP-ERROR对象（错误类型=18）和错误值（错误值=1）的PCErr消息。
To communicate the reasons for not being able to find P2MP path computation, the NO-PATH object can be used in the PCRep message.
为了说明无法找到P2MP路径计算的原因，可以在PCRep消息中使用NO-path对象。
One new 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 new 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 in 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 ability to enable or disable P2MP path computations on the PCE.
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 ("P2MP Computation TLV in the Existing PCE Discovery Protocol"), or during the Open Message Exchange discussed in Section 3.1.2 ("Open Message Extension").
o PCE可被配置为启用或禁用其P2MP路径计算能力的通告。PCE可以通过第3.1.1节（“现有PCE发现协议中的P2MP计算TLV”）中讨论的IGP发现机制，或在第3.1.2节（“开放消息扩展”）中讨论的开放消息交换期间，公布其P2MP能力。
A number of MIB objects have been defined for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. [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.
[PCEP-MIB]中定义了许多MIB对象，用于一般PCEP控制和监控P2P计算。[RFC5862]规定需要MIB对象来支持本文档中定义的协议扩展的控制和监视。需要一份新文件来定义用于PCEP控制和P2MP计算监控的MIB对象。
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 ("P2MP Computation TLV in the Existing PCE Discovery Protocol") of this document.
本文件第3.1.1节（“现有PCE发现协议中的P2MP计算TLV”）讨论了PCE通过OSPF和IS-IS获取能够进行P2MP路径计算的PCE信息的方法。
The subsequent IANA assignments are 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 of [RFC5440] that specifically help to minimize or negate unauthorized P2MP path computation requests and denial of service attacks. These mechanisms include:
如[RFC5862]中所述，P2MP路径计算请求更占用CPU，并且还利用了更多链路带宽。如果发生未经授权的P2MP路径计算请求或拒绝服务攻击，后续PCEP请求和处理可能会中断网络。因此，重要的是实现符合[RFC5440]的相关安全要求，特别有助于最小化或消除未经授权的P2MP路径计算请求和拒绝服务攻击。这些机制包括：
o Securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]).
o 使用TCP安全技术保护PCEP会话请求和响应（RFC5440第10.2节）。
o Authenticating the PCEP requests and responses to ensure the message is intact and sent from an authorized node (Section 10.3 of [RFC5440]).
o 验证PCEP请求和响应，以确保消息完好无损并从授权节点发送（RFC5440第10.3节）。
o Providing policy control by explicitly defining which PCCs, via IP access-lists, are allowed to send P2MP path requests to the PCE (Section 10.6 of [RFC5440]).
o 通过明确定义允许哪些PCC通过IP访问列表向PCE发送P2MP路径请求来提供策略控制（RFC5440第10.6节）。
PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial of service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP based denial of service attacks against PCEs and PCCs.
PCEP通过TCP运行，因此保护PCE和PCC免受TCP拒绝服务攻击也很重要。[RFC5440]的第10.7.1节概述了将针对PCE和PCC的基于TCP的拒绝服务攻击风险降至最低的一些机制。
PCEP implementations SHOULD consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925].
PCEP实现应该考虑TCP认证选项（TCP-AO）[RCF5925]提供的附加安全性。
IANA maintains a registry of PCEP parameters. A number of IANA considerations have been highlighted in previous sections of this document. IANA has made the following allocations.
IANA维护PCEP参数的注册表。本文件前几节已重点介绍了IANA的一些注意事项。IANA进行了以下分配。
As described in Section 3.1.2., the newly defined P2MP capability TLV allows the PCE to advertise its P2MP path computation capability. IANA has made the following allocation from the "PCEP TLV Type Indicators" sub-registry.
如第3.1.2节所述，新定义的P2MP能力TLV允许PCE公布其P2MP路径计算能力。IANA已从“PCEP TLV类型指示器”子注册表中进行了以下分配。
Value Description Reference 6 P2MP capable RFC 6006
值说明参考6支持P2MP的RFC 6006
As described in Section 3.3.1, three new RP Object Flags have been defined. IANA has made the following allocations from the PCEP "RP Object Flag Field" sub-registry:
如第3.3.1节所述，定义了三个新的RP对象标志。IANA已从PCEP“RP对象标志字段”子注册表进行了以下分配：
Bit Description Reference
位描述参考
18 Fragmentation (F-bit) RFC 6006 19 P2MP (N-bit) RFC 6006 20 ERO-compression (E-bit) RFC 6006
18分片（F位）RFC 6006 19 P2MP（N位）RFC 6006 20 ERO压缩（E位）RFC 6006
As described in Section 3.6.1, two new Objective Functions have been defined. IANA has made the following allocations from the PCEP "Objective Function" sub-registry:
如第3.6.1节所述，定义了两个新的目标函数。IANA已从PCEP“目标函数”子注册表中进行了以下分配：
Code Point Name Reference
代码点名称引用
7 SPT RFC 6006 8 MCT RFC 6006
7标的RFC 6006 8 MCT RFC 6006
As described in Section 3.6.2, three new metric object T fields have been defined. IANA has made the following allocations from the PCEP "METRIC Object T Field" sub-registry:
如第3.6.2节所述，定义了三个新的公制对象T字段。IANA已从PCEP“METRIC Object T Field”子注册表进行了以下分配：
Value Description Reference
值描述参考
8 P2MP IGP metric RFC 6006 9 P2MP TE metric RFC 6006 10 P2MP hop count metric RFC 6006
8 P2MP IGP度量值RFC 6006 9 P2MP TE度量值RFC 6006 10 P2MP跃点计数度量值RFC 6006
As discussed in Section 3.3.2, two new END-POINTS Object-Types are defined. IANA has made the following Object-Type allocations from the "PCEP Objects" sub-registry:
如第3.3.2节所述，定义了两种新的端点对象类型。IANA已从“PCEP对象”子注册表进行了以下对象类型分配：
Object-Class Value 4 Name END-POINTS Object-Type 3: IPv4 4: IPv6 5-15: Unassigned Reference RFC 6006
对象类值4名称端点对象类型3:IPv4 4:IPv6 5-15:未分配参考RFC 6006
As described in Section 3.2, Section 3.11.1, and Section 3.14, four PCEP Object-Classes and six PCEP Object-Types have been defined. IANA has made the following allocations from the "PCEP Objects" sub-registry:
如第3.2节、第3.11.1节和第3.14节所述，定义了四个PCEP对象类和六个PCEP对象类型。IANA已从“PCEP对象”子注册表进行了以下分配：
Object-Class Value 28 Name UNREACH-DESTINATION Object-Type 1: IPv4 2: IPv6 3-15: Unassigned Reference RFC 6006
对象类值28名称未访问-目标对象类型1:IPv4 2:IPv6 3-15:未分配参考RFC 6006
Object-Class Value 29 Name SERO Object-Type 1: SERO 2-15: Unassigned Reference RFC 6006
对象类值29名称SERO对象类型1:SERO 2-15:未分配参考RFC 6006
Object-Class Value 30 Name SRRO Object-Type 1: SRRO 2-15: Unassigned Reference RFC 6006
对象类值30名称SRRO对象类型1:SRRO 2-15:未分配参考RFC 6006
Object-Class Value 31 Name Branch Node Capability Object Object-Type 1: Branch node list 2: Non-branch node list 3-15: Unassigned Reference RFC 6006
对象类值31名称分支节点能力对象对象类型1：分支节点列表2：非分支节点列表3-15：未分配参考RFC 6006
As described in Section 3.15, a number of new PCEP-ERROR Object Error Types and Values have been defined. IANA has made the following allocations from the PCEP "PCEP-ERROR Object Error Types and Values" sub-registry:
如第3.15节所述，已定义了许多新的PCEP-ERROR对象错误类型和值。IANA已从PCEP“PCEP-ERROR对象错误类型和值”子注册表进行了以下分配：
Error Type Meaning Reference
错误类型含义引用
5 Policy violation Error-value=7: RFC 6006 P2MP Path computation is not allowed
5策略冲突错误值=7:RFC 6006 P2MP路径计算不允许
16 P2MP Capability Error Error-Value=0: Unassigned RFC 6006 Error-Value=1: RFC 6006 The PCE is not capable to satisfy the request due to insufficient memory Error-Value=2: RFC 6006 The PCE is not capable of P2MP computation
16 P2MP能力错误值=0：未分配RFC 6006错误值=1:RFC 6006由于内存不足，PCE无法满足请求错误值=2:RFC 6006 PCE无法进行P2MP计算
17 P2MP END-POINTS Error Error-Value=0: Unassigned RFC 6006 Error-Value=1: RFC 6006 The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 2 Error-Value=2: RFC 6006 The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 3 Error-Value=3: RFC 6006 The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 4 Error-Value=4: RFC 6006 The PCE is not capable to satisfy the request due to inconsistent END-POINTS
17 P2MP端点错误值=0：未分配RFC 6006错误值=1:RFC 6006由于没有叶类型2的端点错误值=2:RFC 6006 PCE无法满足请求由于没有叶类型3的端点错误值=3:RFC 6006 PCE无法满足请求由于对于没有叶类型4错误值=4的端点：RFC 6006，由于端点不一致，PCE无法满足请求
18 P2MP Fragmentation Error Error-Value=0: Unassigned RFC 6006 Error-Value=1: RFC 6006 Fragmented request failure
18 P2MP碎片错误值=0:未分配RFC 6006错误值=1:RFC 6006碎片请求失败
As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field has been defined. IANA has made the following allocation from the PCEP "NO-PATH-VECTOR TLV Flag Field" sub-registry:
如第3.16节所述，定义了一个新的无路径向量TLV标志字段。IANA已从PCEP“无路径向量TLV标志字段”子注册表中进行了以下分配：
Bit Description Reference
位描述参考
24 P2MP Reachability Problem RFC 6006
24 P2MP可达性问题RFC 6006
As discussed in Section 3.12, two new SVEC Object Flags are defined. IANA has made the following allocation from the PCEP "SVEC Object Flag Field" sub-registry:
如第3.12节所述，定义了两个新的SVEC对象标志。IANA已从PCEP“SVEC对象标志字段”子注册表进行了以下分配：
Bit Description Reference
位描述参考
19 Partial Path Diverse RFC 6006 20 Link Direction Diverse RFC 6006
19部分路径多样性RFC 6006 20链路方向多样性RFC 6006
As discussed in Section 3.1.1, a new OSPF Capability Flag is defined to indicate P2MP path computation capability. IANA has made the following assignment from the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry:
如第3.1.1节所述，定义了一个新的OSPF能力标志，以指示P2MP路径计算能力。IANA已从OSPF参数“路径计算元素（PCE）能力标志”注册表中进行了以下分配：
Bit Description Reference
位描述参考
10 P2MP path computation RFC 6006
10 P2MP路径计算RFC 6006
The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv Dhody, Udayasree Palle, 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 Okim、Nick Neate、Suresh Babu K、Dhruv Dhody、Udayasree Palle、Gaurav Agrawal、Vishwas Manral、Dan Romascanu、Tim Polk、Stewart Bryant、David Harrington和Sean Turner对本文件的宝贵评论和意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[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, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970]Lindem，A.，Ed.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 49702007年7月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073]Vasseur，J.，Ed.，和J.Le Roux，Ed.，“发现流量工程节点能力的IGP路由协议扩展”，RFC 5073，2007年12月。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月。
[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, January 2008.
[RFC5089]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，2009年4月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 55412009年6月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[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, October 2009.
[RFC5671]Yasukawa，S.和A.Farrel，Ed.“路径计算元素（PCE）对点对多点（P2MP）MPLS和GMPLS流量工程（TE）的适用性”，RFC 56712009年10月。
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC5862]Yasukawa，S.和A.Farrel，“点对多点MPLS-TE的路径计算客户端（PCC）-路径计算元件（PCE）要求”，RFC 5862，2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and D. King, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2010.
[PCEP-MIB]Koushik，K.，Stephan，E.，Zhao，Q.，和D.King，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2010年7月。
Contributors
贡献者
Jean-Louis Le Roux France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：jeanlouis。leroux@orange-ftgroup.com
Mohamad Chaitou France EMail: mohamad.chaitou@gmail.com
Mohamad Chaitou法国电子邮件：Mohamad。chaitou@gmail.com
Authors' Addresses
作者地址
Quintin Zhao (editor) Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US EMail: qzhao@huawei.com
赵昆廷（编辑）华为科技125马州纳戈尔科技园阿克顿01719美国电子邮件：qzhao@huawei.com
Daniel King (editor) Old Dog Consulting UK EMail: daniel@olddog.co.uk
Daniel King（编辑）Old Dog Consulting UK电子邮件：daniel@olddog.co.uk
Fabien Verhaeghe Thales Communication France 160 Bd Valmy 92700 Colombes France EMail: fabien.verhaeghe@gmail.com
Fabien Verhaeghe Thales Communication France 160 Bd Valmy 92700 Colombes France电子邮件：Fabien。verhaeghe@gmail.com
Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan EMail: takeda.tomonori@lab.ntt.co.jp
武田NTT公司3-9-11，东京武藏市中岛町，180-8585日本电子邮件：武田。tomonori@lab.ntt.co.jp
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 France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex France EMail: julien.meuric@orange-ftgroup.com
Julien Meuria法国电信2号，Pierre Marzin大街22307 Lannion Cedex法国电子邮件：Julien。meuric@orange-ftgroup.com