Network Working Group JP. Vasseur, Ed.
Request for Comments: 5440 Cisco Systems
Category: Standards Track JL. Le Roux, Ed.
France Telecom
March 2009
Network Working Group JP. Vasseur, Ed.
Request for Comments: 5440 Cisco Systems
Category: Standards Track JL. Le Roux, Ed.
France Telecom
March 2009
Path Computation Element (PCE) Communication Protocol (PCEP)
路径计算元件（PCE）通信协议（PCEP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
本文档规定了用于路径计算客户端（PCC）和PCE之间或两个PCE之间通信的路径计算元素（PCE）通信协议（PCEP）。这种交互包括路径计算请求和路径计算回复，以及在多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程的上下文中与PCE的使用相关的特定状态的通知。PCEP的设计是灵活和可扩展的，以便在将来表达进一步的需求时，能够轻松地添加进一步的消息和对象。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Assumptions .....................................................6
4. Architectural Protocol Overview (Model) .........................7
4.1. Problem ....................................................7
4.2. Architectural Protocol Overview ............................7
4.2.1. Initialization Phase ................................8
4.2.2. Session Keepalive ...................................9
4.2.3. Path Computation Request Sent by a PCC to a PCE ....10
4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11
4.2.5. Notification .......................................12
4.2.6. Error ..............................................14
4.2.7. Termination of the PCEP Session ....................14
4.2.8. Intermittent versus Permanent PCEP Session .........15
5. Transport Protocol .............................................15
6. PCEP Messages ..................................................15
6.1. Common Header .............................................16
6.2. Open Message ..............................................16
6.3. Keepalive Message .........................................18
6.4. Path Computation Request (PCReq) Message ..................19
6.5. Path Computation Reply (PCRep) Message ....................20
6.6. Notification (PCNtf) Message ..............................21
6.7. Error (PCErr) Message .....................................22
6.8. Close Message .............................................23
6.9. Reception of Unknown Messages .............................23
7. Object Formats .................................................23
7.1. PCEP TLV Format ...........................................24
7.2. Common Object Header ......................................24
7.3. OPEN Object ...............................................25
7.4. RP Object .................................................27
7.4.1. Object Definition ..................................27
7.4.2. Handling of the RP Object ..........................30
7.5. NO-PATH Object ............................................31
7.6. END-POINTS Object .........................................34
7.7. BANDWIDTH Object ..........................................35
7.8. METRIC Object .............................................36
7.9. Explicit Route Object .....................................39
7.10. Reported Route Object ....................................39
7.11. LSPA Object ..............................................40
7.12. Include Route Object .....................................42
7.13. SVEC Object ..............................................42
7.13.1. Notion of Dependent and Synchronized Path
Computation Requests ..............................42
7.13.2. SVEC Object .......................................44
7.13.3. Handling of the SVEC Object .......................45
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Assumptions .....................................................6
4. Architectural Protocol Overview (Model) .........................7
4.1. Problem ....................................................7
4.2. Architectural Protocol Overview ............................7
4.2.1. Initialization Phase ................................8
4.2.2. Session Keepalive ...................................9
4.2.3. Path Computation Request Sent by a PCC to a PCE ....10
4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11
4.2.5. Notification .......................................12
4.2.6. Error ..............................................14
4.2.7. Termination of the PCEP Session ....................14
4.2.8. Intermittent versus Permanent PCEP Session .........15
5. Transport Protocol .............................................15
6. PCEP Messages ..................................................15
6.1. Common Header .............................................16
6.2. Open Message ..............................................16
6.3. Keepalive Message .........................................18
6.4. Path Computation Request (PCReq) Message ..................19
6.5. Path Computation Reply (PCRep) Message ....................20
6.6. Notification (PCNtf) Message ..............................21
6.7. Error (PCErr) Message .....................................22
6.8. Close Message .............................................23
6.9. Reception of Unknown Messages .............................23
7. Object Formats .................................................23
7.1. PCEP TLV Format ...........................................24
7.2. Common Object Header ......................................24
7.3. OPEN Object ...............................................25
7.4. RP Object .................................................27
7.4.1. Object Definition ..................................27
7.4.2. Handling of the RP Object ..........................30
7.5. NO-PATH Object ............................................31
7.6. END-POINTS Object .........................................34
7.7. BANDWIDTH Object ..........................................35
7.8. METRIC Object .............................................36
7.9. Explicit Route Object .....................................39
7.10. Reported Route Object ....................................39
7.11. LSPA Object ..............................................40
7.12. Include Route Object .....................................42
7.13. SVEC Object ..............................................42
7.13.1. Notion of Dependent and Synchronized Path
Computation Requests ..............................42
7.13.2. SVEC Object .......................................44
7.13.3. Handling of the SVEC Object .......................45
7.14. NOTIFICATION Object ......................................46
7.15. PCEP-ERROR Object ........................................49
7.16. LOAD-BALANCING Object ....................................54
7.17. CLOSE Object .............................................55
8. Manageability Considerations ...................................56
8.1. Control of Function and Policy ............................56
8.2. Information and Data Models ...............................57
8.3. Liveness Detection and Monitoring .........................57
8.4. Verifying Correct Operation ...............................58
8.5. Requirements on Other Protocols and Functional
Components ................................................58
8.6. Impact on Network Operation ...............................58
9. IANA Considerations ............................................59
9.1. TCP Port ..................................................59
9.2. PCEP Messages .............................................59
9.3. PCEP Object ...............................................59
9.4. PCEP Message Common Header ................................61
9.5. Open Object Flag Field ....................................61
9.6. RP Object .................................................61
9.7. NO-PATH Object Flag Field .................................62
9.8. METRIC Object .............................................63
9.9. LSPA Object Flag Field ....................................63
9.10. SVEC Object Flag Field ...................................64
9.11. NOTIFICATION Object ......................................64
9.12. PCEP-ERROR Object ........................................65
9.13. LOAD-BALANCING Object Flag Field .........................67
9.14. CLOSE Object .............................................67
9.15. PCEP TLV Type Indicators .................................68
9.16. NO-PATH-VECTOR TLV .......................................68
10. Security Considerations .......................................69
10.1. Vulnerability ............................................69
10.2. TCP Security Techniques ..................................70
10.3. PCEP Authentication and Integrity ........................70
10.4. PCEP Privacy .............................................71
10.5. Key Configuration and Exchange ...........................71
10.6. Access Policy ............................................73
10.7. Protection against Denial-of-Service Attacks .............73
10.7.1. Protection against TCP DoS Attacks ................73
10.7.2. Request Input Shaping/Policing ....................74
11. Acknowledgments ...............................................75
12. References ....................................................75
12.1. Normative References .....................................75
12.2. Informative References ...................................76
Appendix A. PCEP Finite State Machine (FSM) ......................79
Appendix B. PCEP Variables .......................................85
Appendix C. Contributors .........................................86
7.14. NOTIFICATION Object ......................................46
7.15. PCEP-ERROR Object ........................................49
7.16. LOAD-BALANCING Object ....................................54
7.17. CLOSE Object .............................................55
8. Manageability Considerations ...................................56
8.1. Control of Function and Policy ............................56
8.2. Information and Data Models ...............................57
8.3. Liveness Detection and Monitoring .........................57
8.4. Verifying Correct Operation ...............................58
8.5. Requirements on Other Protocols and Functional
Components ................................................58
8.6. Impact on Network Operation ...............................58
9. IANA Considerations ............................................59
9.1. TCP Port ..................................................59
9.2. PCEP Messages .............................................59
9.3. PCEP Object ...............................................59
9.4. PCEP Message Common Header ................................61
9.5. Open Object Flag Field ....................................61
9.6. RP Object .................................................61
9.7. NO-PATH Object Flag Field .................................62
9.8. METRIC Object .............................................63
9.9. LSPA Object Flag Field ....................................63
9.10. SVEC Object Flag Field ...................................64
9.11. NOTIFICATION Object ......................................64
9.12. PCEP-ERROR Object ........................................65
9.13. LOAD-BALANCING Object Flag Field .........................67
9.14. CLOSE Object .............................................67
9.15. PCEP TLV Type Indicators .................................68
9.16. NO-PATH-VECTOR TLV .......................................68
10. Security Considerations .......................................69
10.1. Vulnerability ............................................69
10.2. TCP Security Techniques ..................................70
10.3. PCEP Authentication and Integrity ........................70
10.4. PCEP Privacy .............................................71
10.5. Key Configuration and Exchange ...........................71
10.6. Access Policy ............................................73
10.7. Protection against Denial-of-Service Attacks .............73
10.7.1. Protection against TCP DoS Attacks ................73
10.7.2. Request Input Shaping/Policing ....................74
11. Acknowledgments ...............................................75
12. References ....................................................75
12.1. Normative References .....................................75
12.2. Informative References ...................................76
Appendix A. PCEP Finite State Machine (FSM) ......................79
Appendix B. PCEP Variables .......................................85
Appendix C. Contributors .........................................86
[RFC4655] describes the motivations and architecture for a Path
Computation Element (PCE) based model for the computation of
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Label Switched Paths (TE LSPs). The model allows
for the separation of PCE from Path Computation Client (PCC), and
allows for the cooperation between PCEs. This necessitates a
communication protocol between PCC and PCE, and between PCEs.
[RFC4657] states the generic requirements for such a protocol
including that the same protocol be used between PCC and PCE, and
between PCEs. Additional application-specific requirements (for
scenarios such as inter-area, inter-AS, etc.) are not included in
[RFC4657], but there is a requirement that any solution protocol must
be easily extensible to handle other requirements as they are
introduced in application-specific requirements documents. Examples
of such application-specific requirements are [RFC4927], [RFC5376],
and [INTER-LAYER].
[RFC4655] describes the motivations and architecture for a Path
Computation Element (PCE) based model for the computation of
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Label Switched Paths (TE LSPs). The model allows
for the separation of PCE from Path Computation Client (PCC), and
allows for the cooperation between PCEs. This necessitates a
communication protocol between PCC and PCE, and between PCEs.
[RFC4657] states the generic requirements for such a protocol
including that the same protocol be used between PCC and PCE, and
between PCEs. Additional application-specific requirements (for
scenarios such as inter-area, inter-AS, etc.) are not included in
[RFC4657], but there is a requirement that any solution protocol must
be easily extensible to handle other requirements as they are
introduced in application-specific requirements documents. Examples
of such application-specific requirements are [RFC4927], [RFC5376],
and [INTER-LAYER].
This document specifies the Path Computation Element Protocol (PCEP) for communications between a PCC and a PCE, or between two PCEs, in compliance with [RFC4657]. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering.
本文件规定了PCC和PCE之间或两个PCE之间通信的路径计算元素协议（PCEP），符合[RFC4657]。这种交互包括路径计算请求和路径计算回复，以及与MPLS和GMPLS流量工程上下文中的PCE的使用相关的特定状态的通知。
PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
PCEP的设计是灵活和可扩展的，以便在将来表达进一步的需求时，能够轻松地添加进一步的消息和对象。
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]中所述进行解释。
The following terminology is used in this document.
本文件使用以下术语。
AS: Autonomous System.
AS：自治系统。
Explicit path: Full explicit path from start to destination; made of a list of strict hops where a hop may be an abstract node such as an AS.
显式路径：从起点到终点的完整显式路径；由严格跃点列表组成，其中跃点可以是抽象节点，如as。
IGP area: OSPF area or IS-IS level.
IGP区域：OSPF区域或IS-IS级别。
Inter-domain TE LSP: A TE LSP whose path transits at least two different domains where a domain can be an IGP area, an Autonomous System, or a sub-AS (BGP confederation).
域间TE LSP：一种TE LSP，其路径穿过至少两个不同的域，其中一个域可以是IGP区域、自治系统或子AS（BGP联盟）。
PCC: Path Computation Client; any client application requesting a path computation to be performed by a Path Computation Element.
PCC：路径计算客户端；任何请求由路径计算元素执行的路径计算的客户端应用程序。
PCE: Path Computation Element; an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算单元；能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCEP Peer: An element involved in a PCEP session (i.e., a PCC or a PCE).
PCEP对等方：参与PCEP会话的元素（即PCC或PCE）。
TED: Traffic Engineering Database that contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means.
TED：包含域的拓扑和资源信息的流量工程数据库。TED可以通过IGP扩展或可能通过其他方式供电。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
Strict/loose path: A mix of strict and loose hops comprising at least one loose hop representing the destination where a hop may be an abstract node such as an AS.
严格/松散路径：严格和松散跃点的混合，包括至少一个表示目的地的松散跃点，其中一个跃点可以是抽象节点，如as。
Within this document, when describing PCE-PCE communications, the requesting PCE fills the role of a PCC. This provides a saving in documentation without loss of function.
在本文档中，当描述PCE-PCE通信时，请求PCE充当PCC的角色。这样可以在不丢失功能的情况下保存文档。
The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF].
本文档中的消息格式使用[RBNF]中规定的Backus Naur格式（BNF）编码指定。
[RFC4655] describes various types of PCE. PCEP does not make any assumption about, and thus does not impose any constraint on, the nature of the PCE.
[RFC4655]描述了各种类型的PCE。PCEP不会对PCE的性质做出任何假设，因此也不会对PCE的性质施加任何约束。
Moreover, it is assumed that the PCE has the required information (usually including network topology and resource information) so as to perform the computation of a path for a TE LSP. Such information can be gathered by routing protocols or by some other means. The way in which the information is gathered is out of the scope of this document.
此外，假设PCE具有所需的信息（通常包括网络拓扑和资源信息），以便执行TE LSP的路径计算。这些信息可以通过路由协议或其他方式收集。收集信息的方式不在本文件范围内。
Similarly, no assumption is made about the discovery method used by a PCC to discover a set of PCEs (e.g., via static configuration or dynamic discovery) and on the algorithm used to select a PCE. For
类似地，对于PCC用于发现一组PCE（例如，通过静态配置或动态发现）的发现方法以及用于选择PCE的算法，没有作出任何假设。对于
reference, [RFC4674] defines a list of requirements for dynamic PCE discovery and IGP-based solutions for such PCE discovery are specified in [RFC5088] and [RFC5089].
参考文献[RFC4674]定义了动态PCE发现的要求列表，[RFC5088]和[RFC5089]中规定了此类PCE发现的基于IGP的解决方案。
The aim of this section is to describe the PCEP model in the spirit of [RFC4101]. An architectural protocol overview (the big picture of the protocol) is provided in this section. Protocol details can be found in further sections.
本节的目的是按照[RFC4101]的精神描述PCEP模型。本节提供了体系结构协议概述（协议的大图）。协议详情可在后续章节中找到。
The PCE-based architecture used for the computation of paths for MPLS and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the PCE are not collocated, a communication protocol between the PCC and the PCE is needed. PCEP is such a protocol designed specifically for communications between a PCC and a PCE or between two PCEs in compliance with [RFC4657]: a PCC may use PCEP to send a path computation request for one or more TE LSPs to a PCE, and the PCE may reply with a set of computed paths if one or more paths can be found that satisfies the set of constraints.
[RFC4655]中描述了用于计算MPLS和GMPLS TE LSP路径的基于PCE的体系结构。当PCC和PCE未并置时，需要PCC和PCE之间的通信协议。PCEP是专为PCC和PCE之间或两个PCE之间的通信设计的协议，符合[RFC4657]：PCC可使用PCEP向PCE发送一个或多个TE LSP的路径计算请求，并且如果可以找到满足该组约束的一个或多个路径，则PCE可以用一组计算出的路径来回答。
PCEP operates over TCP, which fulfills the requirements for reliable messaging and flow control without further protocol work.
PCEP通过TCP运行，TCP满足可靠消息传递和流控制的要求，无需进一步的协议工作。
Several PCEP messages are defined:
定义了几个PCEP消息：
o Open and Keepalive messages are used to initiate and maintain a PCEP session, respectively.
o Open和Keepalive消息分别用于启动和维护PCEP会话。
o PCReq: a PCEP message sent by a PCC to a PCE to request a path computation.
o PCReq：PCC向PCE发送的PCEP消息，用于请求路径计算。
o PCRep: a PCEP message sent by a PCE to a PCC in reply to a path computation request. A PCRep message can contain either a set of computed paths if the request can be satisfied, or a negative reply if not. The negative reply may indicate the reason why no path could be found.
o PCRep：PCE向PCC发送的PCEP消息，用于响应路径计算请求。PCRep消息可以包含一组计算路径（如果可以满足请求），也可以包含否定回复（如果不能满足）。否定回答可能表明找不到路径的原因。
o PCNtf: a PCEP notification message either sent by a PCC to a PCE or sent by a PCE to a PCC to notify of a specific event.
o PCNtf：PCC发送给PCE或PCE发送给PCC以通知特定事件的PCEP通知消息。
o PCErr: a PCEP message sent upon the occurrence of a protocol error condition.
o PCErr：发生协议错误情况时发送的PCEP消息。
o Close message: a message used to close a PCEP session.
o 关闭消息：用于关闭PCEP会话的消息。
The set of available PCEs may be either statically configured on a PCC or dynamically discovered. The mechanisms used to discover one or more PCEs and to select a PCE are out of the scope of this document.
可用pce的集合可以在PCC上静态配置，也可以动态发现。用于发现一个或多个PCE和选择PCE的机制不在本文档的范围内。
A PCC may have PCEP sessions with more than one PCE, and similarly a PCE may have PCEP sessions with multiple PCCs.
PCC可以具有与多个PCE的PCEP会话，并且类似地，PCE可以具有与多个PCC的PCEP会话。
Each PCEP message is regarded as a single transmission unit and parts of messages MUST NOT be interleaved. So, for example, a PCC sending a PCReq and wishing to close the session, must complete sending the request message before starting to send a Close message.
每个PCEP消息被视为一个单独的传输单元，部分消息不得交叉。因此，例如，发送PCReq并希望关闭会话的PCC必须在开始发送关闭消息之前完成发送请求消息。
The initialization phase consists of two successive steps (described in a schematic form in Figure 1):
初始化阶段包括两个连续步骤（如图1中的示意图所示）：
1) Establishment of a TCP connection (3-way handshake) between the PCC and the PCE.
1) 在PCC和PCE之间建立TCP连接（3路握手）。
2) Establishment of a PCEP session over the TCP connection.
2) 通过TCP连接建立PCEP会话。
Once the TCP connection is established, the PCC and the PCE (also referred to as "PCEP peers") initiate PCEP session establishment during which various session parameters are negotiated. These parameters are carried within Open messages and include the Keepalive timer, the DeadTimer, and potentially other detailed capabilities and policy rules that specify the conditions under which path computation requests may be sent to the PCE. If the PCEP session establishment phase fails because the PCEP peers disagree on the session parameters or one of the PCEP peers does not answer after the expiration of the establishment timer, the TCP connection is immediately closed. Successive retries are permitted but an implementation should make use of an exponential back-off session establishment retry procedure.
一旦TCP连接建立，PCC和PCE（也称为“PCEP对等方”）启动PCEP会话建立，在此期间协商各种会话参数。这些参数包含在打开的消息中，包括Keepalive timer、DeadTimer以及其他可能详细的功能和策略规则，这些功能和规则指定了路径计算请求可以发送到PCE的条件。如果PCEP会话建立阶段失败，因为PCEP对等方对会话参数不一致，或者其中一个PCEP对等方在建立计时器过期后没有应答，TCP连接将立即关闭。允许连续重试，但实现应使用指数退避会话建立重试过程。
Keepalive messages are used to acknowledge Open messages, and are used once the PCEP session has been successfully established.
Keepalive消息用于确认打开的消息，并在成功建立PCEP会话后使用。
Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time.
在任何时候，一对PCEP对等方之间只能存在一个PCEP会话。在任何时候，一对PCEP对等方之间只能存在PCEP端口上的一个TCP连接。
Details about the Open message and the Keepalive message can be found in Sections 6.2 and 6.3, respectively.
有关Open消息和Keepalive消息的详细信息，请分别参见第6.2节和第6.3节。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg |
|-------- |
| \ Open msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ Keepalive|
| --------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------ ---------->|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg |
|-------- |
| \ Open msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ Keepalive|
| --------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------ ---------->|
| |
Figure 1: PCEP Initialization Phase (Initiated by a PCC)
图1:PCEP初始化阶段（由PCC启动）
(Note that once the PCEP session is established, the exchange of Keepalive messages is optional.)
（请注意，一旦PCEP会话建立，Keepalive消息的交换是可选的。）
Once a session has been established, a PCE or PCC may want to know that its PCEP peer is still available for use.
建立会话后，PCE或PCC可能希望知道其PCEP对等机仍可供使用。
It can rely on TCP for this information, but it is possible that the remote PCEP function has failed without disturbing the TCP connection. It is also possible to rely on the mechanisms built into the TCP implementations, but these might not provide failure notifications that are sufficiently timely. Lastly, a PCC could wait until it has a path computation request to send and could use its failed transmission or the failure to receive a response as evidence that the session has failed, but this is clearly inefficient.
它可以依赖TCP获取此信息，但远程PCEP功能可能在不干扰TCP连接的情况下发生故障。也可以依赖TCP实现中内置的机制，但这些机制可能无法提供足够及时的故障通知。最后，PCC可以等待，直到有路径计算请求要发送，并可以使用其失败的传输或接收响应的失败作为会话失败的证据，但这显然是低效的。
In order to handle this situation, PCEP includes a keepalive mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive message.
为了处理这种情况，PCEP包括基于keepalive计时器、DeadTimer和keepalive消息的keepalive机制。
Each end of a PCEP session runs a Keepalive timer. It restarts the timer every time it sends a message on the session. When the timer expires, it sends a Keepalive message. Other traffic may serve as Keepalive (see Section 6.3).
PCEP会话的每一端都运行一个Keepalive计时器。每次在会话上发送消息时，它都会重新启动计时器。当计时器过期时，它会发送一条Keepalive消息。其他交通可作为通行证（见第6.3节）。
The ends of the PCEP session also run DeadTimers, and they restart the timers whenever a message is received on the session. If one end of the session receives no message before the DeadTimer expires, it declares the session dead.
PCEP会话的结束也会运行死区计时器，并且在会话上收到消息时会重新启动计时器。如果会话的一端在DeadTimer过期之前没有收到任何消息，它将声明会话已死亡。
Note that this means that the Keepalive message is unresponded and does not form part of a two-way keepalive handshake as used in some protocols. Also note that the mechanism is designed to reduce to a minimum the amount of keepalive traffic on the session.
注意，这意味着Keepalive消息是未响应的，并且不构成某些协议中使用的双向Keepalive握手的一部分。还请注意，该机制旨在将会话上的keepalive通信量降至最低。
The keepalive traffic on the session may be unbalanced according to the requirements of the session ends. Each end of the session can specify (on an Open message) the Keepalive timer that it will use (i.e., how often it will transmit a Keepalive message if there is no other traffic) and a DeadTimer that it recommends its peer to use (i.e., how long the peer should wait before declaring the session dead if it receives no traffic). The session ends may use different Keepalive timer values.
根据会话结束的要求，会话上的keepalive流量可能不平衡。会话的每个结尾都可以指定（在打开的消息上）它将使用的Keepalive计时器（即，如果没有其他流量，它将发送Keepalive消息的频率）和它建议其对等方使用的DeadTimer（即，如果没有收到流量，对等方在声明会话死亡之前应该等待多长时间）。会话结束可能使用不同的Keepalive计时器值。
The minimum value of the Keepalive timer is 1 second, and it is specified in units of 1 second. The recommended default value is 30 seconds. The timer may be disabled by setting it to zero.
Keepalive计时器的最小值为1秒，并以1秒为单位指定。建议的默认值为30秒。定时器可通过将其设置为零来禁用。
The recommended default for the DeadTimer is 4 times the value of the Keepalive timer used by the remote peer. This means that there is never any risk of congesting TCP with excessive Keepalive messages.
DeadTimer的建议默认值是远程对等方使用的Keepalive计时器值的4倍。这意味着永远不会有任何使用过多Keepalive消息阻塞TCP的风险。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request sent to | |
the selected PCE | |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request sent to | |
the selected PCE | |
Figure 2: Path Computation Request
图2：路径计算请求
Once a PCC has successfully established a PCEP session with one or more PCEs, if an event is triggered that requires the computation of a set of paths, the PCC first selects one or more PCEs. Note that the PCE selection decision process may have taken place prior to the PCEP session establishment.
一旦PCC与一个或多个PCE成功建立PCEP会话，如果触发需要计算一组路径的事件，PCC首先选择一个或多个PCE。请注意，PCE选择决策过程可能发生在PCEP会话建立之前。
Once the PCC has selected a PCE, it sends a path computation request to the PCE (PCReq message) that contains a variety of objects that specify the set of constraints and attributes for the path to be computed. For example, "Compute a TE LSP path with source IP address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding priority=P, ...". Additionally, the PCC may desire to specify the urgency of such request by assigning a request priority. Each request is uniquely identified by a request-id number and the PCC-PCE address pair. The process is shown in a schematic form in Figure 2.
一旦PCC选择了一个PCE，它将向PCE发送一个路径计算请求（PCReq消息），该PCE包含各种对象，这些对象为要计算的路径指定一组约束和属性。例如，“计算一个TE LSP路径，源IP地址=x.y.z.t，目标IP地址=x'.y'.z'.t'，带宽=B Mbit/s，设置/保持优先级=P，…”。此外，PCC可能希望通过分配请求优先级来指定此类请求的紧急性。每个请求由请求id号和PCC-PCE地址对唯一标识。该过程如图2所示。
Note that multiple path computation requests may be outstanding from a PCC to a PCE at any time.
注意，从PCC到PCE的多路径计算请求在任何时候都可能是未完成的。
Details about the PCReq message can be found in Section 6.4.
有关PCReq消息的详细信息，请参见第6.4节。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) Path successfully
| | computed
| |
| |3) Computed paths
| | sent to the PCC
| |
|<--- PCRep message ---|
| (Positive reply) |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) Path successfully
| | computed
| |
| |3) Computed paths
| | sent to the PCC
| |
|<--- PCRep message ---|
| (Positive reply) |
Figure 3a: Path Computation Request With Successful Path Computation
图3a：路径计算成功的路径计算请求
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) No Path found that
| | satisfies the request
| |
| |3) Negative reply sent to
| | the PCC (optionally with
| | various additional
| | information)
|<--- PCRep message ---|
| (Negative reply) |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) No Path found that
| | satisfies the request
| |
| |3) Negative reply sent to
| | the PCC (optionally with
| | various additional
| | information)
|<--- PCRep message ---|
| (Negative reply) |
Figure 3b: Path Computation Request With Unsuccessful Path Computation
图3b：路径计算不成功的路径计算请求
Upon receiving a path computation request from a PCC, the PCE triggers a path computation, the result of which can be either:
在接收到来自PCC的路径计算请求时，PCE触发路径计算，其结果可以是：
o Positive (Figure 3a): the PCE manages to compute a path that satisfies the set of required constraints. In this case, the PCE returns the set of computed paths to the requesting PCC. Note that PCEP supports the capability to send a single request that requires the computation of more than one path (e.g., computation of a set of link-diverse paths).
o 正向（图3a）：PCE设法计算满足所需约束集的路径。在这种情况下，PCE将计算出的路径集返回给请求PCC。请注意，PCEP支持发送需要计算多条路径（例如，计算一组链路路径）的单个请求。
o Negative (Figure 3b): no path could be found that satisfies the set of constraints. In this case, a PCE may provide the set of constraints that led to the path computation failure. Upon receiving a negative reply, a PCC may decide to resend a modified request or take any other appropriate action.
o 否定（图3b）：找不到满足约束集的路径。在这种情况下，PCE可以提供导致路径计算失败的约束集。收到否定回复后，PCC可决定重新发送修改后的请求或采取任何其他适当措施。
Details about the PCRep message can be found in Section 6.5.
有关PCRep消息的详细信息，请参见第6.5节。
There are several circumstances in which a PCE may want to notify a PCC of a specific event. For example, suppose that the PCE suddenly gets overloaded, potentially leading to unacceptable response times. The PCE may want to notify one or more PCCs that some of their requests (listed in the notification) will not be satisfied or may experience unacceptable delays. Upon receiving such notification,
有几种情况下，PCE可能希望将特定事件通知PCC。例如，假设PCE突然过载，可能导致不可接受的响应时间。PCE可能希望通知一个或多个PCC他们的某些请求（在通知中列出）将无法满足或可能遇到不可接受的延迟。在收到此类通知后，
the PCC may decide to redirect its path computation requests to another PCE should an alternate PCE be available. Similarly, a PCC may desire to notify a PCE of a particular event such as the cancellation of pending requests.
如果备用PCE可用，PCC可以决定将其路径计算请求重定向到另一PCE。类似地，PCC可能希望将特定事件（例如取消未决请求）通知PCE。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
5) Path computation | |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| | request X cancelled
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
5) Path computation | |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| | request X cancelled
Figure 4: Example of PCC Notification (Cancellation Notification) Sent to a PCE
图4：发送给PCE的PCC通知（取消通知）示例
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
| |5) PCE gets overloaded
| |
| |
| |6) Path computation
| | request X cancelled
| |
|<--- PCNtf message----|
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
| |5) PCE gets overloaded
| |
| |
| |6) Path computation
| | request X cancelled
| |
|<--- PCNtf message----|
Figure 5: Example of PCE Notification (Cancellation Notification) Sent to a PCC
图5：发送给PCC的PCE通知（取消通知）示例
Details about the PCNtf message can be found in Section 6.6.
有关PCNtf消息的详细信息，请参见第6.6节。
The PCEP Error message (also referred to as a PCErr message) is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP specification (e.g., capability not supported, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference).
PCEP错误消息（也称为PCErr消息）在几种情况下发送：当满足协议错误条件时，或当请求不符合PCEP规范时（例如，不支持功能、接收到带有强制缺少对象的消息、策略冲突、意外消息、未知请求引用）.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Reception of a
the selected PCE | | malformed object
| |
| |5) Request discarded
| |
|<-- PCErr message ---|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Reception of a
the selected PCE | | malformed object
| |
| |5) Request discarded
| |
|<-- PCErr message ---|
| |
Figure 6: Example of Error Message Sent by a PCE to a PCC in Reply to the Reception of a Malformed Object
图6:PCE向PCC发送错误消息的示例，以响应接收到格式错误的对象
Details about the PCErr message can be found in Section 6.7.
有关PCErr消息的详细信息，请参见第6.7节。
When one of the PCEP peers desires to terminate a PCEP session it first sends a PCEP Close message and then closes the TCP connection. If the PCEP session is terminated by the PCE, the PCC clears all the states related to pending requests previously sent to the PCE. Similarly, if the PCC terminates a PCEP session, the PCE clears all pending path computation requests sent by the PCC in question as well as the related states. A Close message can only be sent to terminate a PCEP session if the PCEP session has previously been established.
当一个PCEP对等方希望终止PCEP会话时，它首先发送PCEP Close消息，然后关闭TCP连接。如果PCE终止PCEP会话，PCC将清除与先前发送给PCE的未决请求相关的所有状态。类似地，如果PCC终止PCEP会话，则PCE清除由相关PCC发送的所有挂起的路径计算请求以及相关状态。如果先前已建立PCEP会话，则只能发送关闭消息以终止PCEP会话。
In case of TCP connection failure, the PCEP session is immediately terminated.
如果TCP连接失败，PCEP会话将立即终止。
Details about the Close message can be found in Section 6.8.
有关关闭消息的详细信息，请参见第6.8节。
An implementation may decide to keep the PCEP session alive (and thus the corresponding TCP connection) for an unlimited time. (For instance, this may be appropriate when path computation requests are sent on a frequent basis so as to avoid opening a TCP connection each time a path computation request is needed, which would incur additional processing delays.) Conversely, in some other circumstances, it may be desirable to systematically open and close a PCEP session for each PCEP request (for instance, when sending a path computation request is a rare event).
一个实现可以决定使PCEP会话（以及相应的TCP连接）无限期保持活动状态。（例如，当频繁发送路径计算请求时，这可能是合适的，以避免每次需要路径计算请求时打开TCP连接，这将导致额外的处理延迟。）相反，在一些其他情况下，可能需要为每个PCEP请求系统地打开和关闭PCEP会话（例如，当发送路径计算请求是罕见事件时）。
PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.
PCEP使用注册的TCP端口（4189）在TCP上运行。这允许在无需进一步协议工作的情况下满足可靠消息传递和流控制的要求。必须使用源和目标TCP端口的注册TCP端口发送所有PCEP消息。
A PCEP message consists of a common header followed by a variable-length body made of a set of objects that can either be mandatory or optional. In the context of this document, an object is said to be mandatory in a PCEP message when the object MUST be included for the message to be considered valid. A PCEP message with a missing mandatory object MUST trigger an Error message (see Section 7.15). Conversely, if an object is optional, the object may or may not be present.
PCEP消息由一个公共标头和一个可变长度的正文组成，正文由一组对象组成，这些对象可以是必需的，也可以是可选的。在本文档的上下文中，当必须包含对象才能将消息视为有效时，PCEP消息中的对象称为强制对象。缺少强制对象的PCEP消息必须触发错误消息（见第7.15节）。相反，如果对象是可选的，则该对象可能存在，也可能不存在。
A flag referred to as the P flag is defined in the common header of each PCEP object (see Section 7.2). When this flag is set in an object in a PCReq, the PCE MUST take the information carried in the object into account during the path computation. For example, the METRIC object defined in Section 7.8 allows a PCC to specify a bounded acceptable path cost. The METRIC object is optional, but a PCC may set a flag to ensure that the constraint is taken into account. In this case, if the constraint cannot be taken into account by the PCE, the PCE MUST trigger an Error message.
在每个PCEP对象的公共标头中定义了一个称为P标志的标志（见第7.2节）。当在PCReq中的对象中设置此标志时，PCE必须在路径计算期间考虑对象中携带的信息。例如，第7.8节中定义的度量对象允许PCC指定有界的可接受路径成本。度量对象是可选的，但PCC可以设置标志以确保考虑约束。在这种情况下，如果PCE不能考虑约束，则PCE必须触发错误消息。
For each PCEP message type, rules are defined that specify the set of objects that the message can carry. We use the Backus-Naur Form (BNF) (see [RBNF]) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the PCEP messages using the object ordering specified in this document.
对于每种PCEP消息类型，都定义了规则，用于指定消息可以携带的对象集。我们使用Backus-Naur表格（BNF）（参见[RBNF]）来指定此类规则。方括号表示可选的子序列。实现必须使用本文档中指定的对象顺序形成PCEP消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCEP Message Common Header
图7:PCEP消息公共头
Ver (Version - 3 bits): PCEP version number. Current version is version 1.
版本（版本-3位）：PCEP版本号。当前版本是版本1。
Flags (5 bits): No flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
标志（5位）：当前未定义标志。未分配的位被视为保留位。它们在传输时必须设置为零，在接收时必须忽略。
Message-Type (8 bits): The following message types are currently defined:
消息类型（8位）：当前定义了以下消息类型：
Value Meaning 1 Open 2 Keepalive 3 Path Computation Request 4 Path Computation Reply 5 Notification 6 Error 7 Close
值表示1打开2保留3路径计算请求4路径计算答复5通知6错误7关闭
Message-Length (16 bits): total length of the PCEP message including the common header, expressed in bytes.
消息长度（16位）：包括公共头的PCEP消息的总长度，以字节表示。
The Open message is a PCEP message sent by a PCC to a PCE and by a PCE to a PCC in order to establish a PCEP session. The Message-Type field of the PCEP common header for the Open message is set to 1.
打开消息是由PCC发送到PCE并由PCE发送到PCC以建立PCEP会话的PCEP消息。打开消息的PCEP公用标头的消息类型字段设置为1。
Once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as specified in Appendix A.
一旦TCP连接成功建立，PCC发送给PCE或PCE发送给PCC的第一条消息必须是附录A中规定的开放消息。
Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type "PCEP session establishment failure" and Error-value "reception of an invalid Open message or a non Open message" and the PCEP session establishment attempt MUST be terminated by closing the TCP connection.
在打开消息之前收到的任何消息都必须触发协议错误条件，导致发送带有错误类型“PCEP会话建立失败”和错误值“接收无效的打开消息或非打开消息”的PCErr消息，并且必须通过关闭TCP连接来终止PCEP会话建立尝试。
The Open message is used to establish a PCEP session between the PCEP peers. During the establishment phase, the PCEP peers exchange several session characteristics. If both parties agree on such characteristics, the PCEP session is successfully established.
Open消息用于在PCEP对等方之间建立PCEP会话。在建立阶段，PCEP对等方交换几个会话特征。如果双方就这些特征达成一致，则PCEP会议将成功举行。
The format of an Open message is as follows:
公开信息的格式如下：
<Open Message>::= <Common Header>
<OPEN>
<Open Message>::= <Common Header>
<OPEN>
The Open message MUST contain exactly one OPEN object (see Section 7.3).
打开的消息必须正好包含一个打开的对象（参见第7.3节）。
Various session characteristics are specified within the OPEN object. Once the TCP connection has been successfully established, the sender MUST start an initialization timer called OpenWait after the expiration of which, if no Open message has been received, it sends a PCErr message and releases the TCP connection (see Appendix A for details).
在开放对象中指定了各种会话特征。一旦TCP连接成功建立，发送方必须启动一个名为OpenWait的初始化计时器，在该计时器过期后，如果未收到打开的消息，则发送方将发送一条PCErr消息并释放TCP连接（有关详细信息，请参阅附录a）。
Once an Open message has been sent to a PCEP peer, the sender MUST start an initialization timer called KeepWait after the expiration of which, if neither a Keepalive message has been received nor a PCErr message in case of disagreement of the session characteristics, a PCErr message MUST be sent and the TCP connection MUST be released (see Appendix A for details).
打开的消息发送到PCEP对等方后，发送方必须启动名为KeepWait的初始化计时器，在该计时器过期后，如果既没有收到Keepalive消息，也没有收到PCErr消息（如果会话特征不一致），则必须发送PCErr消息，并且必须释放TCP连接（详见附录A）。
The OpenWait and KeepWait timers have a fixed value of 1 minute.
OpenWait和KeepWait计时器的固定值为1分钟。
Upon the receipt of an Open message, the receiving PCEP peer MUST determine whether the suggested PCEP session characteristics are acceptable. If at least one of the characteristics is not acceptable to the receiving peer, it MUST send an Error message. The Error message SHOULD also contain the related OPEN object and, for each unacceptable session parameter, an acceptable parameter value SHOULD be proposed in the appropriate field of the OPEN object in place of the originally proposed value. The PCEP peer MAY decide to resend an Open message with different session characteristics. If a second Open message is received with the same set of parameters or with parameters that are still unacceptable, the receiving peer MUST send an Error message and it MUST immediately close the TCP connection. Details about error messages can be found in Section 7.15. Successive retries are permitted, but an implementation SHOULD make use of an exponential back-off session establishment retry procedure.
在接收到开放消息后，接收PCEP对等方必须确定建议的PCEP会话特征是否可接受。如果至少有一个特征不被接收对等方接受，则必须发送错误消息。错误消息还应包含相关的开放对象，对于每个不可接受的会话参数，应在开放对象的适当字段中建议一个可接受的参数值，以代替最初建议的值。PCEP对等方可以决定重新发送具有不同会话特征的开放消息。如果接收到第二条打开的消息时使用了相同的参数集或参数仍然不可接受，则接收端必须发送错误消息，并且必须立即关闭TCP连接。有关错误消息的详细信息，请参见第7.15节。允许连续重试，但实现应使用指数退避会话建立重试过程。
If the PCEP session characteristics are acceptable, the receiving PCEP peer MUST send a Keepalive message (defined in Section 6.3) that serves as an acknowledgment.
如果PCEP会话特征可接受，则接收PCEP对等方必须发送一条Keepalive消息（定义见第6.3节），作为确认。
The PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer.
一旦两个PCEP对等方都从其对等方接收到Keepalive消息，则认为PCEP会话已建立。
A Keepalive message is a PCEP message sent by a PCC or a PCE in order to keep the session in active state. The Keepalive message is also used in response to an Open message to acknowledge that an Open message has been received and that the PCEP session characteristics are acceptable. The Message-Type field of the PCEP common header for the Keepalive message is set to 2. The Keepalive message does not contain any object.
Keepalive消息是由PCC或PCE发送的PCEP消息，用于保持会话处于活动状态。Keepalive消息还用于响应打开的消息，以确认已接收到打开的消息，并且PCEP会话特征是可接受的。Keepalive消息的PCEP公共头的消息类型字段设置为2。Keepalive消息不包含任何对象。
PCEP has its own keepalive mechanism used to ensure the liveness of the PCEP session. This requires the determination of the frequency at which each PCEP peer sends Keepalive messages. Asymmetric values may be chosen; thus, there is no constraint mandating the use of identical keepalive frequencies by both PCEP peers. The DeadTimer is defined as the period of time after the expiration of which a PCEP peer declares the session down if no PCEP message has been received (Keepalive or any other PCEP message); thus, any PCEP message acts as a Keepalive message. Similarly, there are no constraints mandating the use of identical DeadTimers by both PCEP peers. The minimum Keepalive timer value is 1 second. Deployments SHOULD consider carefully the impact of using low values for the Keepalive timer as these might not give rise to the expected results in periods of temporary network instability.
PCEP有自己的keepalive机制，用于确保PCEP会话的活跃性。这需要确定每个PCEP对等方发送Keepalive消息的频率。可以选择不对称值；因此，没有约束要求两个PCEP对等方使用相同的保持频率。DeadTimer定义为PCEP对等方在未收到PCEP消息（Keepalive或任何其他PCEP消息）的情况下宣布会话关闭的时间段；因此，任何PCEP消息都充当Keepalive消息。同样，没有任何约束要求两个PCEP对等方使用相同的死区计时器。Keepalive计时器的最小值为1秒。部署应仔细考虑使用低值的KeaPoT定时器的影响，因为这些可能不会导致临时网络不稳定期间的预期结果。
Keepalive messages are sent at the frequency specified in the OPEN object carried within an Open message according to the rules specified in Section 7.3. Because any PCEP message may serve as Keepalive, an implementation may either decide to send Keepalive messages at fixed intervals regardless of whether other PCEP messages might have been sent since the last sent Keepalive message, or may decide to differ the sending of the next Keepalive message based on the time at which the last PCEP message (other than Keepalive) was sent.
根据第7.3节中规定的规则，Keepalive消息以开放消息中包含的开放对象中规定的频率发送。因为任何PCEP消息都可以用作Keepalive，所以实现可以决定以固定的间隔发送Keepalive消息，而不管自上次发送Keepalive消息以来是否已经发送了其他PCEP消息，或者可以决定根据上次PCEP消息发送的时间来区分下一个Keepalive消息的发送（Keepalive除外）已发送。
Note that sending Keepalive messages to keep the session alive is optional, and PCEP peers may decide not to send Keepalive messages once the PCEP session is established; in which case, the peer that does not receive Keepalive messages does not expect to receive them and MUST NOT declare the session as inactive.
注意，发送Keepalive消息以保持会话活动是可选的，一旦建立了PCEP会话，PCEP对等方可能会决定不发送Keepalive消息；在这种情况下，未接收Keepalive消息的对等方不希望接收它们，并且不得将会话声明为非活动。
The format of a Keepalive message is as follows:
Keepalive消息的格式如下所示：
<Keepalive Message>::= <Common Header>
<Keepalive Message>::= <Common Header>
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. The Message-Type field of the PCEP common header for the PCReq message is set to 3.
路径计算请求消息（也称为PCReq消息）是由PCC发送到PCE以请求路径计算的PCEP消息。PCReq消息可以承载多个路径计算请求。PCReq消息的PCEP公共头的消息类型字段设置为3。
There are two mandatory objects that MUST be included within a PCReq message: the RP and the END-POINTS objects (see Section 7). If one or both of these objects is missing, the receiving PCE MUST send an error message to the requesting PCC. Other objects are optional.
PCReq消息中必须包含两个强制对象：RP和端点对象（参见第7节）。如果其中一个或两个对象丢失，则接收PCE必须向请求PCC发送错误消息。其他对象是可选的。
The format of a PCReq message is as follows:
PCReq消息的格式如下所示：
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
哪里：
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where:
哪里：
<metric-list>::=<METRIC>[<metric-list>]
<metric-list>::=<METRIC>[<metric-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects are defined in Section 7. The special case of two BANDWIDTH objects is discussed in detail in Section 7.7.
第7节定义了SVEC、RP、端点、LSPA、带宽、度量、RRO、IRO和负载平衡对象。第7.7节详细讨论了两个带宽对象的特殊情况。
A PCEP implementation is free to process received requests in any order. For example, the requests may be processed in the order they are received, reordered and assigned priority according to local policy, reordered according to the priority encoded in the RP object (Section 7.4.1), or processed in parallel.
PCEP实现可以任意顺序处理收到的请求。例如，请求可以按照接收顺序进行处理，根据本地策略重新排序并分配优先级，根据RP对象中编码的优先级重新排序（第7.4.1节），或者并行处理。
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. The Message-Type field of the PCEP common header for the PCRep message is set to 4.
PCEP路径计算应答消息（也称为PCRep消息）是由PCE向请求PCC发送的PCEP消息，以响应先前接收到的PCReq消息。PCRep消息的PCEP公用标头的消息类型字段设置为4。
The bundling of multiple replies to a set of path computation requests within a single PCRep message is supported by PCEP. If a PCE receives non-synchronized path computation requests by means of one or more PCReq messages from a requesting PCC, it MAY decide to bundle the computed paths within a single PCRep message so as to reduce the control plane load. Note that the counter side of such an approach is the introduction of additional delays for some path computation requests of the set. Conversely, a PCE that receives multiple requests within the same PCReq message MAY decide to provide each computed path in separate PCRep messages or within the same PCRep message. A PCRep message may contain positive and negative replies.
PCEP支持在单个PCRep消息中捆绑对一组路径计算请求的多个响应。如果PCE通过来自请求PCC的一个或多个PCReq消息接收到非同步路径计算请求，则它可以决定将计算出的路径捆绑在单个PCRep消息中，以减少控制平面负载。注意，这种方法的反面是为集合的某些路径计算请求引入额外的延迟。相反，在同一PCReq消息中接收多个请求的PCE可以决定在单独的PCRep消息中或在同一PCRep消息中提供每个计算路径。PCRep消息可能包含肯定和否定回复。
A PCRep message may contain a set of computed paths corresponding to either a single path computation request with load-balancing (see Section 7.16) or multiple path computation requests originated by a requesting PCC. The PCRep message may also contain multiple acceptable paths corresponding to the same request.
PCRep消息可能包含一组计算路径，对应于具有负载平衡的单路径计算请求（参见第7.16节）或由请求PCC发起的多路径计算请求。PCRep消息还可以包含对应于同一请求的多个可接受路径。
The PCRep message MUST contain at least one RP object. For each reply that is bundled into a single PCReq message, an RP object MUST be included that contains a Request-ID-number identical to the one specified in the RP object carried in the corresponding PCReq message (see Section 7.4 for the definition of the RP object).
PCRep消息必须至少包含一个RP对象。对于捆绑到单个PCReq消息中的每个回复，必须包括一个RP对象，该对象包含与相应PCReq消息中RP对象中指定的请求ID号相同的请求ID号（RP对象的定义见第7.4节）。
If the path computation request can be satisfied (i.e., the PCE finds a set of paths that satisfy the set of constraints), the set of computed paths specified by means of Explicit Route Objects (EROs) is inserted in the PCRep message. The ERO is defined in Section 7.9. The situation where multiple computed paths are provided in a PCRep message is discussed in detail in Section 7.13. Furthermore, when a PCC requests the computation of a set of paths for a total amount of bandwidth by means of a LOAD-BALANCING object carried within a PCReq message, the ERO of each computed path may be followed by a BANDWIDTH object as discussed in section Section 7.16.
如果可以满足路径计算请求（即，PCE找到满足约束集的一组路径），则通过显式路由对象（ERO）指定的计算路径集将插入PCRep消息中。能源监管局的定义见第7.9节。第7.13节详细讨论了PCRep消息中提供多条计算路径的情况。此外，当PCC通过PCReq消息中携带的负载平衡对象请求计算总带宽的一组路径时，每个计算路径的ERO后面可能会有一个带宽对象，如第7.16节所述。
If the path computation request cannot be satisfied, the PCRep message MUST include a NO-PATH object. The NO-PATH object (described in Section 7.5) may also contain other information (e.g, reasons for the path computation failure).
如果无法满足路径计算请求，PCRep消息必须包含无路径对象。无路径对象（如第7.5节所述）也可能包含其他信息（例如，路径计算失败的原因）。
The format of a PCRep message is as follows:
PCRep消息的格式如下所示：
<PCRep Message> ::= <Common Header>
<response-list>
<PCRep Message> ::= <Common Header>
<response-list>
where:
哪里：
<response-list>::=<response>[<response-list>]
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
<path>::= <ERO><attribute-list>
where:
哪里：
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
<metric-list>::=<METRIC>[<metric-list>]
The PCEP Notification message (also referred to as the PCNtf message) can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify of a specific event. The Message-Type field of the PCEP common header for the PCNtf message is set to 5.
PCEP通知消息（也称为PCNtf消息）可由PCE发送至PCC，或由PCC发送至PCE，以通知特定事件。PCNtf消息的PCEP公共头的消息类型字段设置为5。
The PCNtf message MUST carry at least one NOTIFICATION object and MAY contain several NOTIFICATION objects should the PCE or the PCC intend to notify of multiple events. The NOTIFICATION object is defined in Section 7.14. The PCNtf message MAY also contain RP objects (see Section 7.4) when the notification refers to particular path computation requests.
PCNtf消息必须至少包含一个通知对象，如果PCE或PCC打算通知多个事件，则可能包含多个通知对象。第7.14节定义了通知对象。当通知涉及特定路径计算请求时，PCNtf消息也可能包含RP对象（见第7.4节）。
The PCNtf message may be sent by a PCC or a PCE in response to a request or in an unsolicited manner.
PCNtf消息可由PCC或PCE响应请求或以非请求方式发送。
The format of a PCNtf message is as follows:
PCNtf报文格式如下：
<PCNtf Message>::=<Common Header>
<notify-list>
<PCNtf Message>::=<Common Header>
<notify-list>
<notify-list>::=<notify> [<notify-list>]
<notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>]
<notification-list>
<notify>::= [<request-id-list>]
<notification-list>
<request-id-list>::=<RP>[<request-id-list>]
<request-id-list>::=<RP>[<request-id-list>]
<notification-list>::=<NOTIFICATION>[<notification-list>]
<notification-list>::=<NOTIFICATION>[<notification-list>]
The PCEP Error message (also referred to as a PCErr message) is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP specification (e.g., reception of a malformed message, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference). The Message-Type field of the PCEP common header for the PCErr message is set to 6.
PCEP错误消息（也称为PCErr消息）在以下几种情况下发送：满足协议错误条件或请求不符合PCEP规范（例如，接收格式不正确的消息、接收带有强制缺少对象的消息、策略冲突、意外消息、未知请求引用）。PCErr消息的PCEP公用标头的消息类型字段设置为6。
The PCErr message is sent by a PCC or a PCE in response to a request or in an unsolicited manner. If the PCErr message is sent in response to a request, the PCErr message MUST include the set of RP objects related to the pending path computation requests that triggered the error condition. In the latter case (unsolicited), no RP object is inserted in the PCErr message. For example, no RP object is inserted in a PCErr when the error condition occurred during the initialization phase. A PCErr message MUST contain a PCEP-ERROR object specifying the PCEP error condition. The PCEP-ERROR object is defined in Section 7.15.
PCErr消息由PCC或PCE响应请求或以未经请求的方式发送。如果PCErr消息是响应请求发送的，则PCErr消息必须包括与触发错误条件的挂起路径计算请求相关的RP对象集。在后一种情况下（未经请求），在PCErr消息中不插入RP对象。例如，在初始化阶段出现错误情况时，不会在PCErr中插入RP对象。PCErr消息必须包含指定PCEP错误条件的PCEP-ERROR对象。第7.15节定义了PCEP-ERROR对象。
The format of a PCErr message is as follows:
PCErr消息的格式如下所示：
<PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error>
[<error-list>]
<PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error>
[<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list>]
<error-obj-list>
<error>::=[<request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<request-id-list>::=<RP>[<request-id-list>]
<error-list>::=<error>[<error-list>]
<error-list>::=<error>[<error-list>]
The procedure upon the receipt of a PCErr message is defined in Section 7.15.
第7.15节规定了收到PCErr消息后的程序。
The Close message is a PCEP message that is either sent by a PCC to a PCE or by a PCE to a PCC in order to close an established PCEP session. The Message-Type field of the PCEP common header for the Close message is set to 7.
关闭消息是PCC发送给PCE或PCE发送给PCC的PCEP消息，以关闭已建立的PCEP会话。关闭消息的PCEP公用标头的消息类型字段设置为7。
The format of a Close message is as follows:
关闭消息的格式如下所示：
<Close Message>::= <Common Header>
<CLOSE>
<Close Message>::= <Common Header>
<CLOSE>
The Close message MUST contain exactly one CLOSE object (see Section 6.8). If more than one CLOSE object is present, the first MUST be processed and subsequent objects ignored.
关闭消息必须仅包含一个关闭对象（见第6.8节）。如果存在多个闭合对象，则必须处理第一个对象，并忽略后续对象。
Upon the receipt of a valid Close message, the receiving PCEP peer MUST cancel all pending requests, it MUST close the TCP connection and MUST NOT send any further PCEP messages on the PCEP session.
收到有效的关闭消息后，接收PCEP对等方必须取消所有挂起的请求，必须关闭TCP连接，并且不得在PCEP会话上发送任何进一步的PCEP消息。
A PCEP implementation that receives an unrecognized PCEP message MUST send a PCErr message with Error-value=2 (capability not supported).
接收无法识别的PCEP消息的PCEP实现必须发送错误值为2的PCErr消息（功能不受支持）。
If a PCC/PCE receives unrecognized messages at a rate equal or greater than MAX-UNKNOWN-MESSAGES unknown message requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message". A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session.
如果PCC/PCE接收未识别消息的速率等于或大于每分钟MAX-UNKNOWN-messages UNKNOWN message requests，则PCC/PCE必须发送一条PCEP CLOSE消息，其CLOSE值为=“接收不可接受数量的未知PCEP消息”。MAX-UNKNOWN-MESSAGES的建议值为5。PCC/PCE必须关闭TCP会话，并且不得在PCEP会话上发送任何进一步的PCEP消息。
PCEP objects have a common format. They begin with a common object header (see Section 7.2). This is followed by object-specific fields defined for each different object. The object may also include one or more type-length-value (TLV) encoded data sets. Each TLV has the same structure as described in Section 7.1.
PCEP对象具有通用格式。它们以公共对象标题开始（参见第7.2节）。然后是为每个不同对象定义的特定于对象的字段。对象还可以包括一个或多个类型长度值（TLV）编码数据集。每个TLV具有第7.1节所述的相同结构。
A PCEP object may include a set of one or more optional TLVs.
PCEP对象可包括一组或多个可选TLV。
All PCEP TLVs have the following format:
所有PCEP TLV具有以下格式：
Type: 2 bytes Length: 2 bytes Value: variable
类型：2字节长度：2字节值：变量
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field.
PCEP对象TLV由类型的2个字节、指定TLV长度的2个字节和一个值字段组成。
The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes).
长度字段以字节为单位定义值部分的长度。TLV填充为4字节对齐；长度字段中不包括填充（因此3字节值的长度为3，但TLV的总大小为8字节）。
Unrecognized TLVs MUST be ignored.
必须忽略无法识别的TLV。
IANA management of the PCEP Object TLV type identifier codespace is described in Section 9.
第9节描述了PCEP对象TLV类型标识符代码空间的IANA管理。
A PCEP object carried within a PCEP message consists of one or more 32-bit words with a common header that has the following format:
PCEP消息中携带的PCEP对象由一个或多个32位字组成，这些字具有以下格式的公共标头：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: PCEP Common Object Header
图8:PCEP公共对象头
Object-Class (8 bits): identifies the PCEP object class.
对象类（8位）：标识PCEP对象类。
OT (Object-Type - 4 bits): identifies the PCEP object type.
OT（对象类型-4位）：标识PCEP对象类型。
The Object-Class and Object-Type fields are managed by IANA.
对象类和对象类型字段由IANA管理。
The Object-Class and Object-Type fields uniquely identify each PCEP object.
对象类和对象类型字段唯一标识每个PCEP对象。
Res flags (2 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Res标志（2位）：保留字段。此字段在传输时必须设置为零，在接收时必须忽略。
P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify in a PCReq message sent to a PCE whether the object must be taken into account by the PCE during path computation or is just optional. When the P flag is set, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE is free to ignore it.
P标志（处理规则-1位）：P标志允许PCC在发送给PCE的PCReq消息中指定PCE在路径计算期间是否必须考虑该对象，或者只是可选的。设置P标志时，PCE必须考虑对象。相反，当清除P标志时，对象是可选的，PCE可以随意忽略它。
I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep message to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its reply and set the I flag to indicate that the optional object was ignored during path computation. When the I flag is cleared, the PCE indicates that the optional object was processed during the path computation. The setting of the I flag for optional objects is purely indicative and optional. The I flag has no meaning in a PCRep message when the P flag has been set in the corresponding PCReq message.
I标志（忽略-1位）：PCE在PCRep消息中使用I标志向PCC指示是否处理了可选对象。PCE可以在其应答中包括被忽略的可选对象，并设置I标志以指示在路径计算期间忽略了可选对象。清除I标志时，PCE表示在路径计算期间处理了可选对象。可选对象的I标志的设置纯粹是指示性的和可选的。当在相应的PCReq消息中设置了P标志时，I标志在PCRep消息中没有意义。
If the PCE does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object" along with the corresponding RP object. Note that if a PCReq includes multiple requests, only requests for which an object with the P flag set is unknown/unrecognized MUST be rejected.
如果PCE不理解设置了P标志的对象，或者不理解该对象，但决定忽略该对象，则必须拒绝整个PCEP消息，并且PCE必须发送一条PCErr消息，其中包含错误类型=“未知对象”或“不支持对象”以及相应的RP对象。请注意，如果PCReq包含多个请求，则只有设置了P标志的对象未知/无法识别的请求才能被拒绝。
Object Length (16 bits): Specifies the total object length including the header, in bytes. The Object Length field MUST always be a multiple of 4, and at least 4. The maximum object content length is 65528 bytes.
对象长度（16位）：指定包括标头在内的对象总长度（以字节为单位）。“对象长度”字段必须始终为4的倍数，且至少为4。最大对象内容长度为65528字节。
The OPEN object MUST be present in each Open message and MAY be present in a PCErr message. There MUST be only one OPEN object per Open or PCErr message.
打开的对象必须出现在每个打开的消息中，并且可能出现在PCErr消息中。每个OPEN或PCErr消息只能有一个OPEN对象。
The OPEN object contains a set of fields used to specify the PCEP version, Keepalive frequency, DeadTimer, and PCEP session ID, along with various flags. The OPEN object may also contain a set of TLVs used to convey various session characteristics such as the detailed PCE capabilities, policy rules, and so on. No TLVs are currently defined.
OPEN对象包含一组字段，用于指定PCEP版本、Keepalive频率、DeadTimer和PCEP会话ID，以及各种标志。开放对象还可以包含一组tlv，用于传递各种会话特征，例如详细的PCE功能、策略规则等。目前没有定义TLV。
OPEN Object-Class is 1.
开放对象类是1。
OPEN Object-Type is 1.
打开的对象类型为1。
The format of the OPEN object body is as follows:
开放对象主体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object Format
图9：开放对象格式
Ver (3 bits): PCEP version. Current version is 1.
版本（3位）：PCEP版本。当前版本为1。
Flags (5 bits): No flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
标志（5位）：当前未定义标志。未分配的位被视为保留位。它们在传输时必须设置为零，在接收时必须忽略。
Keepalive (8 bits): maximum period of time (in seconds) between two consecutive PCEP messages sent by the sender of this message. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the keepalive frequency is 30 seconds.
Keepalive（8位）：此消息的发送方发送的两条连续PCEP消息之间的最长时间（以秒为单位）。Keepalive的最小值为1秒。当设置为0时，一旦建立会话，就不会再向远程对等方发送Keepalive消息。keepalive频率的建议值为30秒。
DeadTimer (8 bits): specifies the amount of time after the expiration of which the PCEP peer can declare the session with the sender of the Open message to be down if no PCEP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive.
DeadTimer（8位）：指定到期后的时间量，如果没有收到PCEP消息，PCEP对等方可以在该时间量到期后将与打开消息的发送方的会话声明为关闭。DeadTimer应设置为0，如果Keepalive设置为0，则必须忽略它。DeadTimer的建议值是Keepalive值的4倍。
Example:
例子：
A sends an Open message to B with Keepalive=10 seconds and DeadTimer=40 seconds. This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40-second period.
A向B发送一条打开的消息，Keepalive=10秒，DeadTimer=40秒。这意味着A每10秒向B发送一次Keepalive消息（或任何其他PCEP消息），如果在任何40秒内没有从A接收到PCEP消息，B可以通过A声明PCEP会话。
SID (PCEP session ID - 8 bits): unsigned PCEP session number that identifies the current session. The SID MUST be incremented each time a new PCEP session is established. It is used for logging and troubleshooting purposes. Each increment SHOULD have a value of 1 and may cause a wrap back to zero.
SID（PCEP会话ID-8位）：标识当前会话的无符号PCEP会话号。每次建立新的PCEP会话时，SID必须增加。它用于日志记录和故障排除。每个增量的值应为1，并可能导致回折为零。
The SID is used to disambiguate instances of sessions to the same peer. A PCEP implementation could use a single source of SIDs across all peers, or one source for each peer. The former might constrain the implementation to only 256 concurrent sessions. The latter potentially requires more states. There is one SID number in each direction.
SID用于消除同一对等方会话实例的歧义。PCEP实施可以在所有对等方使用单一的SID源，或者每个对等方使用一个SID源。前者可能将实现限制为仅256个并发会话。后者可能需要更多的国家。每个方向都有一个SID号。
Optional TLVs may be included within the OPEN object body to specify PCC or PCE characteristics. The specification of such TLVs is outside the scope of this document.
可选TLV可包括在开放对象体内，以指定PCC或PCE特性。此类TLV的规范不在本文件范围内。
When present in an Open message, the OPEN object specifies the proposed PCEP session characteristics. Upon receiving unacceptable PCEP session characteristics during the PCEP session initialization phase, the receiving PCEP peer (PCE) MAY include an OPEN object within the PCErr message so as to propose alternative acceptable session characteristic values.
当存在于开放消息中时，开放对象指定建议的PCEP会话特征。当在PCEP会话初始化阶段期间接收到不可接受的PCEP会话特征时，接收PCEP对等方（PCE）可以在PCErr消息中包括开放对象，以便提出替代的可接受会话特征值。
The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. The RP object is used to specify various characteristics of the path computation request.
RP（请求参数）对象必须包含在每个PCReq和PCRep消息中，并且可以包含在PCNtf和PCErr消息中。RP对象用于指定路径计算请求的各种特征。
The P flag of the RP object MUST be set in PCReq and PCRep messages and MUST be cleared in PCNtf and PCErr messages. If the RP object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification.
RP对象的P标志必须在PCReq和PCRep消息中设置，并且必须在PCNtf和PCErr消息中清除。如果接收RP对象时根据上述规则错误地设置了P标志，则接收对等方必须发送错误类型为10且错误值为1的PCErr消息。PCE必须取消相应的路径计算请求，无需进一步通知。
RP Object-Class is 2.
RP对象类为2。
RP Object-Type is 1.
RP对象类型为1。
The format of the RP object body is as follows:
RP对象体的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP Object Body Format
图10:RP对象体格式
The RP object body has a variable length and may contain additional TLVs. No TLVs are currently defined.
RP对象主体具有可变长度，并且可能包含其他TLV。目前没有定义TLV。
Flags (32 bits)
标志（32位）
The following flags are currently defined:
当前定义了以下标志：
o Pri (Priority - 3 bits): the Priority field may be used by the requesting PCC to specify to the PCE the request's priority from 1 to 7. The decision of which priority should be used for a specific request is a local matter; it MUST be set to 0 when unused. Furthermore, the use of the path computation request priority by the PCE's scheduler is implementation specific and out of the scope of this document. Note that it is not required for a PCE to support the priority field: in this case, it is RECOMMENDED that the PCC set the priority field to 0 in the RP object. If the PCE does not take into account the request priority, it is RECOMMENDED to set the priority field to 0 in the RP object carried within the corresponding PCRep message, regardless of the priority value contained in the RP object carried within the corresponding PCReq message. A higher numerical value of the priority field reflects a higher priority. Note that it is the responsibility of the network administrator to make use of the priority values in a consistent manner across the various PCCs. The ability of a PCE to support request prioritization MAY be dynamically discovered by the PCCs by means of PCE capability discovery. If not advertised by the PCE, a PCC may decide to set the request priority and will learn the ability of the PCE to support request prioritization by observing the Priority field of the RP object received in the PCRep message. If the value of the Pri field is set to 0, this means that the PCE does not support
o Pri（优先级-3位）：优先级字段可由请求PCC用于向PCE指定从1到7的请求优先级。具体请求应使用哪种优先权的决定是当地事务；未使用时，必须将其设置为0。此外，PCE调度器对路径计算请求优先级的使用是特定于实现的，不在本文档的范围内。请注意，PCE不需要支持优先级字段：在这种情况下，建议PCC在RP对象中将优先级字段设置为0。如果PCE未考虑请求优先级，建议将相应PCRep消息中携带的RP对象中的优先级字段设置为0，而不考虑相应PCReq消息中携带的RP对象中包含的优先级值。优先级字段的数值越高，表示优先级越高。请注意，网络管理员有责任在各个PCC中以一致的方式使用优先级值。PCC可通过PCE能力发现动态发现PCE支持请求优先级的能力。如果PCE未公布，PCC可决定设置请求优先级，并将通过观察PCRep消息中接收到的RP对象的优先级字段来了解PCE支持请求优先级排序的能力。如果Pri字段的值设置为0，则表示PCE不支持
the handling of request priorities: in other words, the path computation request has been honored but without taking the request priority into account.
请求优先级的处理：换句话说，路径计算请求已得到满足，但没有考虑请求优先级。
o R (Reoptimization - 1 bit): when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP. For all TE LSPs except zero-bandwidth LSPs, when the R bit is set, an RRO (see Section 7.10) MUST be included in the PCReq message to show the path of the existing TE LSP. Also, for all TE LSPs except zero-bandwidth LSPs, when the R bit is set, the existing bandwidth of the TE LSP to be reoptimized MUST be supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH object is in addition to the instance of that object used to describe the desired bandwidth of the reoptimized LSP. For zero-bandwidth LSPs, the RRO and BANDWIDTH objects that report the characteristics of the existing TE LSP are optional.
o R（重新优化-1位）：设置时，请求PCC指定PCReq消息与现有TE LSP的重新优化相关。对于除零带宽LSP以外的所有TE LSP，当设置R位时，PCReq消息中必须包含一个RRO（见第7.10节），以显示现有TE LSP的路径。此外，对于除零带宽LSP之外的所有TE LSP，当设置R位时，必须在带宽对象中提供要重新优化的TE LSP的现有带宽（参见第7.7节）。此带宽对象是该对象实例的补充，该对象用于描述重新优化的LSP的所需带宽。对于零带宽LSP，报告现有TE LSP特性的RRO和带宽对象是可选的。
o B (Bi-directional - 1 bit): when set, the PCC specifies that the path computation request relates to a bi-directional TE LSP that has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, TE links, and resource requirements (e.g., latency and jitter) in each direction. When cleared, the TE LSP is unidirectional.
o B（双向-1位）：设置时，PCC指定路径计算请求与双向TE LSP相关，双向TE LSP具有相同的流量工程要求，包括命运共享、保护和恢复、LSR、TE链路和每个方向的资源要求（例如，延迟和抖动）。清除时，TE LSP是单向的。
o O (strict/loose - 1 bit): when set, in a PCReq message, this indicates that a loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that a path exclusively made of strict hops is required. In a PCRep message, when the O bit is set this indicates that the returned path is a loose path; otherwise (when the O bit is cleared), the returned path is made of strict hops.
o O（严格/松散-1位）：设置时，在PCReq消息中，这表示松散路径是可接受的。否则，当清除时，这向PCE指示需要专门由严格跃点构成的路径。在PCRep消息中，当设置O位时，这表示返回的路径是松散路径；否则（当O位被清除时），返回的路径由严格的跃点组成。
Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
未分配的位被认为是保留的。它们在传输时必须设置为零，在接收时必须忽略。
Request-ID-number (32 bits): The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely identify the path computation request context. The Request-ID-number is used for disambiguation between pending requests, and thus it MUST be changed (such as by incrementing it) each time a new request is sent to the PCE, and may wrap.
请求ID号（32位）：请求ID号值与PCC的源IP地址和PCE地址相结合，唯一标识路径计算请求上下文。请求ID号用于消除未决请求之间的歧义，因此每次向PCE发送新请求时都必须更改（例如通过增加ID号），并且可能会自动换行。
The value 0x00000000 is considered invalid.
值0x00000000被视为无效。
If no path computation reply is received from the PCE (e.g., the request is dropped by the PCE because of memory overflow), and the PCC wishes to resend its request, the same Request-ID-number MUST be used. Upon receiving a path computation request from a PCC
如果没有从PCE接收到路径计算回复（例如，PCE由于内存溢出而丢弃请求），并且PCC希望重新发送其请求，则必须使用相同的请求ID号。在接收到来自PCC的路径计算请求时
with the same Request-ID-number, the PCE SHOULD treat the request as a new request. An implementation MAY choose to cache path computation replies in order to quickly handle retransmission without having to process a path computation request twice (in the case that the first request was dropped or lost). Upon receiving a path computation reply from a PCE with the same Request-ID-number, the PCC SHOULD silently discard the path computation reply.
对于相同的请求ID号，PCE应将该请求视为新请求。实现可以选择缓存路径计算应答，以便快速处理重传，而不必两次处理路径计算请求（在第一个请求被丢弃或丢失的情况下）。当从具有相同请求ID号的PCE接收到路径计算应答时，PCC应默默地丢弃该路径计算应答。
Conversely, different Request-ID-numbers MUST be used for different requests sent to a PCE.
相反，对于发送到PCE的不同请求，必须使用不同的请求ID号。
The same Request-ID-number MAY be used for path computation requests sent to different PCEs. The path computation reply is unambiguously identified by the IP source address of the replying PCE.
相同的请求ID号可用于发送到不同pce的路径计算请求。路径计算应答由应答PCE的IP源地址明确标识。
If a PCReq message is received that does not contain an RP object, the PCE MUST send a PCErr message to the requesting PCC with Error-Type="Required Object missing" and Error-value="RP Object missing".
如果收到的PCReq消息不包含RP对象，则PCE必须向请求PCC发送一条PCErr消息，错误类型为“Required object missing”，错误值为“RP object missing”。
If the O bit of the RP message carried within a PCReq message is cleared and local policy has been configured on the PCE to not provide explicit paths (for instance, for confidentiality reasons), a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-Type is "Policy Violation" and Error-value is "O bit cleared".
如果PCReq消息中携带的RP消息的O位被清除，并且PCE上的本地策略被配置为不提供显式路径（例如，出于保密原因），则PCE必须向请求PCC发送PCErr消息，并且必须丢弃挂起的路径计算请求。错误类型为“策略冲突”，错误值为“O位清除”。
When the R bit of the RP object is set in a PCReq message, this indicates that the path computation request relates to the reoptimization of an existing TE LSP. In this case, the PCC MUST also provide the strict/loose path by including an RRO object in the PCReq message so as to avoid/limit double-bandwidth counting if and only if the TE LSP is a non-zero-bandwidth TE LSP. If the PCC has not requested a strict path (O bit set), a reoptimization can still be requested by the PCC, but this requires that the PCE either be stateful (keep track of the previously computed path with the associated list of strict hops), or have the ability to retrieve the complete required path segment. Alternatively, the PCC MUST inform the PCE about the working path and the associated list of strict hops in PCReq. The absence of an RRO in the PCReq message for a non-zero-bandwidth TE LSP (when the R bit of the RP object is set) MUST trigger the sending of a PCErr message with Error-Type="Required Object Missing" and Error-value="RRO Object missing for reoptimization".
当RP对象的R位在PCReq消息中设置时，这表示路径计算请求与现有TE LSP的重新优化有关。在这种情况下，PCC还必须通过在PCReq消息中包括RRO对象来提供严格/松散路径，以避免/限制当且仅当TE LSP是非零带宽TE LSP时的双重带宽计数。如果PCC没有请求严格路径（O位集），PCC仍然可以请求重新优化，但这要求PCE要么是有状态的（用严格跳的相关列表跟踪先前计算的路径），要么能够检索完整的所需路径段。或者，PCC必须通知PCE PCReq中的工作路径和相关严格跃点列表。非零带宽TE LSP的PCReq消息中缺少RRO（当设置RP对象的R位时）必须触发PCErr消息的发送，错误类型为“Required object Missing”，错误值为“RRO object Missing for reoptimization”。
If a PCC/PCE receives a PCRep/PCReq message that contains an RP object referring to an unknown Request-ID-number, the PCC/PCE MUST send a PCErr message with Error-Type="Unknown request reference". This is used for debugging purposes. If a PCC/PCE receives PCRep/ PCReq messages with unknown requests at a rate equal or greater than MAX-UNKNOWN-REQUESTS unknown requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown requests/replies". A RECOMMENDED value for MAX-UNKNOWN-REQUESTS is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session.
如果PCC/PCE接收到包含引用未知请求ID号的RP对象的PCRep/PCReq消息，则PCC/PCE必须发送错误类型为“未知请求引用”的PCErr消息。这用于调试目的。如果PCC/PCE以每分钟等于或大于MAX-unknown-requests unknown-requests unknown requests的速率接收到带有未知请求的PCRep/PCReq消息，则PCC/PCE必须发送一条PCEP CLOSE消息，该消息的CLOSE值为=“接收不可接受数量的未知请求/回复”。MAX-UNKNOWN-REQUESTS的建议值为5。PCC/PCE必须关闭TCP会话，并且不得在PCEP会话上发送任何进一步的PCEP消息。
The reception of a PCEP message that contains an RP object referring to a Request-ID-number=0x00000000 MUST be treated in similar manner as an unknown request.
接收包含引用请求ID号=0x00000000的RP对象的PCEP消息时，必须以与未知请求类似的方式处理。
The NO-PATH object is used in PCRep messages in response to an unsuccessful path computation request (the PCE could not find a path satisfying the set of constraints). When a PCE cannot find a path satisfying a set of constraints, it MUST include a NO-PATH object in the PCRep message.
无路径对象用于PCRep消息中，以响应不成功的路径计算请求（PCE无法找到满足约束集的路径）。当PCE找不到满足一组约束的路径时，它必须在PCRep消息中包含无路径对象。
There are several categories of issue that can lead to a negative reply. For example, the PCE chain might be broken (should there be more than one PCE involved in the path computation) or no path obeying the set constraints could be found. The "NI (Nature of Issue)" field in the NO-PATH object is used to report the error category.
有几类问题可能导致否定回答。例如，PCE链可能会断开（如果路径计算涉及多个PCE），或者找不到符合设置约束的路径。NO-PATH对象中的“NI（问题性质）”字段用于报告错误类别。
Optionally, if the PCE supports such capability, the NO-PATH object MAY contain an optional NO-PATH-VECTOR TLV defined below and used to provide more information on the reasons that led to a negative reply. The PCRep message MAY also contain a list of objects that specify the set of constraints that could not be satisfied. The PCE MAY just replicate the set of objects that was received that was the cause of the unsuccessful computation or MAY optionally report a suggested value for which a path could have been found (in which case, the value differs from the value in the original request).
可选地，如果PCE支持这种能力，则NO-PATH对象可以包含下面定义的可选NO-PATH-VECTOR TLV，并用于提供关于导致否定回答的原因的更多信息。PCRep消息还可能包含指定无法满足的约束集的对象列表。PCE可以只复制接收到的导致计算失败的对象集，或者可以选择性地报告可能已找到路径的建议值（在这种情况下，该值不同于原始请求中的值）。
NO-PATH Object-Class is 3.
无路径对象类为3。
NO-PATH Object-Type is 1.
无路径对象类型为1。
The format of the NO-PATH object body is as follows:
无路径对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH Object Format
图11：无路径对象格式
NI - Nature of Issue (8 bits): The NI field is used to report the nature of the issue that led to a negative reply. Two values are currently defined:
NI-问题的性质（8位）：NI字段用于报告导致否定回答的问题的性质。目前定义了两个值：
0: No path satisfying the set of constraints could be found
0:找不到满足约束集的路径
1: PCE chain broken
1:PCE链条断裂
The Nature of Issue field value can be used by the PCC for various purposes:
PCC可将问题字段值的性质用于各种用途：
* Constraint adjustment before reissuing a new path computation request,
* 重新发出新路径计算请求之前的约束调整，
* Explicit selection of a new PCE chain,
* 明确选择新的PCE链，
* Logging of the error type for further action by the network administrator.
* 记录错误类型以供网络管理员进一步操作。
IANA management of the NI field codespace is described in Section 9.
第9节描述了NI字段代码空间的IANA管理。
Flags (16 bits).
标志（16位）。
The following flag is currently defined:
当前定义了以下标志：
o C flag (1 bit): when set, the PCE indicates the set of unsatisfied constraints (reasons why a path could not be found) in the PCRep message by including the relevant PCEP objects. When cleared, no failing constraints are specified. The C flag has no meaning and is ignored unless the NI field is set to 0x00.
o C标志（1位）：设置时，PCE通过包括相关PCEP对象，指示PCRep消息中未满足的约束集（无法找到路径的原因）。清除此选项后，不会指定失败的约束。除非NI字段设置为0x00，否则C标志没有任何意义，将被忽略。
Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
未分配的位被视为保留位。它们在传输时必须设置为零，在接收时必须忽略。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（8位）：此字段在传输时必须设置为零，在接收时必须忽略。
The NO-PATH object body has a variable length and may contain additional TLVs. The only TLV currently defined is the NO-PATH-VECTOR TLV defined below.
无路径对象主体具有可变长度，并且可能包含其他TLV。当前唯一定义的TLV是下面定义的无路径向量TLV。
Example: consider the case of a PCC that sends a path computation request to a PCE for a TE LSP of X Mbit/s. Suppose that PCE cannot find a path for X Mbit/s. In this case, the PCE must include in the PCRep message a NO-PATH object. Optionally, the PCE may also include the original BANDWIDTH object so as to indicate that the reason for the unsuccessful computation is the bandwidth constraint (in this case, the NI field value is 0x00 and C flag is set). If the PCE supports such capability, it may alternatively include the BANDWIDTH object and report a value of Y in the bandwidth field of the BANDWIDTH object (in this case, the C flag is set) where Y refers to the bandwidth for which a TE LSP with the same other characteristics (such as Setup/Holding priorities, TE LSP attribute, local protection, etc.) could have been computed.
示例：考虑PCC的情况，该PCC向PCE发送路径计算请求，用于X Mbit／s的TLSP。假设PCE找不到X Mbit/s的路径。在这种情况下，PCE必须在PCRep消息中包含无路径对象。可选地，PCE还可以包括原始带宽对象，以便指示计算失败的原因是带宽约束（在这种情况下，NI字段值为0x00，并且设置了C标志）。如果PCE支持这种能力，则它可以可选地包括带宽对象，并在带宽对象的带宽字段中报告Y的值（在这种情况下，设置了C标志），其中Y表示具有相同其他特性的TE LSP的带宽（如设置/保持优先级、TE LSP属性、本地保护等）可以计算。
When the NO-PATH object is absent from a PCRep message, the path computation request has been fully satisfied and the corresponding paths are provided in the PCRep message.
当PCRep消息中不存在NO-PATH对象时，路径计算请求已完全满足，并且在PCRep消息中提供了相应的路径。
An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH object in order to provide more information on the reasons that led to a negative reply.
NO-PATH对象中可能包括一个名为NO-PATH-VECTOR的可选TLV，以便提供更多关于导致否定回答的原因的信息。
The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes) followed by a fixed-length 32-bit flags field.
无路径向量TLV符合第7.1节中定义的PCEP TLV格式，由类型的2个字节组成，2个字节指定TLV长度（值部分的长度以字节为单位），后跟固定长度的32位标志字段。
Type: 1 Length: 4 bytes Value: 32-bit flags field
类型：1长度：4字节值：32位标志字段
IANA manages the space of flags carried in the NO-PATH-VECTOR TLV (see Section 9).
IANA管理无路径向量TLV中携带的标志空间（见第9节）。
The following flags are currently defined:
当前定义了以下标志：
o Bit number: 31 - PCE currently unavailable
o 位号：31-PCE当前不可用
o Bit number: 30 - Unknown destination
o 位号：30-未知目的地
o Bit number: 29 - Unknown source
o 位号：29-未知源
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. The P flag of the END-POINTS object MUST be set. If the END-POINTS object is received with the P flag cleared, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification.
端点对象在PCReq消息中用于指定请求路径计算的路径的源IP地址和目标IP地址。必须设置端点对象的P标志。如果在清除P标志的情况下接收端点对象，则接收对等方必须发送错误类型为10且错误值为1的PCErr消息。PCE必须取消相应的路径计算请求，无需进一步通知。
Note that the source and destination addresses specified in the END-POINTS object may correspond to the source and destination IP address of the TE LSP or to those of a path segment. Two END-POINTS objects (for IPv4 and IPv6) are defined.
注意，端点对象中指定的源和目的地地址可能对应于TE LSP的源和目的地IP地址或路径段的源和目的地IP地址。定义了两个端点对象（IPv4和IPv6）。
END-POINTS Object-Class is 4.
端点对象类为4。
END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6.
端点对象类型对于IPv4为1，对于IPv6为2。
The format of the END-POINTS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: END-POINTS Object Body Format for IPv4
图12:IPv4的端点对象体格式
The format of the END-POINTS object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: END-POINTS Object Body Format for IPv6
图13:IPv6的端点对象体格式
The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 32 bytes for IPv6.
端点对象主体的固定长度为IPv4的8字节和IPv6的32字节。
If more than one END-POINTS object is present, the first MUST be processed and subsequent objects ignored.
如果存在多个端点对象，则必须处理第一个端点对象，并忽略后续对象。
The BANDWIDTH object is used to specify the requested bandwidth for a TE LSP. The notion of bandwidth is similar to the one used for RSVP signaling in [RFC2205], [RFC3209], and [RFC3473].
带宽对象用于指定TE LSP的请求带宽。带宽的概念类似于[RFC2205]、[RFC3209]和[RFC3473]中用于RSVP信令的概念。
If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is not equal to 0, the PCReq message MUST contain a BANDWIDTH object.
如果请求的带宽等于0，则带宽对象是可选的。相反，如果请求的带宽不等于0，则PCReq消息必须包含带宽对象。
In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type values are defined that refer to the requested bandwidth and the bandwidth of the TE LSP for which a reoptimization is being performed.
在TE-LSP的重新优化的情况下，当且仅当两个值不同时，除了请求的带宽之外，还必须包括现有TE-LSP的带宽。因此，定义了两个对象类型值，它们参考所请求的带宽和正在对其执行再优化的TE LSP的带宽。
The BANDWIDTH object may be carried within PCReq and PCRep messages.
带宽对象可以在PCReq和PCRep消息中携带。
BANDWIDTH Object-Class is 5.
带宽对象类为5。
Two Object-Type values are defined for the BANDWIDTH object:
为带宽对象定义了两个对象类型值：
o Requested bandwidth: BANDWIDTH Object-Type is 1.
o 请求的带宽：带宽对象类型为1。
o Bandwidth of an existing TE LSP for which a reoptimization is requested. BANDWIDTH Object-Type is 2.
o 请求重新优化的现有TE LSP的带宽。带宽对象类型为2。
The format of the BANDWIDTH object body is as follows:
带宽对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: BANDWIDTH Object Body Format
图14：带宽对象体格式
Bandwidth (32 bits): The requested bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values.
带宽（32位）：请求的带宽以32位的IEEE浮点格式编码（参见[IEEE.754.1985]），以字节/秒表示。有关常用值表，请参阅[RFC3471]第3.1.2节。
The BANDWIDTH object body has a fixed length of 4 bytes.
带宽对象主体的固定长度为4字节。
The METRIC object is optional and can be used for several purposes.
公制对象是可选的，可用于多种用途。
In a PCReq message, a PCC MAY insert one or more METRIC objects:
在PCReq消息中，PCC可以插入一个或多个度量对象：
o To indicate the metric that MUST be optimized by the path computation algorithm (IGP metric, TE metric, hop counts). Currently, three metrics are defined: the IGP cost, the TE metric (see [RFC3785]), and the number of hops traversed by a TE LSP.
o 指示必须通过路径计算算法优化的度量（IGP度量、TE度量、跳数）。目前，定义了三个指标：IGP成本、TE指标（请参见[RFC3785]）和TE LSP通过的跃点数。
o To indicate a bound on the path cost that MUST NOT be exceeded for the path to be considered as acceptable by the PCC.
o 指示路径成本的界限，该界限不得超过PCC认为可接受的路径的界限。
In a PCRep message, the METRIC object MAY be inserted so as to provide the cost for the computed path. It MAY also be inserted within a PCRep with the NO-PATH object to indicate that the metric constraint could not be satisfied.
在PCRep消息中，可以插入度量对象以提供计算路径的成本。也可以将其插入到带有NO-PATH对象的PCRep中，以指示无法满足度量约束。
The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document.
PCE用于针对特定度量优化路径的路径计算算法方面超出了本文档的范围。
It must be understood that such path metrics are only meaningful if used consistently: for instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, consistent ways of defining the delay must be used.
必须理解，此类路径度量只有在一致使用时才有意义：例如，如果计算路径段的延迟在驻留在不同域中的两个pce之间交换，则必须使用一致的定义延迟的方法。
The absence of the METRIC object MUST be interpreted by the PCE as a path computation request for which no constraints need be applied to any of the metrics.
PCE必须将缺少度量对象解释为无需对任何度量应用约束的路径计算请求。
METRIC Object-Class is 6.
度量对象类是6。
METRIC Object-Type is 1.
度量对象类型为1。
The format of the METRIC object body is as follows:
公制对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: METRIC Object Body Format
图15：公制对象体格式
The METRIC object body has a fixed length of 8 bytes.
度量对象主体的固定长度为8字节。
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（16位）：此字段在传输时必须设置为零，在接收时必须忽略。
T (Type - 8 bits): Specifies the metric type.
T（类型-8位）：指定度量类型。
Three values are currently defined:
* T=1: IGP metric
* T=2: TE metric
* T=3: Hop Counts
Three values are currently defined:
* T=1: IGP metric
* T=2: TE metric
* T=3: Hop Counts
Flags (8 bits): Two flags are currently defined:
标志（8位）：当前定义了两个标志：
* B (Bound - 1 bit): When set in a PCReq message, the metric-value indicates a bound (a maximum) for the path metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path metric must be less than or equal to the value specified in the metric-value field. When the B flag is cleared, the metric-value field is not used to reflect a bound constraint.
* B（绑定- 1位）：当在PCReq消息中设置时，度量值指示对于PCC而言，路径度量的绑定（最大值），以考虑所计算的路径为可接受的。路径度量必须小于或等于“度量值”字段中指定的值。清除B标志时，度量值字段不用于反映绑定约束。
* C (Computed Metric - 1 bit): When set in a PCReq message, this indicates that the PCE MUST provide the computed path metric value (should a path satisfying the constraints be found) in the PCRep message for the corresponding metric.
* C（计算度量-1位）：当在PCReq消息中设置时，这表示PCE必须在PCRep消息中为相应度量提供计算路径度量值（如果找到满足约束的路径）。
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
未分配标志在传输时必须设置为零，在接收时必须忽略。
Metric-value (32 bits): metric value encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]).
度量值（32位）：以IEEE浮点格式以32位编码的度量值（见[IEEE.754.1985]）。
Multiple METRIC objects MAY be inserted in a PCRep or a PCReq message for a given request (i.e., for a given RP). For a given request, there MUST be at most one instance of the METRIC object for each metric type with the same B flag value. If, for a given request, two or more instances of a METRIC object with the same B flag value are present for a metric type, only the first instance MUST be considered and other instances MUST be ignored.
对于给定的请求（即，对于给定的RP），可以在PCRep或PCReq消息中插入多个度量对象。对于给定的请求，对于具有相同B标志值的每个度量类型，必须最多有一个度量对象实例。对于给定的请求，如果一个度量类型存在两个或多个具有相同B标志值的度量对象实例，则必须只考虑第一个实例，而忽略其他实例。
For a given request, the presence of two METRIC objects of the same type with a different value of the B flag is allowed. Furthermore, it is also allowed to insert, for a given request, two METRIC objects with different types that have both their B flag cleared: in this case, an objective function must be used by the PCE to solve a multi-parameter optimization problem.
对于给定的请求，允许存在具有不同B标志值的相同类型的两个度量对象。此外，还允许为给定的请求插入两个不同类型的度量对象，这两个对象的B标志都已清除：在这种情况下，PCE必须使用目标函数来解决多参数优化问题。
A METRIC object used to indicate the metric to optimize during the path computation MUST have the B flag cleared and the C flag set to the appropriate value. When the path computation relates to the reoptimization of an exiting TE LSP (in which case, the R flag of the RP object is set), an implementation MAY decide to set the metric-value field to the computed value of the metric of the TE LSP to be reoptimized with regards to a specific metric type.
用于指示路径计算期间要优化的度量的度量对象必须清除B标志，并将C标志设置为适当的值。当路径计算涉及现有TE LSP的重新优化时（在这种情况下，设置RP对象的R标志），实现可以决定将度量值字段设置为关于特定度量类型要重新优化的TE LSP的度量的计算值。
A METRIC object used to reflect a bound MUST have the B flag set, and the C flag and metric-value field set to the appropriate values.
用于反映边界的度量对象必须设置B标志，并将C标志和度量值字段设置为适当的值。
In a PCRep message, unless not allowed by PCE policy, at least one METRIC object MUST be present that reports the computed path metric if the C flag of the METRIC object was set in the corresponding path computation request (the B flag MUST be cleared). The C flag has no meaning in a PCRep message. Optionally, the PCRep message MAY contain additional METRIC objects that correspond to bound constraints; in which case, the metric-value MUST be equal to the corresponding computed path metric (the B flag MUST be set). If no path satisfying the constraints could be found by the PCE, the METRIC objects MAY also be present in the PCRep message with the NO-PATH object to indicate the constraint metric that could be satisfied.
在PCRep消息中，除非PCE策略不允许，否则如果在相应的路径计算请求中设置了度量对象的C标志，则必须至少存在一个报告计算路径度量的度量对象（必须清除B标志）。C标志在PCRep消息中没有意义。可选地，PCRep消息可以包含对应于绑定约束的附加度量对象；在这种情况下，度量值必须等于相应的计算路径度量（必须设置B标志）。如果PCE找不到满足约束的路径，则度量对象也可能与无路径对象一起出现在PCRep消息中，以指示可能满足的约束度量。
Example: if a PCC sends a path computation request to a PCE where the metric to optimize is the IGP metric and the TE metric must not exceed the value of M, two METRIC objects are inserted in the PCReq message:
示例：如果PCC向PCE发送路径计算请求，其中要优化的度量为IGP度量且TE度量不得超过M值，则在PCReq消息中插入两个度量对象：
o First METRIC object with B=0, T=1, C=1, metric-value=0x0000
o B=0、T=1、C=1、度量值=0x0000的第一个度量对象
o Second METRIC object with B=1, T=2, metric-value=M
o 第二个度量对象，B=1，T=2，度量值=M
If a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, the PCE inserts one METRIC object with B=0, T=1, metric-value= computed IGP path cost. Additionally, the PCE may insert a second METRIC object with B=1, T=2, metric-value= computed TE path cost.
如果PCE可以找到满足约束集的路径，并且没有阻止返回计算度量的策略，则PCE将插入一个B=0、T=1、度量值=计算IGP路径成本的度量对象。另外，PCE可以插入B＝1、T＝2、度量值＝计算的TE路径成本的第二度量对象。
The ERO is used to encode the path of a TE LSP through the network. The ERO is carried within a PCRep message to provide the computed TE LSP if the path computation was successful.
ERO用于编码TE LSP通过网络的路径。如果路径计算成功，则在PCRep消息中携带ERO以提供计算的TE LSP。
The contents of this object are identical in encoding to the contents of the Resource Reservation Protocol Traffic Engineering Extensions (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-objects. Any RSVP-TE ERO sub-object already defined or that could be defined in the future for use in the RSVP-TE ERO is acceptable in this object.
此对象的内容在编码上与[RFC3209]、[RFC3473]和[RFC3477]中定义的资源预留协议流量工程扩展（RSVP-TE）显式路由对象（ERO）的内容相同。也就是说，对象由一系列子对象构成。任何已定义的RSVP-TE ERO子对象或将来可能定义用于RSVP-TE ERO的子对象均可在该对象中使用。
PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types.
PCEP ERO子对象类型对应于RSVP-TE ERO子对象类型。
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定义的含义相同。
ERO Object-Class is 7.
ERO对象类为7。
ERO Object-Type is 1.
ERO对象类型为1。
The RRO is exclusively carried within a PCReq message so as to report the route followed by a TE LSP for which a reoptimization is desired.
在PCReq消息中专门携带RRO，以便报告需要重新优化的TE LSP所遵循的路由。
The contents of this object are identical in encoding to the contents of the Route Record Object defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-
此对象的内容在编码上与[RFC3209]、[RFC3473]和[RFC3477]中定义的路由记录对象的内容相同。也就是说，对象由一系列子对象构成-
objects. Any RSVP-TE RRO sub-object already defined or that could be defined in the future for use in the RSVP-TE RRO is acceptable in this object.
物体。任何已定义的RSVP-TE RRO子对象或将来可能定义用于RSVP-TE RRO的子对象在此对象中都是可接受的。
The meanings of all of the sub-objects and fields in this object are identical to those defined for the RSVP-TE RRO.
此对象中所有子对象和字段的含义与为RSVP-TE RRO定义的含义相同。
PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types.
PCEP RRO子对象类型对应于RSVP-TE RRO子对象类型。
RRO Object-Class is 8.
RRO对象类是8。
RRO Object-Type is 1.
RRO对象类型为1。
The LSPA (LSP Attributes) object is optional and specifies various TE LSP attributes to be taken into account by the PCE during path computation. The LSPA object can be carried within a PCReq message, or a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the LSPA object is used to indicate the set of constraints that could not be satisfied). Most of the fields of the LSPA object are identical to the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in [RFC3209] and [RFC4090]. When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0, and there are no affinity constraints. See Section 4.7.4 of [RFC3209] for a detailed description of the use of resource affinities.
LSPA（LSP属性）对象是可选的，指定PCE在路径计算期间要考虑的各种TE LSP属性。LSPA对象可以在PCReq消息中携带，或者在路径计算失败的情况下在PCRep消息中携带（在这种情况下，PCRep消息还包含无路径对象，并且LSPA对象用于指示无法满足的约束集）。LSPA对象的大多数字段与[RFC3209]和[RFC4090]中定义的会话属性对象（C-Type=7）的字段相同。当PCReq消息中不存在时，这意味着设置和保持优先级等于0，并且没有关联约束。有关资源亲缘关系使用的详细说明，请参见[RFC3209]第4.7.4节。
LSPA Object-Class is 9.
LSPA对象类是9。
LSPA Object-Types is 1.
LSPA对象类型为1。
The format of the LSPA object body is:
LSPA对象体的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LSPA Object Body Format
图16:LSPA对象体格式
Setup Prio (Setup Priority - 8 bits): The priority of the TE LSP with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
Setup Prio（Setup Priority-8位）：TE LSP占用资源的优先级，范围为0到7。值0是最高优先级。设置优先级用于决定此会话是否可以抢占另一个会话。
Holding Prio (Holding Priority - 8 bits): The priority of the TE LSP with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
保持优先级（保持优先级-8位）：TE LSP相对于保持资源的优先级，范围为0到7。值0是最高优先级。保持优先级用于决定此会话是否可以被另一个会话抢占。
Flags (8 bits)
标志（8位）
L flag: Corresponds to the "Local Protection Desired" bit ([RFC3209]) of the SESSION-ATTRIBUTE Object. When set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090].
L标志：对应于会话属性对象的“所需本地保护”位（[RFC3209]）。设置时，这意味着计算路径必须包括[RFC4090]中定义的受快速重路由保护的链路。
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
未分配标志在传输时必须设置为零，在接收时必须忽略。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（8位）：此字段在传输时必须设置为零，在接收时必须忽略。
Note that optional TLVs may be defined in the future to carry additional TE LSP attributes such as those defined in [RFC5420].
请注意，将来可能会定义可选TLV，以携带额外的TE LSP属性，如[RFC5420]中定义的属性。
The IRO (Include Route Object) is optional and can be used to specify that the computed path MUST traverse a set of specified network elements. The IRO MAY be carried within PCReq and PCRep messages. When carried within a PCRep message with the NO-PATH object, the IRO indicates the set of elements that cause the PCE to fail to find a path.
IRO（包含路由对象）是可选的，可用于指定计算路径必须穿过一组指定的网络元素。IRO可以在PCReq和PCRep消息中携带。当在带有NO-PATH对象的PCRep消息中携带时，IRO指示导致PCE无法找到路径的元素集。
IRO Object-Class is 10.
IRO对象类是10。
IRO Object-Type is 1.
对象类型为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: IRO Body Format
图17:IRO正文格式
Sub-objects: The IRO is made of sub-objects identical to the ones defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub-object type is identical to the sub-object type defined in the related documents.
子对象：IRO由与[RFC3209]、[RFC3473]和[RFC3477]中定义的子对象相同的子对象组成，其中IRO子对象类型与相关文档中定义的子对象类型相同。
The following sub-object types are supported.
支持以下子对象类型。
Type Sub-object 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number
类型子对象1 IPv4前缀2 IPv6前缀4未编号的接口ID 32自治系统编号
The L bit of such sub-object has no meaning within an IRO.
该子对象的L位在IRO中没有意义。
Independent versus dependent path computation requests: path computation requests are said to be independent if they are not related to each other. Conversely, a set of dependent path computation requests is such that their computations cannot be performed independently of each other (a typical example of dependent requests is the computation of a set of diverse paths).
独立与从属路径计算请求：如果路径计算请求彼此不相关，则称它们为独立的。相反，一组依赖路径计算请求使得它们的计算不能彼此独立地执行（依赖请求的典型示例是一组不同路径的计算）。
Synchronized versus non-synchronized path computation requests: a set of path computation requests is said to be non-synchronized if their respective treatment (path computations) can be performed by a PCE in a serialized and independent fashion.
同步与非同步路径计算请求：如果一组路径计算请求的各自处理（路径计算）可以由PCE以序列化和独立的方式执行，则称其为非同步。
There are various circumstances where the synchronization of a set of path computations may be beneficial or required.
在各种情况下，一组路径计算的同步可能是有益的或必需的。
Consider the case of a set of N TE LSPs for which a PCC needs to send path computation requests to a PCE. The first solution consists of sending N separate PCReq messages to the selected PCE. In this case, the path computation requests are non-synchronized. Note that the PCC may chose to distribute the set of N requests across K PCEs for load balancing purposes. Considering that M (with M<N) requests are sent to a particular PCEi, as described above, such M requests can be sent in the form of successive PCReq messages destined to PCEi or bundled within a single PCReq message (since PCEP allows for the bundling of multiple path computation requests within a single PCReq message). That said, even in the case of independent requests, it can be desirable to request from the PCE the computation of their paths in a synchronized fashion that is likely to lead to more optimal path computations and/or reduced blocking probability if the PCE is a stateless PCE. In other words, the PCE should not compute the corresponding paths in a serialized and independent manner, but it should rather "simultaneously" compute their paths. For example, trying to "simultaneously" compute the paths of M TE LSPs may allow the PCE to improve the likelihood to meet multiple constraints.
考虑一组N TE LSP的情况，PCC需要向PCE发送路径计算请求。第一种解决方案包括向所选PCE发送N条单独的PCReq消息。在这种情况下，路径计算请求是非同步的。注意，为了负载平衡的目的，PCC可以选择在K个pce之间分发N个请求的集合。考虑到M（M<N）个请求被发送到特定PCEi，如上所述，这样的M个请求可以以目的地为PCEi的连续PCReq消息的形式发送，或者在单个PCReq消息中捆绑（因为PCEP允许在单个PCReq消息中捆绑多个路径计算请求）。这就是说，即使在独立请求的情况下，也可以期望以同步方式从PCE请求对其路径的计算，如果PCE是无状态PCE，则可能导致更优化的路径计算和/或降低阻塞概率。换句话说，PCE不应该以序列化和独立的方式计算相应的路径，而是应该“同时”计算它们的路径。例如，尝试“同时”计算mte lsp的路径可允许PCE提高满足多个约束的可能性。
Consider the case of two TE LSPs requesting N1 Mbit/s and N2 Mbit/s, respectively, and a maximum tolerable end-to-end delay for each TE LSP of X ms. There may be circumstances where the computation of the first TE LSP, irrespectively of the second TE LSP, may lead to the impossibility to meet the delay constraint for the second TE LSP.
考虑两个TE LSP分别请求N1 Mbit／s和N2 Mbit／s的情况，以及对于X TE的每个TE LSP的最大可容忍端到端延迟。可能存在第一TE LSP的计算，与第二TE LSP无关的计算可能导致不可能满足第二TE LSP的延迟约束。
A second example is related to the bandwidth constraint. It is quite straightforward to provide examples where a serialized independent path computation approach would lead to the impossibility to satisfy both requests (due to bandwidth fragmentation), while a synchronized path computation would successfully satisfy both requests.
第二个例子与带宽约束有关。提供的示例非常简单，其中序列化独立路径计算方法将导致无法满足两个请求（由于带宽碎片），而同步路径计算将成功满足两个请求。
A last example relates to the ability to avoid the allocation of the same resource to multiple requests, thus helping to reduce the call setup failure probability compared to the serialized computation of independent requests.
最后一个示例涉及避免将同一资源分配给多个请求的能力，因此与独立请求的序列化计算相比，有助于降低呼叫建立失败概率。
Dependent path computations are usually synchronized. For example, in the case of the computation of M diverse paths, if such paths are computed in a non-synchronized fashion, this seriously increases the
依赖路径计算通常是同步的。例如，在计算M条不同路径的情况下，如果以非同步方式计算这些路径，这将严重增加
probability of not being able to satisfy all requests (sometimes also referred to as the well-known "trapping problem").
无法满足所有请求的概率（有时也称为众所周知的“陷阱问题”）。
Furthermore, this would not allow a PCE to implement objective functions such as trying to minimize the sum of the TE LSP costs. In such a case, the path computation requests must be synchronized: they cannot be computed independently of each other.
此外，这将不允许PCE实现目标函数，例如尝试最小化TE LSP成本的总和。在这种情况下，路径计算请求必须同步：它们不能相互独立地计算。
Conversely, a set of independent path computation requests may or may not be synchronized.
相反，一组独立的路径计算请求可以同步，也可以不同步。
The synchronization of a set of path computation requests is achieved by using the SVEC object that specifies the list of synchronized requests that can either be dependent or independent.
一组路径计算请求的同步是通过使用SVEC对象来实现的，SVEC对象指定了同步请求的列表，这些请求可以是依赖的，也可以是独立的。
PCEP supports the following three modes:
PCEP支持以下三种模式：
o Bundle of a set of independent and non-synchronized path computation requests,
o 一组独立且非同步的路径计算请求的捆绑包，
o Bundle of a set of independent and synchronized path computation requests (requires the SVEC object defined below),
o 一组独立且同步的路径计算请求的捆绑（需要下面定义的SVEC对象），
o Bundle of a set of dependent and synchronized path computation requests (requires the SVEC object defined below).
o 一组相关和同步路径计算请求的捆绑（需要下面定义的SVEC对象）。
Section 7.13.1 details the circumstances under which it may be desirable and/or required to synchronize a set of path computation requests. The SVEC (Synchronization VECtor) object allows a PCC to request the synchronization of a set of dependent or independent path computation requests. The SVEC object is optional and may be carried within a PCReq message.
第7.13.1节详细说明了可能需要和/或需要同步一组路径计算请求的情况。SVEC（同步向量）对象允许PCC请求一组相关或独立路径计算请求的同步。SVEC对象是可选的，可以在PCReq消息中携带。
The aim of the SVEC object carried within a PCReq message is to request the synchronization of M path computation requests. The SVEC object is a variable-length object that lists the set of M path computation requests that must be synchronized. Each path computation request is uniquely identified by the Request-ID-number carried within the respective RP object. The SVEC object also contains a set of flags that specify the synchronization type.
PCReq消息中携带的SVEC对象的目的是请求M个路径计算请求的同步。SVEC对象是一个可变长度的对象，它列出了必须同步的M个路径计算请求集。每个路径计算请求由各自RP对象中携带的请求ID号唯一标识。SVEC对象还包含一组用于指定同步类型的标志。
SVEC Object-Class is 11.
SVEC对象类是11。
SVEC Object-Type is 1.
SVEC对象类型为1。
The format of the SVEC object body is as follows:
SVEC对象体的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SVEC Body Object Format
图18:SVEC主体对象格式
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（8位）：此字段在传输时必须设置为零，在接收时必须忽略。
Flags (24 bits): Defines the potential dependency between the set of path computation requests.
标志（24位）：定义路径计算请求集之间的潜在依赖关系。
* L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any link in common.
* L（链路多样性）位：设置时，这表示与以下RP对象指定的请求相对应的计算路径不得具有任何公共链路。
* N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any node in common.
* N（节点多样性）位：设置时，这表示与以下RP对象指定的请求相对应的计算路径不得有任何公共节点。
* S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT share any SRLG (Shared Risk Link Group).
* S（SRLG多样化）位：设置时，这表示与以下RP对象指定的请求相对应的计算路径不得共享任何SRLG（共享风险链接组）。
In case of a set of M synchronized independent path computation requests, the bits L, N, and S are cleared.
在一组M个同步独立路径计算请求的情况下，位L、N和S被清除。
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
未分配标志在传输时必须设置为零，在接收时必须忽略。
The flags defined above are not exclusive.
上面定义的标志不是独占的。
The SVEC object allows a PCC to specify a list of M path computation requests that MUST be synchronized along with a potential dependency. The set of M path computation requests may be sent within a single PCReq message or multiple PCReq messages. In the latter case, it is RECOMMENDED for the PCE to implement a local timer (called the
SVEC对象允许PCC指定必须与潜在依赖项同步的M路径计算请求列表。M路径计算请求的集合可以在单个PCReq消息或多个PCReq消息内发送。在后一种情况下，建议PCE实施本地计时器（称为
SyncTimer) activated upon the receipt of the first PCReq message that contains the SVEC object after the expiration of which, if all the M path computation requests have not been received, a protocol error is triggered. When a PCE receives a path computation request that cannot be satisfied (for example, because the PCReq message contains an object with the P bit set that is not supported), the PCE sends a PCErr message for this request (see Section 7.2), the PCE MUST cancel the whole set of related path computation requests and MUST send a PCErr message with Error-Type="Synchronized path computation request missing".
SyncTimer）在收到包含SVEC对象的第一条PCReq消息时激活，在该消息过期后，如果尚未收到所有M路径计算请求，则会触发协议错误。当PCE接收到无法满足的路径计算请求时（例如，因为PCReq消息包含不支持的P位设置的对象），PCE将为此请求发送PCErr消息（参见第7.2节），PCE必须取消整套相关的路径计算请求，并且必须发送一条PCErr消息，错误类型为“Synchronized path Computing request missing”。
Note that such PCReq messages may also contain non-synchronized path computation requests. For example, the PCReq message may comprise N synchronized path computation requests that are related to RP 1, ..., RP N and are listed in the SVEC object along with any other path computation requests that are processed as normal.
请注意，此类PCReq消息还可能包含非同步路径计算请求。例如，PCReq消息可以包括与RP 1、…、RP N相关的N个同步路径计算请求，这些请求与正常处理的任何其他路径计算请求一起列在SVEC对象中。
The NOTIFICATION object is exclusively carried within a PCNtf message and can either be used in a message sent by a PCC to a PCE or by a PCE to a PCC so as to notify of an event.
通知对象在PCNtf消息中被独占地携带，并且可以在由PCC发送到PCE的消息中使用，或者由PCE发送到PCC以便通知事件。
NOTIFICATION Object-Class is 12.
通知对象类是12。
NOTIFICATION Object-Type is 1.
通知对象类型为1。
The format of the NOTIFICATION body object is as follows:
通知正文对象的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NOTIFICATION Body Object Format
图19：通知体对象格式
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（8位）：此字段在传输时必须设置为零，在接收时必须忽略。
Flags (8 bits): No flags are currently defined. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
标志（8位）：当前未定义标志。未分配标志在传输时必须设置为零，在接收时必须忽略。
NT (Notification Type - 8 bits): The Notification-type specifies the class of notification.
NT（通知类型-8位）：通知类型指定通知的类别。
NV (Notification Value - 8 bits): The Notification-value provides addition information related to the nature of the notification.
NV（通知值-8位）：通知值提供与通知性质相关的附加信息。
Both the Notification-type and Notification-value are managed by IANA.
通知类型和通知值都由IANA管理。
The following Notification-type and Notification-value values are currently defined:
当前定义了以下通知类型和通知值：
o Notification-type=1: Pending Request cancelled
o 通知类型=1：挂起的请求已取消
* Notification-value=1: PCC cancels a set of pending requests. A Notification-type=1, Notification-value=1 indicates that the PCC wants to inform a PCE of the cancellation of a set of pending requests. Such an event could be triggered because of external conditions such as the receipt of a positive reply from another PCE (should the PCC have sent multiple requests to a set of PCEs for the same path computation request), a network event such as a network failure rendering the request obsolete, or any other events local to the PCC. A NOTIFICATION object with Notification-type=1, Notification-value=1 is carried within a PCNtf message sent by the PCC to the PCE. The RP object corresponding to the cancelled request MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message; in which case, the notification applies to all of them. If such a notification is received by a PCC from a PCE, the PCC MUST silently ignore the notification and no errors should be generated.
* 通知值=1:PCC取消一组挂起的请求。通知类型=1，通知值=1表示PCC希望通知PCE取消一组挂起的请求。这样的事件可能会因为外部条件而触发，例如从另一个PCE接收到肯定回复（如果PCC已经针对同一路径计算请求向一组PCE发送了多个请求）、网络事件（例如导致请求过时的网络故障）或PCC本地的任何其他事件。通知类型为1、通知值为1的通知对象在PCC发送给PCE的PCNtf消息中携带。与已取消请求相对应的RP对象也必须出现在PCNtf消息中。PCNtf报文中可能携带多个RP对象；在这种情况下，通知适用于所有这些人。如果PCC从PCE接收到此类通知，则PCC必须默默忽略该通知，并且不应生成任何错误。
* Notification-value=2: PCE cancels a set of pending requests. A Notification-type=1, Notification-value=2 indicates that the PCE wants to inform a PCC of the cancellation of a set of pending requests. A NOTIFICATION object with Notification-type=1, Notification-value=2 is carried within a PCNtf message sent by a PCE to a PCC. The RP object corresponding to the cancelled request MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message; in which case, the notification applies to all of them. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated.
* 通知值=2:PCE取消一组挂起的请求。通知类型=1，通知值=2表示PCE希望通知PCC取消一组挂起的请求。PCE发送给PCC的PCNtf消息中携带通知类型为1、通知值为2的通知对象。与已取消请求相对应的RP对象也必须出现在PCNtf消息中。PCNtf报文中可能携带多个RP对象；在这种情况下，通知适用于所有这些人。如果PCE从PCC接收到此类通知，则PCE必须默默忽略该通知，并且不应生成任何错误。
o Notification-type=2: Overloaded PCE
o 通知类型=2：过载的PCE
* Notification-value=1: A Notification-type=2, Notification-
* 通知值=1：通知类型=2，通知-
value=1 indicates to the PCC that the PCE is currently in an overloaded state. If no RP objects are included in the PCNtf message, this indicates that no other requests SHOULD be sent to that PCE until the overloaded state is cleared: the pending requests are not affected and will be served. If some pending requests cannot be served due to the overloaded state, the PCE MUST also include a set of RP objects that identifies the set of pending requests that are cancelled by the PCE and will not be honored. In this case, the PCE does not have to send an additional PCNtf message with Notification-type=1 and Notification-value=2 since the list of cancelled requests is specified by including the corresponding set of RP objects. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated.
值=1向PCC指示PCE当前处于过载状态。如果PCNtf消息中未包含RP对象，则表示在清除过载状态之前，不应向该PCE发送任何其他请求：挂起的请求不受影响，将得到服务。如果某些挂起的请求由于过载状态而无法提供服务，则PCE还必须包括一组RP对象，这些对象标识PCE取消的挂起的请求集，并且不会被执行。在这种情况下，PCE不必发送通知类型为1且通知值为2的附加PCNtf消息，因为已取消请求的列表是通过包含相应的RP对象集来指定的。如果PCE从PCC接收到此类通知，则PCE必须默默忽略该通知，并且不应生成任何错误。
* A PCE implementation SHOULD use a dual-threshold mechanism used to determine whether it is in a congestion state with regards to specific resource monitoring (e.g. CPU, memory). The use of such thresholds is to avoid oscillations between overloaded/ non-overloaded state that may result in oscillations of request targets by the PCCs.
* PCE实现应使用双阈值机制，用于确定其是否处于与特定资源监控（例如CPU、内存）相关的拥塞状态。此类阈值的使用是为了避免过载/非过载状态之间的振荡，这可能导致PCC对请求目标的振荡。
* Optionally, a TLV named OVERLOADED-DURATION may be included in the NOTIFICATION object that specifies the period of time during which no further request should be sent to the PCE. Once this period of time has elapsed, the PCE should no longer be considered in a congested state.
* 可选地，可以在通知对象中包括名为OVERLOADED-DURATION的TLV，该通知对象指定不应向PCE发送进一步请求的时间段。一旦这段时间过去，就不应再认为PCE处于拥挤状态。
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format defined in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes), followed by a fixed-length value field of a 32-bit flags field.
重载持续时间TLV符合第7.1节中定义的PCEP TLV格式，由类型的2个字节组成，2个字节指定TLV长度（值部分的长度以字节为单位），然后是32位标志字段的固定长度值字段。
Type: 2 Length: 4 bytes Value: 32-bit flags field indicates the estimated PCE congestion duration in seconds.
类型：2长度：4字节值：32位标志字段表示估计的PCE拥塞持续时间（秒）。
* Notification-value=2: A Notification-type=2, Notification-value=2 indicates that the PCE is no longer in an overloaded state and is available to process new path computation requests. An implementation SHOULD make sure that a PCE sends such notification to every PCC to which a Notification message (with Notification-type=2, Notification-value=1) has been sent unless an OVERLOADED-DURATION TLV has been included in the corresponding message and the PCE wishes to wait for the
* 通知值=2：通知类型=2，通知值=2表示PCE不再处于过载状态，可用于处理新的路径计算请求。实现应确保PCE将此类通知发送到已向其发送通知消息（通知类型=2，通知值=1）的每个PCC，除非相应消息中包含超载持续时间TLV，并且PCE希望等待通知
expiration of that period of time before receiving new requests. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated. It is RECOMMENDED to support some dampening notification procedure on the PCE so as to avoid too frequent congestion state and congestion state release notifications. For example, an implementation could make use of an hysteresis approach using a dual-threshold mechanism that triggers the sending of congestion state notifications. Furthermore, in case of high instabilities of the PCE resources, an additional dampening mechanism SHOULD be used (linear or exponential) to pace the notification frequency and avoid oscillation of path computation requests.
在接收新请求之前该时间段的过期。如果PCE从PCC接收到此类通知，则PCE必须默默忽略该通知，并且不应生成任何错误。建议在PCE上支持一些抑制通知程序，以避免过于频繁的拥塞状态和拥塞状态释放通知。例如，实现可以使用滞后方法，该方法使用触发拥塞状态通知发送的双阈值机制。此外，在PCE资源高度不稳定的情况下，应使用额外的抑制机制（线性或指数）来调整通知频率并避免路径计算请求的振荡。
When a PCC receives an overload indication from a PCE, it should consider the impact on the entire network. It must be remembered that other PCCs may also receive the notification, and so many path computation requests could be redirected to other PCEs. This may, in turn, cause further overloading at PCEs in the network. Therefore, an application at a PCC receiving an overload notification should consider applying some form of back-off (e.g., exponential) to the rate at which it generates path computation requests into the network. This is especially the case as the number of PCEs reporting overload grows.
当PCC从PCE接收过载指示时，它应该考虑对整个网络的影响。必须记住，其他PCC也可能收到通知，因此许多路径计算请求可能被重定向到其他PCE。这反过来可能会导致网络中的PCE进一步过载。因此，在接收过载通知的PCC上的应用程序应考虑将某种形式的退避（例如，指数）应用到其生成路径计算请求到网络中的速率。随着报告过载的PCE数量的增加，情况尤其如此。
The PCEP-ERROR object is exclusively carried within a PCErr message to notify of a PCEP error.
PCEP-ERROR对象专门携带在PCErr消息中，用于通知PCEP错误。
PCEP-ERROR Object-Class is 13.
PCEP-ERROR对象类为13。
PCEP-ERROR Object-Type is 1.
PCEP-ERROR对象类型为1。
The format of the PCEP-ERROR object body is as follows:
PCEP-ERROR对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Error-Type | Error-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Error-Type | Error-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: PCEP-ERROR Object Body Format
图20:PCEP-ERROR对象体格式
A PCEP-ERROR object is used to report a PCEP error and is characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-value are managed by IANA (see the IANA section).
PCEP-ERROR对象用于报告PCEP错误，其特征是指定错误类型的错误类型和提供有关错误类型的附加信息的错误值。错误类型和错误值都由IANA管理（请参阅IANA部分）。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（8位）：此字段在传输时必须设置为零，在接收时必须忽略。
Flags (8 bits): no flag is currently defined. This flag MUST be set to zero on transmission and MUST be ignored on receipt.
标志（8位）：当前未定义标志。此标志在传输时必须设置为零，在接收时必须忽略。
Error-Type (8 bits): defines the class of error.
错误类型（8位）：定义错误类别。
Error-value (8 bits): provides additional details about the error.
错误值（8位）：提供有关错误的其他详细信息。
Optionally, the PCEP-ERROR object may contain additional TLVs so as to provide further information about the encountered error.
可选地，PCEP-ERROR对象可以包含额外的TLV，以便提供关于遇到的错误的进一步信息。
A single PCErr message may contain multiple PCEP-ERROR objects.
单个PCErr消息可能包含多个PCEP-ERROR对象。
For each PCEP error, an Error-Type and an Error-value are defined.
对于每个PCEP错误，定义了错误类型和错误值。
Error-Type Meaning 1 PCEP session establishment failure Error-value=1: reception of an invalid Open message or a non Open message. Error-value=2: no Open message received before the expiration of the OpenWait timer Error-value=3: unacceptable and non-negotiable session characteristics Error-value=4: unacceptable but negotiable session characteristics Error-value=5: reception of a second Open message with still unacceptable session characteristics Error-value=6: reception of a PCErr message proposing unacceptable session characteristics Error-value=7: No Keepalive or PCErr message received before the expiration of the KeepWait timer 2 Capability not supported 3 Unknown Object Error-value=1: Unrecognized object class Error-value=2: Unrecognized object Type 4 Not supported object Error-value=1: Not supported object class Error-value=2: Not supported object Type 5 Policy violation Error-value=1: C bit of the METRIC object set (request rejected) Error-value=2: O bit of the RP object set (request rejected) 6 Mandatory Object missing Error-value=1: RP object missing Error-value=2: RRO object missing for a reoptimization request (R bit of the RP object set) when bandwidth is not equal to 0. Error-value=3: END-POINTS object missing 7 Synchronized path computation request missing 8 Unknown request reference 9 Attempt to establish a second PCEP session 10 Reception of an invalid object Error-value=1: reception of an object with P flag not set although the P flag must be set according to this specification.
错误类型表示1 PCEP会话建立失败错误值=1：接收无效的打开消息或非打开消息。错误值=2：在OpenWait计时器过期之前未收到打开的消息错误值=3：不可接受和不可协商的会话特征错误值=4：不可接受但可协商的会话特征错误值=5：接收第二条打开的消息，但会话特征仍然不可接受错误值=6：接收PCErr消息建议不可接受的会话特征错误值=7:在KeepWait计时器2功能过期之前未收到Keepalive或PCErr消息不受支持3未知对象错误值=1:无法识别的对象类错误值=2:无法识别的对象类型4不受支持的对象错误值=1:不受支持的对象类错误值=2：不支持的对象类型5策略冲突错误值=1:C度量对象集位（请求被拒绝）错误值=2:O RP对象集位（请求被拒绝）6强制对象缺少错误值=1:RP对象缺少错误值=2:RRO对象缺少重新优化请求（RP对象集的R位）当带宽不等于0时。错误值=3：端点对象缺失7同步路径计算请求缺失8未知请求参考9尝试建立第二个PCEP会话10接收无效对象错误值=1：接收未设置P标志的对象，尽管必须根据本规范设置P标志。
The error types listed above are described below.
上面列出的错误类型如下所述。
Error-Type=1: PCEP session establishment failure.
错误类型=1：PCEP会话建立失败。
If a malformed message is received, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=1.
如果收到格式错误的消息，则接收PCEP对等方必须发送错误类型为1、错误值为1的PCErr消息。
If no Open message is received before the expiration of the OpenWait timer, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=2 (see Appendix A for details).
如果在OpenWait计时器到期之前未收到任何打开消息，则接收PCEP对等方必须发送错误类型为1、错误值为2的PCErr消息（有关详细信息，请参阅附录a）。
If one or more PCEP session characteristics are unacceptable by the receiving peer and are not negotiable, it MUST send a PCErr message with Error-Type=1, Error-value=3.
如果接收对等方不接受一个或多个PCEP会话特征，且无法协商，则必须发送错误类型为1、错误值为3的PCErr消息。
If an Open message is received with unacceptable session characteristics but these characteristics are negotiable, the receiving PCEP peer MUST send a PCErr message with Error-Type-1, Error-value=4 (see Section 6.2 for details).
如果接收到的开放消息具有不可接受的会话特征，但这些特征是可协商的，则接收PCEP对等方必须发送错误类型为1、错误值为4的PCErr消息（详见第6.2节）。
If a second Open message is received during the PCEP session establishment phase and the session characteristics are still unacceptable, the receiving PCEP peer MUST send a PCErr message with Error-Type-1, Error-value=5 (see Section 6.2 for details).
如果在PCEP会话建立阶段接收到第二条开放消息，且会话特征仍然不可接受，则接收PCEP对等方必须发送错误类型为1、错误值为5的PCErr消息（详见第6.2节）。
If a PCErr message is received during the PCEP session establishment phase that contains an Open message proposing unacceptable session characteristics, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=6.
如果在PCEP会话建立阶段收到PCErr消息，其中包含提出不可接受会话特征的开放消息，则接收PCEP对等方必须发送错误类型为1、错误值为6的PCErr消息。
If neither a Keepalive message nor a PCErr message is received before the expiration of the KeepWait timer during the PCEP session establishment phase, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=7.
如果在PCEP会话建立阶段期间，在KeepWait计时器到期之前未收到Keepalive消息或PCErr消息，则接收PCEP对等方必须发送错误类型为1、错误值为7的PCErr消息。
Error-Type=2: the PCE indicates that the path computation request cannot be honored because it does not support one or more required capability. The corresponding path computation request MUST be cancelled.
错误类型=2：PCE表示无法执行路径计算请求，因为它不支持一个或多个必需的功能。必须取消相应的路径计算请求。
Error-Type=3 or Error-Type=4: if a PCEP message is received that carries a PCEP object (with the P flag set) not recognized by the PCE or recognized but not supported, then the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3 and 4, respectively). In addition, the PCE MAY include in the PCErr message the unknown or not supported object. The corresponding path computation request MUST be cancelled by the PCE without further notification.
错误类型=3或错误类型=4：如果接收到的PCEP消息包含PCE无法识别或无法识别但不受支持的PCEP对象（设置了P标志），则PCE必须发送带有PCEP-Error对象的PCErr消息（错误类型分别为3和4）。此外，PCE可以在PCErr消息中包括未知或不受支持的对象。PCE必须取消相应的路径计算请求，无需进一步通知。
Error-Type=5: if a path computation request is received that is not compliant with an agreed policy between the PCC and the PCE, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5). The corresponding path computation MUST be cancelled. Policy-specific TLVs carried within the PCEP-ERROR object may be defined in other documents to specify the nature of the policy violation.
错误类型=5：如果收到的路径计算请求不符合PCC和PCE之间约定的策略，PCE必须发送带有PCEP-Error对象的PCErr消息（错误类型=5）。必须取消相应的路径计算。PCEP-ERROR对象中携带的特定于策略的TLV可以在其他文档中定义，以指定策略冲突的性质。
Error-Type=6: if a path computation request is received that does not contain a mandatory object, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=6). If there are multiple mandatory objects missing, the PCErr message MUST contain one PCEP-ERROR object per missing object. The corresponding path computation MUST be cancelled.
错误类型=6：如果收到的路径计算请求不包含强制对象，则PCE必须发送带有PCEP-Error对象的PCErr消息（错误类型=6）。如果缺少多个必需对象，则PCErr消息必须为每个缺少的对象包含一个PCEP-ERROR对象。必须取消相应的路径计算。
Error-Type=7: if a PCC sends a synchronized path computation request to a PCE and the PCE does not receive all the synchronized path computation requests listed within the corresponding SVEC object after the expiration of the timer SyncTimer defined in Section 7.13.3, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=7). The corresponding synchronized path computation MUST be cancelled. It is RECOMMENDED for the PCE to include the REQ-MISSING TLVs (defined below) that identify the missing requests.
错误类型=7：如果PCC向PCE发送同步路径计算请求，并且PCE在第7.13.3节中定义的计时器SyncTimer过期后未收到相应SVEC对象中列出的所有同步路径计算请求，则PCE必须发送带有PCEP-Error对象的PCErr消息（错误类型=7）。必须取消相应的同步路径计算。建议PCE包括识别缺失请求的REQ-MISSING TLV（定义见下文）。
The REQ-MISSING TLV is compliant with the PCEP TLV format defined in section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes), followed by a fixed-length value field of 4 bytes.
REQ-MISSING TLV符合第7.1节中定义的PCEP TLV格式，由类型的2个字节组成，2个字节指定TLV长度（值部分的长度以字节为单位），然后是4个字节的固定长度值字段。
Type: 3 Length: 4 bytes Value: 4 bytes that indicate the Request-ID-number that corresponds to the missing request.
类型：3长度：4字节值：4字节，指示与缺少的请求相对应的请求ID号。
Error-Type=8: if a PCC receives a PCRep message related to an unknown path computation request, the PCC MUST send a PCErr message with a PCEP-ERROR object (Error-Type=8). In addition, the PCC MUST include in the PCErr message the unknown RP object.
错误类型=8：如果PCC接收到与未知路径计算请求相关的PCRep消息，则PCC必须发送带有PCEP-Error对象的PCErr消息（错误类型=8）。此外，PCC必须在PCErr消息中包含未知RP对象。
Error-Type=9: if a PCEP peer detects an attempt from another PCEP peer to establish a second PCEP session, it MUST send a PCErr message with Error-Type=9, Error-value=1. The existing PCEP session MUST be preserved and all subsequent messages related to the tentative establishment of the second PCEP session MUST be silently ignored.
错误类型=9：如果一个PCEP对等方检测到另一个PCEP对等方试图建立第二个PCEP会话，它必须发送一个错误类型=9、错误值=1的PCErr消息。必须保留现有PCEP会话，并且与第二个PCEP会话的临时建立相关的所有后续消息都必须以静默方式忽略。
Error-Type=10: if a PCEP peers receives an object with the P flag not set although the P flag must be set according to this specification, it MUST send a PCErr message with Error-Type=10, Error-value=1.
错误类型=10：如果PCEP对等方接收到未设置P标志的对象（尽管必须根据本规范设置P标志），则它必须发送错误类型=10、错误值=1的PCErr消息。
There are situations where no TE LSP with a bandwidth of X could be found by a PCE although such a bandwidth requirement could be satisfied by a set of TE LSPs such that the sum of their bandwidths is equal to X. Thus, it might be useful for a PCC to request a set of TE LSPs so that the sum of their bandwidth is equal to X Mbit/s, with potentially some constraints on the number of TE LSPs and the minimum bandwidth of each of these TE LSPs. Such a request is made by inserting a LOAD-BALANCING object in a PCReq message sent to a PCE.
存在PCE不能找到带宽为X的TE-LSP的情况，尽管这样的带宽要求可以由一组TE-LSP来满足，使得它们的带宽之和等于X。因此，PCC请求一组TE-LSP，使得它们的带宽之和等于X Mbit/s可能是有用的，对TE LSP的数量和每个TE LSP的最小带宽可能有一些限制。通过在发送到PCE的PCReq消息中插入负载平衡对象来发出这样的请求。
The LOAD-BALANCING object is optional.
负载平衡对象是可选的。
LOAD-BALANCING Object-Class is 14.
负载平衡对象类是14。
LOAD-BALANCING Object-Type is 1.
负载平衡对象类型为1。
The format of the LOAD-BALANCING object body is as follows:
负载平衡对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Max-LSP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Max-LSP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: LOAD-BALANCING Object Body Format
图21：负载平衡对象体格式
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（16位）：此字段在传输时必须设置为零，在接收时必须忽略。
Flags (8 bits): No flag is currently defined. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
标志（8位）：当前未定义标志。标志字段在传输时必须设置为零，在接收时必须忽略。
Max-LSP (8 bits): maximum number of TE LSPs in the set.
最大LSP（8位）：集合中TE LSP的最大数量。
Min-Bandwidth (32 bits): Specifies the minimum bandwidth of each element of the set of TE LSPs. The bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second.
最小带宽（32位）：指定TE LSP集合中每个元素的最小带宽。带宽以32位的IEEE浮点格式编码（见[IEEE.754.1985]），以字节/秒表示。
The LOAD-BALANCING object body has a fixed length of 8 bytes.
负载平衡对象主体具有8字节的固定长度。
If a PCC requests the computation of a set of TE LSPs so that the sum of their bandwidth is X, the maximum number of TE LSPs is N, and each TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH object specifying X as the required bandwidth and a LOAD-BALANCING object with the Max-LSP and Min-Bandwidth fields set to N and B, respectively.
如果PCC请求计算一组TE LSP，使其带宽之和为X，TE LSP的最大数量为N，并且每个TE LSP必须至少具有B的带宽，则它插入一个带宽对象，指定X为所需带宽，并插入一个负载平衡对象，其中最大LSP和最小带宽字段设置为N和B，分别地
The CLOSE object MUST be present in each Close message. There MUST be only one CLOSE object per Close message. If a Close message is received that contains more than one CLOSE object, the first CLOSE object is the one that must be processed. Other CLOSE objects MUST be silently ignored.
关闭对象必须出现在每个关闭消息中。每个关闭消息只能有一个关闭对象。如果接收到包含多个关闭对象的关闭消息，则必须处理第一个关闭对象。必须以静默方式忽略其他闭合对象。
CLOSE Object-Class is 15.
CLOSE对象类是15。
CLOSE Object-Type is 1.
关闭对象类型为1。
The format of the CLOSE object body is as follows:
闭合对象体的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: CLOSE Object Format
图22：关闭对象格式
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（16位）：此字段在传输时必须设置为零，在接收时必须忽略。
Flags (8 bits): No flags are currently defined. The Flag field MUST be set to zero on transmission and MUST be ignored on receipt.
标志（8位）：当前未定义标志。标志字段在传输时必须设置为零，在接收时必须忽略。
Reason (8 bits): specifies the reason for closing the PCEP session. The setting of this field is optional. IANA manages the codespace of the Reason field. The following values are currently defined:
原因（8位）：指定关闭PCEP会话的原因。此字段的设置是可选的。IANA管理原因字段的代码空间。当前定义了以下值：
Reasons Value Meaning 1 No explanation provided 2 DeadTimer expired 3 Reception of a malformed PCEP message 4 Reception of an unacceptable number of unknown requests/replies 5 Reception of an unacceptable number of unrecognized PCEP messages
原因值意味着1未提供解释2死区计时器过期3接收格式错误的PCEP消息4接收数量不可接受的未知请求/答复5接收数量不可接受的未识别PCEP消息
Optional TLVs may be included within the CLOSE object body. The specification of such TLVs is outside the scope of this document.
可选TLV可包括在封闭物体体内。此类TLV的规范不在本文件范围内。
This section follows the guidance of [PCE-MANAGE].
本节遵循[PCE-MANAGE]的指导。
A PCEP implementation SHOULD allow configuring the following PCEP session parameters on the implementation:
PCEP实现应允许在实现上配置以下PCEP会话参数：
o The local Keepalive and DeadTimer (i.e., parameters sent by the PCEP peer in an Open message),
o 本地Keepalive和DeadTimer（即PCEP对等方在开放消息中发送的参数），
o The maximum acceptable remote Keepalive and DeadTimer (i.e., parameters received from a peer in an Open message),
o 可接受的最大远程Keepalive和DeadTimer（即，在开放消息中从对等方接收的参数），
o Whether negotiation is enabled or disabled,
o 无论协商是启用还是禁用，
o If negotiation is allowed, the minimum acceptable Keepalive and DeadTimer timers received from a PCEP peer,
o 如果允许协商，则从PCEP对等方接收的最小可接受Keepalive和DeadTimer计时器，
o The SyncTimer,
o 同步计时器，
o The maximum number of sessions that can be set up,
o 可以设置的最大会话数，
o The request timer, the amount of time a PCC waits for a reply before resending its path computation requests (potentially to an alternate PCE),
o 请求计时器，PCC在重新发送其路径计算请求（可能发送到备用PCE）之前等待回复的时间量，
o The MAX-UNKNOWN-REQUESTS,
o 最大未知请求数，
o The MAX-UNKNOWN-MESSAGES.
o MAX-UNKNOWN-MESSAGES。
These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or may apply to a specific session with a given PCEP peer or to a specific group of sessions
这些参数可以配置为PCEP演讲者参与的任何PCEP会话的默认参数，或者可以应用于与给定PCEP对等方的特定会话或特定会话组
with a specific group of PCEP peers. A PCEP implementation SHOULD allow configuring the initiation of a PCEP session with a selected subset of discovered PCEs. Note that PCE selection is a local implementation issue. A PCEP implementation SHOULD allow configuring a specific PCEP session with a given PCEP peer. This includes the configuration of the following parameters:
与一组特定的PCEP同龄人。PCEP实施应允许使用所发现PCE的选定子集配置PCEP会话的启动。请注意，PCE选择是本地实现问题。PCEP实现应允许与给定的PCEP对等方配置特定的PCEP会话。这包括以下参数的配置：
o The IP address of the PCEP peer,
o PCEP对等方的IP地址，
o The PCEP speaker role: PCC, PCE, or both,
o PCEP演讲者角色：PCC、PCE或两者，
o Whether the PCEP speaker should initiate the PCEP session or wait for initiation by the peer,
o PCEP演讲者应发起PCEP会话还是等待对等方发起，
o The PCEP session parameters, as listed above, if they differ from the default parameters,
o 如上所列的PCEP会话参数，如果与默认参数不同，
o A set of PCEP policies including the type of operations allowed for the PCEP peer (e.g., diverse path computation, synchronization, etc.).
o 一组PCEP策略，包括PCEP对等方允许的操作类型（例如，多样路径计算、同步等）。
A PCEP implementation MUST allow restricting the set of PCEP peers that can initiate a PCEP session with the PCEP speaker (e.g., list of authorized PCEP peers, all PCEP peers in the area, all PCEP peers in the AS).
PCEP实施必须允许限制可与PCEP扬声器启动PCEP会话的PCEP对等点集（例如，授权PCEP对等点列表、区域内的所有PCEP对等点、AS内的所有PCEP对等点）。
A PCEP MIB module is defined in [PCEP-MIB] that describes managed objects for modeling of PCEP communication including:
[PCEP-MIB]中定义了PCEP MIB模块，该模块描述了用于PCEP通信建模的托管对象，包括：
o PCEP client configuration and status,
o PCEP客户端配置和状态，
o PCEP peer configuration and information,
o PCEP对等配置和信息，
o PCEP session configuration and information,
o PCEP会话配置和信息，
o Notifications to indicate PCEP session changes.
o 指示PCEP会话更改的通知。
PCEP includes a keepalive mechanism to check the liveliness of a PCEP peer and a notification procedure allowing a PCE to advertise its overloaded state to a PCC. Also, procedures in order to monitor the liveliness and performances of a given PCE chain (in case of multiple-PCE path computation) are defined in [PCE-MONITOR].
PCEP包括一个keepalive机制，用于检查PCEP对等方的活跃性，以及一个通知过程，允许PCE向PCC公布其过载状态。此外，在[PCE-monitor]中定义了监控给定PCE链的活性和性能的程序（在多个PCE路径计算的情况下）。
Verifying the correct operation of a PCEP communication can be performed by monitoring various parameters. A PCEP implementation SHOULD provide the following parameters:
可通过监测各种参数来验证PCEP通信的正确运行。PCEP实施应提供以下参数：
o Response time (minimum, average, and maximum), on a per-PCE-peer basis,
o 响应时间（最小、平均和最大），基于每个PCE对等体，
o PCEP session failures,
o PCEP会话失败，
o Amount of time the session has been in active state,
o 会话处于活动状态的时间量，
o Number of corrupted messages,
o 损坏邮件的数量，
o Number of failed computations,
o 计算失败的次数，
o Number of requests for which no reply has been received after the expiration of a configurable timer and by verifying that at least one path exists that satisfies the set of constraints.
o 在可配置计时器过期后，通过验证是否存在至少一条满足约束集的路径，未收到回复的请求数。
A PCEP implementation SHOULD log error events (e.g., corrupted messages, unrecognized objects).
PCEP实现应记录错误事件（例如，损坏的消息、无法识别的对象）。
PCEP does not put any new requirements on other protocols. As PCEP relies on the TCP transport protocol, PCEP management can make use of TCP management mechanisms (such as the TCP MIB defined in [RFC4022]).
PCEP没有对其他协议提出任何新要求。由于PCEP依赖于TCP传输协议，因此PCEP管理可以使用TCP管理机制（如[RFC4022]中定义的TCP MIB）。
The PCE Discovery mechanisms ([RFC5088], [RFC5089]) may have an impact on PCEP. To avoid that a high frequency of PCE Discoveries/ Disappearances triggers a high frequency of PCEP session setups/ deletions, it is RECOMMENDED to introduce some dampening for establishment of PCEP sessions.
PCE发现机制（[RFC5088]、[RFC5089]）可能会对PCEP产生影响。为避免PCE发现/消失的高频率触发PCEP会话设置/删除的高频率，建议为建立PCEP会话引入一些阻尼。
In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of sessions that can be set up on a PCEP speaker, and MAY allow a limit to be placed on the rate of messages sent by a PCEP speaker and received from a peer. It MAY also allow sending a notification when a rate threshold is reached.
为了避免对网络操作造成任何不可接受的影响，实现应允许对可在PCEP扬声器上设置的会话数量进行限制，并允许对PCEP扬声器发送和从对等方接收的消息的速率进行限制。它还允许在达到速率阈值时发送通知。
IANA assigns values to the PCEP protocol parameters (messages, objects, TLVs).
IANA为PCEP协议参数（消息、对象、TLV）赋值。
IANA established a new top-level registry to contain all PCEP codepoints and sub-registries.
IANA建立了一个新的顶级注册表，包含所有PCEP代码点和子注册表。
The allocation policy for each new registry is by IETF Consensus: new values are assigned through the IETF consensus process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
每个新注册表的分配策略由IETF协商一致：通过IETF协商一致过程分配新值（见[RFC5226]）。具体而言，新任务通过IESG批准的RFC完成。通常情况下，IESG将寻求适当人员（例如，相关工作组，如果存在）对预期任务的投入。
PCEP has been registered as TCP port 4189.
PCEP已注册为TCP端口4189。
IANA created a registry for PCEP messages. Each PCEP message has a message type value.
IANA为PCEP消息创建了一个注册表。每个PCEP消息都有一个消息类型值。
Value Meaning Reference 1 Open This document 2 Keepalive This document 3 Path Computation Request This document 4 Path Computation Reply This document 5 Notification This document 6 Error This document 7 Close This document
值含义参考1打开此文档2保留此文档3路径计算请求此文档4路径计算答复此文档5通知此文档6错误此文档7关闭此文档
IANA created a registry for PCEP objects. Each PCEP object has an Object-Class and an Object-Type.
IANA为PCEP对象创建了一个注册表。每个PCEP对象都有一个对象类和一个对象类型。
Object-Class Value Name Reference
对象类值名称引用
1 OPEN This document Object-Type 1
1打开此文档对象类型1
2 RP This document Object-Type 1
2 RP此文档对象类型1
3 NO-PATH This document Object-Type 1
3无路径此文档对象类型1
4 END-POINTS This document Object-Type 1: IPv4 addresses 2: IPv6 addresses
4个端点此文档对象类型1:IPv4地址2:IPv6地址
5 BANDWIDTH This document Object-Type 1: Requested bandwidth 2: Bandwidth of an existing TE LSP for which a reoptimization is performed.
5带宽此文档对象类型1：请求的带宽2：对其执行重新优化的现有TE LSP的带宽。
6 METRIC This document Object-Type 1
6度量此文档对象类型1
7 ERO This document Object-Type 1
7.此文档对象类型为1
8 RRO This document Object-Type 1
8 RRO此文档对象类型1
9 LSPA This document Object-Type 1
9 LSPA此文档对象类型1
10 IRO This document Object-Type 1
10.此文档对象类型为1
11 SVEC This document Object-Type 1
11 SVEC此文档对象类型1
12 NOTIFICATION This document Object-Type 1
12通知此文档对象类型1
13 PCEP-ERROR This document Object-Type 1
13 PCEP-ERROR此文档对象类型1
14 LOAD-BALANCING This document Object-Type 1
14负载平衡此文档对象类型1
15 CLOSE This document Object-Type 1
15关闭此文档对象类型1
IANA created a registry to manage the Flag field of the PCEP Message Common Header.
IANA创建了一个注册表来管理PCEP消息公共头的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
No bits are currently defined for the PCEP message common header.
当前没有为PCEP消息公共标头定义任何位。
IANA created a registry to manage the Flag field of the OPEN object.
IANA创建了一个注册表来管理打开对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
No bits are currently for the OPEN Object flag field.
打开对象标志字段当前没有位。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
Several bits are defined for the RP Object flag field in this document. The following values have been assigned:
本文档中为RP对象标志字段定义了若干位。已指定以下值：
Codespace of the Flag field (RP Object)
标志字段的代码空间（RP对象）
Bit Description Reference
位描述参考
26 Strict/Loose This document 27 Bi-directional This document 28 Reoptimization This document 29-31 Priority This document
26严格/放松本文件27双向本文件28重新优化本文件29-31优先权本文件
IANA created a registry to manage the codespace of the NI field and the Flag field of the NO-PATH object.
IANA创建了一个注册表来管理NO-PATH对象的NI字段和标志字段的代码空间。
Value Meaning Reference
价值意义参照
0 No path satisfying the set This document of constraints could be found 1 PCE chain broken This document
0找不到满足此文档约束集的路径1 PCE链已断开此文档
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
One bit is defined for the NO-PATH Object flag field in this document:
本文档中的无路径对象标志字段定义了一位：
Codespace of the Flag field (NO-PATH Object)
标志字段的代码空间（无路径对象）
Bit Description Reference
位描述参考
0 Unsatisfied constraint indicated This document
0未满足的约束指示此文档
IANA created a registry to manage the codespace of the T field and the Flag field of the METRIC Object.
IANA创建了一个注册表来管理度量对象的T字段和标志字段的代码空间。
Codespace of the T field (Metric Object)
T字段的代码空间（度量对象）
Value Meaning Reference
价值意义参照
1 IGP metric This document 2 TE metric This document 3 Hop Counts This document
1 IGP指标本文件2 TE指标本文件3跃点计数本文件
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
Several bits are defined in this document. The following values have been assigned:
本文档中定义了几个位。已指定以下值：
Codespace of the Flag field (Metric Object)
标志字段的代码空间（度量对象）
Bit Description Reference
位描述参考
6 Computed metric This document 7 Bound This document
6.本文件7.装订本文件
IANA created a registry to manage the Flag field of the LSPA object.
IANA创建了一个注册表来管理LSPA对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
One bit is defined for the LSPA Object flag field in this document:
本文档中为LSPA对象标志字段定义了一位：
Codespace of the Flag field (LSPA Object)
标志字段的代码空间（LSPA对象）
Bit Description Reference
位描述参考
7 Local Protection Desired This document
7本文件要求的本地保护
IANA created a registry to manage the Flag field of the SVEC object.
IANA创建了一个注册表来管理SVEC对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
Three bits are defined for the SVEC Object flag field in this document:
本文件中为SVEC对象标志字段定义了三位：
Codespace of the Flag field (SVEC Object)
标志字段的代码空间（SVEC对象）
Bit Description Reference
位描述参考
21 SRLG Diverse This document 22 Node Diverse This document 23 Link Diverse This document
21 SRLG多样性本文件22节点多样性本文件23链接多样性本文件
IANA created a registry for the Notification-type and Notification-value of the NOTIFICATION object and manages the code space.
IANA为通知对象的通知类型和通知值创建了一个注册表，并管理代码空间。
Notification-type Name Reference 1 Pending Request cancelled This document Notification-value 1: PCC cancels a set of pending requests 2: PCE cancels a set of pending requests
通知类型名称引用1挂起请求已取消此文档通知值1:PCC取消一组挂起请求2:PCE取消一组挂起请求
2 Overloaded PCE This document Notification-value 1: PCE in congested state 2: PCE no longer in congested state
2过载PCE本文档通知值1:PCE处于拥塞状态2:PCE不再处于拥塞状态
IANA created a registry to manage the Flag field of the NOTIFICATION object.
IANA创建了一个注册表来管理通知对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
No bits are currently for the Flag Field of the NOTIFICATION object.
通知对象的标志字段当前没有位。
IANA created a registry for the Error-Type and Error-value of the PCEP Error Object and manages the code space.
IANA为PCEP错误对象的错误类型和错误值创建了一个注册表，并管理代码空间。
For each PCEP error, an Error-Type and an Error-value are defined.
对于每个PCEP错误，定义了错误类型和错误值。
Error- Meaning Reference Type 1 PCEP session establishment failure This document Error-value=1: reception of an invalid Open message or a non Open message. Error-value=2: no Open message received before the expiration of the OpenWait timer Error-value=3: unacceptable and non-negotiable session characteristics Error-value=4: unacceptable but negotiable session characteristics Error-value=5: reception of a second Open message with still unacceptable session characteristics Error-value=6: reception of a PCErr message proposing unacceptable session characteristics Error-value=7: No Keepalive or PCErr message received before the expiration of the KeepWait timer Error-value=8: PCEP version not supported 2 Capability not supported This document 3 Unknown Object This document Error-value=1: Unrecognized object class Error-value=2: Unrecognized object Type 4 Not supported object This document Error-value=1: Not supported object class Error-value=2: Not supported object Type 5 Policy violation This document Error-value=1: C bit of the METRIC object set (request rejected) Error-value=2: O bit of the RP object cleared (request rejected) 6 Mandatory Object missing This document Error-value=1: RP object missing Error-value=2: RRO missing for a reoptimization request (R bit of the RP object set) Error-value=3: END-POINTS object missing 7 Synchronized path computation request missing This document 8 Unknown request reference This document 9 Attempt to establish a second PCEP session This document 10 Reception of an invalid object This document Error-value=1: reception of an object with P flag not set although the P flag must be set according to this specification.
错误-表示参考类型1 PCEP会话建立失败此文档错误值=1：接收无效的打开消息或非打开消息。错误值=2：在OpenWait计时器过期之前未收到打开的消息错误值=3：不可接受和不可协商的会话特征错误值=4：不可接受但可协商的会话特征错误值=5：接收第二条打开的消息，但会话特征仍然不可接受错误值=6：接收PCErr消息建议不可接受的会话特征错误值=7:在KeepWait计时器错误值=8:PCEP版本不受支持2功能不支持此文档3未知对象此文档错误值=1:无法识别的对象类错误值=2:无法识别的对象类型4不支持的对象此文档错误值=1:不支持的对象类错误值=2:不支持的对象类型5策略冲突此文档错误值=1:度量对象集的C位（请求被拒绝）错误值=2:清除的RP对象的O位（请求被拒绝）6强制对象缺少此文档错误值=1:RP对象缺少错误值=2:RRO缺少重新优化请求（RP对象集的R位）错误值=3：端点对象缺少7同步路径计算请求缺少此文档8未知请求参考此文档9尝试建立第二个PCEP会话此文档10接收无效对象此文档错误值=1：接收未设置P标志的对象，尽管必须设置P标志根据本规范。
IANA created a registry to manage the Flag field of the PCEP-ERROR object.
IANA创建了一个注册表来管理PCEP-ERROR对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
No bits are currently for the Flag Field of the PCEP-ERROR Object.
PCEP-ERROR对象的标志字段当前没有位。
IANA created a registry to manage the Flag field of the LOAD-BALANCING object.
IANA创建了一个注册表来管理负载平衡对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
No bits are currently for the Flag Field of the LOAD-BALANCING Object.
负载平衡对象的标志字段当前没有位。
The CLOSE object MUST be present in each Close message in order to close a PCEP session. The reason field of the CLOSE object specifies the reason for closing the PCEP session. The reason field of the CLOSE object is managed by IANA.
关闭对象必须出现在每条关闭消息中，才能关闭PCEP会话。CLOSE对象的reason字段指定关闭PCEP会话的原因。关闭对象的原因字段由IANA管理。
Reasons
理由
Value Meaning 1 No explanation provided 2 DeadTimer expired 3 Reception of a malformed PCEP message 4 Reception of an unacceptable number of unknown requests/replies 5 Reception of an unacceptable number of unrecognized PCEP messages
值表示1未提供解释2死区计时器过期3接收格式错误的PCEP消息4接收数量不可接受的未知请求/答复5接收数量不可接受的未识别PCEP消息
IANA created a registry to manage the flag field of the CLOSE object.
IANA创建了一个注册表来管理关闭对象的标志字段。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新的位号只能由IETF一致行动分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
No bits are currently for the Flag Field of the CLOSE Object.
关闭对象的标志字段当前没有位。
IANA created a registry for the PCEP TLVs.
IANA为PCEP TLV创建了一个注册表。
Value Meaning Reference
价值意义参照
1 NO-PATH-VECTOR TLV This document 2 OVERLOAD-DURATION TLV This document 3 REQ-MISSING TLV This document
1无路径向量TLV本文件2过载持续时间TLV本文件3请求缺失TLV本文件
IANA manages the space of flags carried in the NO-PATH-VECTOR TLV defined in this document, numbering them from 0 as the least significant bit.
IANA管理本文档中定义的无路径向量TLV中的标志空间，从0开始将其编号为最低有效位。
New bit numbers may be allocated only by an IETF Consensus action.
新的位号只能由IETF一致行动分配。
Each bit should be tracked with the following qualities:
应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Name flag
o 姓名标志
o Reference
o 参考
Bit Number Name Reference 31 PCE currently unavailable This document 30 Unknown destination This document 29 Unknown source This document
位号名称参考31 PCE当前不可用此文档30未知目的地此文档29未知源此文档
Attacks on PCEP may result in damage to active networks. If path computation responses are changed, the PCC may be encouraged to set up inappropriate LSPs. Such LSPs might deviate to parts of the network susceptible to snooping, or might transit congested or reserved links. Path computation responses may be attacked by modification of the PCRep message, by impersonation of the PCE, or by modification of the PCReq to cause the PCE to perform a different computation from that which was originally requested.
对PCEP的攻击可能会损坏活动网络。如果路径计算响应发生变化，可能会鼓励PCC设置不适当的LSP。这种LSP可能会偏离网络中易受窥探的部分，或者可能会通过拥塞或保留的链路。路径计算响应可能受到以下攻击：修改PCRep消息、模拟PCE或修改PCReq以使PCE执行与最初请求的计算不同的计算。
It is also possible to damage the operation of a PCE through a variety of denial-of-service attacks. Such attacks can cause the PCE to become congested with the result that path computations are supplied too slowly to be of value for PCCs. This could lead to slower-than-acceptable recovery times or delayed LSP establishment. In extreme cases, it may be that service requests are not satisfied.
还可能通过各种拒绝服务攻击破坏PCE的运行。此类攻击可导致PCE变得拥挤，导致路径计算提供得太慢，对PCC没有价值。这可能导致比可接受的恢复时间慢或LSP建立延迟。在极端情况下，可能无法满足服务请求。
PCEP could be the target of the following attacks:
PCEP可能成为以下攻击的目标：
o Spoofing (PCC or PCE impersonation)
o 欺骗（PCC或PCE模拟）
o Snooping (message interception)
o 窥探（消息截获）
o Falsification
o 伪造
o Denial of Service
o 拒绝服务
In inter-AS scenarios when PCE-to-PCE communication is required, attacks may be particularly significant with commercial as well as service-level implications.
在需要PCE到PCE通信的AS间场景中，攻击可能特别严重，具有商业和服务级别影响。
Additionally, snooping of PCEP requests and responses may give an attacker information about the operation of the network. Simply by viewing the PCEP messages someone can determine the pattern of service establishment in the network and can know where traffic is being routed, thereby making the network susceptible to targeted attacks and the data within specific LSPs vulnerable.
此外，窥探PCEP请求和响应可能会向攻击者提供有关网络操作的信息。只需查看PCEP消息，就可以确定网络中服务建立的模式，并知道流量路由的位置，从而使网络容易受到目标攻击，并且特定LSP中的数据容易受到攻击。
The following sections identify mechanisms to protect PCEP against security attacks.
以下各节确定了保护PCEP免受安全攻击的机制。
At the time of writing, TCP-MD5 [RFC2385] is the only available security mechanism for securing the TCP connections that underly PCEP sessions.
在撰写本文时，TCP-MD5[RFC2385]是保护PCEP会话下TCP连接的唯一可用安全机制。
As explained in [RFC2385], the use of MD5 faces some limitations and does not provide as high a level of security as was once believed. A PCEP implementation supporting TCP-MD5 SHOULD be designed so that stronger security keying techniques or algorithms that may be specified for TCP can be easily integrated in future releases.
正如[RFC2385]中所解释的，MD5的使用面临一些限制，并且不能提供曾经认为的高级别安全性。应设计支持TCP-MD5的PCEP实现，以便在将来的版本中可以轻松集成为TCP指定的更强大的安全密钥技术或算法。
The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new security procedures for TCP, but is not yet complete. Since it is believed that [TCP-AUTH] will offer significantly improved security for applications using TCP, implementers should expect to update their implementation as soon as the TCP Authentication Option is published as an RFC.
TCP身份验证选项[TCP-AUTH]（TCP-AO）为TCP指定了新的安全过程，但尚未完成。由于人们相信[TCP-AUTH]将为使用TCP的应用程序提供显著改进的安全性，所以实现者应该期望在TCP身份验证选项作为RFC发布后立即更新其实现。
Implementations MUST support TCP-MD5 and should make the security function available as a configuration option.
实现必须支持TCP-MD5，并应将安全功能作为配置选项提供。
Operators will need to observe that some deployed PCEP implementations may pre-date the completion of [TCP-AUTH], and it will be necessary to configure policy for secure communication between PCEP speakers that support the TCP Authentication Option, and those that don't.
运营商需要注意，一些已部署的PCEP实施可能早于[TCP-AUTH]的完成，并且有必要为支持TCP认证选项的PCEP扬声器和不支持TCP认证选项的PCEP扬声器之间的安全通信配置策略。
An alternative approach for security over TCP transport is to use the Transport Layer Security (TLS) protocol [RFC5246]. This provides protection against eavesdropping, tampering, and message forgery. But TLS doesn't protect the TCP connection itself, because it does not authenticate the TCP header. Thus, it is vulnerable to attacks such as TCP reset attacks (something against which TCP-MD5 does protect). The use of TLS would, however, require the specification of how PCEP initiates TLS handshaking and how it interprets the certificates exchanged in TLS. That specification is out of the scope of this document, but could be the subject of future work.
TCP传输安全的另一种方法是使用传输层安全（TLS）协议[RFC5246]。这提供了防止窃听、篡改和消息伪造的保护。但是TLS不保护TCP连接本身，因为它不验证TCP头。因此，它容易受到诸如TCP重置攻击（TCP-MD5确实可以防止的攻击）之类的攻击。然而，TLS的使用需要规范PCEP如何启动TLS握手以及如何解释在TLS中交换的证书。该规范不在本文件范围内，但可能是未来工作的主题。
Authentication and integrity checks allow the receiver of a PCEP message to know that the message genuinely comes from the node that purports to have sent it and to know whether the message has been modified.
身份验证和完整性检查允许PCEP消息的接收者知道消息确实来自声称已发送它的节点，并知道消息是否已被修改。
The TCP-MD5 mechanism [RFC2385] described in the previous section provides such a mechanism subject to the concerns listed in [RFC2385] and [RFC4278]. These issues will be addressed and resolved by [TCP-AUTH].
上一节中描述的TCP-MD5机制[RFC2385]提供了一种受[RFC2385]和[RFC4278]中所列问题影响的机制。这些问题将由[TCP-AUTH]解决。
Ensuring PCEP communication privacy is of key importance, especially in an inter-AS context, where PCEP communication end-points do not reside in the same AS, as an attacker that intercepts a PCE message could obtain sensitive information related to computed paths and resources.
确保PCEP通信隐私至关重要，尤其是在AS间环境中，因为截获PCE消息的攻击者可能获得与计算路径和资源相关的敏感信息，PCEP通信端点不在AS内。
PCEP privacy can be ensured by encryption. TCP MAY be run over IPsec [RFC4303] tunnels to provide the required encryption. Note that IPsec can also ensure authentication and integrity; in which case, TCP-MD5 or TCP-AO would not be required. However, there is some concern that IPsec on this scale would be hard to configure and operate. Use of IPSec with PCEP is out of the scope of this document and may be addressed in a separate document.
PCEP隐私可以通过加密来保证。TCP可以在IPsec[RFC4303]隧道上运行，以提供所需的加密。请注意，IPsec还可以确保身份验证和完整性；在这种情况下，不需要TCP-MD5或TCP-AO。然而，有人担心这种规模的IPsec将难以配置和操作。在PCEP中使用IPSec不在本文档的范围内，可以在单独的文档中进行说明。
Authentication, tamper protection, and encryption all require the use of keys by sender and receiver.
身份验证、篡改保护和加密都需要发送方和接收方使用密钥。
Although key configuration per session is possible, it may be particularly onerous to operators (in the same way as for the Border Gateway Protocol (BGP) as discussed in [BGP-SEC]). If there is a relatively small number of PCCs and PCEs in the network, manual key configuration MAY be considered a valid choice by the operator, although it is important to be aware of the vulnerabilities introduced by such mechanisms (i.e., configuration errors, social engineering, and carelessness could all give rise to security breaches). Furthermore, manually configured keys are less likely to be regularly updated which also increases the security risk. Where there is a large number of PCCs and PCEs, the operator could find that key configuration and maintenance is a significant burden as each PCC needs to be configured to the PCE.
虽然每个会话的密钥配置是可能的，但对运营商来说可能特别繁重（与[BGP-SEC]中讨论的边界网关协议（BGP）的方式相同）。如果网络中的PCC和PCE数量相对较少，则运营商可以认为手动密钥配置是一种有效的选择，尽管意识到此类机制引入的漏洞（即配置错误、社会工程和粗心大意都可能导致安全漏洞）很重要。此外，手动配置的密钥不太可能定期更新，这也增加了安全风险。在存在大量PCC和PCE的情况下，运营商可能会发现密钥配置和维护是一个巨大的负担，因为每个PCC都需要配置到PCE。
An alternative to individual keys is the use of a group key. A group key is common knowledge among all members of a trust domain. Thus, since the routers in an IGP area or an AS are part of a common trust domain [MPLS-SEC], a PCEP group key MAY be shared among all PCCs and PCEs in an IGP area or AS. The use of a group key will considerably simplify the operator's configuration task while continuing to secure
单个密钥的替代方法是使用组密钥。组密钥是信任域所有成员的共同知识。因此，由于IGP区域或AS中的路由器是公共信任域[MPLS-SEC]的一部分，因此可以在IGP区域或AS中的所有pcc和pce之间共享PCEP组密钥。使用组密钥将大大简化操作员的配置任务，同时继续确保安全
PCEP against attack from outside the network. However, it must be noted that the more entities that have access to a key, the greater the risk of that key becoming public.
防止来自网络外部的攻击。但是，必须注意的是，访问密钥的实体越多，该密钥公开的风险就越大。
With the use of a group key, separate keys would need to be configured for the PCE-to-PCE communications that cross trust domain (e.g., AS) boundaries, but the number of these relationships is likely to be very small.
使用组密钥时，需要为跨越信任域（例如AS）边界的PCE到PCE通信配置单独的密钥，但这些关系的数量可能非常少。
PCE discovery ([RFC5088] and [RFC5089]) is a significant feature for the successful deployment of PCEP in large networks. This mechanism allows a PCC to discover the existence of suitable PCEs within the network without the necessity of configuration. It should be obvious that, where PCEs are discovered and not configured, the PCC cannot know the correct key to use. There are three possible approaches to this problem that retain some aspect of security:
PCE发现（[RFC5088]和[RFC5089]）是在大型网络中成功部署PCEP的重要功能。该机制允许PCC在不需要配置的情况下发现网络中存在合适的pce。显然，在发现PCE且未配置PCE的情况下，PCC无法知道要使用的正确密钥。有三种解决此问题的可能方法可以保留安全性的某些方面：
o The PCCs may use a group key as previously discussed.
o 如前所述，pcc可以使用组密钥。
o The PCCs may use some form of secure key exchange protocol with the PCE (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]). The drawback to this is that IKE implementations on routers are not common and this may be a barrier to the deployment of PCEP. Details are out of the scope of this document and may be addressed in a separate document.
o pcc可以与PCE使用某种形式的安全密钥交换协议（例如因特网密钥交换协议v2（IKE）[RFC4306]）。这样做的缺点是IKE在路由器上的实现并不常见，这可能是PCEP部署的障碍。详细信息不在本文件范围内，可在单独的文件中说明。
o The PCCs may make use of a key server to determine the key to use when talking to the PCE. To some extent, this is just moving the problem, since the PCC's communications with the key server must also be secure (for example, using Kerberos [RFC4120]), but there may some (minor) benefit in scaling if the PCC is to learn about several PCEs and only needs to know one key server. Note that key servers currently have very limited implementation. Details are out of the scope of this document and may be addressed in a separate document.
o pcc可以利用密钥服务器来确定在与PCE通话时要使用的密钥。从某种程度上说，这只是转移了问题，因为PCC与密钥服务器的通信也必须是安全的（例如，使用Kerberos[RFC4120]），但如果PCC要了解多个PCE并且只需要知道一个密钥服务器，那么在扩展方面可能会有一些（微小的）好处。请注意，关键服务器目前的实现非常有限。详细信息不在本文件范围内，可在单独的文件中说明。
PCEP relationships are likely to be long-lived even if the PCEP sessions are repeatedly closed and re-established. Where protocol relationships persist for a large number of protocol interactions or over a long period of time, changes in the keys used by the protocol peers is RECOMMENDED [RFC4107]. Note that TCP-MD5 does not allow the key to be changed without closing and reopening the TCP connection which would result in the PCEP session being terminated and needing to be restarted. That might not be a significant issue for PCEP. Note also that the plans for the TCP Authentication Option [TCP-AUTH] will allow dynamic key change (roll-over) for an active TCP connection.
即使PCEP会话反复关闭并重新建立，PCEP关系也可能长期存在。如果协议关系持续存在大量协议交互或长时间，建议更改协议对等方使用的密钥[RFC4107]。请注意，TCP-MD5不允许在不关闭和重新打开TCP连接的情况下更改密钥，这将导致PCEP会话终止并需要重新启动。这对PCEP来说可能不是什么大问题。还请注意，TCP身份验证选项[TCP-AUTH]的计划将允许活动TCP连接的动态密钥更改（回滚）。
If key exchange is used (for example, through IKE), then it is relatively simple to support dynamic key updates and apply these to PCEP.
如果使用密钥交换（例如，通过IKE），则支持动态密钥更新并将其应用于PCEP相对简单。
Note that in-band key management for the TCP Authentication Option [TCP-AUTH] is currently unresolved.
请注意，TCP身份验证选项[TCP-AUTH]的带内密钥管理目前尚未解决。
[RFC3562] sets out some of the issues for the key management of secure TCP connections.
[RFC3562]阐述了安全TCP连接的密钥管理的一些问题。
Unauthorized access to PCE function represents a variety of potential attacks. Not only may this be a simple denial-of-service attack (see Section 10.7), but it would be a mechanism for an intruder to determine important information about the network and operational network policies simply by inserting bogus computation requests. Furthermore, false computation requests could be used to predict where traffic will be placed in the network when real requests are made, allowing the attacker to target specific network resources.
未经授权访问PCE功能表示各种潜在攻击。这不仅可能是一种简单的拒绝服务攻击（见第10.7节），而且可能是入侵者通过插入虚假计算请求来确定有关网络和操作网络策略的重要信息的一种机制。此外，当发出真实请求时，虚假计算请求可用于预测流量在网络中的位置，从而允许攻击者以特定网络资源为目标。
PCEs SHOULD be configurable for access policy. Where authentication is used, access policy can be achieved through the exchange or configuration of keys as described in Section 10.5. More simple policies MAY be configured on PCEs in the form of access lists where the IP addresses of the legitimate PCCs are listed. Policies SHOULD also be configurable to limit the type of computation requests that are supported from different PCCs.
PCE应可配置访问策略。在使用身份验证的情况下，可以通过第10.5节所述的密钥交换或配置来实现访问策略。可以在pce上以访问列表的形式配置更简单的策略，其中列出了合法pcc的IP地址。策略还应可配置为限制不同PCC支持的计算请求类型。
It is RECOMMENDED that access policy violations are logged by the PCE and are available for inspection by the operator to determine whether attempts have been made to attack the PCE. Such mechanisms MUST be lightweight to prevent them from being used to support denial-of-service attacks (see Section 10.7).
建议PCE记录访问策略违反情况，并可供操作员检查，以确定是否有人试图攻击PCE。此类机制必须是轻量级的，以防止它们被用于支持拒绝服务攻击（参见第10.7节）。
Denial-of-service (DoS) attacks could be mounted at the TCP level or at the PCEP level. That is, the PCE could be attacked through attacks on TCP or through attacks within established PCEP sessions.
拒绝服务（DoS）攻击可以安装在TCP级别或PCEP级别。也就是说，可以通过对TCP的攻击或通过已建立的PCEP会话内的攻击来攻击PCE。
PCEP can be the target of TCP DoS attacks, such as for instance SYN attacks, as is the case for all protocols that run over TCP. Other protocol specifications have investigated this problem and PCEP can share their experience. The reader is referred to the specification
PCEP可能是TCP DoS攻击的目标，例如SYN攻击，所有在TCP上运行的协议都是如此。其他协议规范已经研究了这个问题，PCEP可以分享他们的经验。读者可参考说明书
of the Label Distribution Protocol (LDP) [RFC5036] for example. In order to protect against TCP DoS attacks, PCEP implementations can support the following techniques.
例如，标签分发协议（LDP）[RFC5036]的定义。为了防止TCP DoS攻击，PCEP实现可以支持以下技术。
o PCEP uses a single registered port for all communications. The PCE SHOULD listen for TCP connections only on ports where communication is expected.
o PCEP使用单个注册端口进行所有通信。PCE应仅在需要通信的端口上侦听TCP连接。
o The PCE MAY implement an access list to immediately reject (or discard) TCP connection attempts from unauthorized PCCs.
o PCE可以实现访问列表，以立即拒绝（或放弃）来自未经授权PCC的TCP连接尝试。
o The PCE SHOULD NOT allow parallel TCP connections from the same PCC on the PCEP-registered port.
o PCE不应允许来自PCEP注册端口上相同PCC的并行TCP连接。
o The PCE MAY require the use of the MD5 option on all TCP connections, and MAY reject (or discard) any connection setup attempt that does not use MD5. A PCE MUST NOT accept any SYN packet for which the MD5 segment checksum is invalid. Note, however, that the use of MD5 requires that the receiver use CPU resources to compute the checksum before it can decide to discard an otherwise acceptable SYN segment.
o PCE可能要求在所有TCP连接上使用MD5选项，并且可能拒绝（或放弃）任何不使用MD5的连接设置尝试。PCE不得接受MD5段校验和无效的任何SYN数据包。但是，请注意，MD5的使用要求接收器在决定放弃其他可接受的SYN段之前使用CPU资源来计算校验和。
A PCEP implementation may be subject to DoS attacks within a legitimate PCEP session. For example, a PCC might send a very large number of PCReq messages causing the PCE to become congested or causing requests from other PCCs to be queued.
PCEP实现可能在合法的PCEP会话中受到DoS攻击。例如，PCC可能发送大量PCReq消息，导致PCE拥塞或导致来自其他PCC的请求排队。
Note that the direct use of the Priority field on the RP object to prioritize received requests does not provide any protection since the attacker could set all requests to be of the highest priority.
请注意，直接使用RP对象上的“优先级”字段对收到的请求进行优先级排序不会提供任何保护，因为攻击者可以将所有请求设置为最高优先级。
Therefore, it is RECOMMENDED that PCE implementations include input shaping/policing mechanisms that either throttle the requests received from any one PCC, or apply queuing or priority-degradation techniques to over-communicative PCCs.
因此，建议PCE实现包括输入整形/监管机制，该机制或者限制从任何一个PCC接收的请求，或者对过度通信的PCC应用排队或优先级降低技术。
Such mechanisms MAY be set by default, but SHOULD be available for configuration. Such techniques may be considered particularly important in multi-service-provider environments to protect the resources of one service provider from unwarranted, over-zealous, or malicious use by PCEs in another service provider.
默认情况下可以设置这些机制，但应可用于配置。这些技术在多服务提供商环境中可能被认为是特别重要的，以保护一个服务提供商的资源不被另一个服务提供商中的pce不必要、过度热心或恶意使用。
The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard Douville, Jon Parker, Martin German, and Dennis Aristow for their very valuable input. The authors would also like to thank Fabien Verhaeghe for the very fruitful discussions and useful suggestions. David McGrew and Brian Weis provided valuable input to the Security Considerations section.
作者要感谢Dave Oran、Dean Cheng、Jerry Ash、Igor Bryskin、Carol Iturrade、Siva Sivabalan、Rich Bradford、Richard Douville、Jon Parker、Martin German和Dennis Aristow的宝贵意见。作者还要感谢Fabien Verhaeghe进行了富有成效的讨论并提出了有益的建议。David McGrew和Brian Weis为安全注意事项部分提供了有价值的输入。
Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk, Chris Newman, and Russ Housley provided important input during IESG review.
Ross Callon、Magnus Westerlund、Lars Eggert、Pasi Eronen、Tim Polk、Chris Newman和Russ Housley在IESG审查期间提供了重要信息。
[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月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[BGP-SEC] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
[BGP-SEC]Christian，B.和T.Tauber，“BGP安全要求”，正在进行的工作，2008年11月。
[IEEE.754.1985] IEEE Standard 754, "Standard for Binary Floating-Point Arithmetic", August 1985.
[IEEE.754.1985]IEEE标准754，“二进制浮点运算标准”，1985年8月。
[INTER-LAYER] Oki, E., Roux, J., Kumaki, K., Farrel, A., and T. Takeda, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Work in Progress, January 2009.
[层间]Oki，E.，Roux，J.，Kumaki，K.，Farrel，A.，和T.Takeda，“层间流量工程的PCC-PCE通信和PCE发现要求”，在建工程，2009年1月。
[MPLS-SEC] Fang, L. and M. Behringer, "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC]Fang，L.和M.Behringer，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年11月。
[PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
[PCE-MANAGE]Farrel，A.，“将可管理性部分纳入PCE工作组草案”，正在进行的工作，2009年1月。
[PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008.
[PCE-MONITOR]Vasseur，J.，Roux，J.，和Y.Ikejiri，“基于元素的路径计算体系结构的一套监控工具”，正在进行的工作，2008年11月。
[PCEP-MIB] Stephan, E. and K. Koushik, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB]Stephan，E.和K.Koushik，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2008年11月。
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
[RBNF]Farrel，A.，“各种协议规范中使用的简化巴科斯诺尔形式（RBNF）语法”，正在进行的工作，2008年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[RFC3785]Le Faucheur，F.，Uppili，R.，Vedrene，A.，Merckx，P.，和T.Telkamp，“内部网关协议（IGP）度量作为第二个MPLS流量工程（TE）度量的使用”，BCP 87，RFC 3785，2004年5月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022]Raghunarayan，R.，“传输控制协议（TCP）的管理信息库”，RFC 40222，2005年3月。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]Rescorla，E.和IAB，“编写协议模型”，RFC 41012005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[RFC4278]Bellovin，S.和A.Zinin，“关于TCP MD5签名选项（RFC 2385）和BGP-4规范的标准成熟度差异”，RFC 4278，2006年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）建立MPLS LSP的属性编码”，RFC 5420，2009年2月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.和J.Le Roux，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]Le Roux，J.，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
[RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4927]Le Roux，J.“区域间MPLS和GMPLS流量工程的路径计算元素通信协议（PCECP）特定要求”，RFC 4927，2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月。
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376]Bitar，N.，Zhang，R.，和K.Kumaki，“路径计算元素通信协议（PCECP）的内部AS要求”，RFC 5376，2008年11月。
[TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
[TCP-AUTH]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，正在进行的工作，2008年11月。
Appendix A. PCEP Finite State Machine (FSM)
附录A.PCEP有限状态机（FSM）
The section describes the PCEP finite state machine (FSM). PCEP Finite State Machine
本节介绍PCEP有限状态机（FSM）。有限状态机
+-+-+-+-+-+-+<------+
+------| SessionUP |<---+ |
| +-+-+-+-+-+-+ | |
| | |
| +->+-+-+-+-+-+-+ | |
| | | KeepWait |----+ |
| +--| |<---+ |
|+-----+-+-+-+-+-+-+ | |
|| | | |
|| | | |
|| V | |
|| +->+-+-+-+-+-+-+----+ |
|| | | OpenWait |-------+
|| +--| |<------+
||+----+-+-+-+-+-+-+<---+ |
||| | | |
||| | | |
||| V | |
||| +->+-+-+-+-+-+-+ | |
||| | |TCPPending |----+ |
||| +--| | |
|||+---+-+-+-+-+-+-+<---+ |
|||| | | |
|||| | | |
|||| V | |
|||+--->+-+-+-+-+ | |
||+---->| Idle |-------+ |
|+----->| |----------+
+------>+-+-+-+-+
+-+-+-+-+-+-+<------+
+------| SessionUP |<---+ |
| +-+-+-+-+-+-+ | |
| | |
| +->+-+-+-+-+-+-+ | |
| | | KeepWait |----+ |
| +--| |<---+ |
|+-----+-+-+-+-+-+-+ | |
|| | | |
|| | | |
|| V | |
|| +->+-+-+-+-+-+-+----+ |
|| | | OpenWait |-------+
|| +--| |<------+
||+----+-+-+-+-+-+-+<---+ |
||| | | |
||| | | |
||| V | |
||| +->+-+-+-+-+-+-+ | |
||| | |TCPPending |----+ |
||| +--| | |
|||+---+-+-+-+-+-+-+<---+ |
|||| | | |
|||| | | |
|||| V | |
|||+--->+-+-+-+-+ | |
||+---->| Idle |-------+ |
|+----->| |----------+
+------>+-+-+-+-+
Figure 23: PCEP Finite State Machine for the PCC
图23:PCC的PCEP有限状态机
PCEP defines the following set of variables:
PCEP定义了以下一组变量：
Connect: the timer (in seconds) started after having initialized a TCP connection using the PCEP-registered TCP port. The value of the Connect timer is 60 seconds.
连接：使用PCEP注册的TCP端口初始化TCP连接后，计时器（秒）启动。连接计时器的值为60秒。
ConnectRetry: the number of times the system has tried to establish a TCP connection with a PCEP peer without success.
ConnectRetry：系统尝试与PCEP对等方建立TCP连接但未成功的次数。
ConnectMaxRetry: the maximum number of times the system tries to establish a TCP connection using the PCEP-registered TCP port before going back to the Idle state. The value of the ConnectMaxRetry is 5.
ConnectMaxRetry：返回空闲状态之前，系统尝试使用PCEP注册的TCP端口建立TCP连接的最大次数。ConnectMaxRetry的值为5。
OpenWait: the timer that corresponds to the amount of time a PCEP peer will wait to receive an Open message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The OpenWait timer has a fixed value of 60 seconds.
OpenWait：对应于PCEP对等机等待从PCEP对等机接收打开消息的时间量的计时器，在该时间到期后，系统释放PCEP资源并返回空闲状态。OpenWait计时器的固定值为60秒。
KeepWait: the timer that corresponds to the amount of time a PCEP peer will wait to receive a Keepalive or a PCErr message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The KeepWait timer has a fixed value of 60 seconds.
KeepWait：对应于PCEP对等机等待从PCEP对等机接收Keepalive或PCErr消息的时间量的计时器，在该时间到期后，系统释放PCEP资源并返回空闲状态。KeepWait计时器的固定值为60秒。
OpenRetry: the number of times the system has received an Open message with unacceptable PCEP session characteristics.
OpenRetry：系统接收到具有不可接受PCEP会话特征的打开消息的次数。
The following two state variables are defined:
定义了以下两个状态变量：
RemoteOK: a boolean that is set to 1 if the system has received an acceptable Open message.
RemoteOK：如果系统收到可接受的打开消息，则将布尔值设置为1。
LocalOK: a boolean that is set to 1 if the system has received a Keepalive message acknowledging that the Open message sent to the peer was valid.
LocalOK：如果系统收到Keepalive消息，确认发送给对等方的打开消息有效，则将布尔值设置为1。
Idle State:
空闲状态：
The idle state is the initial PCEP state where the PCEP (also referred to as "the system") waits for an initialization event that can either be manually triggered by the user (configuration) or automatically triggered by various events. In Idle state, PCEP resources are allocated (memory, potential process, etc.) but no PCEP messages are accepted from any PCEP peer. The system listens to the PCEP-registered TCP port.
空闲状态是初始PCEP状态，其中PCEP（也称为“系统”）等待初始化事件，该事件可以由用户（配置）手动触发，也可以由各种事件自动触发。在空闲状态下，分配PCEP资源（内存、潜在进程等），但不接受来自任何PCEP对等方的PCEP消息。系统侦听PCEP注册的TCP端口。
The following set of variables are initialized:
以下变量集已初始化：
TCPRetry=0,
TCPRetry=0，
LocalOK=0,
LocalOK=0，
RemoteOK=0,
RemoteOK=0，
OpenRetry=0.
OpenRetry=0。
Upon detection of a local initialization event (e.g., user configuration to establish a PCEP session with a particular PCEP peer, local event triggering the establishment of a PCEP session with a PCEP peer such as the automatic detection of a PCEP peer), the system:
在检测到本地初始化事件（例如，用于与特定PCEP对等方建立PCEP会话的用户配置，触发与PCEP对等方建立PCEP会话的本地事件，例如自动检测PCEP对等方）时，系统：
o Initiates a TCP connection with the PCEP peer,
o 启动与PCEP对等方的TCP连接，
o Starts the Connect timer,
o 启动连接计时器，
o Moves to the TCPPending state.
o 移动到TCPPending状态。
Upon receiving a TCP connection on the PCEP-registered TCP port, if the TCP connection establishment succeeds, the system:
在PCEP注册的TCP端口上接收到TCP连接后，如果TCP连接建立成功，系统将：
o Sends an Open message,
o 发送一条公开消息，
o Starts the OpenWait timer,
o 启动OpenWait计时器，
o Moves to the OpenWait state.
o 移动到OpenWait状态。
If the connection establishment fails, the system remains in the Idle state. Any other event received in the Idle state is ignored.
如果连接建立失败，系统将保持空闲状态。在空闲状态下接收到的任何其他事件都将被忽略。
It is expected that an implementation will use an exponentially increasing timer between automatically generated Initialization events and between retries of TCP connection establishment.
预计实现将在自动生成的初始化事件之间和TCP连接建立的重试之间使用指数递增的计时器。
TCPPending State:
TCPPending状态：
If the TCP connection establishment succeeds, the system:
如果TCP连接建立成功，系统将：
o Sends an Open message,
o 发送一条公开消息，
o Starts the OpenWait timer,
o 启动OpenWait计时器，
o Moves to the OpenWait state.
o 移动到OpenWait状态。
If the TCP connection establishment fails (an error is detected during the TCP connection establishment) or the Connect timer expires:
如果TCP连接建立失败（TCP连接建立期间检测到错误）或连接计时器过期：
o If ConnectRetry = ConnectMaxRetry, the system moves to the Idle State.
o 如果ConnectRetry=ConnectMaxRetry，系统将移至空闲状态。
o If ConnectRetry < ConnectMaxRetry, the system:
o 如果ConnectRetry<ConnectMaxRetry，则系统：
1. Initiates of a TCP connection with the PCEP peer,
1. 启动与PCEP对等方的TCP连接，
2. Increments the ConnectRetry variable,
2. 递增ConnectRetry变量，
3. Restarts the Connect timer,
3. 重新启动连接计时器，
4. Stays in the TCPPending state.
4. 保持TCPPEND状态。
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state.
作为对任何其他事件的响应，系统将释放该对等方的PCEP资源并移回空闲状态。
OpenWait State:
OpenWait状态：
In the OpenWait state, the system waits for an Open message from its PCEP peer.
在OpenWait状态下，系统等待来自其PCEP对等方的打开消息。
If the system receives an Open message from the PCEP peer before the expiration of the OpenWait timer, the system first examines all of its sessions that are in the OpenWait or KeepWait state. If another session with the same PCEP peer already exists (same IP address), then the system performs the following collision-resolution procedure:
如果系统在OpenWait计时器到期之前收到来自PCEP对等方的Open消息，则系统首先检查其处于OpenWait或KeepWait状态的所有会话。如果已存在具有相同PCEP对等方的另一个会话（相同IP地址），则系统将执行以下冲突解决过程：
o If the system has initiated the current session and it has a lower IP address than the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state.
o 如果系统已启动当前会话，且其IP地址低于PCEP对等方，则系统将关闭TCP连接，释放挂起会话的PCEP资源，并移回空闲状态。
o If the session was initiated by the PCEP peer and the system has a higher IP address that the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state.
o 如果会话由PCEP对等方发起，且系统的IP地址高于PCEP对等方，则系统将关闭TCP连接，释放挂起会话的PCEP资源，并移回空闲状态。
o Otherwise, the system checks the PCEP session attributes (Keepalive frequency, DeadTimer, etc.).
o 否则，系统将检查PCEP会话属性（保持激活频率、死区计时器等）。
If an error is detected (e.g., malformed Open message, reception of a message that is not an Open message, presence of two OPEN objects), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state.
如果检测到错误（例如，格式错误的打开消息、接收到非打开消息、存在两个打开对象），PCEP将生成错误通知，PCEP对等方将发送错误类型为1且错误值为1的PCErr消息。系统为PCEP对等方释放PCEP资源，关闭TCP连接，并移动到空闲状态。
If no errors are detected, OpenRetry=1, and the session characteristics are unacceptable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=5, and the system releases the PCEP resources for that peer and moves back to the Idle state.
如果未检测到错误，OpenRetry=1，并且会话特征不可接受，则PCEP对等方发送错误类型为1且错误值为5的PCErr，系统释放该对等方的PCEP资源并移回空闲状态。
If no errors are detected, and the session characteristics are acceptable to the local system, the system:
如果未检测到错误，并且本地系统可以接受会话特征，则系统：
o Sends a Keepalive message to the PCEP peer,
o 向PCEP对等方发送Keepalive消息，
o Starts the Keepalive timer,
o 启动Keepalive计时器，
o Sets the RemoteOK variable to 1.
o 将RemoteOK变量设置为1。
If LocalOK=1, the system clears the OpenWait timer and moves to the UP state.
如果LocalOK=1，系统将清除OpenWait计时器并移到UP状态。
If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state.
如果LocalOK=0，系统将清除OpenWait计时器，启动KeepWait计时器，并移动到KeepWait状态。
If no errors are detected, but the session characteristics are unacceptable and non-negotiable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=3, and the system releases the PCEP resources for that peer and moves back to the Idle state.
如果未检测到错误，但会话特征不可接受且不可协商，则PCEP对等方发送错误类型为1且错误值为3的PCErr，系统释放该对等方的PCEP资源并移回空闲状态。
If no errors are detected, and OpenRetry is 0, and the session characteristics are unacceptable but negotiable (such as, the Keepalive period or the DeadTimer), then the system:
如果未检测到错误，且OpenRetry为0，且会话特征不可接受但可协商（如Keepalive period或DeadTimer），则系统：
o Increments the OpenRetry variable,
o 递增OpenRetry变量，
o Sends a PCErr message with Error-Type=1 and Error-value=4 that contains proposed acceptable session characteristics,
o 发送错误类型为1且错误值为4的PCErr消息，该消息包含建议的可接受会话特征，
o If LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state.
o 如果LocalOK=1，系统将重新启动OpenWait计时器并保持OpenWait状态。
o If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state.
o 如果LocalOK=0，系统将清除OpenWait计时器，启动KeepWait计时器，并移动到KeepWait状态。
If no Open message is received before the expiration of the OpenWait timer, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=2, the system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state.
如果在OpenWait计时器过期之前未收到打开消息，则PCEP对等方发送错误类型为1且错误值为2的PCErr消息，系统释放PCEP对等方的PCEP资源，关闭TCP连接，并移动到空闲状态。
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state.
作为对任何其他事件的响应，系统将释放该对等方的PCEP资源并移回空闲状态。
KeepWait State:
保持等待状态：
In the Keepwait state, the system waits for the receipt of a Keepalive from its PCEP peer acknowledging its Open message or a PCErr message in response to unacceptable PCEP session characteristics proposed in the Open message.
在Keepwait状态下，系统等待从其PCEP对等方收到Keepalive，确认其打开消息或PCErr消息，以响应打开消息中提出的不可接受的PCEP会话特征。
If an error is detected (e.g., malformed Keepalive message), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state.
如果检测到错误（例如，格式错误的Keepalive消息），PCEP将生成错误通知，PCEP对等方将发送错误类型为1且错误值为1的PCErr消息。系统为PCEP对等方释放PCEP资源，关闭TCP连接，并移动到空闲状态。
If a Keepalive message is received before the expiration of the KeepWait timer, then the system sets LocalOK=1 and:
如果在KeepWait计时器过期之前收到Keepalive消息，则系统将LocalOK设置为1，并且：
o If RemoteOK=1, the system clears the KeepWait timer and moves to the UP state.
o 如果RemoteOK=1，系统将清除KeepWait计时器并移到UP状态。
o If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait State.
o 如果RemoteOK=0，系统将清除KeepWait计时器，启动OpenWait计时器，并移到OpenWait状态。
If a PCErr message is received before the expiration of the KeepWait timer:
如果在KeepWait计时器到期之前收到PCErr消息：
1. If the proposed values are unacceptable, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=6, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle state.
1. 如果建议的值不可接受，则PCEP对等方发送错误类型为1且错误值为6的PCErr消息，系统释放该PCEP对等方的PCEP资源，关闭TCP连接，并移动到空闲状态。
2. If the proposed values are acceptable, the system adjusts its PCEP session characteristics according to the proposed values received in the PCErr message, restarts the KeepWait timer, and sends a new Open message. If RemoteOK=1, the system restarts the KeepWait timer and stays in the KeepWait state. If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait state.
2. 如果建议值可接受，系统将根据PCErr消息中接收到的建议值调整其PCEP会话特性，重新启动KeepWait计时器，并发送新的Open消息。如果RemoteOK=1，系统将重新启动KeepWait计时器并保持KeepWait状态。如果RemoteOK=0，系统将清除KeepWait计时器，启动OpenWait计时器，并移到OpenWait状态。
If neither a Keepalive nor a PCErr is received after the expiration of the KeepWait timer, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=7, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State.
如果在KeepWait计时器过期后未收到Keepalive或PCErr，则PCEP对等方发送错误类型为1且错误值为7的PCErr消息，系统释放该PCEP对等方的PCEP资源，关闭TCP连接，并移动到空闲状态。
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state.
作为对任何其他事件的响应，系统将释放该对等方的PCEP资源并移回空闲状态。
UP State:
向上状态：
In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics.
在UP状态下，PCEP对等方开始根据会话特征交换PCEP消息。
If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message.
如果Keepalive计时器过期，系统将重新启动Keepalive计时器并发送Keepalive消息。
If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from the PCEP peer before the expiration of the DeadTimer, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State.
如果在死区计时器过期之前没有从PCEP对等方收到任何PCEP消息（Keepalive、PCReq、PCRep、PCNtf），系统将根据第6.8节中定义的过程终止PCEP会话，释放该PCEP对等方的PCEP资源，关闭TCP连接，并移到空闲状态。
If a malformed message is received, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State.
如果收到格式不正确的消息，系统将根据第6.8节中定义的过程终止PCEP会话，释放该PCEP对等方的PCEP资源，关闭TCP连接并移动到空闲状态。
If the system detects that the PCEP peer tries to set up a second TCP connection, it stops the TCP connection establishment and sends a PCErr with Error-Type=9.
如果系统检测到PCEP对等方尝试建立第二个TCP连接，它将停止TCP连接建立并发送错误类型为9的PCErr。
If the TCP connection fails, the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State.
如果TCP连接失败，系统将释放该PCEP对等方的PCEP资源，关闭TCP连接，并移动到空闲状态。
PCEP defines the following configurable variables:
PCEP定义了以下可配置变量：
Keepalive timer: minimum period of time between the sending of PCEP messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A suggested value for the Keepalive timer is 30 seconds.
Keepalive timer：向PCEP对等方发送PCEP消息（Keepalive、PCReq、PCRep、PCNtf）之间的最短时间段。Keepalive计时器的建议值为30秒。
DeadTimer: period of timer after the expiration of which a PCEP peer declares the session down if no PCEP message has been received.
DeadTimer：如果没有收到PCEP消息，则PCEP对等方在该计时器到期后宣布会话关闭的时间段。
SyncTimer: timer used in the case of synchronized path computation request using the SVEC object defined in Section 7.13.3. Consider the case where a PCReq message is received by a PCE that contains the SVEC object referring to M synchronized path computation requests. If after the expiration of the SyncTimer all the M path computation requests have not been received, a protocol error is triggered and the PCE MUST cancel the whole set of path computation requests. The aim of the SyncTimer is to avoid the storage of unused synchronized requests should one of them get lost for some reason (e.g., a misbehaving PCC). Thus, the value
SyncTimer：使用第7.13.3节中定义的SVEC对象进行同步路径计算请求时使用的计时器。考虑PCRE消息由PCE接收的情况，该PCE包含指向M同步路径计算请求的SIEC对象。如果在SyncTimer过期后未收到所有M路径计算请求，则会触发协议错误，并且PCE必须取消整个路径计算请求集。SyncTimer的目的是避免存储未使用的同步请求（如果其中一个请求因某种原因丢失）（例如，行为不端的PCC）。因此，价值
of the SyncTimer must be large enough to avoid the expiration of the timer under normal circumstances. A RECOMMENDED value for the SyncTimer is 60 seconds.
SyncTimer的长度必须足够大，以避免在正常情况下计时器过期。SyncTimer的建议值为60秒。
MAX-UNKNOWN-REQUESTS: A RECOMMENDED value is 5.
MAX-UNKNOWN-REQUESTS：建议值为5。
MAX-UNKNOWN-MESSAGES: A RECOMMENDED value is 5.
MAX-UNKNOWN-MESSAGES：建议值为5。
The content of this document was contributed by those listed below and the editors listed at the end of the document.
本文件的内容由下列人员和文件末尾列出的编辑提供。
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号阿尔西·艾扬加·杜松网络公司，邮编94089
EMail: arthi@juniper.net
EMail: arthi@juniper.net
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944
阿德里安·法雷尔老狗咨询电话：+44（0）1978 860944
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo, 180-8585 JAPAN
日本东京武藏野3-9-11，180-8585
EMail: oki.eiji@lab.ntt.co.jp
EMail: oki.eiji@lab.ntt.co.jp
Alia Atlas British Telecom
英国电信公司
EMail: akatlas@alum.mit.edu
EMail: akatlas@alum.mit.edu
Andrew Dolganow Alcatel 600 March Road Ottawa, ON K2K 2E6 CANADA
加拿大渥太华三月路600号，K2K 2E6，安德鲁·多尔加诺·阿尔卡特
EMail: andrew.dolganow@alcatel.com
EMail: andrew.dolganow@alcatel.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-819 JAPAN
Yuichi Ikejiri NTT通信公司1-1-6 Uchisaiwai cho，日本东京千代田区，100-819
EMail: y.ikejiri@ntt.com
EMail: y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN
Kenji Kumaki KDDI公司花园航空塔Iidabashi，千代田区，东京，102-8460
EMail: ke-kumaki@kddi.com
EMail: ke-kumaki@kddi.com
Authors' Addresses
作者地址
JP Vasseur (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（编辑）思科系统美国马萨诸塞州博克斯堡马萨诸塞大道1414号01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE
JL Le Roux（编辑）法国电信2号，Pierre Marzin Lannion大街22307号，法国
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com