Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8231 Oracle
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
J. Medved
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
September 2017
Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8231 Oracle
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
J. Medved
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
September 2017
Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
有状态PCE的路径计算元素通信协议（PCEP）扩展
Abstract
摘要
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
路径计算元素通信协议（PCEP）为路径计算元素（PCE）提供响应于路径计算客户端（PCC）请求执行路径计算的机制。
Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.
尽管PCEP没有明确对PCE可用的信息做出任何假设，但也没有规定PCE控制PCEP会话内和会话间路径计算的时间和顺序。本文档描述了PCEP的一组扩展，以通过PCEP实现MPLS-TE和GMPLS标签交换路径（LSP）的状态控制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8231.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8231.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Motivation and Objectives for Stateful PCE ......................6
3.1. Motivation .................................................6
3.1.1. Background ..........................................6
3.1.2. Why a Stateful PCE? .................................7
3.1.3. Protocol vs. Configuration ..........................8
3.2. Objectives .................................................9
4. New Functions to Support Stateful PCEs ..........................9
5. Overview of Protocol Extensions ................................10
5.1. LSP State Ownership .......................................10
5.2. New Messages ..............................................11
5.3. Error Reporting ...........................................11
5.4. Capability Advertisement ..................................11
5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement .............................................12
5.6. State Synchronization .....................................13
5.7. LSP Delegation ............................................16
5.7.1. Delegating an LSP ..................................16
5.7.2. Revoking a Delegation ..............................17
5.7.3. Returning a Delegation .............................19
5.7.4. Redundant Stateful PCEs ............................19
5.7.5. Redelegation on PCE Failure ........................20
5.8. LSP Operations ............................................21
5.8.1. Passive Stateful PCE Path Computation
Request/Response ...................................21
5.8.2. Switching from Passive Stateful to Active
Stateful ...........................................22
5.8.3. Active Stateful PCE LSP Update .....................23
5.9. LSP Protection ............................................24
5.10. PCEP Sessions ............................................24
6. PCEP Messages ..................................................25
6.1. The PCRpt Message .........................................25
6.2. The PCUpd Message .........................................27
6.3. The PCErr Message .........................................30
6.4. The PCReq Message .........................................31
6.5. The PCRep Message .........................................31
7. Object Formats .................................................32
7.1. OPEN Object ...............................................32
7.1.1. STATEFUL-PCE-CAPABILITY TLV ........................32
7.2. SRP Object ................................................33
7.3. LSP Object ................................................34
7.3.1. LSP-IDENTIFIERS TLVs ...............................36
7.3.2. Symbolic Path Name TLV .............................39
7.3.3. LSP Error Code TLV .................................40
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Motivation and Objectives for Stateful PCE ......................6
3.1. Motivation .................................................6
3.1.1. Background ..........................................6
3.1.2. Why a Stateful PCE? .................................7
3.1.3. Protocol vs. Configuration ..........................8
3.2. Objectives .................................................9
4. New Functions to Support Stateful PCEs ..........................9
5. Overview of Protocol Extensions ................................10
5.1. LSP State Ownership .......................................10
5.2. New Messages ..............................................11
5.3. Error Reporting ...........................................11
5.4. Capability Advertisement ..................................11
5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement .............................................12
5.6. State Synchronization .....................................13
5.7. LSP Delegation ............................................16
5.7.1. Delegating an LSP ..................................16
5.7.2. Revoking a Delegation ..............................17
5.7.3. Returning a Delegation .............................19
5.7.4. Redundant Stateful PCEs ............................19
5.7.5. Redelegation on PCE Failure ........................20
5.8. LSP Operations ............................................21
5.8.1. Passive Stateful PCE Path Computation
Request/Response ...................................21
5.8.2. Switching from Passive Stateful to Active
Stateful ...........................................22
5.8.3. Active Stateful PCE LSP Update .....................23
5.9. LSP Protection ............................................24
5.10. PCEP Sessions ............................................24
6. PCEP Messages ..................................................25
6.1. The PCRpt Message .........................................25
6.2. The PCUpd Message .........................................27
6.3. The PCErr Message .........................................30
6.4. The PCReq Message .........................................31
6.5. The PCRep Message .........................................31
7. Object Formats .................................................32
7.1. OPEN Object ...............................................32
7.1.1. STATEFUL-PCE-CAPABILITY TLV ........................32
7.2. SRP Object ................................................33
7.3. LSP Object ................................................34
7.3.1. LSP-IDENTIFIERS TLVs ...............................36
7.3.2. Symbolic Path Name TLV .............................39
7.3.3. LSP Error Code TLV .................................40
7.3.4. RSVP Error Spec TLV ................................41
8. IANA Considerations ............................................42
8.1. PCE Capabilities in IGP Advertisements ....................42
8.2. PCEP Messages .............................................43
8.3. PCEP Objects ..............................................43
8.4. LSP Object ................................................44
8.5. PCEP-Error Object .........................................45
8.6. Notification Object .......................................46
8.7. PCEP TLV Type Indicators ..................................46
8.8. STATEFUL-PCE-CAPABILITY TLV ...............................47
8.9. LSP-ERROR-CODE TLV ........................................47
9. Manageability Considerations ...................................48
9.1. Control Function and Policy ...............................48
9.2. Information and Data Models ...............................49
9.3. Liveness Detection and Monitoring .........................49
9.4. Verifying Correct Operation ...............................49
9.5. Requirements on Other Protocols and Functional
Components ................................................50
9.6. Impact on Network Operation ...............................50
10. Security Considerations .......................................50
10.1. Vulnerability ............................................50
10.2. LSP State Snooping .......................................51
10.3. Malicious PCE ............................................51
10.4. Malicious PCC ............................................52
11. References ....................................................52
11.1. Normative References .....................................52
11.2. Informative References ...................................53
Acknowledgements ..................................................55
Contributors ......................................................56
Authors' Addresses ................................................57
7.3.4. RSVP Error Spec TLV ................................41
8. IANA Considerations ............................................42
8.1. PCE Capabilities in IGP Advertisements ....................42
8.2. PCEP Messages .............................................43
8.3. PCEP Objects ..............................................43
8.4. LSP Object ................................................44
8.5. PCEP-Error Object .........................................45
8.6. Notification Object .......................................46
8.7. PCEP TLV Type Indicators ..................................46
8.8. STATEFUL-PCE-CAPABILITY TLV ...............................47
8.9. LSP-ERROR-CODE TLV ........................................47
9. Manageability Considerations ...................................48
9.1. Control Function and Policy ...............................48
9.2. Information and Data Models ...............................49
9.3. Liveness Detection and Monitoring .........................49
9.4. Verifying Correct Operation ...............................49
9.5. Requirements on Other Protocols and Functional
Components ................................................50
9.6. Impact on Network Operation ...............................50
10. Security Considerations .......................................50
10.1. Vulnerability ............................................50
10.2. LSP State Snooping .......................................51
10.3. Malicious PCE ............................................51
10.4. Malicious PCC ............................................52
11. References ....................................................52
11.1. Normative References .....................................52
11.2. Informative References ...................................53
Acknowledgements ..................................................55
Contributors ......................................................56
Authors' Addresses ................................................57
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. Extensions for support of Generalized MPLS (GMPLS) in PCEP are defined in [PCEP-GMPLS].
[RFC5440]描述了路径计算元素通信协议（PCEP）。PCEP定义了路径计算客户端（PCC）和路径计算元素（PCE）之间的通信，或PCE之间的通信，从而能够计算流量工程标签交换路径（TE LSP）特性的多协议标签交换（MPLS）。[PCEP-GMPLS]中定义了PCEP中支持通用MPLS（GMPLS）的扩展。
This document specifies a set of extensions to PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect Label Switched Path (LSP) State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions.
本文档指定了一组PCEP扩展，以根据[RFC4657]在PCEP会话内和会话间对LSP进行有状态控制。它包括用于在PCC和PCE之间实现标签交换路径（LSP）状态同步的机制，将LSP的控制权委托给PCE，以及PCE控制PCEP会话内和跨PCEP会话的路径计算的定时和顺序。
Extensions to permit the PCE to drive creation of an LSP are defined in [PCE-Init-LSP], which specifies PCE-initiated LSP creation.
[PCE Init LSP]中定义了允许PCE驱动LSP创建的扩展，该扩展指定了PCE启动的LSP创建。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, and PCEP speaker.
本文件使用[RFC5440]中定义的以下术语：PCC、PCE、PCEP对等和PCEP扬声器。
This document uses the following terms defined in [RFC4655]: Traffic Engineering Database (TED).
本文件使用[RFC4655]中定义的以下术语：交通工程数据库（TED）。
This document uses the following terms defined in [RFC3031]: LSP.
本文件使用[RFC3031]中定义的以下术语：LSP。
This document uses the following terms defined in [RFC8051]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, and LSP State Database.
本文档使用[RFC8051]中定义的以下术语：有状态PCE、被动有状态PCE、主动有状态PCE、委派和LSP状态数据库。
The following terms are defined in this document:
本文件中定义了以下术语：
Revocation: an operation performed by a PCC on a previously delegated LSP. Revocation revokes the rights granted to the PCE in the delegation operation.
撤销：PCC对先前委托的LSP执行的操作。撤销撤销在委派操作中授予PCE的权限。
Redelegation Timeout Interval: the period of time a PCC waits for, when a PCEP session is terminated, before revoking LSP delegation to a PCE and attempting to redelegate LSPs associated with the terminated PCEP session to an alternate PCE. The Redelegation Timeout Interval is a PCC-local value that can be either operator configured or dynamically computed by the PCC based on local policy.
重新委派超时间隔：PCC在PCEP会话终止时，在撤消对PCE的LSP委派并尝试将与终止的PCEP会话相关联的LSP重新委派到备用PCE之前等待的时间段。重新委派超时时间间隔是一个PCC本地值，可以由操作员配置，也可以由PCC根据本地策略动态计算。
State Timeout Interval: the period of time a PCC waits for, when a PCEP session is terminated, before flushing LSP state associated with that PCEP session and reverting to operator-defined default parameters or behaviors. The State Timeout Interval is a PCC-local value that can be either operator configured or dynamically computed by the PCC based on local policy.
状态超时间隔：PCC在PCEP会话终止时，在刷新与该PCEP会话关联的LSP状态并恢复为操作员定义的默认参数或行为之前等待的时间段。状态超时间隔是一个PCC本地值，可以由操作员配置，也可以由PCC根据本地策略动态计算。
LSP State Report: an operation to send LSP state (operational/ administrative status, LSP attributes configured at the PCC and set by a PCE, etc.) from a PCC to a PCE.
LSP状态报告：从PCC向PCE发送LSP状态（操作/管理状态、在PCC配置并由PCE设置的LSP属性等）的操作。
LSP Update Request: an operation where an Active Stateful PCE requests a PCC to update one or more attributes of an LSP and to re-signal the LSP with updated attributes.
LSP更新请求：一种操作，其中活动有状态PCE请求PCC更新LSP的一个或多个属性，并用更新的属性重新向LSP发送信号。
SRP-ID-number: a number used to correlate errors and LSP State Reports to LSP Update Requests. It is carried in the Stateful PCE Request Parameter (SRP) object described in Section 7.2.
SRP ID编号：用于将错误和LSP状态报告与LSP更新请求关联的编号。它在第7.2节中描述的有状态PCE请求参数（SRP）对象中携带。
Within this document, PCEP communications are described through PCC-PCE relationships. The PCE architecture also supports PCE-PCE communication, by having the requesting PCE fill the role of a PCC, as usual.
在本文件中，PCEP通信通过PCC-PCE关系进行描述。PCE体系结构还支持PCE-PCE通信，通常由请求PCE担任PCC的角色。
The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
本文件中的消息格式使用[RFC5511]中规定的路由Backus-Naur格式（RBNF）编码指定。
[RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments.
[RFC8051]介绍了几个用例，演示了从部署有状态PCE中获益的场景。这些场景同样适用于MPLS-TE和GMPLS部署。
Traffic engineering has been a goal of the MPLS architecture since its inception [RFC2702] [RFC3031] [RFC3346]. In the traffic engineering system provided by [RFC3209], [RFC3630], and [RFC5305],
自MPLS体系结构诞生以来，流量工程一直是其目标[RFC2702][RFC3031][RFC3346]。在[RFC3209]、[RFC3630]和[RFC5305]提供的交通工程系统中，
information about network resources utilization is only available as total reserved capacity by the traffic class on a per-interface basis; individual LSP state is available only locally on each Label Edge Router (LER) for its own LSPs. In most cases, this makes good sense, as distribution and retention of total LSP state for all LERs within in the network would be prohibitively costly.
关于网络资源利用率的信息仅作为每个接口上的流量类别的总保留容量可用；单个LSP状态仅在每个标签边缘路由器（LER）上对其自己的LSP本地可用。在大多数情况下，这是很有意义的，因为为网络中的所有LER分配和保留总LSP状态的成本过高。
Unfortunately, this visibility in terms of global LSP state may result in a number of issues for some demand patterns, particularly within a common setup and hold priority. This issue affects online traffic engineering systems.
不幸的是，这种全局LSP状态的可见性可能会导致某些需求模式出现许多问题，特别是在公共设置和保持优先级中。此问题影响在线流量工程系统。
A sufficiently over-provisioned system will by definition have no issues routing its demand on the shortest path. However, lowering the degree to which network over-provisioning is required in order to run a healthy, functioning network is a clear and explicit promise of MPLS architecture. In particular, it has been a goal of MPLS to provide mechanisms to alleviate congestion scenarios in which "traffic streams are inefficiently mapped onto available resources; causing subsets of network resources to become over-utilized while others remain underutilized" [RFC2702].
根据定义，充足的过度供应系统将不会在最短路径上路由其需求。然而，为了运行一个健康、正常运行的网络，降低网络过度供应的程度是MPLS体系结构的明确承诺。特别是，MPLS的一个目标是提供缓解拥塞情况的机制，在这种情况下，“业务流被无效地映射到可用资源上；导致网络资源子集被过度利用，而其他资源仍然未被充分利用”[RFC2702]。
[RFC4655] defines a stateful PCE to be one in which the PCE maintains "strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network." [RFC4655] also expressed a number of concerns with regard to a stateful PCE, specifically:
[RFC4655]将有状态PCE定义为“PCE与网络状态（拓扑和资源信息方面）以及网络中使用的一组计算路径和保留资源之间保持严格同步。”[RFC4655]还表达了对有状态PCE的一些关注，明确地：
o Any reliable synchronization mechanism would result in significant control-plane overhead
o 任何可靠的同步机制都会导致显著的控制平面开销
o Out-of-band TED synchronization would be complex and prone to race conditions
o 带外TED同步将非常复杂，并且容易出现竞争情况
o Path calculations incorporating total network state would be highly complex
o 包含整个网络状态的路径计算将非常复杂
In general, stress on the control plane will be directly proportional to the size of the system being controlled and the tightness of the control loop and indirectly proportional to the amount of over-provisioning in terms of both network capacity and reservation overhead.
一般来说，控制平面上的压力将与被控制系统的大小和控制回路的紧密性成正比，并间接与网络容量和预留开销方面的过度供应量成正比。
Despite these concerns in terms of implementation complexity and scalability, several TE algorithms exist today that have been demonstrated to be extremely effective in large TE systems, providing both rapid convergence and significant benefits in terms of optimality of resource usage [MXMN-TE]. All of these systems share at least two common characteristics: the requirement for both global visibility of a flow (or in this case, a TE LSP) state and for ordered control of path reservations across devices within the system being controlled. While some approaches have been suggested in order to remove the requirements for ordered control (see [MPLS-PC]), these approaches are highly dependent on traffic distribution and do not allow for multiple simultaneous LSP priorities representing Diffserv classes.
尽管在实现复杂性和可伸缩性方面存在这些问题，但目前存在的几种TE算法已被证明在大型TE系统中非常有效，在优化资源使用方面提供了快速收敛和显著优势[MXMN-TE]。所有这些系统都至少具有两个共同特征：对流（或在本例中为TE LSP）状态的全局可见性的要求，以及对被控制系统内设备间路径预留的有序控制。虽然已经提出了一些方法来消除有序控制的要求（参见[MPLS-PC]），但这些方法高度依赖于流量分布，并且不允许多个同时表示区分服务类的LSP优先级。
The use cases described in [RFC8051] demonstrate a need for visibility into global inter-PCC LSP state in PCE path computations and for PCE control of sequence and timing in altering LSP path characteristics within and across PCEP sessions.
[RFC8051]中描述的用例表明，在PCE路径计算中需要了解全局PCC间LSP状态，并需要在PCEP会话内和会话间改变LSP路径特性时，对序列和定时进行PCE控制。
Note that existing configuration tools and protocols can be used to set LSP state, such as a Command Line Interface (CLI) tool. However, this solution has several shortcomings:
请注意，现有的配置工具和协议可用于设置LSP状态，例如命令行界面（CLI）工具。但是，该解决方案有几个缺点：
o Scale & Performance: configuration operations often have transactional semantics that are typically heavyweight and often require processing of additional configuration portions beyond the state being directly acted upon, with corresponding cost in CPU cycles, negatively impacting both PCC stability LSP Update rate capacity.
o 规模和性能：配置操作通常具有事务语义，这些语义通常是重量级的，并且通常需要处理直接作用于状态之外的其他配置部分，相应的CPU周期成本会对PCC稳定性和LSP更新率容量产生负面影响。
o Security: when a PCC opens a configuration channel allowing a PCE to send configuration, a malicious PCE may take advantage of this ability to take over the PCC. In contrast, the PCEP extensions described in this document only allow a PCE control over a very limited set of LSP attributes.
o 安全性：当PCC打开允许PCE发送配置的配置通道时，恶意PCE可能会利用此能力接管PCC。相反，本文档中描述的PCEP扩展只允许PCE控制非常有限的一组LSP属性。
o Interoperability: each vendor has a proprietary information model for configuring LSP state, which limits interoperability of a stateful PCE with PCCs from different vendors. The PCEP extensions described in this document allow for a common information model for LSP state for all vendors.
o 互操作性：每个供应商都有一个用于配置LSP状态的专有信息模型，这限制了有状态PCE与来自不同供应商的PCC的互操作性。本文档中描述的PCEP扩展为所有供应商提供了LSP状态的通用信息模型。
o Efficient State Synchronization: configuration channels may be heavyweight and unidirectional; therefore, efficient State Synchronization between a PCC and a PCE may be a problem.
o 有效的状态同步：配置通道可能是重量级和单向的；因此，PCC和PCE之间的有效状态同步可能是一个问题。
The objectives for the protocol extensions to support stateful PCE described in this document are as follows:
本文档中描述的支持有状态PCE的协议扩展的目标如下：
o Allow a single PCC to interact with a mix of stateless and stateful PCEs simultaneously using the same protocol, i.e., PCEP.
o 允许单个PCC使用同一协议（即PCEP）同时与无状态和有状态PCE的混合进行交互。
o Support efficient LSP State Synchronization between the PCC and one or more active or passive stateful PCEs.
o 支持PCC和一个或多个主动或被动有状态PCE之间的高效LSP状态同步。
o Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a given LSP is under the control of a single PCE at any given time.
o 允许PCC将其LSP的控制权委托给活动的有状态PCE，从而使给定LSP在任何给定时间处于单个PCE的控制之下。
* A PCC may revoke this delegation at any time during the lifetime of the LSP. If LSP delegation is revoked while the PCEP session is up, the PCC MUST notify the PCE about the revocation.
* PCC可在LSP有效期内的任何时间撤销该委托。如果LSP委派在PCEP会话启动时被撤销，PCC必须将撤销通知PCE。
* A PCE may return an LSP delegation at any point during the lifetime of the PCEP session. If LSP delegation is returned by the PCE while the PCEP session is up, the PCE MUST notify the PCC about the returned delegation.
* PCE可以在PCEP会话生命周期的任何时间点返回LSP委派。如果PCE在PCEP会话结束时返回LSP委派，则PCE必须将返回的委派通知PCC。
o Allow a PCE to control computation timing and update timing across all LSPs that have been delegated to it.
o 允许PCE控制计算定时，并跨已委托给它的所有LSP更新定时。
o Enable uninterrupted operation of a PCC's LSPs in the event of a PCE failure or while control of LSPs is being transferred between PCEs.
o 在PCE发生故障或在PCE之间传输LSP控制时，启用PCC LSP的不间断运行。
Several new functions are required in PCEP to support stateful PCEs. A function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). The new functions are:
PCEP中需要几个新功能来支持有状态的PCE。可以从PCC向PCE（C-E）或从PCE向PCC（E-C）启动功能。新功能包括：
Capability advertisement (E-C,C-E): both the PCC and the PCE must announce during PCEP session establishment that they support PCEP Stateful PCE extensions defined in this document.
能力公告（E-C，C-E）：PCC和PCE必须在PCEP会话建立期间宣布，它们支持本文档中定义的PCEP有状态PCE扩展。
LSP State Synchronization (C-E): after the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a PCC's LSPs before it can perform path computations or update LSP attributes in a PCC.
LSP状态同步（C-E）：PCC和有状态PCE之间的会话初始化后，PCE必须先了解PCC LSP的状态，然后才能执行路径计算或更新PCC中的LSP属性。
LSP Update Request (E-C): a PCE requests modification of attributes on a PCC's LSP.
LSP更新请求（E-C）：PCE请求修改PCC LSP上的属性。
LSP State Report (C-E): a PCC sends an LSP State Report to a PCE whenever the state of an LSP changes.
LSP状态报告（C-E）：只要LSP的状态发生变化，PCC就会向PCE发送LSP状态报告。
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to update LSP attributes on one or more LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (see Section 5.7); the PCC may withdraw the delegation or the PCE may give up the delegation at any time.
LSP控制委派（C-E，E-C）：PCC授予PCE更新一个或多个LSP上的LSP属性的权利；只要授权有效，PCE就成为LSP属性的权威来源（见第5.7节）；PCC可随时撤回授权或放弃授权。
Similarly to [RFC5440], 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.
与[RFC5440]类似，未对PCC用于发现一组PCE的发现方法（例如，通过静态配置或动态发现）和用于选择PCE的算法进行假设。
In PCEP (defined in [RFC5440]), LSP state and operation are under the control of a PCC (a PCC may be a Label Switching Router (LSR) or a management station). Attributes received from a PCE are subject to PCC's local policy. The PCEP extensions described in this document do not change this behavior.
在PCEP（在[RFC5440]中定义）中，LSP状态和操作由PCC控制（PCC可以是标签交换路由器（LSR）或管理站）。从PCE收到的属性受PCC本地政策的约束。本文档中描述的PCEP扩展不会更改此行为。
An active stateful PCE may have control of a PCC's LSPs that were delegated to it, but the LSP state ownership is retained by the PCC. In particular, in addition to specifying values for LSP's attributes, an active stateful PCE also decides when to make LSP modifications.
活动状态PCE可以控制PCC委托给它的LSP，但LSP状态所有权由PCC保留。特别是，除了为LSP的属性指定值外，活动的有状态PCE还决定何时进行LSP修改。
Retaining LSP state ownership on the PCC allows for:
在PCC上保留LSP国家所有权允许：
o a PCC to interact with both stateless and stateful PCEs at the same time
o 同时与无状态和有状态PCE交互的PCC
o a stateful PCE to only modify a small subset of LSP parameters, i.e., to set only a small subset of the overall LSP state; other parameters may be set by the operator, for example, through CLI commands
o 有状态PCE，仅修改LSP参数的小子集，即，仅设置整体LSP状态的小子集；其他参数可由操作员设置，例如，通过CLI命令
o a PCC to revert delegated LSP to an operator-defined default or to delegate the LSPs to a different PCE, if the PCC gets disconnected from a PCE with currently delegated LSPs
o 如果PCC与具有当前委派LSP的PCE断开连接，则PCC将委派LSP恢复为运营商定义的默认值，或将LSP委派给不同的PCE
In this document, we define the following new PCEP messages:
在本文档中，我们定义了以下新的PCEP消息：
Path Computation State Report (PCRpt): a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs. Each LSP State Report in a PCRpt message MAY contain the actual LSP's path, bandwidth, operational and administrative status, etc. An LSP Status Report carried on a PCRpt message is also used in delegation or revocation of control of an LSP to/from a PCE. The PCRpt message is described in Section 6.1.
路径计算状态报告（PCRpt）：由PCC发送给PCE的PCEP消息，用于报告一个或多个LSP的状态。PCRpt消息中的每个LSP状态报告可能包含实际LSP的路径、带宽、操作和管理状态等。PCRpt消息中携带的LSP状态报告也用于向PCE委派或撤销对LSP的控制。第6.1节描述了PCRpt消息。
Path Computation Update Request (PCUpd): a PCEP message sent by a PCE to a PCC to update LSP parameters, on one or more LSPs. Each LSP Update Request on a PCUpd message MUST contain all LSP parameters that a PCE wishes to be set for a given LSP. An LSP Update Request carried on a PCUpd message is also used to return LSP delegations if at any point PCE no longer desires control of an LSP. The PCUpd message is described in Section 6.2.
路径计算更新请求（PCUpd）：PCE向PCC发送的PCEP消息，用于更新一个或多个LSP上的LSP参数。PCUpd消息上的每个LSP更新请求必须包含PCE希望为给定LSP设置的所有LSP参数。如果PCE不再希望控制LSP，则PCUpd消息上携带的LSP更新请求也可用于返回LSP委派。第6.2节描述了PCUpd消息。
The new functions defined in Section 4 are mapped onto the new messages as shown in the following table.
第4节中定义的新功能映射到新消息上，如下表所示。
+----------------------------------------+--------------+
| Function | Message |
+----------------------------------------+--------------+
| Capability Advertisement (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd |
+----------------------------------------+--------------+
+----------------------------------------+--------------+
| Function | Message |
+----------------------------------------+--------------+
| Capability Advertisement (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd |
+----------------------------------------+--------------+
Table 1: New Function to Message Mapping
表1：新函数到消息的映射
Error reporting is done using the procedures defined in [RFC5440] and reusing the applicable error types and error values of [RFC5440] wherever appropriate. The current document defines new error values for several error types to cover failures specific to stateful PCE.
使用[RFC5440]中定义的程序进行错误报告，并在适当情况下重用[RFC5440]中适用的错误类型和错误值。当前文档为几种错误类型定义了新的错误值，以涵盖特定于有状态PCE的故障。
During the PCEP initialization phase, PCEP speakers (PCE or PCC) advertise their support of PCEP Stateful PCE extensions. A PCEP speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in Section 7.1.1, in the OPEN object to advertise its support for PCEP
在PCEP初始化阶段，PCEP扬声器（PCE或PCC）宣传其对PCEP状态PCE扩展的支持。PCEP扬声器在开放对象中包括第7.1.1节所述的“有状态PCE能力TLV”，以宣传其对PCEP的支持
Stateful PCE extensions. The STATEFUL-PCE-CAPABILITY TLV includes the 'LSP Update' flag that indicates whether the PCEP speaker supports LSP parameter updates.
有状态PCE扩展。STATEFUL-PCE-CAPABILITY TLV包含“LSP更新”标志，指示PCEP扬声器是否支持LSP参数更新。
The presence of the STATEFUL-PCE-CAPABILITY TLV in PCC's OPEN object indicates that the PCC is willing to send LSP State Reports whenever LSP parameters or operational status changes.
PCC的开放对象中存在有状态的PCE能力TLV表明，只要LSP参数或运行状态发生变化，PCC愿意发送LSP状态报告。
The presence of the STATEFUL-PCE-CAPABILITY TLV in PCE's OPEN message indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes.
PCE的OPEN消息中存在STATEFUL-PCE-CAPABILITY TLV表示PCE有兴趣在LSP参数或运行状态发生变化时接收LSP状态报告。
The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP speakers have not included the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP speaker on the PCC supports the extensions of this specification but did not advertise this capability, then upon receipt of a PCUpd message from the PCE, it MUST generate a PCEP Error (PCErr) with Error-type=19 (Invalid Operation) and error-value 2 (Attempted LSP Update Request if the stateful PCE capability was not advertised)(see Section 8.5), and it SHOULD terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this specification but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation) and error-value 5 (Attempted LSP State Report if stateful PCE capability was not advertised) (see Section 8.5), and it SHOULD terminate the PCEP session.
如果一个或两个PCEP扬声器在各自的打开信息中未包含stateful-PCE-CAPABILITY TLV，则不得使用有状态PCE的PCEP扩展。如果PCC上的PCEP扬声器支持本规范的扩展，但未公布此功能，则在收到PCE的PCUpd消息后，它必须生成一个PCEP错误（PCErr），错误类型=19（无效操作），错误值为2（如果未公布有状态PCE功能，则尝试LSP更新请求）（参见第8.5节），它应终止PCEP会话。如果PCE上的PCEP扬声器支持本规范的扩展，但未公布此功能，则在从PCC收到PCRpt消息后，它必须生成错误类型为19（无效操作）且错误值为5的PCErr（如果未公布有状态PCE能力，则尝试进行LSP状态报告）（参见第8.5节），并应终止PCEP会话。
LSP delegation and LSP Update operations defined in this document may only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag in the STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)'. If this is not the case and LSP delegation or LSP Update operations are attempted, then a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP) (see Section 8.5) MUST be generated. Note that, even if one of the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its STATEFUL-PCE-CAPABILITY TLV, a PCE can still operate as a passive stateful PCE by accepting LSP State Reports from the PCC in order to build and maintain an up-to-date view of the state of the PCC's LSPs.
只有当两位PCEP发言者将STATEFUL-PCE-CAPABILITY TLV中的LSP-Update-CAPABILITY标志设置为“允许更新（U标志=1）”时，才能使用本文档中定义的LSP委派和LSP更新操作。如果情况并非如此，并且尝试LSP委派或LSP更新操作，则必须生成错误类型为19（无效操作）且错误值为1（针对未委派LSP的尝试LSP更新请求）（参见第8.5节）的PCErr。注意，即使其中一个PCEP扬声器没有在其STATEFUL-PCE-CAPABILITY TLV中设置LSP-UPDATE-CAPABILITY标志，PCE仍然可以通过接受来自PCC的LSP状态报告来作为被动状态PCE运行，以便构建和维护PCC LSP状态的最新视图。
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements. Extensions for the advertisement of PCE Discovery Information are defined for OSPF and for IS-IS in [RFC5088] and [RFC5089], respectively.
当pcc是参与IGP（OSPF或IS-IS）的lsr，并且PCE是也参与IGP的lsr或服务器时，IGP路由域内PCE发现的有效机制包括利用IGP广告。[RFC5088]和[RFC5089]中分别为OSPF和IS-IS定义了PCE发现信息发布的扩展。
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-TLV used to advertise PCE capabilities. It MAY be present within the PCE Discovery (PCED) sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively.
[RFC5089]中定义的PCE-CAP-FLAGS子TLV是用于公布PCE能力的可选子TLV。它可能存在于OSPF或IS-IS携带的PCE发现（PCED）子TLV中。[RFC5088]和[RFC5089]分别为OSPF和IS-IS中携带的子TLV提供描述和处理规则。
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy reference:
PCE-CAP-FLAGS子TLV的格式如下所示，以便于参考：
Type: 5
类型：5
Length: Multiple of 4.
长度：4的倍数。
Value: This contains an array of units of 32-bit flags with the most significant bit as 0. Each bit represents one PCE capability.
值：包含32位标志的单位数组，最高有效位为0。每一位代表一个PCE能力。
PCE capability bits are defined in [RFC5088]. This document defines new capability bits for the stateful PCE as follows:
PCE能力位在[RFC5088]中定义。本文件定义了有状态PCE的新功能位，如下所示：
Bit Capability
--- -------------------------------
11 Active stateful PCE capability
12 Passive stateful PCE capability
Bit Capability
--- -------------------------------
11 Active stateful PCE capability
12 Passive stateful PCE capability
Note that while active and passive stateful PCE capabilities may be advertised during discovery, PCEP speakers that wish to use stateful PCEP MUST negotiate stateful PCEP capabilities during PCEP session setup, as specified in the current document. A PCC MAY initiate stateful PCEP capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisements.
请注意，虽然主动和被动有状态PCE功能可能会在发现期间公布，但希望使用有状态PCEP的PCEP扬声器必须在PCEP会话设置期间协商有状态PCEP功能，如当前文档中所述。PCC可以在PCEP会话设置时启动有状态PCEP能力协商，即使它没有收到任何IGP PCE能力公告。
The purpose of State Synchronization is to provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE. State Synchronization is performed immediately after the initialization phase [RFC5440].
状态同步的目的是在PCE中提供PCC的LSP状态的时间状态副本中的检查点。在初始化阶段[RFC5440]之后立即执行状态同步。
During State Synchronization, a PCC first takes a snapshot of the state of its LSPs, then it sends the snapshot to a PCE in a sequence of LSP State Reports. Each LSP State Report sent during State Synchronization has the SYNC flag in the LSP object set to 1. The set of LSPs for which state is synchronized with a PCE is determined by the PCC's local configuration (see more details in Section 9.1) and MAY also be determined by stateful PCEP capabilities defined in other documents, such as [RFC8232].
在状态同步期间，PCC首先获取其LSP状态的快照，然后以LSP状态报告的顺序将快照发送给PCE。在状态同步期间发送的每个LSP状态报告都将LSP对象中的同步标志设置为1。状态与PCE同步的LSP集由PCC的本地配置确定（详见第9.1节），也可由其他文件（如[RFC8232]）中定义的有状态PCEP功能确定。
The end of the synchronization marker is a PCRpt message with the SYNC flag set to 0 for an LSP object with PLSP-ID equal to the reserved value 0 (see Section 7.3). In this case, the LSP object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP-IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty Explicit Route Object (ERO) as its intended path and SHOULD NOT include the optional Record Route Object (RRO) for its actual path. If the PCC has no state to synchronize, it SHOULD only send the end of the synchronization marker.
同步标记的结尾是一条PCRpt消息，对于PLSP-ID等于保留值0的LSP对象，同步标志设置为0（参见第7.3节）。在这种情况下，LSP对象不应包括符号路径名TLV，而应包括特殊值为全零的LSP标识符TLV。PCRpt消息必须包含一个空的显式路由对象（ERO）作为其预期路径，并且不应包含其实际路径的可选记录路由对象（RRO）。如果PCC没有要同步的状态，它应该只发送同步标记的结束。
A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete. This is to allow the PCE to get the best possible view of the network before it starts computing new paths.
在状态同步完成之前，PCE不应向PCC发送PCUpd消息。在状态同步完成之前，PCC不应向PCE发送PCReq消息。这是为了允许PCE在开始计算新路径之前获得网络的最佳视图。
Either the PCE or the PCC MAY terminate the session using the PCEP session termination procedures during the synchronization phase. If the session is terminated, the PCE MUST clean up the state it received from this PCC. The session re-establishment MUST be re-attempted per the procedures defined in [RFC5440], including use of a backoff timer.
PCE或PCC可以在同步阶段期间使用PCEP会话终止过程来终止会话。如果会话终止，PCE必须清除从该PCC接收到的状态。必须按照[RFC5440]中定义的程序重新尝试会话重建，包括使用退避计时器。
If the PCC encounters a problem that prevents it from completing the LSP State Synchronization, it MUST send a PCErr message with error-type 20 (LSP State Synchronization Error) and error-value 5 (indicating an internal PCC error) to the PCE and terminate the session.
如果PCC遇到阻止其完成LSP状态同步的问题，则必须向PCE发送错误类型为20（LSP状态同步错误）和错误值为5（表示内部PCC错误）的PCErr消息，并终止会话。
The PCE does not send positive acknowledgments for properly received synchronization messages. It MUST respond with a PCErr message with Error-type=20 (LSP State Synchronization Error) and error-value 1 (indicating an error in processing the PCRpt) (see Section 8.5) if it encounters a problem with the LSP State Report it received from the PCC, and it MUST terminate the session.
PCE不会为正确接收的同步消息发送肯定确认。如果从PCC收到的LSP状态报告出现问题，则必须使用错误类型为20（LSP状态同步错误）且错误值为1（表示处理PCRpt时出错）的PCErr消息进行响应（参见第8.5节），并且必须终止会话。
A PCE implementing a limit on the resources a single PCC can occupy MUST send a PCEP Notify (PCNtf) message with Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Value 1 (Entering resource limit exceeded state) in response to the PCRpt message triggering this condition in the synchronization phase and MUST terminate the session.
对单个PCC可以占用的资源实施限制的PCE必须发送通知类型为4（超过有状态PCE资源限制）和通知值为1（进入资源限制超过状态）的PCEP Notify（PCNtf）消息为了响应在同步阶段触发此条件的PCRpt消息，必须终止会话。
The successful State Synchronization sequence is shown in Figure 1.
成功的状态同步序列如图1所示。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->| (Sync start)
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
| |
|-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report
| | for PLSP-ID=0)
| | (Sync done)
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->| (Sync start)
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
| |
|-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report
| | for PLSP-ID=0)
| | (Sync done)
Figure 1: Successful State Synchronization
图1：成功的状态同步
The sequence where the PCE fails during the State Synchronization phase is shown in Figure 2.
PCE在状态同步阶段失败的顺序如图2所示。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| |
|-PCRpt, SYNC=1 |
| \ ,-PCErr |
| \ / |
| \/ |
| /\ |
| / `-------->| (Ignored)
|<--------` |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| |
|-PCRpt, SYNC=1 |
| \ ,-PCErr |
| \ / |
| \/ |
| /\ |
| / `-------->| (Ignored)
|<--------` |
Figure 2: Failed State Synchronization (PCE Failure)
图2：失败的状态同步（PCE失败）
The sequence where the PCC fails during the State Synchronization phase is shown in Figure 3.
PCC在状态同步阶段失败的顺序如图3所示。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-------- PCErr=? ------>|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-------- PCErr=? ------>|
| |
Figure 3: Failed State Synchronization (PCC Failure)
图3：失败的状态同步（PCC失败）
Optimizations to the synchronization procedures and alternate mechanisms of providing the synchronization function are outside the scope of this document and are discussed elsewhere (see [RFC8232]).
同步过程的优化和提供同步功能的替代机制不在本文档的范围内，在其他地方讨论（请参见[RFC8232]）。
If during capability advertisement both the PCE and the PCC have indicated that they support LSP Update, then the PCC may choose to grant the PCE a temporary right to update (a subset of) LSP attributes on one or more LSPs. This is called "LSP delegation", and it MAY be performed at any time after the initialization phase, including during the State Synchronization phase.
如果在能力公布期间PCE和PCC都指示它们支持LSP更新，则PCC可以选择授予PCE在一个或多个LSP上更新LSP属性（其子集）的临时权利。这称为“LSP委派”，可以在初始化阶段之后的任何时间执行，包括在状态同步阶段。
A PCE MAY return an LSP delegation at any time if it no longer wishes to update the LSP's state. A PCC MAY revoke an LSP delegation at any time. Delegation, Revocation, and Return are done individually for each LSP.
如果PCE不再希望更新LSP的状态，则可以随时返回LSP委派。PCC可随时撤销LSP委托。委托、撤销和返回分别针对每个LSP进行。
In the event of a delegation being rejected or returned by a PCE, the PCC SHOULD react based on local policy. It can, for example, either retry delegating to the same PCE using an exponentially increasing timer or delegate to an alternate PCE.
如果PCE拒绝或退回委托，PCC应根据当地政策作出反应。例如，它可以使用指数递增计时器重试委派给同一PCE，也可以委派给备用PCE。
A PCC delegates an LSP to a PCE by setting the Delegate flag in the LSP State Report to 1. If the PCE does not accept the LSP delegation, it MUST immediately respond with an empty LSP Update Request that has the Delegate flag set to 0. If the PCE accepts the LSP delegation, it MUST set the Delegate flag to 1 when it sends an
PCC通过将LSP状态报告中的委托标志设置为1，将LSP委托给PCE。如果PCE不接受LSP委派，它必须立即响应一个空的LSP更新请求，该请求的委派标志设置为0。如果PCE接受LSP委派，则在发送请求时必须将委派标志设置为1
LSP Update Request for the delegated LSP (note that this may occur at a later time). The PCE MAY also immediately acknowledge a delegation by sending an empty LSP Update Request that has the Delegate flag set to 1.
委托LSP的LSP更新请求（请注意，这可能会在以后发生）。PCE还可以通过发送将委托标志设置为1的空LSP更新请求来立即确认委托。
The delegation sequence is shown in Figure 4.
委托顺序如图4所示。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| |
|---PCRpt, Delegate=1--->|
| . |
| . |
| . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| |
|---PCRpt, Delegate=1--->|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| |
|---PCRpt, Delegate=1--->|
| . |
| . |
| . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| |
|---PCRpt, Delegate=1--->|
| |
Figure 4: Delegating an LSP
图4：授权LSP
Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP State Report sent to the PCE.
请注意，要使LSP保持委托给PCE，PCC必须在发送给PCE的每个LSP状态报告中将委托标志设置为1。
When a PCC decides that a PCE is no longer permitted to modify an LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke an LSP delegation at any time during the LSP's lifetime. A PCC revoking an LSP delegation MAY immediately remove the updated parameters provided by the PCE and revert to the operator-defined parameters, but to avoid traffic loss, it SHOULD do so in a make-before-break fashion. If the PCC has received but not yet acted on PCUpd messages from the PCE for the LSP whose delegation is being revoked, then it SHOULD ignore these PCUpd messages when processing the message queue. All effects of all messages for which processing started before the revocation took place MUST be allowed to complete, and the result MUST be given the same treatment as any LSP that had been previously delegated to the PCE (e.g., the state MAY immediately revert to the operator-defined parameters).
当PCC决定不再允许PCE修改LSP时，它将撤销LSP对PCE的授权。PCC可在LSP生命周期内的任何时间撤销LSP委派。撤销LSP委托的PCC可立即删除PCE提供的更新参数，并恢复到运营商定义的参数，但为避免交通损失，应以先通后断的方式进行。如果PCC已从PCE接收到但尚未对其委派被撤销的LSP的PCUpd消息采取行动，则在处理消息队列时应忽略这些PCUpd消息。必须允许在撤销发生之前开始处理的所有消息的所有效果完成，并且必须对结果给予与先前委托给PCE的任何LSP相同的处理（例如，状态可能立即恢复为操作员定义的参数）。
If a PCEP session with the PCE to which the LSP is delegated exists in the UP state during the revocation, the PCC MUST notify that PCE by sending an LSP State Report with the Delegate flag set to 0, as shown in Figure 5.
如果在撤销期间，与LSP被委托到的PCE的PCEP会话处于UP状态，则PCC必须发送一个LSP状态报告，并将委托标志设置为0，以通知该PCE，如图5所示。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->|
| |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| . |
| . |
| . |
|---PCRpt, Delegate=0--->| PCC revokes delegation
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->|
| |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| . |
| . |
| . |
|---PCRpt, Delegate=0--->| PCC revokes delegation
| |
Figure 5: Revoking a Delegation
图5：撤销委派
After an LSP delegation has been revoked, a PCE can no longer update an LSP's parameters; an attempt to update parameters of a non-delegated LSP will result in the PCC sending a PCErr message with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP) (see Section 8.5).
LSP委派被撤销后，PCE不能再更新LSP的参数；尝试更新未授权LSP的参数将导致PCC发送一条PCErr消息，错误类型为19（无效操作），错误值为1（未授权LSP的尝试LSP更新请求）（参见第8.5节）。
When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait the time interval specified in the Redelegation Timeout Interval before revoking LSP delegations to that PCE and attempting to redelegate LSPs to an alternate PCE. If a PCEP session with the original PCE can be re-established before the Redelegation Timeout Interval timer expires, LSP delegations to the PCE remain intact.
当PCC与PCE的PCEP会话意外终止时，PCC必须等待重新委派超时间隔中指定的时间间隔，然后才能撤消对该PCE的LSP委派并尝试将LSP重新委派给备用PCE。如果可以在重新委派超时间隔计时器到期之前重新建立与原始PCE的PCEP会话，则对PCE的LSP委派将保持不变。
Likewise, when a PCC's PCEP session with a PCE terminates unexpectedly, and the PCC does not succeed in redelegating its LSPs, the PCC MUST wait for the State Timeout Interval before flushing any LSP state associated with that PCE. Note that the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE, for example, if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation. In this case, the PCC MUST flush any LSP state set by the PCE upon expiration of the State Timeout Interval and revert to operator-defined default parameters or behaviors. This operation SHOULD be done in a make-before-break fashion.
类似地，当PCC与PCE的PCEP会话意外终止，且PCC无法成功重新委派其LSP时，PCC必须等待状态超时时间间隔，然后才能刷新与该PCE关联的任何LSP状态。请注意，状态超时间隔计时器可能在PCC将LSP重新委派给另一个PCE之前过期，例如，如果PCC未连接到任何活动有状态PCE，或者如果没有连接的活动有状态PCE接受委派。在这种情况下，PCC必须在状态超时间隔到期时刷新PCE设置的任何LSP状态，并恢复到操作员定义的默认参数或行为。此操作应以先通后断的方式进行。
The State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval and MAY be set to infinity (meaning that until the PCC specifically takes action to change the parameters set by the PCE, they will remain intact).
状态超时时间间隔必须大于或等于重新委派超时时间间隔，并且可以设置为无穷大（这意味着在PCC特别采取措施更改PCE设置的参数之前，这些参数将保持不变）。
In order to keep a delegation, a PCE MUST set the Delegate flag to 1 on each LSP Update Request sent to the PCC. A PCE that no longer wishes to update an LSP's parameters SHOULD return the LSP delegation back to the PCC by sending an empty LSP Update Request that has the Delegate flag set to 0. If a PCC receives an LSP Update Request with the Delegate flag set to 0 (whether the LSP Update Request is empty or not), it MUST treat this as a delegation return.
为了保留委派，PCE必须在发送给PCC的每个LSP更新请求中将委派标志设置为1。不再希望更新LSP参数的PCE应通过发送将委托标志设置为0的空LSP更新请求，将LSP委托返回给PCC。如果PCC接收到委托标志设置为0的LSP更新请求（无论LSP更新请求是否为空），则必须将其视为委托返回。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| . |
| . |
| . |
|<--PCUpd, Delegate=0----| Delegation returned
| |
|---PCRpt, Delegate=0--->| No delegation for LSP
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| . |
| . |
| . |
|<--PCUpd, Delegate=0----| Delegation returned
| |
|---PCRpt, Delegate=0--->| No delegation for LSP
| |
Figure 6: Returning a Delegation
图6：返回一个委派
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation), the LSP delegation on the PCC will timeout within a configurable Redelegation Timeout Interval, and the PCC MUST flush any LSP state set by a PCE at the expiration of the State Timeout Interval and revert to operator-defined default parameters or behaviors.
如果PCC无法将LSP委派给PCE（例如，如果PCC未连接到任何活动有状态PCE，或者如果没有连接的活动有状态PCE接受委派），则PCC上的LSP委派将在可配置的重新委派超时间隔内超时，PCC必须在状态超时间隔到期时刷新PCE设置的任何LSP状态，并恢复为操作员定义的默认参数或行为。
In a redundant configuration where one PCE is backing up another PCE, the backup PCE may have only a subset of the LSPs in the network delegated to it. The backup PCE does not update any LSPs that are not delegated to it. In order to allow the backup to operate in a hot-standby mode and avoid the need for State Synchronization in case the primary fails, the backup receives all LSP State Reports from a PCC. When the primary PCE for a given LSP set fails, after expiry of the Redelegation Timeout Interval, the PCC SHOULD delegate to the
在一个PCE备份另一个PCE的冗余配置中，备份PCE在网络中可能只有一个子集的LSP委托给它。备份PCE不会更新任何未委派给它的LSP。为了允许备份在热备份模式下运行，并避免在主设备出现故障时需要进行状态同步，备份将从PCC接收所有LSP状态报告。当给定LSP集的主PCE出现故障时，在重新委派超时间隔到期后，PCC应委派给
redundant PCE all LSPs that had been previously delegated to the failed PCE. Assuming that the State Timeout Interval had been configured to be greater than the Redelegation Timeout Interval (as MANDATORY), and assuming that the primary and redundant PCEs take similar decisions, this delegation change will not cause any changes to the LSP parameters.
冗余PCE以前委托给故障PCE的所有LSP。假设已将状态超时时间间隔配置为大于重新委派超时时间间隔（强制），并且假设主PCE和冗余PCE做出类似的决定，此委派更改不会导致LSP参数发生任何更改。
On failure, the goal is to: 1) avoid any traffic loss on the LSPs that were updated by the PCE that crashed, 2) minimize the churn in the network in terms of ownership of the LSPs, 3) not leave any "orphan" (undelegated) LSPs, and 4) be able to control when the state that was set by the PCE can be changed or purged. The values chosen for the Redelegation Timeout and State Timeout values affect the ability to accomplish these goals.
发生故障时，目标是：1）避免由崩溃的PCE更新的LSP上的任何流量损失，2）在LSP所有权方面最大限度地减少网络中的波动，3）不留下任何“孤立”（未删除）LSP，以及4）能够控制PCE设置的状态何时可以更改或清除。为重新委派超时和状态超时值选择的值会影响实现这些目标的能力。
This section summarizes the behavior with regards to LSP delegation and LSP state on a PCE failure.
本节总结了PCE故障时与LSP委派和LSP状态有关的行为。
If the PCE crashes but recovers within the Redelegation Timeout, both the delegation state and the LSP state are kept intact.
如果PCE崩溃但在重新委派超时内恢复，则委派状态和LSP状态将保持不变。
If the PCE crashes but does not recover within the Redelegation Timeout, the delegation state is returned to the PCC. If the PCC can redelegate the LSPs to another PCE, and that PCE accepts the delegations, there will be no change in LSP state. If the PCC cannot redelegate the LSPs to another PCE, then upon expiration of the State Timeout Interval, the state set by the PCE is removed and the LSP reverts to operator-defined parameters, which may cause a change in the LSP state. Note that an operator may choose to use an infinite State Timeout Interval if he wishes to maintain the PCE state indefinitely. Note also that flushing the state should be implemented using make-before-break to avoid traffic loss.
如果PCE崩溃但未在重新委派超时内恢复，则委派状态将返回给PCC。如果PCC可以将LSP重新委派给另一个PCE，并且该PCE接受委派，则LSP状态不会发生变化。如果PCC无法将LSP重新委派给另一个PCE，则在状态超时间隔到期时，PCE设置的状态将被删除，LSP将恢复为操作员定义的参数，这可能会导致LSP状态发生变化。请注意，如果操作员希望无限期地保持PCE状态，则可以选择使用无限状态超时间隔。还要注意的是，刷新状态应该使用先通后断来实现，以避免交通损失。
If there is a standby PCE, the Redelegation Timeout may be set to 0 through policy on the PCC, causing the LSPs to be redelegated immediately to the PCC, which can delegate them immediately to the standby PCE. Assuming that the PCC can redelegate the LSP to the standby PCE within the State Timeout Interval, and assuming the standby PCE takes similar decisions as the failed PCE, the LSP state will be kept intact.
如果存在备用PCE，则可通过PCC上的策略将重新委派超时设置为0，从而使LSP立即重新委派给PCC，PCC可立即将其委派给备用PCE。假设PCC可以在状态超时间隔内将LSP重新委派给备用PCE，并且假设备用PCE做出与故障PCE类似的决定，则LSP状态将保持不变。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation
PCE | | request received,
| | path computed
| |
|<---- PCRep message ----|3) Computed paths
| (Positive reply) | sent to the PCC
| (Negative reply) |
4) LSP state change | |
event | |
| |
5) LSP State Report |----- PCRpt message --->|
sent to all | . |
stateful PCEs | . |
| . |
6) Repeat for each |----- PCRpt message --->|
LSP state change | |
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation
PCE | | request received,
| | path computed
| |
|<---- PCRep message ----|3) Computed paths
| (Positive reply) | sent to the PCC
| (Negative reply) |
4) LSP state change | |
event | |
| |
5) LSP State Report |----- PCRpt message --->|
sent to all | . |
stateful PCEs | . |
| . |
6) Repeat for each |----- PCRpt message --->|
LSP state change | |
| |
Figure 7: Passive Stateful PCE Path Computation Request/Response
图7：被动有状态PCE路径计算请求/响应
Once a PCC has successfully established a PCEP session with a passive stateful PCE and the PCC's LSP state is synchronized with the PCE (i.e., the PCE knows about all of the PCC's existing LSPs), if an event is triggered that requires the computation of a set of paths, the PCC sends a path computation request to the PCE ([RFC5440], Section 4.2.3). The PCReq message MAY contain the LSP object to identify the LSP for which the path computation is requested.
一旦PCC与被动有状态PCE成功建立PCEP会话，并且PCC的LSP状态与PCE同步（即，PCE知道PCC的所有现有LSP），如果触发需要计算一组路径的事件，PCC将向PCE发送路径计算请求（[RFC5440]，第4.2.3节）. PCReq消息可以包含LSP对象，以标识请求路径计算的LSP。
Upon receiving a path computation request from a PCC, the PCE triggers a path computation and returns either a positive or a negative reply to the PCC ([RFC5440], Section 4.2.4).
收到PCC的路径计算请求后，PCE触发路径计算，并向PCC返回肯定或否定回复（[RFC5440]，第4.2.4节）。
Upon receiving a positive path computation reply, the PCC receives a set of computed paths and starts to set up the LSPs. For each LSP, it MAY send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is "Going-up".
在接收到正路径计算应答时，PCC接收一组计算出的路径并开始设置lsp。对于每个LSP，它可以向PCE发送PCRpt消息中携带的LSP状态报告，指示LSP的状态为“上升”。
Once an LSP is up or active, the PCC MUST send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Up' or 'Active', respectively. If the LSP could not be set up, the PCC MUST send an LSP State Report indicating that the LSP is 'Down' and stating the cause of the failure. Note that due to timing constraints, the LSP status may change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a chance to send an LSP State Report indicating that the status is 'Going-up'. In such cases, the PCC MAY choose to only send the PCRpt indicating the latest status ('Active', 'Up', or 'Down').
LSP启动或激活后，PCC必须向PCE发送PCRpt消息中包含的LSP状态报告，分别指示LSP的状态为“启动”或“激活”。如果无法设置LSP，PCC必须发送一份LSP状态报告，指出LSP“关闭”，并说明故障原因。请注意，由于时间限制，在PCC有机会发送指示状态为“上升”的LSP状态报告之前，LSP状态可能会从“上升”变为“上升”（或“下降”）。在这种情况下，PCC可以选择仅发送指示最新状态的PCRpt（“活动”、“向上”或“向下”）。
Upon receiving a negative reply from a PCE, a PCC MAY resend a modified request or take any other appropriate action. For each requested LSP, it SHOULD also send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
收到PCE的否定回复后，PCC可以重新发送修改后的请求或采取任何其他适当的措施。对于每个请求的LSP，它还应向PCE发送PCRpt消息中包含的LSP状态报告，指示LSP的状态为“关闭”。
There is no direct correlation between PCRep and PCRpt messages. For a given LSP, multiple LSP State Reports will follow a single PCRep message, as a PCC notifies a PCE of the LSP's state changes.
PCRep和PCRpt消息之间没有直接关联。对于给定的LSP，当PCC通知PCE LSP的状态更改时，多个LSP状态报告将跟随单个PCRep消息。
A PCC MUST send each LSP State Report to each stateful PCE that is connected to the PCC.
PCC必须向连接到PCC的每个有状态PCE发送每个LSP状态报告。
Note that a single PCRpt message MAY contain multiple LSP State Reports.
请注意，单个PCRpt消息可能包含多个LSP状态报告。
The passive stateful model for stateful PCEs is described in [RFC4655], Section 6.8.
[RFC4655]第6.8节描述了有状态PCE的被动有状态模型。
This section deals with the scenario of an LSP transitioning from a passive stateful to an active stateful mode of operation. When the LSP has no working path, prior to delegating the LSP, the PCC MUST first use the procedure defined in Section 5.8.1 to request the initial path from the PCE. This is required because the action of delegating the LSP to a PCE using a PCRpt message is not an explicit request to the PCE to compute a path for the LSP. The only explicit way for a PCC to request a path from the PCE is to send a PCReq message. The PCRpt message MUST NOT be used by the PCC to attempt to request a path from the PCE.
本节介绍LSP从被动有状态运行模式过渡到主动有状态运行模式的场景。当LSP没有工作路径时，在授权LSP之前，PCC必须首先使用第5.8.1节中定义的程序从PCE请求初始路径。这是必需的，因为使用PCRpt消息将LSP委派给PCE的操作不是对PCE的明确请求，以计算LSP的路径。PCC从PCE请求路径的唯一明确方式是发送PCReq消息。PCC不得使用PCRpt消息尝试从PCE请求路径。
When the LSP is delegated after its setup, it may be useful for the PCC to communicate to the PCE the locally configured intended configuration parameters, so that the PCE may reuse them in its computations. Such parameters MAY be acquired through an out-of-band channel, or MAY be communicated in the PCRpt message delegating the LSPs, by including them as part of the intended-attribute-list as
当LSP在其设置之后被委派时，PCC将本地配置的预期配置参数传送给PCE可能是有用的，以便PCE可以在其计算中重用它们。这些参数可以通过带外信道获取，或者可以通过将它们作为预期属性列表的一部分包括在指定lsp的PCRpt消息中进行通信
explained in Section 6.1. An implementation MAY allow policies on the PCC to determine the configuration parameters to be sent to the PCE.
如第6.1节所述。一种实现可以允许PCC上的策略确定要发送到PCE的配置参数。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . |
| . |2) PCE decides to
| . | update the LSP
| |
|<---- PCUpd message ----|3) PCUpd message sent
| | to the PCC
| |
| |
4) LSP State Report |---- PCRpt message ---->|
sent(->Going-up) | . |
| . |
| . |
5) LSP State Report |---- PCRpt message ---->|
sent (->Up|Down) | |
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . |
| . |2) PCE decides to
| . | update the LSP
| |
|<---- PCUpd message ----|3) PCUpd message sent
| | to the PCC
| |
| |
4) LSP State Report |---- PCRpt message ---->|
sent(->Going-up) | . |
| . |
| . |
5) LSP State Report |---- PCRpt message ---->|
sent (->Up|Down) | |
| |
Figure 8: Active Stateful PCE
图8：活动状态PCE
Once a PCC has successfully established a PCEP session with an active stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e., the PCE knows about all of the PCC's existing LSPs). After LSPs have been delegated to the PCE, the PCE can modify LSP parameters of delegated LSPs.
一旦PCC成功地与活动的有状态PCE建立PCEP会话，PCC的LSP状态将与PCE同步（即，PCE知道PCC的所有现有LSP）。将LSP委托给PCE后，PCE可以修改委托LSP的LSP参数。
To update an LSP, a PCE MUST send the PCC an LSP Update Request using a PCUpd message. The LSP Update Request contains a variety of objects that specify the set of constraints and attributes for the LSP's path. Each LSP Update Request MUST have a unique identifier, the SRP-ID-number, carried in the SRP object described in Section 7.2. The SRP-ID-number is used to correlate errors and state reports to LSP Update Requests. A single PCUpd message MAY contain multiple LSP Update Requests.
要更新LSP，PCE必须使用PCUpd消息向PCC发送LSP更新请求。LSP更新请求包含多种对象，用于指定LSP路径的约束集和属性。每个LSP更新请求必须具有唯一标识符，即SRP ID号，该标识符包含在第7.2节所述的SRP对象中。SRP ID号用于将错误和状态报告与LSP更新请求关联起来。单个PCUpd消息可能包含多个LSP更新请求。
Upon receiving a PCUpd message, the PCC starts to set up LSPs specified in LSP Update Requests carried in the message. For each LSP, it MAY send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Going-up'. If the PCC
在接收到PCUpd消息后，PCC开始设置消息中携带的LSP更新请求中指定的LSP。对于每个LSP，它可以向PCE发送PCRpt消息中携带的LSP状态报告，指示LSP的状态为“上升”。如果PCC
decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable parameters" in the LSP object in the PCRpt message to the PCE. Based on local policy, it MAY react further to this error by revoking the delegation. If the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that does not exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID) (see Section 8.5).
决定PCUpd消息中建议的LSP参数不可接受，必须通过在PCRpt消息的LSP对象中包含LSP错误值为“不可接受参数”的LSP错误代码TLV（第7.3.3节）向PCE报告此错误。根据当地政策，它可能会通过撤销委派来进一步应对此错误。如果PCC收到PCC上不存在PLSP-ID标识的LSP对象的PCUpd消息，则必须生成错误类型为19（无效操作）、错误值为3的PCErr（尝试对未知PSP-ID标识的LSP进行LSP更新请求）（参见第8.5节）。
Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt message) to the PCE, indicating that the LSP's status is 'Up'. If the LSP could not be set up, the PCC MUST send an LSP State Report indicating that the LSP is 'Down' and stating the cause of the failure. A PCC MAY compress LSP State Reports to only reflect the most up to date state, as discussed in the previous section.
LSP启动后，PCC必须向PCE发送LSP状态报告（PCRpt消息），指示LSP的状态为“启动”。如果无法设置LSP，PCC必须发送一份LSP状态报告，指出LSP“关闭”，并说明故障原因。PCC可以压缩LSP状态报告，以仅反映最新状态，如前一节所述。
A PCC MUST send each LSP State Report to each stateful PCE that is connected to the PCC.
PCC必须向连接到PCC的每个有状态PCE发送每个LSP状态报告。
PCErr and PCRpt messages triggered as a result of a PCUpd message MUST include the SRP-ID-number from the PCUpd. This provides correlation of requests and errors and acknowledgement of state processing. The PCC MAY compress the state when processing PCUpd. In this case, receipt of a higher SRP-ID-number implicitly acknowledges processing all the updates with a lower SRP-ID-number for the specific LSP (as per Section 7.2).
由PCUpd消息触发的PCErr和PCRpt消息必须包含PCUpd中的SRP ID号。这提供了请求和错误的关联以及状态处理的确认。PCC可在处理PCUpd时压缩状态。在这种情况下，接收到较高的SRP ID号，即意味着确认使用较低的SRP ID号处理特定LSP的所有更新（根据第7.2节）。
A PCC MUST NOT send to any PCE a path computation request for a delegated LSP. Should the PCC decide it wants to issue a Path Computation Request on a delegated LSP, it MUST perform the Delegation Revocation procedure first.
PCC不得向任何PCE发送委托LSP的路径计算请求。如果PCC决定要对委托的LSP发出路径计算请求，则必须首先执行委托撤销过程。
LSP protection and interaction with stateful PCE, as well as the extensions necessary to implement this functionality, will be discussed in a separate document.
LSP保护和与有状态PCE的交互，以及实现此功能所需的扩展，将在单独的文档中讨论。
A permanent PCEP session MUST be established between a stateful PCE and the PCC. In the case of session failure, session re-establishment MUST be re-attempted per the procedures defined in [RFC5440].
必须在有状态PCE和PCC之间建立永久PCEP会话。在会话失败的情况下，必须按照[RFC5440]中定义的程序重新尝试会话重建。
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made of a set of objects. For each PCEP message type, a set of rules is defined that specifies the set of objects that the message can carry.
如[RFC5440]中所定义，PCEP消息由一个公共头和一个由一组对象组成的可变长度正文组成。对于每种PCEP消息类型，都定义了一组规则，用于指定消息可以携带的对象集。
A Path Computation LSP State Report message (also referred to as a PCRpt message) is a PCEP message sent by a PCC to a PCE to report the current state of an LSP. A PCRpt message can carry more than one LSP State Reports. A PCC can send an LSP State Report either in response to an LSP Update Request from a PCE or asynchronously when the state of an LSP changes. The Message-Type field of the PCEP common header for the PCRpt message is 10.
路径计算LSP状态报告消息（也称为PCRpt消息）是由PCC发送到PCE以报告LSP的当前状态的PCEP消息。PCRpt消息可以携带多个LSP状态报告。PCC可以发送LSP状态报告以响应PCE的LSP更新请求，也可以在LSP状态更改时异步发送。PCRpt消息的PCEP公用标头的消息类型字段为10。
The format of the PCRpt message is as follows:
PCRpt消息的格式如下：
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]
Where: <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440].
其中：<预期路径>由[RFC5440]第7.9节中定义的ERO对象表示。
<actual-attribute-list> consists of the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440].
<actual attribute list>由[RFC5440]中定义的<BANDWIDTH>和<metric list>对象的实际计算值和信号值组成。
<actual-path> is represented by the RRO object defined in Section 7.10 of [RFC5440].
<actual path>由[RFC5440]第7.10节中定义的RRO对象表示。
<intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440] and extended by PCEP extensions.
<预期属性列表>是[RFC5440]第6.5节中定义并通过PCEP扩展扩展扩展的属性列表。
The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message is not in response to a PCupd message, the SRP object MAY be omitted.
SRP对象（见第7.2节）是可选的。如果PCRpt消息没有响应PCupd消息，则可以省略SRP对象。
When the PCC does not include the SRP object, the PCE MUST treat this as an SRP object with an SRP-ID-number equal to the reserved value 0x00000000. The reserved value 0x00000000 indicates that the state reported is not a result of processing a PCUpd message.
当PCC不包括SRP对象时，PCE必须将其视为SRP对象，SRP ID号等于保留值0x00000000。保留值0x00000000表示报告的状态不是处理PCUpd消息的结果。
If the PCRpt message is in response to a PCUpd message, the SRP object MUST be included and the value of the SRP-ID-number in the SRP object MUST be the same as that sent in the PCUpd message that triggered the state that is reported. If the PCC compressed several PCUpd messages for the same LSP by only processing the one with the highest number, then it should use the SRP-ID-number of that request. No state compression is allowed for state reporting, e.g., PCRpt messages MUST NOT be pruned from the PCC's egress queue even if subsequent operations on the same LSP have been completed before the PCRpt message has been sent to the TCP stack. The PCC MUST explicitly report state changes (including removal) for paths it manages.
如果PCRpt消息响应PCUpd消息，则必须包括SRP对象，并且SRP对象中的SRP ID号的值必须与触发报告状态的PCUpd消息中发送的值相同。如果PCC仅通过处理数量最多的一条来压缩同一LSP的多条PCUpd消息，则应使用该请求的SRP ID号。不允许对状态报告进行状态压缩，例如，即使在PCRpt消息发送到TCP堆栈之前已完成同一LSP上的后续操作，也不得从PCC的出口队列中删除PCRpt消息。PCC必须明确报告其管理的路径的状态更改（包括删除）。
The LSP object (see Section 7.3) is REQUIRED, and it MUST be included in each LSP State Report on the PCRpt message. If the LSP object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value 8 (LSP object missing).
LSP对象（见第7.3节）是必需的，并且必须包含在PCRpt消息的每个LSP状态报告中。如果缺少LSP对象，则接收PCE必须发送一条PCErr消息，错误类型为6（必需缺少对象）且错误值为8（缺少LSP对象）。
If the LSP transitioned to non-operational state, the PCC SHOULD include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error Code to report the error to the PCE.
如果LSP转换为非运行状态，PCC应包括带有相关LSP错误代码的LSP-ERROR-TLV（第7.3.3节），以向PCE报告错误。
The intended path, represented by the ERO object, is REQUIRED. If the ERO object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value 9 (ERO object missing). The ERO may be empty if the PCE does not have a path for a delegated LSP.
需要由ERO对象表示的预期路径。如果ERO对象丢失，接收PCE必须发送一条PCErr消息，错误类型=6（强制对象丢失）和错误值9（ERO对象丢失）。如果PCE没有委托LSP的路径，则ERO可能为空。
The actual path, represented by the RRO object, SHOULD be included in a PCRpt by the PCC when the path is up or active, but it MAY be omitted if the path is down due to a signaling error or another failure.
当路径向上或处于活动状态时，由RRO对象表示的实际路径应由PCC包含在PCRpt中，但如果由于信令错误或其他故障导致路径向下，则可以省略该路径。
The intended-attribute-list maps to the attribute-list in Section 6.5 of [RFC5440] and is used to convey the requested parameters of the LSP path. This is needed in order to support the switch from passive
预期属性列表映射到[RFC5440]第6.5节中的属性列表，并用于传递请求的LSP路径参数。这是必要的，以支持从被动到被动的切换
to active stateful PCE as described in Section 5.8.2. When included as part of the intended-attribute-list, the meaning of the BANDWIDTH object is the requested bandwidth as intended by the operator. In this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, to indicate a limiting constraint, the METRIC object SHOULD be included as part of the intended-attribute-list with the B flag set and with a specific metric value. To indicate the optimization metric, the METRIC object SHOULD be included as part of the intended-attribute-list with the B flag unset and the metric value set to zero. Note that the intended-attribute-list is optional and thus may be omitted. In this case, the PCE MAY use the values in the actual-attribute-list as the requested parameters for the path.
如第5.8.2节所述，激活状态PCE。当作为预期属性列表的一部分包含时，带宽对象的含义是操作员预期的请求带宽。在这种情况下，应使用带宽对象类型1。类似地，为了指示限制约束，应将度量对象作为设置了B标志和特定度量值的预期属性列表的一部分包括在内。要指示优化度量，度量对象应作为预期属性列表的一部分包含，且B标志未设置，度量值设置为零。注意，预期属性列表是可选的，因此可以省略。在这种情况下，PCE可以使用实际属性列表中的值作为路径的请求参数。
The actual-attribute-list consists of the actual computed and signaled values of the BANDWIDTH and METRIC objects defined in [RFC5440]. When included as part of the actual-attribute-list, Object-Type 2 [RFC5440] SHOULD be used for the BANDWIDTH object, and the C flag SHOULD be set in the METRIC object [RFC5440].
实际属性列表包括[RFC5440]中定义的带宽和度量对象的实际计算值和信号值。当包含在实际属性列表中时，应将对象类型2[RFC5440]用于带宽对象，并且应在度量对象[RFC5440]中设置C标志。
Note that the ordering of intended-path, actual-attribute-list, actual-path, and intended-attribute-list is chosen to retain compatibility with implementations of an earlier version of this standard.
注意，选择预期路径、实际属性列表、实际路径和预期属性列表的顺序是为了保持与本标准早期版本实现的兼容性。
A PCE may choose to implement a limit on the resources a single PCC can occupy. If a PCRpt is received that causes the PCE to exceed this limit, the PCE MUST notify the PCC using a PCNtf message with Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Value 1 (Entering resource limit exceeded state), and it MUST terminate the session.
PCE可以选择对单个PCC可以占用的资源实施限制。如果收到的PCRpt导致PCE超过此限制，则PCE必须使用通知类型为4（有状态PCE资源限制已超出）且通知值为1（进入资源限制已超出状态）的PCNtf消息通知PCC，并且必须终止会话。
A Path Computation LSP Update Request message (also referred to as PCUpd message) is a PCEP message sent by a PCE to a PCC to update attributes of an LSP. A PCUpd message can carry more than one LSP Update Request. The Message-Type field of the PCEP common header for the PCUpd message is 11.
路径计算LSP更新请求消息（也称为PCUpd消息）是由PCE发送到PCC以更新LSP的属性的PCEP消息。PCUpd消息可以承载多个LSP更新请求。PCUpd消息的PCEP公共头的消息类型字段为11。
The format of a PCUpd message is as follows:
PCUpd消息的格式如下所示：
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path>::= <intended-path><intended-attribute-list>
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path>::= <intended-path><intended-attribute-list>
Where: <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440].
其中：<预期路径>由[RFC5440]第7.9节中定义的ERO对象表示。
<intended-attribute-list> is the attribute-list defined in [RFC5440] and extended by PCEP extensions.
<destined attribute list>是[RFC5440]中定义并由PCEP扩展扩展的属性列表。
There are three mandatory objects that MUST be included within each LSP Update Request in the PCUpd message: the SRP object (see Section 7.2), the LSP object (see Section 7.3) and the ERO object (as defined in [RFC5440], which represents the intended path. If the SRP object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP object missing). If the LSP object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object missing). If the ERO object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object missing).
PCUpd消息中的每个LSP更新请求中必须包含三个强制对象：SRP对象（见第7.2节）、LSP对象（见第7.3节）和ERO对象（如[RFC5440]中所定义），代表预期路径。如果缺少SRP对象，则接收PCC必须发送错误类型为6的PCErr消息（强制对象缺失）和错误值=10（SRP对象缺失）。如果LSP对象缺失，接收PCC必须发送错误类型=6（强制对象缺失）和错误值=8（LSP对象缺失）的PCErr消息。如果ERO对象缺失，接收PCC必须发送错误类型=6（强制对象缺失）的PCErr消息错误值=9（ERO对象丢失）。
The ERO in the PCUpd may be empty if the PCE cannot find a valid path for a delegated LSP. One typical situation resulting in this empty ERO carried in the PCUpd message is that a PCE can no longer find a strict SRLG-disjoint path for a delegated LSP after a link failure. The PCC SHOULD implement a local policy to decide the appropriate action to be taken: either tear down the LSP or revoke the delegation and use a locally computed path, or keep the existing LSP.
如果PCE找不到委派LSP的有效路径，PCUpd中的ERO可能为空。导致PCUpd消息中携带此空ERO的一种典型情况是，在链路故障后，PCE无法再为委托LSP找到严格的SRLG不相交路径。PCC应实施本地策略，以决定要采取的适当行动：拆除LSP或撤销委托并使用本地计算的路径，或保留现有LSP。
A PCC only acts on an LSP Update Request if permitted by the local policy configured by the network manager. Each LSP Update Request that the PCC acts on results in an LSP setup operation. An LSP Update Request MUST contain all LSP parameters that a PCE wishes to
如果网络管理器配置的本地策略允许，PCC仅对LSP更新请求起作用。PCC处理的每个LSP更新请求都会导致LSP设置操作。LSP更新请求必须包含PCE希望使用的所有LSP参数
be set for the LSP. A PCC MAY set missing parameters from locally configured defaults. If the LSP specified in the Update Request is already up, it will be re-signaled.
设置为LSP。PCC可以根据本地配置的默认值设置缺少的参数。如果更新请求中指定的LSP已启动，则将重新发出信号。
The PCC SHOULD minimize the traffic interruption and MAY use the make-before-break procedures described in [RFC3209] in order to achieve this goal. If the make-before-break procedures are used, two paths will briefly coexist. The PCC MUST send separate PCRpt messages for each, identified by the LSP-IDENTIFIERS TLV. When the old path is torn down after the head end switches over the traffic, this event MUST be reported by sending a PCRpt message with the LSP-IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a make-before-break operation will typically result in at least two PCRpt messages, one for the new path and one for the removal of the old path (more messages may be possible if intermediate states are reported).
PCC应尽量减少交通中断，并可使用[RFC3209]中所述的先通后断程序，以实现这一目标。如果使用先通后断程序，两条路径将短暂共存。PCC必须为每个发送单独的PCRpt消息，由LSP-TLV标识。当前端切换流量后旧路径被拆除时，必须通过发送带有旧路径的LSP-IDENTIFIERS-TLV和R位设置的PCRpt消息来报告此事件。PCC与此PCRpt关联的SRP ID号必须为0x00000000。因此，先通后断操作通常会产生至少两条PCRpt消息，一条用于新路径，另一条用于删除旧路径（如果报告中间状态，可能会有更多消息）。
If the path setup fails due to an RSVP signaling error, the error is reported to the PCE. The PCC will not attempt to re-signal the path until it is prompted again by the PCE with a subsequent PCUpd message.
如果由于RSVP信令错误导致路径设置失败，则该错误将报告给PCE。PCC不会尝试重新发送路径信号，直到PCE再次提示该路径并显示后续PCUpd消息。
A PCC MUST respond with an LSP State Report to each LSP Update Request it processed to indicate the resulting state of the LSP in the network (even if this processing did not result in changing the state of the LSP). The SRP-ID-number included in the PCRpt MUST match that in the PCUpd. A PCC MAY respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included for the first message; for subsequent messages, the reserved value 0x00000000 SHOULD be used.
PCC必须以LSP状态报告对其处理的每个LSP更新请求作出响应，以指示网络中LSP的结果状态（即使此处理没有导致LSP状态的更改）。PCRpt中包含的SRP ID编号必须与PCUpd中的编号匹配。PCC可以使用多个LSP状态报告进行响应，以报告单个LSP的LSP设置进度。在这种情况下，第一条消息必须包含SRP ID号；对于后续消息，应使用保留值0x00000000。
Note that a PCC MUST process all LSP Update Requests -- for example, an LSP Update Request is sent when a PCE returns delegation or puts an LSP into non-operational state. The protocol relies on TCP for message-level flow control.
请注意，PCC必须处理所有LSP更新请求——例如，当PCE返回委派或将LSP置于非操作状态时，会发送LSP更新请求。该协议依赖TCP进行消息级流控制。
If the rate of PCUpd messages sent to a PCC for the same target LSP exceeds the rate at which the PCC can signal LSPs into the network, the PCC MAY perform state compression on its ingress queue. The compression algorithm is based on the fact that each PCUpd request contains the complete LSP state the PCE wishes to be set and works as follows: when the PCC starts processing a PCUpd message at the head of its ingress queue, it may search the queue forward for more recent PCUpd messages pertaining to that particular LSP, prune all but the latest one from the queue, and process only the last one as that request contains the most up-to-date desired state for the LSP. The PCC MUST NOT send PCRpt nor PCErr messages for requests that were
如果针对同一目标LSP发送到PCC的PCUpd消息的速率超过PCC向网络发送LSP信号的速率，则PCC可以对其入口队列执行状态压缩。压缩算法基于以下事实：每个PCUpd请求包含PCE希望设置的完整LSP状态，并按如下方式工作：当PCC开始在其入口队列的头部处理PCUpd消息时，它可以向前搜索队列，以查找与该特定LSP有关的较新PCUpd消息，从队列中删除除最新一个之外的所有请求，并仅处理最后一个请求，因为该请求包含LSP的最新所需状态。PCC不得为已发送的请求发送PCRpt或PCErr消息
pruned from the queue in this way. This compression step may be performed only while the LSP is not being signaled, e.g., if two PCUpd arrive for the same LSP in quick succession and the PCC started the signaling of the changes relevant to the first PCUpd, then it MUST wait until the signaling finishes (and report the new state via a PCRpt) before attempting to apply the changes indicated in the second PCUpd.
以这种方式从队列中删除。此压缩步骤仅可在LSP未被发信号时执行，例如，如果两个PCUpd连续快速到达同一LSP，并且PCC开始发送与第一个PCUpd相关的更改的信号，则它必须等待信号发送完成（并通过PCRpt报告新状态）在尝试应用第二个PCUpd中指示的更改之前。
Note also that it is up to the PCE to handle inter-LSP dependencies; for example, if ordering of LSP setups is required, the PCE has to wait for an LSP State Report for a previous LSP before starting the update of the next LSP.
还要注意，由PCE处理LSP之间的依赖关系；例如，如果需要对LSP设置进行排序，则PCE必须等待上一个LSP的LSP状态报告，然后才能开始更新下一个LSP。
If the PCUpd cannot be satisfied (for example, due to an unsupported object or a TLV), the PCC MUST respond with a PCErr message indicating the failure (see Section 7.3.3).
如果无法满足PCUpd（例如，由于不受支持的对象或TLV），则PCC必须以指示故障的PCErr消息进行响应（见第7.3.3节）。
If the stateful PCE capability has been advertised on the PCEP session, the PCErr message MAY include the SRP object. If the error reported is the result of an LSP Update Request, then the SRP-ID-number MUST be the one from the PCUpd that triggered the error. If the error is unsolicited, the SRP object MAY be omitted. This is equivalent to including an SRP object with the SRP-ID-number equal to the reserved value 0x00000000.
如果有状态PCE功能已在PCEP会话上公布，则PCErr消息可能包括SRP对象。如果报告的错误是LSP更新请求的结果，则SRP ID号必须是触发错误的PCUpd中的编号。如果错误是未经请求的，则可以省略SRP对象。这相当于包含SRP ID号等于保留值0x00000000的SRP对象。
The format of a PCErr message from [RFC5440] is extended as follows:
[RFC5440]的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> | <stateful-request-id-list>]
<error-obj-list>
<error>::=[<request-id-list> | <stateful-request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<request-id-list>::=<RP>[<request-id-list>]
<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]
<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]
<error-list>::=<error>[<error-list>]
<error-list>::=<error>[<error-list>]
A PCC MAY include the LSP object in the PCReq message (see Section 7.3) if the stateful PCE capability has been negotiated on a PCEP session between the PCC and a PCE.
如果在PCC和PCE之间的PCEP会话上协商了有状态PCE能力，则PCC可以在PCReq消息中包括LSP对象（参见第7.3节）。
The definition of the PCReq message from [RFC5440] is extended to optionally include the LSP object after the END-POINTS object. The encoding from [RFC5440] will become:
来自[RFC5440]的PCReq消息的定义扩展为可选地在端点对象之后包括LSP对象。[RFC5440]的编码将变为：
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<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>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
A PCE MAY include the LSP object in the PCRep message (see Section 7.3) if the stateful PCE capability has been negotiated on a PCEP session between the PCC, and the PCE and the LSP object were included in the corresponding PCReq message from the PCC.
如果在PCC之间的PCEP会话上协商了有状态PCE能力，并且PCE和LSP对象包括在来自PCC的相应PCReq消息中，则PCE可以在PCRep消息中包括LSP对象（参见第7.3节）。
The definition of the PCRep message from [RFC5440] is extended to optionally include the LSP object after the Request Parameter (RP) object. The encoding from [RFC5440] will become:
来自[RFC5440]的PCRep消息的定义被扩展，以可选地在请求参数（RP）对象之后包括LSP对象。[RFC5440]的编码将变为：
<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>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
The PCEP objects defined in this document are compliant with the PCEP object format defined in [RFC5440]. The P and I flags of the PCEP objects defined in the current document MUST be set to 0 on transmission and SHOULD be ignored on receipt since they are exclusively related to path computation requests.
本文件中定义的PCEP对象符合[RFC5440]中定义的PCEP对象格式。当前文档中定义的PCEP对象的P和I标志在传输时必须设置为0，并且在接收时应忽略，因为它们专门与路径计算请求相关。
This document defines one new optional TLV for use in the OPEN object.
本文档定义了一个新的可选TLV，用于开放对象。
The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN object for stateful PCE capability advertisement. Its format is shown in the following figure:
STATEFUL-PCE-CAPABILITY TLV是可选的TLV，用于有状态PCE功能播发的开放对象中。其格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: STATEFUL-PCE-CAPABILITY TLV Format
图9:STATEFUL-PCE-CAPABILITY TLV格式
The type (16 bits) of the TLV is 16. The length field is 16 bits long and has a fixed value of 4.
TLV的类型（16位）为16。长度字段的长度为16位，固定值为4。
The value comprises a single field -- Flags (32 bits):
该值由单个字段组成——标志（32位）：
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U flag indicates that the PCC allows modification of LSP parameters; if set to 1 by a PCE, the U flag indicates that the PCE is capable of
U（LSP-UPDATE-CAPABILITY-1位）：如果PCC设置为1，则U标志表示PCC允许修改LSP参数；如果PCE设置为1，则U标志表示PCE能够
updating LSP parameters. The LSP-UPDATE-CAPABILITY flag must be advertised by both a PCC and a PCE for PCUpd messages to be allowed on a PCEP session.
正在更新LSP参数。PCC和PCE都必须公布LSP-UPDATE-CAPABILITY标志，以便在PCEP会话上允许PCUpd消息。
Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt.
未分配的位被认为是保留的。它们在传输时必须设置为0，在接收时必须忽略。
A PCEP speaker operating in passive stateful PCE mode advertises the stateful PCE capability with the U flag set to 0. A PCEP speaker operating in active stateful PCE mode advertises the stateful PCE capability with the U flag set to 1.
在被动有状态PCE模式下工作的PCEP扬声器在U标志设置为0的情况下播发有状态PCE功能。在活动有状态PCE模式下工作的PCEP扬声器在U标志设置为1的情况下播发有状态PCE功能。
Advertisement of the stateful PCE capability implies support of LSPs that are signaled via RSVP, as well as the objects, TLVs, and procedures defined in this document.
有状态PCE功能的公布意味着支持通过RSVP发出信号的LSP，以及本文档中定义的对象、TLV和过程。
The SRP (Stateful PCE Request Parameters) object MUST be carried within PCUpd messages and MAY be carried within PCRpt and PCErr messages. The SRP object is used to correlate between update requests sent by the PCE and the error reports and state reports sent by the PCC.
SRP（有状态PCE请求参数）对象必须包含在PCUpd消息中，也可以包含在PCRpt和PCErr消息中。SRP对象用于将PCE发送的更新请求与PCC发送的错误报告和状态报告关联起来。
SRP Object-Class is 33.
SRP对象类是33。
SRP Object-Type is 1.
SRP对象类型为1。
The format of the SRP object body is shown in Figure 10:
SRP对象体的格式如图10所示：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The SRP Object Format
图10:SRP对象格式
The SRP object body has a variable length and may contain additional TLVs.
SRP对象主体具有可变长度，并且可能包含其他TLV。
Flags (32 bits): None defined yet.
标志（32位）：尚未定义。
SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the current PCEP session uniquely identifies the operation that the PCE has requested the PCC to perform on a given LSP. The SRP-ID-number is incremented each time a new request is sent to the PCC, and it may wrap around.
SRP ID号（32位）：当前PCEP会话范围内的SRP ID号值唯一标识PCE已请求PCC在给定LSP上执行的操作。每次向PCC发送新请求时，SRP ID号都会增加，并且可能会环绕。
The values 0x00000000 and 0xFFFFFFFF are reserved.
保留值0x00000000和0xFFFFFF。
Optional TLVs MAY be included within the SRP object body. The specification of such TLVs is outside the scope of this document.
可选TLV可包含在SRP对象体内。此类TLV的规范不在本文件范围内。
Every request to update an LSP receives a new SRP-ID-number. This number is unique per PCEP session and is incremented each time an operation is requested from the PCE. Thus, for a given LSP, there may be more than one SRP-ID-number unacknowledged at a given time. The value of the SRP-ID-number is echoed back by the PCC in PCErr and PCRpt messages to allow for correlation between requests made by the PCE and errors or state reports generated by the PCC. If the error or report was not a result of a PCE operation (for example, in the case of a link down event), the reserved value of 0x00000000 is used for the SRP-ID-number. The absence of the SRP object is equivalent to an SRP object with the reserved value of 0x00000000. An SRP-ID-number is considered unacknowledged and cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same LSP. In case of SRP-ID-number wrapping, the last SRP-ID-number before the wrapping MUST be explicitly acknowledged, to avoid a situation where SRP-ID-numbers remain unacknowledged after the wrap. This means that the PCC may need to issue two PCUpd messages on detecting a wrap.
每个更新LSP的请求都会收到一个新的SRP ID号。此数字在每个PCEP会话中是唯一的，并且每次从PCE请求操作时都会递增。因此，对于给定LSP，在给定时间可能有多个SRP ID号未确认。PCC在PCErr和PCRpt消息中回显SRP ID号的值，以允许PCE发出的请求与PCC生成的错误或状态报告之间的关联。如果错误或报告不是PCE操作的结果（例如，在链路断开事件的情况下），则SRP ID号使用保留值0x00000000。缺少SRP对象相当于保留值为0x00000000的SRP对象。SRP ID号被认为是未确认的，并且在PCErr或PCRpt到达且SRP ID号等于或高于同一LSP之前，无法重复使用。对于SRP ID号换行，必须明确确认换行前的最后一个SRP ID号，以避免换行后SRP ID号保持未确认的情况。这意味着PCC可能需要在检测包裹时发出两条PCUpd消息。
The LSP object MUST be present within PCRpt and PCUpd messages. The LSP object MAY be carried within PCReq and PCRep messages if the stateful PCE capability has been negotiated on the session. The LSP object contains a set of fields used to specify the target LSP, the operation to be performed on the LSP, and LSP delegation. It also contains a flag indicating to a PCE that the LSP State Synchronization is in progress. This document focuses on LSPs that are signaled with RSVP; many of the TLVs used with the LSP object mirror RSVP state.
LSP对象必须存在于PCRpt和PCUpd消息中。如果在会话上协商了有状态PCE能力，则LSP对象可以在PCReq和PCRep消息中携带。LSP对象包含一组字段，用于指定目标LSP、要在LSP上执行的操作以及LSP委派。它还包含一个标志，向PCE指示LSP状态同步正在进行。本文件重点介绍用RSVP发送信号的LSP；与LSP对象镜像RSVP状态一起使用的许多TLV。
LSP Object-Class is 32.
LSP对象类是32。
LSP Object-Type is 1.
LSP对象类型为1。
The format of the LSP object body is shown in Figure 11:
LSP对象体的格式如图11所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag | O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag | O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The LSP Object Format
图11:LSP对象格式
PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC creates a unique PLSP-ID for each LSP that is constant for the lifetime of a PCEP session. The PCC will advertise the same PLSP-ID on all PCEP sessions it maintains at a given time. The mapping of the symbolic path name to PLSP-ID is communicated to the PCE by sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a value that is constant for the lifetime of the PCEP session, during which time for an RSVP-signaled LSP there might be different RSVP identifiers (LSP-id, tunnel-id) allocated to it.
PLSP-ID（20位）：LSP的PCEP特定标识符。PCC为每个LSP创建一个唯一的PLSP-ID，该ID在PCEP会话的生命周期内保持不变。PCC将在其在给定时间维护的所有PCEP会话上公布相同的PLSP-ID。通过发送包含符号路径名TLV的PCRpt消息，将符号路径名到PLSP-ID的映射传送到PCE。然后，所有后续PCEP消息通过PLSP-ID寻址LSP。保留0和0xFFFFF的值。请注意，PLSP-ID是在PCEP会话的生存期内保持不变的值，在此期间，对于发送RSVP信号的LSP，可能会为其分配不同的RSVP标识符（LSP ID、隧道ID）。
Flags (12 bits), starting from the least significant bit:
标志（12位），从最低有效位开始：
D (Delegate - 1 bit): On a PCRpt message, the D flag set to 1 indicates that the PCC is delegating the LSP to the PCE. On a PCUpd message, the D flag set to 1 indicates that the PCE is confirming the LSP delegation. To keep an LSP delegated to the PCE, the PCC must set the D flag to 1 on each PCRpt message for the duration of the delegation -- the first PCRpt with the D flag set to 0 revokes the delegation. To keep the delegation, the PCE must set the D flag to 1 on each PCUpd message for the duration of the delegation -- the first PCUpd with the D flag set to 0 returns the delegation.
D（委派-1位）：在PCRpt消息上，设置为1的D标志表示PCC正在将LSP委派给PCE。在PCUpd消息上，设置为1的D标志表示PCE正在确认LSP委派。要将LSP委托给PCE，PCC必须在委托期间将每条PCRpt消息上的D标志设置为1——将D标志设置为0的第一个PCRpt将撤销委托。若要保留委派，PCE必须在委派期间将每个PCUpd消息上的D标志设置为1——将D标志设置为0的第一个PCUpd返回委派。
S (SYNC - 1 bit): The S flag MUST be set to 1 on each PCRpt sent from a PCC during State Synchronization. The S flag MUST be set to 0 in other messages sent from the PCC. When sending a PCUpd message, the PCE MUST set the S flag to 0.
S（同步-1位）：在状态同步期间，从PCC发送的每个PCRpt上的S标志必须设置为1。在从PCC发送的其他消息中，S标志必须设置为0。发送PCUpd消息时，PCE必须将S标志设置为0。
R (Remove - 1 bit): On PCRpt messages, the R flag indicates that the LSP has been removed from the PCC and the PCE SHOULD remove all state from its database. Upon receiving an LSP State Report with the R flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD remove all state for the path identified by the LSP-IDENTIFIERS
R（删除-1位）：在PCRpt消息上，R标志表示LSP已从PCC中删除，PCE应从其数据库中删除所有状态。在接收到RSVP信号LSP的R标志设置为1的LSP状态报告后，PCE应删除LSP-1标识符标识的路径的所有状态
TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is used, the PCE SHOULD remove all state for the PLSP-ID from its database. When sending a PCUpd message, the PCE MUST set the R flag to 0.
TLV从其数据库中删除。使用全零LSP-TLV时，PCE应从其数据库中删除PLSP-ID的所有状态。发送PCUpd消息时，PCE必须将R标志设置为0。
A (Administrative - 1 bit): On PCRpt messages, the A flag indicates the PCC's target operational status for this LSP. On PCUpd messages, the A flag indicates the LSP status that the PCE desires for this LSP. In both cases, a value of '1' means that the desired operational state is active, and a value of '0' means that the desired operational state is inactive. A PCC ignores the A flag on a PCUpd message unless the operator's policy allows the PCE to control the corresponding LSP's administrative state.
A（管理-1位）：在PCRpt消息上，A标志表示该LSP的PCC目标运行状态。在PCUpd消息上，A标志指示PCE希望此LSP的LSP状态。在这两种情况下，值“1”表示所需操作状态为活动状态，“0”表示所需操作状态为非活动状态。PCC忽略PCUpd消息上的A标志，除非运营商的策略允许PCE控制相应LSP的管理状态。
O (Operational - 3 bits): On PCRpt messages, the O field represents the operational status of the LSP.
O（操作-3位）：在PCRpt消息上，O字段表示LSP的操作状态。
The following values are defined:
定义了以下值：
0 - DOWN: not active.
0-向下：未激活。
1 - UP: signaled.
1-向上：发出信号。
2 - ACTIVE: up and carrying traffic.
2-主动：启动并承载流量。
3 - GOING-DOWN: LSP is being torn down, and resources are being released.
3-下降：LSP被拆除，资源被释放。
4 - GOING-UP: LSP is being signaled.
4-上升：LSP正在发出信号。
5-7 - Reserved: these values are reserved for future use.
5-7-保留：这些值保留供将来使用。
Unassigned bits are reserved for future uses. They MUST be set to 0 on transmission and MUST be ignored on receipt. When sending a PCUpd message, the PCE MUST set the O field to 0.
未分配的位保留供将来使用。它们在传输时必须设置为0，在接收时必须忽略。发送PCUpd消息时，PCE必须将O字段设置为0。
TLVs that may be included in the LSP object are described in the following sections. Other optional TLVs, that are not defined in this document, MAY also be included within the LSP object body.
LSP对象中可能包含的TLV将在以下部分中描述。本文档中未定义的其他可选TLV也可能包含在LSP对象体中。
The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will generate an error with Error-type=6 (Mandatory Object missing) and error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd messages for RSVP-signaled LSPs. The special value of all zeros for
LSP标识符TLV必须包含在RSVP信号LSP的PCRpt消息中的LSP对象中。如果TLV缺失，PCE将生成错误类型为6（强制对象缺失）和错误值为11（LSP-TLV缺失）的错误，并关闭会话。LSP标识符TLV可以包括在RSVP信号LSP的PCUpd消息中的LSP对象中。所有零的特殊值
this TLV is used to refer to all paths pertaining to a particular PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6.
此TLV用于引用与特定PLSP-ID相关的所有路径。有两个LSP-ID TLV，一个用于IPv4，一个用于IPv6。
It is the responsibility of the PCC to send to the PCE the identifiers for each RSVP incarnation of the tunnel. For example, in a make-before-break scenario, the PCC MUST send a separate PCRpt for the old and reoptimized paths and explicitly report removal of any of these paths using the R bit in the LSP object.
PCC负责向PCE发送隧道每个RSVP化身的标识符。例如，在先通后断方案中，PCC必须为旧路径和重新优化的路径发送单独的PCRpt，并使用LSP对象中的R位显式报告删除这些路径中的任何一条。
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following figure:
IPV4-LSP-TLV的格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=18 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=18 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPV4-LSP-IDENTIFIERS TLV Format
图12:IPV4-LSP-TLV格式
The type (16 bits) of the TLV is 18. The length field is 16 bits long and has a fixed value of 16. The value contains the following fields:
TLV的类型（16位）为18。长度字段的长度为16位，固定值为16。该值包含以下字段：
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, as defined in [RFC3209], Section 4.6.2.1, for the LSP_TUNNEL_IPv4 Sender Template Object.
IPv4隧道发送方地址：包含发送方节点的IPv4地址，如[RFC3209]第4.6.2.1节中为LSP_Tunnel_IPv4发送方模板对象定义的。
LSP ID: contains the 16-bit 'LSP ID' identifier defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template Object. A value of 0 MUST be used if the LSP is not yet signaled.
LSP ID：包含在[RFC3209]第4.6.2.1节中为LSP_TUNNEL_IPv4发送方模板对象定义的16位“LSP ID”标识符。如果LSP尚未发出信号，则必须使用值0。
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
隧道ID：包含在[RFC3209]第4.6.1.1节中为LSP_Tunnel_IPv4会话对象定义的16位“隧道ID”标识符。
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
扩展隧道ID：包含在[RFC3209]第4.6.1.1节中为LSP_Tunnel_IPv4会话对象定义的32位“扩展隧道ID”标识符。
IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 address, as defined in [RFC3209], Section 4.6.1.1, for the LSP_TUNNEL_IPv4 Sender Template Object.
IPv4隧道端点地址：包含出口节点的IPv4地址，如[RFC3209]第4.6.1.1节中为LSP_Tunnel_IPv4发送方模板对象定义的。
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following figure:
IPV6-LSP-TLV的格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=19 | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Sender Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Endpoint Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=19 | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Sender Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Endpoint Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPV6-LSP-IDENTIFIERS TLV Format
图13:IPV6-LSP-TLV格式
The type (16 bits) of the TLV is 19. The length field is 16 bits long and has a fixed value of 52. The value contains the following fields:
TLV的类型（16位）为19。长度字段的长度为16位，固定值为52。该值包含以下字段：
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, as defined in [RFC3209], Section 4.6.2.2, for the LSP_TUNNEL_IPv6 Sender Template Object.
IPv6隧道发送方地址：包含发送方节点的IPv6地址，如[RFC3209]第4.6.2.2节中为LSP_Tunnel_IPv6发送方模板对象定义的。
LSP ID: contains the 16-bit 'LSP ID' identifier defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template Object. A value of 0 MUST be used if the LSP is not yet signaled.
LSP ID：包含在[RFC3209]第4.6.2.2节中为LSP_TUNNEL_IPv6发送方模板对象定义的16位“LSP ID”标识符。如果LSP尚未发出信号，则必须使用值0。
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
隧道ID：包含在[RFC3209]第4.6.1.2节中为LSP_Tunnel_IPv6会话对象定义的16位“隧道ID”标识符。
Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
扩展隧道ID：包含[RFC3209]第4.6.1.2节中为LSP_Tunnel_IPv6会话对象定义的128位“扩展隧道ID”标识符。
IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 address, as defined in [RFC3209], Section 4.6.1.2, for the LSP_TUNNEL_IPv6 Session Object.
IPv6隧道端点地址：包含出口节点的IPv6地址，如[RFC3209]第4.6.1.2节中为LSP_Tunnel_IPv6会话对象定义的。
The Tunnel ID remains constant over the lifetime of a tunnel.
隧道ID在隧道的整个生命周期内保持不变。
Each LSP MUST have a symbolic path name that is unique in the PCC. The symbolic path name is a human-readable string that identifies an LSP in the network. The symbolic path name MUST remain constant throughout an LSP's lifetime, which may span across multiple consecutive PCEP sessions and/or PCC restarts. The symbolic path name MAY be specified by an operator in a PCC's configuration. If the operator does not specify a unique symbolic name for an LSP, then the PCC MUST auto-generate one.
每个LSP必须具有在PCC中唯一的符号路径名。符号路径名是一个人类可读的字符串，用于标识网络中的LSP。符号路径名必须在LSP的整个生命周期内保持不变，这可能跨越多个连续PCEP会话和/或PCC重新启动。符号路径名可由PCC配置中的操作员指定。如果操作员没有为LSP指定唯一的符号名，则PCC必须自动生成一个符号名。
The PCE uses the symbolic path name as a stable identifier for the LSP. If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates the LSP to a different PCE, the symbolic path name for the LSP remains constant and can be used to correlate across the PCEP session instances.
PCE使用符号路径名作为LSP的稳定标识符。如果PCEP会话重新启动，或PCC重新启动，或PCC将LSP重新委托给不同的PCE，则LSP的符号路径名保持不变，并可用于跨PCEP会话实例进行关联。
The other protocol identifiers for the LSP cannot reliably be used to identify the LSP across multiple PCEP sessions, for the following reasons.
由于以下原因，LSP的其他协议标识符不能可靠地用于跨多个PCEP会话识别LSP。
o The PLSP-ID is unique only within the scope of a single PCEP session.
o PLSP-ID仅在单个PCEP会话范围内是唯一的。
o The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs that are signaled with RSVP-TE, and it may change during the lifetime of the LSP.
o LSP-TLV仅保证在用RSVP-TE发信号的LSP中存在，并且它可能在LSP的生存期内发生变化。
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the LSP State Report (PCRpt) message when during a given PCEP session an LSP is first reported to a PCE. A PCC sends to a PCE the first LSP
在给定PCEP会话期间，LSP首次报告给PCE时，LSP状态报告（PCRpt）消息中的LSP对象中必须包含SYMBOL-PATH-NAME TLV。PCC向PCE发送第一个LSP
State Report either during State Synchronization or when a new LSP is configured at the PCC.
状态同步期间或在PCC配置新LSP时的状态报告。
The initial PCRpt creates a binding between the symbolic path name and the PLSP-ID for the LSP that lasts for the duration of the PCEP session. The PCC MAY omit the symbolic path name from subsequent LSP State Reports for that LSP on that PCEP session, and just use the PLSP-ID.
初始PCRpt在符号路径名和LSP的PLSP-ID之间创建一个绑定，该绑定在PCEP会话期间持续。PCC可以从该PCEP会话上该LSP的后续LSP状态报告中省略符号路径名，而只使用PLSP-ID。
The format of the SYMBOLIC-PATH-NAME TLV is shown in the following figure:
符号路径名称TLV的格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV Format
图14：符号路径名称TLV格式
Type (16 bits): the type is 17.
类型（16位）：类型为17。
Length (16 bits): indicates the total length of the TLV in octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
长度（16位）：以八位字节表示TLV的总长度，必须大于0。TLV必须为零填充，以便TLV为4-八位组对齐。
Symbolic Path Name (variable): symbolic name for the LSP, unique in the PCC. It SHOULD be a string of printable ASCII characters, without a NULL terminator.
符号路径名（变量）：LSP的符号名，在PCC中是唯一的。它应该是一个可打印的ASCII字符字符串，没有空终止符。
The LSP Error Code TLV is an optional TLV for use in the LSP object to convey error information. When an LSP Update Request fails, an LSP State Report MUST be sent to report the current state of the LSP, and it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for the failure. Similarly, when a PCRpt is sent as a result of an LSP transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD be included to indicate the reason for the transition.
LSP错误代码TLV是可选的TLV，用于在LSP对象中传递错误信息。当LSP更新请求失败时，必须发送LSP状态报告以报告LSP的当前状态，并且该报告应包含指示失败原因的LSP错误代码TLV。类似地，当由于LSP转换为非运行状态而发送PCRpt时，应包括LSP错误代码TLV，以指示转换的原因。
The format of the LSP-ERROR-CODE TLV is shown in the following figure:
LSP-ERROR-CODE TLV的格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=20 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=20 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV Format
图15:LSP-ERROR-CODE TLV格式
The type (16 bits) of the TLV is 20. The length field is 16 bits long and has a fixed value of 4. The value contains an error code that indicates the cause of the failure.
TLV的类型（16位）为20。长度字段的长度为16位，固定值为4。该值包含指示故障原因的错误代码。
The following LSP Error Codes are currently defined:
当前定义了以下LSP错误代码：
Value Description
----- -------------------------------------
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
Value Description
----- -------------------------------------
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object to carry RSVP error information. It includes the RSVP ERROR_SPEC or USER_ERROR_SPEC object ([RFC2205] and [RFC5284]), which were returned to the PCC from a downstream node. If the setup of an LSP fails at a downstream node that returned an ERROR_SPEC to the PCC, the PCC SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC object.
RSVP-ERROR-SPEC TLV是一个可选TLV，用于LSP对象中，以携带RSVP错误信息。它包括从下游节点返回到PCC的RSVP错误规范或用户错误规范对象（[RFC2205]和[RFC5284]）。如果LSP的设置在向PCC返回错误规范的下游节点失败，PCC应在该LSP的PCRpt中包含LSP-ERROR-CODE TLV（LSP ERROR CODE=“RSVP SIGNAL ERROR”）和RSVP-ERROR-SPEC TLV（RSVP ERROR-SPEC或USER-ERROR\U SPEC对象）。
The format of the RSVP-ERROR-SPEC TLV is shown in the following figure:
RSVP-ERROR-SPEC TLV的格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=21 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=21 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: RSVP-ERROR-SPEC TLV Format
图16:RSVP-ERROR-SPEC TLV格式
Type (16 bits): the type is 21.
类型（16位）：类型为21。
Length (16 bits): indicates the total length of the TLV in octets. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
长度（16位）：以八位字节表示TLV的总长度。TLV必须为零填充，以便TLV为4-八位组对齐。
Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, as specified in [RFC2205] and [RFC5284], including the object header.
值（变量）：包含[RFC2205]和[RFC5284]中指定的RSVP ERROR_SPEC或USER_ERROR_SPEC对象，包括对象头。
The code points described below have been allocated for the protocol elements defined in this document.
以下描述的代码点已分配给本文件中定义的协议元素。
The following bits have been registered in the "Path Computation Element (PCE) Capability Flags" subregistry of the "Open Shortest Path First (OSPF) Parameters" registry:
以下位已在“开放最短路径优先（OSPF）参数”注册表的“路径计算元素（PCE）能力标志”子区中注册：
Bit Description Reference
--- ------------------------------- -------------
11 Active stateful PCE capability This document
12 Passive stateful PCE capability This document
Bit Description Reference
--- ------------------------------- -------------
11 Active stateful PCE capability This document
12 Passive stateful PCE capability This document
The following message types have been allocated within the "PCEP Messages" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
在“路径计算元素协议（PCEP）编号”注册表的“PCEP消息”子区内分配了以下消息类型：
Value Description Reference
----- ------------ -------------
10 Report This document
11 Update This document
Value Description Reference
----- ------------ -------------
10 Report This document
11 Update This document
The following object-class values and object types have been allocated within the "PCEP Objects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
在“路径计算元素协议（PCEP）编号”注册表的“PCEP对象”子区内分配了以下对象类值和对象类型：
Object-Class Value Name Reference
------------------ ---------------- -------------
32 LSP This document
Object-Type
0: Reserved
1: LSP
Object-Class Value Name Reference
------------------ ---------------- -------------
32 LSP This document
Object-Type
0: Reserved
1: LSP
33 SRP This document Object-Type 0: Reserved 1: SRP
33 SRP此文档对象类型0:保留1:SRP
A new subregistry, named "LSP Object Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP object. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
在“路径计算元素协议（PCEP）编号”注册表中创建了一个名为“LSP对象标志字段”的新子域，用于管理LSP对象的标志字段。新值由标准操作[RFC8126]指定。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
The following values are defined in this document:
本文件中定义了以下值：
Bit Description Reference
--- -------------------- -------------
0-4 Unassigned This document
5-7 Operational (3 bits) This document
8 Administrative This document
9 Remove This document
10 SYNC This document
11 Delegate This document
Bit Description Reference
--- -------------------- -------------
0-4 Unassigned This document
5-7 Operational (3 bits) This document
8 Administrative This document
9 Remove This document
10 SYNC This document
11 Delegate This document
The following error types and error values have been registered within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
以下错误类型和错误值已在“路径计算元素协议（PCEP）编号”注册表的“PCEP-error对象错误类型和值”子区中注册：
Error-Type Meaning
---------- -------------------------------------------------------
6 Mandatory Object missing
Error-Type Meaning
---------- -------------------------------------------------------
6 Mandatory Object missing
Error-value 8: LSP object missing 9: ERO object missing 10: SRP object missing 11: LSP-IDENTIFIERS TLV missing
错误值8:缺少LSP对象9:缺少ERO对象10:缺少SRP对象11:缺少LSP-TLV标识符
19 Invalid Operation
19无效操作
Error-value 1: Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. 2: Attempted LSP Update Request if the stateful PCE capability was not advertised. 3: Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID. 5: Attempted LSP State Report if stateful PCE capability was not advertised.
错误值1:尝试对未委派的LSP进行LSP更新请求。PCEP-ERROR对象后面跟着标识LSP的LSP对象。2：如果没有公布有状态PCE功能，则尝试LSP更新请求。3：尝试对未知PLSP-ID标识的LSP进行LSP更新请求。5：如果未公布有状态PCE功能，则尝试进行LSP状态报告。
20 LSP State Synchronization Error
20 LSP状态同步错误
Error-value 1: A PCE indicates to a PCC that it cannot process (an otherwise valid) LSP State Report. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. 5: A PCC indicates to a PCE that it cannot complete the State Synchronization.
错误值1：PCE向PCC指示它无法处理（其他有效的）LSP状态报告。PCEP-ERROR对象后面跟着标识LSP的LSP对象。5：PCC向PCE指示它无法完成状态同步。
The following Notification Types and Notification Values have been allocated within the "Notification Object" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
以下通知类型和通知值已在“路径计算元素协议（PCEP）编号”注册表的“通知对象”子区内分配：
Notification-Type Name 4 Stateful PCE resource limit exceeded
超过通知类型名称4有状态PCE资源限制
Notification-value 1: Entering resource limit exceeded state 2: Deprecated
通知值1:输入的资源限制超出状态2:已弃用
Note that the early allocation included an additional Notification Value 2 for "Exiting resource limit exceeded state". This Notification Value is no longer required and has been marked as "Deprecated".
请注意，早期分配包括“退出资源限制超出状态”的附加通知值2。此通知值不再是必需的，已标记为“已弃用”。
The following TLV Type Indicator values have been registered within the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
以下TLV类型指示器值已在“路径计算元素协议（PCEP）编号”注册表的“PCEP TLV类型指示器”子区中注册：
Value Description Reference
----- ----------------------- -------------
16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document
Value Description Reference
----- ----------------------- -------------
16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document
A new subregistry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
在“路径计算元素协议（PCEP）编号”注册表中创建了一个名为“STATEFUL-PCE-CAPABILITY TLV标志字段”的新子域，用于管理PCEP开放对象（类=1）的STATEFUL-PCE-CAPABILITY TLV中的标志字段。新值由标准操作[RFC8126]指定。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability description
o 能力描述
o Defining RFC
o 定义RFC
The following values are defined in this document:
本文件中定义了以下值：
Value Description Reference
----- --------------------- -------------
31 LSP-UPDATE-CAPABILITY This document
Value Description Reference
----- --------------------- -------------
31 LSP-UPDATE-CAPABILITY This document
A new subregistry, named "LSP-ERROR-CODE TLV Error Code Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the LSP Error Code field of the LSP-ERROR-CODE TLV. This field specifies the reason for failure to update the LSP.
在“路径计算元素协议（PCEP）编号”注册表中创建了一个名为“LSP-ERROR-CODE TLV ERROR CODE Field”的新分区，以管理LSP-ERROR-CODE TLV的LSP ERROR CODE字段。此字段指定更新LSP失败的原因。
New values are assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities: value, meaning, and defining RFC. The following values are defined in this document:
新值由标准操作[RFC8126]指定。每一个值都应该通过以下质量进行跟踪：值、含义和定义RFC。本文件中定义了以下值：
Value Meaning
--- -------------------------------------
0 Reserved
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
Value Meaning
--- -------------------------------------
0 Reserved
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
All manageability requirements and considerations listed in [RFC5440] apply to the PCEP extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]中列出的所有可管理性要求和注意事项适用于本文件中定义的PCEP扩展。此外，本节中列出的要求和注意事项也适用。
In addition to configuring specific PCEP session parameters, as specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST allow configuring the stateful PCEP capability and the LSP Update capability. A PCC implementation SHOULD allow the operator to specify multiple candidate PCEs for and a delegation preference for each candidate PCE. A PCC SHOULD allow the operator to specify an LSP delegation policy where LSPs are delegated to the most-preferred online PCE. A PCC MAY allow the operator to specify different LSP delegation policies.
除了按照[RFC5440]第8.1节的规定配置特定PCEP会话参数外，PCE或PCC实现还必须允许配置有状态PCEP功能和LSP更新功能。PCC实施应允许运营商为每个候选PCE指定多个候选PCE，并为每个候选PCE指定委派偏好。PCC应允许运营商指定LSP委派策略，其中LSP委派给最首选的在线PCE。PCC可允许运营商指定不同的LSP委派策略。
A PCC implementation that allows concurrent connections to multiple PCEs SHOULD allow the operator to group the PCEs by administrative domains, and it MUST NOT advertise LSP existence and state to a PCE if the LSP is delegated to a PCE in a different group.
允许并发连接到多个PCE的PCC实现应允许运营商按管理域对PCE进行分组，并且如果LSP被委托给不同组中的PCE，则不得向PCE通告LSP存在和状态。
A PCC implementation SHOULD allow the operator to specify whether the PCC will advertise LSP existence and state for LSPs that are not controlled by any PCE (for example, LSPs that are statically configured at the PCC).
PCC实现应允许运营商指定PCC是否会公布LSP存在以及不受任何PCE控制的LSP的状态（例如，在PCC静态配置的LSP）。
A PCC implementation SHOULD allow the operator to specify both the Redelegation Timeout Interval and the State Timeout Interval. The default value of the Redelegation Timeout Interval SHOULD be set to 30 seconds. An operator MAY also configure a policy that will dynamically adjust the Redelegation Timeout Interval, for example setting it to zero when the PCC has an established session to a backup PCE. The default value for the State Timeout Interval SHOULD be set to 60 seconds.
PCC实现应允许操作员指定重新发送超时时间间隔和状态超时时间间隔。重新委派超时时间间隔的默认值应设置为30秒。操作员还可以配置一个策略，该策略将动态调整重新发送超时时间间隔，例如，当PCC与备份PCE建立会话时，将其设置为零。状态超时间隔的默认值应设置为60秒。
After the expiration of the State Timeout Interval, the LSP reverts to operator-defined default parameters. A PCC implementation MUST allow the operator to specify the default LSP parameters. To achieve a behavior where the LSP retains the parameters set by the PCE until such time that the PCC makes a change to them, a State Timeout Interval of infinity SHOULD be used. Any changes to LSP parameters SHOULD be done in a make-before-break fashion.
状态超时时间间隔到期后，LSP恢复为操作员定义的默认参数。PCC实现必须允许操作员指定默认LSP参数。为实现LSP保留PCE设置的参数直到PCC对其进行更改的行为，应使用无限的状态超时间隔。对LSP参数的任何更改都应以先通后断的方式进行。
LSP delegation is controlled by operator-defined policies on a PCC. LSPs are delegated individually -- different LSPs may be delegated to different PCEs. An LSP is delegated to at most one PCE at any given
LSP委派由PCC上的操作员定义的策略控制。LSP被单独委托——不同的LSP可能被委托给不同的PCE。LSP在任何给定时间最多委托给一个PCE
point in time. A PCC implementation SHOULD support the delegation policy, when all PCC's LSPs are delegated to a single PCE at any given time. Conversely, the policy revoking the delegation for all PCC's LSPs SHOULD also be supported.
时间点。当所有PCC的LSP在任何给定时间被委托给单个PCE时，PCC实施应支持委托政策。相反，撤销所有PCC LSP委托的政策也应得到支持。
A PCC implementation SHOULD allow the operator to specify delegation priority for PCEs. This effectively defines the primary PCE and one or more backup PCEs to which a primary PCE's LSPs can be delegated when the primary PCE fails.
PCC实施应允许运营商为PCE指定委派优先级。这有效地定义了主PCE和一个或多个备份PCE，当主PCE发生故障时，主PCE的LSP可以委托给这些PCE。
Policies defined for stateful PCEs and PCCs should eventually fit in the policy-enabled path computation framework defined in [RFC5394], and the framework should be extended to support stateful PCEs.
为有状态PCE和PCC定义的策略最终应适用于[RFC5394]中定义的策略启用路径计算框架，并且该框架应扩展以支持有状态PCE。
The PCEP YANG module [PCEP-YANG] should include:
PCEP-YANG模块[PCEP-YANG]应包括：
o advertised stateful capabilities and synchronization status per PCEP session.
o 每个PCEP会话的播发状态功能和同步状态。
o the delegation status of each configured LSP.
o 每个已配置LSP的委派状态。
The PCEP MIB [RFC7420] could also be updated to include this information.
PCEP MIB[RFC7420]也可以更新以包含此信息。
PCEP extensions defined in this document do not require any new mechanisms beyond those already defined in [RFC5440], Section 8.3.
除[RFC5440]第8.3节中已经定义的机制外，本文件中定义的PCEP扩展不需要任何新机制。
Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP extensions defined in this document. In addition to monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP implementation SHOULD provide the following parameters:
[RFC5440]第8.4节中定义的机制也适用于本文件中定义的PCEP扩展。除了[RFC5440]中定义的监控参数外，有状态PCC侧PCEP实现还应提供以下参数：
o Total number of LSP Updates
o LSP更新的总数
o Number of successful LSP Updates
o 成功的LSP更新数
o Number of dropped LSP Updates
o 丢弃的LSP更新数
o Number of LSP Updates where LSP setup failed
o LSP安装失败的LSP更新数
A PCC implementation SHOULD provide a command to show for each LSP whether it is delegated, and if so, to which PCE.
PCC实现应提供一个命令，为每个LSP显示它是否被委派，如果是，则向哪个PCE委派。
A PCC implementation SHOULD allow the operator to manually revoke LSP delegation.
PCC实施应允许运营商手动撤销LSP委托。
PCEP extensions defined in this document do not put new requirements on other protocols.
本文件中定义的PCEP扩展不会对其他协议提出新要求。
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP extensions defined in this document.
[RFC5440]第8.6节中定义的机制也适用于本文件中定义的PCEP扩展。
Additionally, a PCEP implementation SHOULD allow a limit to be placed on the number of LSPs delegated to the PCE and on the rate of PCUpd and PCRpt messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached.
此外，PCEP实施应允许对委托给PCE的LSP数量以及PCEP扬声器发送并从对等方处理的PCUpd和PCRpt消息的速率进行限制。它还应允许在达到速率阈值时发送通知。
A PCC implementation SHOULD allow a limit to be placed on the rate of LSP Updates to the same LSP to avoid signaling overload discussed in Section 10.3.
PCC实施应允许对同一LSP的LSP更新速率进行限制，以避免第10.3节中讨论的信令过载。
This document defines extensions to PCEP to enable stateful PCEs. The nature of these extensions and the delegation of path control to PCEs results in more information being available for a hypothetical adversary and a number of additional attack surfaces that must be protected.
本文档定义了对PCEP的扩展，以启用有状态PCE。这些扩展的性质以及将路径控制委托给PCE，导致假设对手可以获得更多的信息，以及必须保护的许多额外攻击面。
The security provisions described in [RFC5440] remain applicable to these extensions. However, because the protocol modifications outlined in this document allow the PCE to control path computation timing and sequence, the PCE defense mechanisms described in [RFC5440], Section 7.2 are also now applicable to PCC security.
[RFC5440]中描述的安全规定仍然适用于这些扩展。然而，由于本文件中概述的协议修改允许PCE控制路径计算定时和顺序，[RFC5440]第7.2节中描述的PCE防御机制现在也适用于PCC安全。
As a general precaution, it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525].
作为一般预防措施，建议根据[RFC7525]中的建议和最佳现行做法，使用传输层安全性（TLS）[PCEP]，仅在属于同一管理机构的PCE和PCC之间经过身份验证和加密的会话上激活这些PCEP扩展。
The following sections identify specific security concerns that may result from the PCEP extensions outlined in this document along with recommended mechanisms to protect PCEP infrastructure against related attacks.
以下各节确定了本文档中概述的PCEP扩展可能导致的特定安全问题，以及保护PCEP基础设施免受相关攻击的建议机制。
The stateful nature of this extension explicitly requires LSP status updates to be sent from PCC to PCE. While this gives the PCE the ability to provide more optimal computations to the PCC, it also provides an adversary with the opportunity to eavesdrop on decisions made by network systems external to PCE. This is especially true if the PCC delegates LSPs to multiple PCEs simultaneously.
此扩展的有状态特性明确要求从PCC向PCE发送LSP状态更新。虽然这使PCE能够向PCC提供更优化的计算，但也为对手提供了窃听PCE外部网络系统所做决策的机会。如果PCC同时将LSP委托给多个PCE，则尤其如此。
Adversaries may gain access to this information by eavesdropping on unsecured PCEP sessions and might then use this information in various ways to target or optimize attacks on network infrastructure, for example, by flexibly countering anti-DDoS measures being taken to protect the network or by determining choke points in the network where the greatest harm might be caused.
对手可能通过窃听不安全的PCEP会话来获取此信息，然后可能以各种方式使用此信息来瞄准或优化对网络基础设施的攻击，例如，通过灵活应对为保护网络而采取的防DDoS措施，或通过确定网络中可能造成最大危害的瓶颈。
PCC implementations that allow concurrent connections to multiple PCEs SHOULD allow the operator to group the PCEs by administrative domains, and they MUST NOT advertise LSP existence and state to a PCE if the LSP is delegated to a PCE in a different group.
允许并发连接到多个PCE的PCC实现应允许运营商按管理域对PCE进行分组，并且如果LSP委托给不同组中的PCE，则不得向PCE通告LSP存在和状态。
The LSP delegation mechanism described in this document allows a PCC to grant effective control of an LSP to the PCE for the duration of a PCEP session. While this enables PCE control of the timing and sequence of path computations within and across PCEP sessions, it also introduces a new attack vector: an attacker may flood the PCC with PCUpd messages at a rate that exceeds either the PCC's ability to process them or the network's ability to signal the changes, by either spoofing messages or compromising the PCE itself.
本文档中描述的LSP委派机制允许PCC在PCEP会话期间向PCE授予LSP的有效控制权。虽然这使得PCE能够控制PCEP会话内和会话间路径计算的时间和顺序，但它也引入了一种新的攻击向量：攻击者可能以超过PCC处理它们的能力或网络发出更改信号的能力的速率向PCC发送PCUpd消息，通过欺骗消息或破坏PCE本身。
A PCC is free to revoke an LSP delegation at any time without needing any justification. A defending PCC can do this by enqueueing the appropriate PCRpt message. As soon as that message is enqueued in the session, the PCC is free to drop any incoming PCUpd messages without additional processing.
PCC可随时撤销LSP委托，无需任何理由。防御PCC可以通过将适当的PCRpt消息排入队列来实现这一点。一旦该消息在会话中排队，PCC就可以随意丢弃任何传入的PCUpd消息，而无需额外处理。
A stateful session also results in an increased attack surface by placing a requirement for the PCE to keep an LSP state replica for each PCC. It is RECOMMENDED that PCE implementations provide a limit on resources a single PCC can occupy. A PCE implementing such a limit MUST send a PCNtf message with notification-type 4 (Stateful PCE resource limit exceeded) and notification-value 1 (Entering resource limit exceeded state) upon receiving an LSP State Report causing it to exceed this threshold.
有状态会话还要求PCE为每个PCC保留LSP状态副本，从而增加攻击面。建议PCE实施对单个PCC可以占用的资源进行限制。当接收到导致其超过此阈值的LSP状态报告时，实现此限制的PCE必须发送通知类型为4（超过有状态PCE资源限制）和通知值为1（进入资源限制超出状态）的PCNtf消息。
Delegation of LSPs can create further strain on PCE resources and a PCE implementation MAY preemptively give back delegations if it finds itself lacking the resources needed to effectively manage the delegation. Since the delegation state is ultimately controlled by the PCC, PCE implementations SHOULD provide throttling mechanisms to prevent strain created by flaps of either a PCEP session or an LSP delegation.
LSP的委托可能会对PCE资源造成进一步的压力，如果PCE实施发现自己缺乏有效管理委托所需的资源，可能会先发制人地返还委托。由于委派状态最终由PCC控制，PCE实施应提供节流机制，以防止PCEP会话或LSP委派的襟翼造成的紧张。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<https://www.rfc-editor.org/info/rfc2205>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5088]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，DOI 10.17487/RFC5088，2008年1月<https://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5089]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，DOI 10.17487/RFC5089，2008年1月<https://www.rfc-editor.org/info/rfc5089>.
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", RFC 5284, DOI 10.17487/RFC5284, August 2008, <https://www.rfc-editor.org/info/rfc5284>.
[RFC5284]Swallow，G.和A.Farrel，“RSVP的用户定义错误”，RFC 5284，DOI 10.17487/RFC5284，2008年8月<https://www.rfc-editor.org/info/rfc5284>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，DOI 10.17487/RFC5511，2009年4月<https://www.rfc-editor.org/info/rfc5511>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]Zhang，X.，Ed.和I.Minei，Ed.“有状态路径计算元素（PCE）的适用性”，RFC 8051，DOI 10.17487/RFC8051，2017年1月<https://www.rfc-editor.org/info/rfc8051>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE LSP Path Computation using Preemption", Global Information Infrastructure Symposium, DOI 10.1109/GIIS.2007.4404195, July 2007.
[MPLS-PC]Chaieb，I.，Le Roux，JL.，和B.Counse，“使用抢占改进的MPLS-TE LSP路径计算”，全球信息基础设施研讨会，DOI 10.1109/GIIS.2007.44041952007年7月。
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "A practical algorithm for balancing the max-min fairness and throughput objectives in traffic engineering", INFOCOM, 2012 Proceedings IEEE, pp. 846-854, DOI 10.1109/INFCOM.2012.6195833, March 2012.
[MXMN-TE]Danna，E.，Mandal，S.，和A.Singh，“交通工程中平衡最大-最小公平性和吞吐量目标的实用算法”，INFOCOM，2012年IEEE会议记录，第846-854页，DOI 10.1109/INFCOM.2012.6195833，2012年3月。
[PCE-Init-LSP] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-10, June 2017.
[PCE初始LSP]Crabbe，E.，Minei，I.，Sivabalan，S.，和R.Varga，“状态PCE模型中PCE启动LSP设置的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-PCE-initiated-LSP-10，2017年6月。
[PCEP-GMPLS] Margaria, C., de Dios, O., and F. Zhang, "PCEP extensions for GMPLS", Work in Progress, draft-ietf-pce-gmpls-pcep-extensions-11, October 2015.
[PCEP-GMPLS]Margaria，C.，de Dios，O.，和F.Zhang，“GMPLS的PCEP扩展”，正在进行的工作，草案-ietf-pce-GMPLS-PCEP-extensions-112015年10月。
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
[PCEP-YANG]杜迪，D.，哈德威克，J.，比拉姆，V.，和J。jefftant@gmail.com，“路径计算元件通信协议（PCEP）的YANG数据模型”，正在进行的工作，草稿-ietf-pce-PCEP-YANG-052017年6月。
[PCEPS] Lopez, D., de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-18, September 2017.
[PCEP]Lopez，D.，de Dios，O.，Wu，Q.，和D.Dhody，“PCEP的安全运输”，正在进行的工作，草案-ietf-pce-PCEPS-18，2017年9月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，DOI 10.17487/RFC2702，1999年9月<https://www.rfc-editor.org/info/rfc2702>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, DOI 10.17487/RFC3346, August 2002, <https://www.rfc-editor.org/info/rfc3346>.
[RFC3346]Boyle，J.，Gill，V.，Hannan，A.，Cooper，D.，Awduche，D.，Christian，B.，和W.Lai，“MPLS流量工程的适用性声明”，RFC 3346，DOI 10.17487/RFC3346，2002年8月<https://www.rfc-editor.org/info/rfc3346>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<https://www.rfc-editor.org/info/rfc3630>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4657]Ash，J.，Ed.和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，DOI 10.17487/RFC4657，2006年9月<https://www.rfc-editor.org/info/rfc4657>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<https://www.rfc-editor.org/info/rfc5305>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, <https://www.rfc-editor.org/info/rfc5394>.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 5394，DOI 10.17487/RFC5394，2008年12月<https://www.rfc-editor.org/info/rfc5394>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素通信协议（PCEP）管理信息库（MIB）模块”，RFC 7420，DOI 10.17487/RFC7420，2014年12月<https://www.rfc-editor.org/info/rfc7420>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <http://www.rfc-editor.org/info/rfc8232>.
[RFC8232]Crabbe，E.，Minei，I.，Medved，J.，Varga，R.，Zhang，X.，和D.Dhody，“有状态PCE标签交换路径状态同步程序的优化”，RFC 8232，DOI 10.17487/RFC8232，2017年9月<http://www.rfc-editor.org/info/rfc8232>.
Acknowledgements
致谢
We would like to thank Adrian Farrel, Cyril Margaria, and Ramon Casellas for their contributions to this document.
我们要感谢Adrian Farrel、Cyril Margaria和Ramon Casellas对本文件的贡献。
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, Paul Schultz, and Raveendra Torvi for their comments and suggestions. Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui, Stephane Litkowski, and Olivier Dugeon for helpful comments and discussions.
我们要感谢Shane Amante、Julien Meuri、Kohei Shiomoto、Paul Schultz和Ravendra Torvi的评论和建议。还要感谢乔恩·哈德威克、奥斯卡·冈萨雷斯·德迪奥斯、托马斯·扬西加、斯蒂芬·科布扎、唐可欣、马特·斯潘尼克、乔恩·帕克、马瑞克·扎沃茨基、安布罗斯·邝、阿什温·桑帕斯、卡尔文·英、穆斯塔法·艾萨维、斯蒂芬·利特科夫斯基和奥利维尔·杜容，感谢他们提供了有益的评论和讨论。
Contributors
贡献者
The following people contributed substantially to the content of this document and should be considered coauthors:
以下人员对本文件的内容做出了重大贡献，应被视为合著者：
Xian Zhang Huawei Technology F3-5-B R&D Center Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 China Email: zhang.xian@huawei.com
中国广东省深圳市龙岗区坂田华为工业基地华为技术F3-5-B研发中心邮编：518129电子邮件：张。xian@huawei.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 INDIA Email: dhruv.dhody@huawei.com
杜鲁夫杜迪华为技术有限公司，卡纳塔克邦班加罗尔，邮编560008，印度电子邮件：杜鲁夫。dhody@huawei.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com
Siva Sivabalan Cisco Systems，Inc.安大略省卡纳塔创新大道2000号K2K 3E8加拿大电子邮件：msiva@cisco.com
Authors' Addresses
作者地址
Edward Crabbe Oracle 1501 4th Ave, suite 1800 Seattle, WA 98101 United States of America
爱德华·克拉布·甲骨文美国华盛顿州西雅图第四大道1501号1800室98101
Email: edward.crabbe@oracle.com
Email: edward.crabbe@oracle.com
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
Email: inaminei@google.com
Email: inaminei@google.com
Jan Medved Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America
Jan Medved Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼170号，邮编95134
Email: jmedved@cisco.com
Email: jmedved@cisco.com
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56 Bratislava 821 05 Slovakia
罗伯特·瓦尔加万神殿科技公司SRO Mlynske Nivy 56布拉迪斯拉发821 05斯洛伐克
Email: robert.varga@pantheon.tech
Email: robert.varga@pantheon.tech