Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8281 Individual Contributor
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
December 2017
Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8281 Individual Contributor
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
December 2017
Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model
有状态PCE模型中PCE启动LSP设置的路径计算元素通信协议（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）请求执行路径计算的机制。
The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.
对于PCC将对一个或多个本地配置的LSP的控制委托给PCE的模型，有状态PCE的扩展通过PCEP提供了对多协议标签交换（MPLS）流量工程标签交换路径（TE LSP）的主动控制。本文档描述了在有状态PCE模型下创建和删除PCE启动的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/rfc8281.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8281.
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(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.
(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 6
4. Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . 7
4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8
5. PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 8
5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 8
5.2. The R Flag in the SRP Object . . . . . . . . . . . . . . 10
5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 10
5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 12
5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 13
5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 13
6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 14
7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 6
4. Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . 7
4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8
5. PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 8
5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 8
5.2. The R Flag in the SRP Object . . . . . . . . . . . . . . 10
5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 10
5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 12
5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 13
5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 13
6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 14
7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
[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 PCE and PCE, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.
[RFC5440]描述了路径计算元素通信协议（PCEP）。PCEP定义了路径计算客户端（PCC）和路径计算元素（PCE）之间的通信，或PCE和PCE之间的通信，从而能够计算流量工程标签交换路径（TE LSP）特性的多协议标签交换（MPLS）。
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes:
[RFC8231]指定PCEP的一组扩展，以根据[RFC4657]在PCEP会话之间和跨PCEP会话对TE LSP进行有状态控制。它包括：
o mechanisms to effect LSP State Synchronization between PCCs and PCEs
o 影响PCC和PCE之间LSP状态同步的机制
o delegation of control of LSPs to PCEs
o 将LSP的控制权委托给PCE
o PCE control of timing and sequence of path computations within and across PCEP sessions
o PCE控制PCEP会话内和会话间路径计算的时间和顺序
It focuses on a model where LSPs are configured on the PCC, and control over them is delegated to the PCE.
它关注的是在PCC上配置LSP，并将对它们的控制权委托给PCE的模型。
This document describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed.
本文档描述了在有状态PCE模型下PCE启动的LSP的设置、维护和拆卸，无需在PCC上进行本地配置，从而允许集中控制和部署动态网络。
This document uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP Peer.
本文件使用[RFC5440]中定义的以下术语：PCC、PCE和PCEP对等。
This document uses the following terms defined in [RFC8051]: Stateful PCE and Delegation.
本文件使用[RFC8051]中定义的以下术语：有状态PCE和委托。
This document uses the following terms defined in [RFC8231]: Redelegation Timeout Interval, State Timeout Interval, LSP State Report, and LSP Update Request.
本文档使用[RFC8231]中定义的以下术语：重新委派超时时间间隔、状态超时时间间隔、LSP状态报告和LSP更新请求。
The following terms are defined in this document:
本文件中定义了以下术语：
PCE-initiated LSP: LSP that is instantiated as a result of a request from the PCE.
PCE启动的LSP：根据PCE的请求实例化的LSP。
The message formats in this document are specified using Routing Backus-Naur Form (RBNF) encoding as specified in [RFC5511].
本文件中的消息格式使用[RFC5511]中规定的路由Backus-Naur格式（RBNF）编码指定。
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]所述进行解释。
[RFC8231] provides active control over LSPs that are locally configured on the PCC. This model relies on the Label Edge Router (LER) taking an active role in delegating locally configured LSPs to the PCE and is well suited in environments where the LSP placement is fairly static. However, in environments where the LSP placement needs to change in response to application demands, it is useful to support dynamic creation and teardown of LSPs. The ability for a PCE to trigger the creation of LSPs on demand can be seamlessly integrated into a controller-based network architecture, where intelligence in the controller can determine when and where to set up paths.
[RFC8231]提供对PCC上本地配置的LSP的主动控制。该模型依赖于标签边缘路由器（LER），在将本地配置的LSP委托给PCE时发挥积极作用，非常适合LSP放置相当静态的环境。但是，在需要根据应用程序需求更改LSP位置的环境中，支持LSP的动态创建和拆卸非常有用。PCE触发按需创建LSP的能力可以无缝集成到基于控制器的网络体系结构中，控制器中的智能可以确定何时何地设置路径。
A possible use case is a software-defined network, where applications request network resources and paths from the network infrastructure. For example, an application can request a path with certain constraints between two Label Switching Routers (LSRs) by contacting the PCE. The PCE can compute a path satisfying the constraints, and instruct the head end LSR to instantiate and signal it. When the path is no longer required by the application, the PCE can request its teardown.
一个可能的用例是软件定义的网络，其中应用程序从网络基础设施请求网络资源和路径。例如，应用程序可以通过联系PCE请求两个标签交换路由器（LSR）之间具有特定约束的路径。PCE可以计算满足约束的路径，并指示前端LSR实例化并发送信号。当应用程序不再需要该路径时，PCE可以请求其拆卸。
Another use case is dynamically adjusting aggregate bandwidth between two points in the network using multiple LSPs. This functionality is very similar to auto-bandwidth, but it allows for providing the desired capacity through multiple LSPs. This approach overcomes two of the limitations auto-bandwidth can experience: 1) growing the capacity between the endpoints beyond the capacity of individual links in the path and 2) achieving good bin packing through use of several small LSPs instead of a single large one. The number of LSPs varies based on the demand, and LSPs are created and deleted dynamically to satisfy the bandwidth requirements.
另一个用例是使用多个LSP动态调整网络中两点之间的聚合带宽。此功能与自动带宽非常相似，但它允许通过多个LSP提供所需的容量。这种方法克服了自动带宽可能遇到的两个限制：1）使端点之间的容量超过路径中单个链路的容量；2）通过使用多个小LSP（而不是单个大LSP）实现良好的装箱。LSP的数量根据需求而变化，并且动态创建和删除LSP以满足带宽需求。
Another use case is demand engineering, where a PCE with visibility into both the network state and the demand matrix can anticipate and optimize how traffic is distributed across the infrastructure. Such optimizations may require creating new paths across the infrastructure.
另一个用例是需求工程（demand engineering），在该用例中，对网络状态和需求矩阵都具有可见性的PCE可以预测并优化流量在整个基础设施中的分布方式。这种优化可能需要在整个基础架构中创建新的路径。
This document defines the new I flag in the STATEFUL-PCE-CAPABILITY TLV to indicate that the sender supports PCE-initiated LSPs (see details in Section 4.1). A PCC or PCE sets this flag in the Open message during the PCEP initialization phase to indicate that it supports the procedures of this document.
本文件在有状态-PCE-CAPABILITY TLV中定义了新的I标志，以表明发送方支持PCE启动的LSP（详见第4.1节）。PCC或PCE在PCEP初始化阶段在Open消息中设置此标志，以表明其支持本文档的过程。
This document defines a new PCEP message, the LSP Initiate Request (PCInitiate) message, which a PCE can send to a PCC to request the initiation or deletion of an LSP. The decision when to instantiate or delete a PCE-initiated LSP is out of the scope of this document.
本文档定义了一条新的PCEP消息，即LSP Initiate Request（PCInitiate）消息，PCE可将该消息发送给PCC，以请求启动或删除LSP。何时实例化或删除PCE启动的LSP的决定超出了本文档的范围。
The PCE sends a PCInitiate message to the PCC to request the initiation of an LSP. The PCC creates the LSP using the attributes communicated by the PCE and local values for any unspecified parameters. The PCC generates a Path Computation State Report (PCRpt) for the LSP, carrying a newly assigned PLSP-ID for the LSP and delegating the LSP to the PCE via the Delegate flag in the LSP object.
PCE向PCC发送PCInitiate消息以请求LSP的启动。PCC使用PCE传递的属性和任何未指定参数的本地值创建LSP。PCC为LSP生成路径计算状态报告（PCRpt），携带新分配的LSP PLSP-ID，并通过LSP对象中的委托标志将LSP委托给PCE。
The PCE can update the attributes of the LSP by sending subsequent Path Computation Update Request (PCUpd) messages. Subsequent PCRpt and PCUpd messages that the PCC and PCE, respectively, send for the LSP will carry the PCC-assigned PLSP-ID, which uniquely identifies the LSP. See details in Section 5.3.
PCE可以通过发送后续路径计算更新请求（PCUpd）消息来更新LSP的属性。PCC和PCE分别为LSP发送的后续PCRpt和PCUpd消息将携带PCC分配的PLSP-ID，其唯一标识LSP。详见第5.3节。
The PCE sends a PCInitiate message to the PCC to request the deletion of an LSP. To indicate a delete operation, this document defines the new R flag in the Stateful PCE Request Parameter (SRP) object in the PCInitiate message, as described in Section 5.2. As a result of the deletion request, the PCC removes the LSP and sends a PCRpt for the removed state. See details in Section 5.4.
PCE向PCC发送PCInitiate消息以请求删除LSP。为了指示删除操作，本文档在PCInitiate消息中的有状态PCE请求参数（SRP）对象中定义了新的R标志，如第5.2节所述。作为删除请求的结果，PCC删除LSP并发送删除状态的PCRpt。详见第5.4节。
Figure 1 illustrates these message exchanges.
图1说明了这些消息交换。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|<--PCInitiate-------------------| (Initiate LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation)
| . |
| . |
| |
|<--PCUpd, PLSP_ID=1-------------| (Update LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm update)
| . |
| . |
| |
|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
| |
|---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete)
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|<--PCInitiate-------------------| (Initiate LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation)
| . |
| . |
| |
|<--PCUpd, PLSP_ID=1-------------| (Update LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm update)
| . |
| . |
| |
|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
| |
|---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete)
Figure 1: PCE-Initiated LSP Life Cycle
图1：PCE启动的LSP生命周期
A PCEP speaker indicates its ability to support PCE-initiated LSPs during the PCEP initialization phase, as follows. When the PCEP session is created, it sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag, is introduced to this TLV to indicate support for instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only for PCCs that advertised this capability. A PCC will follow the procedures described in this document only on sessions where the PCE advertised the I flag.
PCEP扬声器表示其在PCEP初始化阶段支持PCE启动的LSP的能力，如下所示。创建PCEP会话时，它会发送一条打开的消息，其中包含[RFC8231]中定义的有状态-PCE-CAPABILITY TLV的打开对象。在该TLV中引入了一个新的标志，即I（LSP-INSTANTIATION-CAPABILITY）标志，以指示对PCE启动的LSP的实例化的支持。PCE只能为宣传此功能的PCC启动LSP。PCC将仅在PCE公布I标志的会话上遵循本文档中描述的步骤。
The format of the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and included here for easy reference with the addition of the new I flag.
有状态-PCE-CAPABILITY TLV的格式在[RFC8231]中定义，并包括在此处，以便于参考，同时添加了新的I标志。
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 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|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 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
Figure 2: STATEFUL-PCE-CAPABILITY TLV Format
图2：有状态PCE能力TLV格式
A new flag is defined to indicate the sender's support for LSP instantiation by a PCE:
定义了一个新标志，表示发送方支持PCE进行LSP实例化：
I (LSP-INSTANTIATION-CAPABILITY -- 1 bit): If set to 1 by a PCC, the I flag indicates that the PCC allows instantiation of an LSP by a PCE. If set to 1 by a PCE, the I flag indicates that the PCE supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC and PCE in order to enable PCE-initiated LSP instantiation.
I（LSP-INSTANTIATION-CAPABILITY--1位）：如果PCC将其设置为1，则I标志表示PCC允许PCE实例化LSP。如果PCE设置为1，则I标志指示PCE支持实例化LSP。PCC和PCE必须设置LSP-INSTANTIATION-CAPABILITY标志，以便启用PCE启动的LSP实例化。
To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The message format, objects, and TLVs are discussed separately below for the creation and the deletion cases.
要启动LSP，PCE向PCC发送PCInitiate消息。下面将针对创建和删除案例分别讨论消息格式、对象和TLV。
An LSP Initiate Request (PCInitiate) message is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion. The Message-Type field of the PCEP common header for the PCInitiate message is set to 12. The PCInitiate message MUST include the SRP and the LSP objects and MAY contain other objects, as discussed later in this section.
LSP Initiate Request（PCInitiate）消息是PCE向PCC发送的PCEP消息，用于触发LSP实例化或删除。PCEP启动消息的PCEP公用标头的消息类型字段设置为12。PCInitiate消息必须包括SRP和LSP对象，并且可能包含其他对象，如本节后面所述。
The format of a PCInitiate message is as follows:
PCInitiate消息的格式如下所示：
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<Common Header> is defined in RFC 5440
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<Common Header> is defined in RFC 5440
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where: <attribute-list> is defined in RFC 5440 and extended by PCEP extensions.
其中：<attribute list>在RFC 5440中定义，并通过PCEP扩展进行扩展。
The LSP object is defined in [RFC8231]. The END-POINTS and Explicit Route Objects (EROs) are defined in [RFC5440].
LSP对象在[RFC8231]中定义。端点和显式布线对象（ERO）在[RFC5440]中定义。
The SRP object is defined in [RFC8231]. The SRP object contains an SRP-ID-number that is unique within a PCEP session. The PCE increments the last-used SRP-ID-number before it sends each PCInitiate message. The PCC MUST echo the value of the SRP-ID-number in PCEP Error (PCErr) and PCRpt messages that it sends as a result of the PCInitiate; this allows the PCE to correlate them with the corresponding PCInitiate message.
SRP对象在[RFC8231]中定义。SRP对象包含在PCEP会话中唯一的SRP ID号。在发送每个PCInitiate消息之前，PCE递增上次使用的SRP ID号。PCC必须在PCEP错误（PCErr）和PCRpt消息中回显SRP ID号的值，该消息是PCEP启动后发送的；这允许PCE将它们与相应的PCInitiate消息相关联。
The format of the SRP object is defined in [RFC8231] and included here for easy reference with the addition of the new R flag.
[RFC8231]中定义了SRP对象的格式，并将其包括在此处，以便于参考，同时添加了新的R标志。
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 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The SRP Object Format
图3:SRP对象格式
A new flag is defined to indicate a delete operation initiated by the PCE:
定义了一个新标志，以指示PCE启动的删除操作：
R (LSP-REMOVE -- 1 bit): If set to 0, it indicates a request to create an LSP. If set to 1, it indicates a request to remove an LSP.
R（LSP-REMOVE--1位）：如果设置为0，则表示请求创建LSP。如果设置为1，则表示请求删除LSP。
The LSP is instantiated by sending a PCInitiate message. The LSP is set up using RSVP-TE. Extensions for other setup methods are outside the scope of this document.
通过发送PCInitiate消息来实例化LSP。使用RSVP-TE设置LSP。其他设置方法的扩展超出了本文档的范围。
The PCInitiate message, when used to instantiate an LSP, MUST contain an LSP object with the reserved PLSP-ID 0. The LSP object MUST include the SYMBOLIC-PATH-NAME TLV, which is used to correlate between the PCC-assigned PLSP-ID and the LSP.
PCInitiate消息用于实例化LSP时，必须包含保留PLSP-ID为0的LSP对象。LSP对象必须包括符号路径名TLV，用于在PCC分配的PLSP-ID和LSP之间进行关联。
The PCInitiate message, when used to instantiate an LSP, MUST contain an ERO for the LSP.
PCInitiate消息用于实例化LSP时，必须包含LSP的ERO。
For an instantiation request of an RSVP-signaled LSP, the destination address may be needed. The PCC MAY determine it from a provided object (e.g., ERO) or a local decision. Alternatively, the END-POINTS object MAY be included to explicitly convey the destination addresses to be used in the RSVP-TE signaling. The source address MUST be either specified or left for the PCC to choose by setting it to "0.0.0.0" (if the destination is an IPv4 address) or "::" (if the destination is an IPv6 address).
对于RSVP信号LSP的实例化请求，可能需要目标地址。PCC可根据提供的对象（例如ERO）或本地决策来确定。或者，可以包括端点对象以显式地传送要在RSVP-TE信令中使用的目的地地址。必须指定或保留源地址，以便PCC通过将其设置为“0.0.0.0”（如果目标是IPv4地址）或“：”（如果目标是IPv6地址）进行选择。
The PCE MAY include various attributes as per [RFC5440]. The PCC MUST use these values in the LSP instantiation and local values for unspecified parameters. After the LSP setup, the PCC MUST send a PCRpt to the PCE, reflecting these values. The SRP object in the PCRpt message MUST echo the value of the PCInitiate message that triggered the setup. LSPs that were instantiated as a result of a PCInitiate message MUST have the Create flag (Section 5.3.1) set in the LSP object.
PCE可包括符合[RFC5440]的各种属性。PCC必须在LSP实例化中使用这些值，并对未指定参数使用本地值。LSP设置后，PCC必须向PCE发送反映这些值的PCRpt。PCRpt消息中的SRP对象必须回显触发设置的PCInitiate消息的值。由于PCInitiate消息而实例化的LSP必须在LSP对象中设置创建标志（第5.3.1节）。
If the PCC receives a PCInitiate message with a non-zero PLSP-ID and the R flag in the SRP object set to zero, then it MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=8 (Non-zero PLSP-ID in the LSP Initiate Request).
如果PCC接收到一条PCInitiate消息，其中PLSP-ID非零，SRP对象中的R标志设置为零，则必须发送一条PCErr消息，错误类型=19（无效操作），错误值=8（LSP Initiate请求中的PLSP-ID非零）。
If the PCC receives a PCInitiate message without an ERO and the R flag in the SRP object set to zero, then it MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object missing).
如果PCC收到的PCInitiate消息没有ERO且SRP对象中的R标志设置为零，则必须发送错误类型为6（强制对象缺失）且错误值为9（ERO对象缺失）的PCErr消息。
If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME TLV, then it MUST send a PCErr message with Error-type=10 (Reception of an invalid object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV missing).
如果PCC接收到没有符号路径名TLV的PCInitiate消息，则必须发送错误类型为10（接收无效对象）且错误值为8（缺少符号路径名TLV）的PCErr消息。
The PCE MUST NOT provide a symbolic path name that conflicts with the symbolic path name of any existing LSP in the PCC. (Existing LSPs may be either statically configured or initiated by another PCE.) If there is a conflict with the symbolic path name of an existing LSP, the PCC MUST send a PCErr message with Error-type=23 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The only exception to this rule is for LSPs for which the State Timeout Interval timer is running (see Section 6).
PCE不得提供与PCC中任何现有LSP的符号路径名冲突的符号路径名。（现有LSP可以是静态配置的，也可以由另一个PCE启动。）如果与现有LSP的符号路径名存在冲突，PCC必须发送错误类型为23（错误参数值）且错误值为1（使用中的符号路径名）的PCErr消息。此规则的唯一例外是运行状态超时间隔计时器的LSP（请参阅第6节）。
If the PCC determines that the LSP parameters proposed in the PCInitiate message are unacceptable, it MUST send a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=1 (Unacceptable instantiation parameters). If the PCC encounters an internal error during the processing of the PCInitiate message, it MUST send a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=2 (Internal error).
如果PCC确定PCInitiate消息中建议的LSP参数不可接受，则必须发送错误类型为24（PCE实例化错误）且错误值为1（不可接受实例化参数）的PCErr消息。如果PCC在处理PCInitiate消息期间遇到内部错误，则必须发送错误类型为24（PCE实例化错误）且错误值为2（内部错误）的PCErr消息。
A PCC MUST relay errors it encounters in the setup of a PCE-initiated LSP to the PCE by sending a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=3 (Signaling error). The PCErr message MUST echo the SRP-ID-number of the PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP ERROR_SPEC object was returned to the PCC by a downstream node).
PCC必须通过发送错误类型为24（PCE实例化错误）且错误值为3（信令错误）的PCErr消息，将其在设置PCE启动的LSP时遇到的错误中继到PCE。PCErr消息必须回显PCInitiate消息的SRP ID号。PCEP-ERROR对象应包括RSVP_ERROR_SPEC TLV（如果下游节点将RSVP ERROR_SPEC对象返回给PCC）。
After the LSP is set up, errors in RSVP signaling are reported in PCRpt messages, as described in [RFC8231].
设置LSP后，如[RFC8231]所述，在PCRpt消息中报告RSVP信令中的错误。
On successful completion of the LSP instantiation, the PCC MUST send a PCRpt message. The LSP object message MUST contain a non-zero PLSP-ID that uniquely identifies the LSP within this PCC and MUST have the Create flag (Section 5.3.1) and Delegate flag set. The SRP object MUST contain an SRP-ID-number that echoes the value from the PCInitiate message that triggered the setup. The PCRpt MUST include the attributes that the PCC used to instantiate the LSP.
成功完成LSP实例化后，PCC必须发送PCRpt消息。LSP对象消息必须包含唯一标识此PCC内LSP的非零PLSP-ID，并且必须设置创建标志（第5.3.1节）和委托标志。SRP对象必须包含与触发设置的PCInitiate消息中的值相呼应的SRP ID号。PCRpt必须包括PCC用于实例化LSP的属性。
A PCC SHOULD be able to place a limit on either the number of LSPs or the percentage of resources that are allocated to honor PCE-initiated LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached) and is free to drop any incoming PCInitiate messages without additional processing.
PCC应能够限制LSP的数量或分配用于满足PCE发起的LSP请求的资源百分比。一旦达到该限制，PCC必须发送错误类型为19（无效操作）且错误值为6（达到PCE启动的LSP限制）的PCErr消息，并且可以自由删除任何传入的PCInitiate消息，无需额外处理。
Similarly, the PCE SHOULD be able to place a limit on either the number of PCInitiate messages pending for a particular PCC or the time it waits for a response (positive or negative) to a PCInitiate message from a PCC, and it MAY take further action (such as closing the session or removing all its LSPs) if this limit is reached.
类似地，PCE应该能够对特定PCC的PCInitiate消息的挂起数量或等待来自PCC的PCInitiate消息的响应（肯定或否定）的时间设置限制，并且如果达到该限制，它可以采取进一步的操作（例如关闭会话或移除其所有LSP）。
The LSP object is defined in [RFC8231] and included here for easy reference with the addition of the new Create (C) flag.
LSP对象在[RFC8231]中定义，并包含在此处，以便于参考，同时添加了新的Create（C）标志。
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 |Flags |C| 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 |Flags |C| O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The LSP Object Format
图4:LSP对象格式
A new flag, the C flag, is introduced. On a PCRpt message, the C flag set to 1 indicates that this LSP was created via a PCInitiate message. The C flag MUST be set to 1 on each PCRpt message for the LSP's duration of existence. The C flag allows PCEs to be aware of which LSPs were PCE initiated (a state that would otherwise only be known by the PCC and the PCE that initiated them).
引入了一个新的标志，即C标志。在PCRpt消息上，设置为1的C标志表示此LSP是通过PCInitiate消息创建的。在LSP存在期间，每条PCRpt消息上的C标志必须设置为1。C标志允许PCE知道哪些LSP是PCE启动的（否则只有PCC和启动它们的PCE才能知道该状态）。
The optional SPEAKER-ENTITY-ID TLV defined in [RFC8232] MAY be included in the LSP object in a PCRpt message as an optional TLV for LSPs for which the C flag is 1. The SPEAKER-ENTITY-ID TLV identifies the PCE that initiated the creation of the LSP on all PCEP sessions, a state that would otherwise only be known by the PCC and the PCE that initiated the LSP. If the TLV appears in a PCRpt for an LSP for which the C flag is 0, the LSP MUST be ignored, and the PCE MUST send a PCErr message with Error-type=23 (Bad parameter value) and Error-value=2 (Speaker identity included for an LSP that is not PCE initiated).
[RFC8232]中定义的可选SPEAKER-ENTITY-ID TLV可以作为C标志为1的LSP的可选TLV包含在PCRpt消息中的LSP对象中。SPEAKER-ENTITY-ID TLV标识在所有PCEP会话上发起LSP创建的PCE，否则只有PCC和发起LSP的PCE才知道该状态。如果TLV出现在C标志为0的LSP的PCRpt中，则必须忽略LSP，并且PCE必须发送错误类型为23（错误参数值）且错误值为2（非PCE启动的LSP包含扬声器标识）的PCErr消息。
A PCE can initiate the removal of a PCE-initiated LSP by sending a PCInitiate message with an LSP object carrying the PLSP-ID of the LSP to be removed and an SRP object with the R flag set (see Section 5.2). A PLSP-ID of zero removes all LSPs with the C flag set to 1 (in their LSP object) that are delegated to the PCE.
PCE可以通过发送PCInitiate消息来启动移除PCE启动的LSP，其中LSP对象携带要移除的LSP的PLSP-ID，SRP对象设置了R标志（参见第5.2节）。PLSP-ID为零将删除委托给PCE的C标志设置为1（在其LSP对象中）的所有LSP。
If the PLSP-ID is unknown, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=3 (Unknown PLSP-ID) [RFC8231].
如果PLSP-ID未知，PCC必须发送错误类型为19（无效操作）且错误值为3（未知PLSP-ID）的PCErr消息[RFC8231]。
If the PLSP-ID specified in the PCInitiate message is not delegated to the PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid operation) and Error-value=1 (LSP is not delegated) [RFC8231].
如果PCInitiate消息中指定的PLSP-ID未委托给PCE，则PCC必须发送错误类型为19（无效操作）且错误值为1（未委托LSP）的PCErr消息[RFC8231]。
If the PLSP-ID specified in the PCInitiate message was not created by a PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid operation) and Error-value=9 (LSP is not PCE initiated).
如果PCE未创建PCInitiate消息中指定的PLSP-ID，则PCC必须发送错误类型为19（无效操作）且错误值为9（LSP未由PCE启动）的PCErr消息。
Following the removal of the LSP, the PCC MUST send a PCRpt as described in [RFC8231]. The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R flag in the SRP object MUST be set.
移除LSP后，PCC必须发送[RFC8231]中所述的PCRpt。PCRpt中的SRP对象必须包含触发删除的PCInitiate消息中的SRP ID号。必须设置SRP对象中的R标志。
The PCC MUST delegate PCE-initiated LSPs to the PCE upon instantiation. The PCC MUST set the delegation bit to 1 in the PCRpt that includes the assigned PLSP-ID.
PCC必须在实例化时将PCE启动的LSP委托给PCE。PCC必须在包含分配的PLSP-ID的PCRpt中将委派位设置为1。
The PCC MUST NOT revoke the delegation for a PCE-initiated LSP on an active PCEP session. Therefore, all PCRpt messages from the PCC to the PCE that owns the delegation MUST have the delegation bit set to 1. If the PCE that owns the delegation receives a PCRpt message with the delegation bit set to 0, then it MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=7 (Delegation for PCE-initiated LSP cannot be revoked). The PCE MAY further react by closing the session.
PCC不得在活动PCEP会话上撤销PCE启动的LSP的委派。因此，从PCC到拥有委派的PCE的所有PCRpt消息必须将委派位设置为1。如果拥有委派的PCE接收到委派位设置为0的PCRpt消息，则必须发送错误类型为19（无效操作）且错误值为7的PCErr消息（无法撤销PCE启动的LSP的委派）。PCE可通过关闭会话来进一步作出反应。
Control over a PCE-initiated LSP can revert to the PCC in two ways. A PCE MAY return a delegation to the PCC to allow for LSP transfer between PCEs. Alternatively, the PCC gains control of an LSP if the PCEP session that it was delegated on fails and the Redelegation Timeout Interval timer expires. In both cases, the LSP becomes an orphan until the expiration of the State Timeout Interval timer [RFC8231].
对PCE启动的LSP的控制可以通过两种方式恢复到PCC。PCE可以向PCC返回委托，以允许在PCE之间传输LSP。或者，如果被委派的PCEP会话失败且重新委派超时间隔计时器过期，PCC将获得LSP的控制权。在这两种情况下，LSP在状态超时间隔计时器[RFC8231]过期之前都会成为孤立的。
The PCC MAY attempt to redelegate an orphaned LSP by following the procedures of [RFC8231]. Alternatively, if the orphaned LSP was PCE-initiated, then a PCE MAY obtain control over it, as follows.
PCC可尝试按照[RFC8231]中的程序重新发送孤立LSP。或者，如果孤立LSP是PCE发起的，则PCE可以获得对其的控制，如下所示。
A PCE (either the original or one of its backups) sends a PCInitiate message that includes just the SRP and LSP objects and carries the PLSP-ID of the LSP it wants to take control of. If the PCC receives a PCInitiate message with a PLSP-ID pointing to an orphaned PCE-initiated LSP, then it MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST result in the generation of a PCErr message using the rules described in Section 5.4. The State Timeout Interval timer for the LSP is stopped upon the redelegation. After obtaining control of the LSP, the PCE may remove it using the procedures described in this document.
PCE（原始或其一个备份）发送一条PCInitiate消息，该消息仅包括SRP和LSP对象，并携带它想要控制的LSP的PLSP-ID。如果PCC收到一条PCInitiate消息，其PLSP-ID指向一个孤立的PCE启动的LSP，则必须将该LSP重新发送到PCE。任何其他非零PLSP-ID必须使用第5.4节中描述的规则生成PCErr消息。LSP的状态超时间隔计时器在重新发送时停止。在获得LSP的控制后，PCE可使用本文件中描述的程序将其移除。
The State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC MUST support removal of PCE-initiated LSPs as one of the behaviors applied on expiration of the State Timeout Interval timer. The behavior MUST be picked based on local policy and can result in either LSP removal or reverting to operator-defined default parameters.
状态超时间隔计时器确保PCE崩溃不会导致使用PCE启动的LSP的服务自动立即中断。PCE启动的LSP不会在PCE故障时立即移除。相反，它们会在计时器过期时被清除。这允许在无需手动干预的情况下进行网络清理。PCC必须支持删除PCE启动的LSP，作为在状态超时间隔计时器过期时应用的行为之一。必须根据本地策略选择该行为，并可能导致LSP删除或恢复为操作员定义的默认参数。
LSP State Synchronization procedures are described in Section 5.6 of [RFC8231]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP object. For PCE-initiated LSPs, the PCC MUST also set the Create flag in the LSP object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of State Synchronization, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. Under some circumstances, depending on the deployment, it might be preferable for a PCE not to send this PCInitiate immediately, or at all. For example, the PCC may be a slow device, or the operator might prefer not to disrupt active flows.
LSP状态同步程序在[RFC8231]的第5.6节中进行了描述。在状态同步期间，PCC使用PCRpt消息向PCE报告其LSP的状态，并在LSP对象中设置同步标志。对于PCE发起的LSP，PCC还必须在LSP对象中设置创建标志，并且可以包括识别请求创建LSP的PCE的SPEAKER-ENTITY-ID TLV。在状态同步结束时，PCE应发送PCInitiate消息以启动任何缺失的LSP和/或删除任何不需要的LSP。在某些情况下，根据部署情况，PCE最好不要立即或根本不发送此PCInitiate。例如，PCC可能是慢速设备，或者操作员可能更愿意不中断活动流。
As detailed below, IANA has allocated code points for the protocol elements defined in this document.
如下所述，IANA已为本文件中定义的协议元素分配了代码点。
IANA has registered the following message type within the "PCEP Messages" subregistry of the PCEP Numbers registry. (Note that the early allocation for this message type was called "Initiate"; it has been changed as follows.)
IANA已在PCEP号码注册中心的“PCEP消息”子区内注册了以下消息类型。（请注意，此消息类型的早期分配称为“Initiate”；其更改如下。）
Value Meaning Reference
----- -------------------- -------------
12 LSP Initiate Request RFC 8281
Value Meaning Reference
----- -------------------- -------------
12 LSP Initiate Request RFC 8281
[RFC8231] defines the LSP object; per that RFC, IANA created a registry to manage the value of the LSP object's Flag field. IANA has allocated a new bit in the "LSP Object Flag Field" subregistry, as follows:
[RFC8231]定义LSP对象；根据该RFC，IANA创建了一个注册表来管理LSP对象标志字段的值。IANA已在“LSP对象标志字段”子区域中分配了一个新位，如下所示：
Bit Description Reference
--- ----------- -------------
Bit Description Reference
--- ----------- -------------
4 Create RFC 8281
4创建RFC 8281
IANA has created a new subregistry, named "SRP Object Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the SRP object. New values are to be assigned by Standards Action [RFC8126]. Each bit is tracked with the following qualities: bit number (counting from bit 0 as the most significant bit), description, and defining RFC.
IANA在“路径计算元素协议（PCEP）编号”注册表中创建了一个新的子区域，名为“SRP对象标志字段”，用于管理SRP对象的标志字段。新值将由标准行动[RFC8126]分配。跟踪每一位的质量如下：位号（从位0开始计算为最高有效位）、描述和定义RFC。
The following values are defined in this document:
本文件中定义了以下值：
Bit Description Reference
--- ----------- -------------
Bit Description Reference
--- ----------- -------------
31 LSP-Remove RFC 8281
31 LSP拆卸RFC 8281
[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA created a registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows:
[RFC8231]定义有状态PCE能力TLV；根据该RFC，IANA创建了一个注册表来管理STATEFUL-PCE-CAPABILITY TLV的标志字段的值。IANA已在STATEFUL-PCE-CAPABILITY TLV标志字段注册表中分配了一个新位，如下所示：
Bit Description Reference
--- -------------------------------- -------------
Bit Description Reference
--- -------------------------------- -------------
29 LSP-INSTANTIATION-CAPABILITY (I) RFC 8281
29 LSP-实例化-能力（I）RFC 8281
IANA has registered the following error types and error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry.
IANA已在PCEP编号注册表的“PCEP-error对象错误类型和值”子区内注册了以下错误类型和错误值。
Error-Type Meaning
---------- --------------
10 Reception of an invalid object
Error-Type Meaning
---------- --------------
10 Reception of an invalid object
Error-value=8: SYMBOLIC-PATH-NAME TLV missing
错误值=8:缺少符号路径名TLV
19 Invalid Operation
19无效操作
Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked
Error-value=8: Non-zero PLSP-ID in LSP Initiate Request
Error-value=9: LSP is not PCE initiated
Error-value=10: PCE-initiated operation-frequency limit
reached
Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked
Error-value=8: Non-zero PLSP-ID in LSP Initiate Request
Error-value=9: LSP is not PCE initiated
Error-value=10: PCE-initiated operation-frequency limit
reached
23 Bad parameter value
23错误的参数值
Error-value=1: SYMBOLIC-PATH-NAME in use Error-value=2: Speaker identity included for an LSP that is not PCE initiated
错误值=1:SYMBOL-PATH-NAME正在使用错误值=2:LSP包含的非PCE启动的扬声器标识
24 LSP instantiation error
24 LSP实例化错误
Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error
Error-value=3: Signaling error
Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error
Error-value=3: Signaling error
The security considerations described in [RFC8231] apply to the extensions described in this document. Additional considerations related to a malicious PCE are introduced.
[RFC8231]中描述的安全注意事项适用于本文档中描述的扩展。介绍了与恶意PCE相关的其他注意事项。
The LSP instantiation mechanism described in this document allows a PCE to generate state on the PCC and throughout the network. As a result, it introduces a new attack vector: an attacker may flood the PCC with LSP instantiation requests and consume network and LSR resources by either spoofing messages or compromising the PCE itself.
本文档中描述的LSP实例化机制允许PCE在PCC和整个网络上生成状态。因此，它引入了一种新的攻击向量：攻击者可能会向PCC大量发送LSP实例化请求，并通过欺骗消息或破坏PCE本身来消耗网络和LSR资源。
A PCC can protect itself from such an attack by imposing a limit on either the number of LSPs or the percentage of resources that are allocated to honor PCE-initiated LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached) and is free to drop any incoming PCInitiate messages for LSP initiation without additional processing.
PCC可以通过限制LSP的数量或分配给PCE发起的LSP请求的资源百分比来保护自己免受此类攻击。一旦达到该限制，PCC必须发送错误类型为19（无效操作）且错误值为6（达到PCE启动的LSP限制）的PCErr消息，并且可以自由删除任何传入的PCInitiate消息以启动LSP，无需额外处理。
Rapid flaps triggered by the PCE can also be an attack vector. A PCC can protect itself from such an attack by imposing a limit on the number of flaps per unit of time that it allows a PCE to generate. As soon as that limit is reached, a PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=10 (PCE-initiated operation-frequency limit reached) and is free to treat the session as having reached the limit in terms of resources allocated to honor PCE-initiated LSP requests, either permanently or for a locally-defined cool-off period.
PCE触发的快速皮瓣也可以是攻击向量。PCC可以通过限制每单位时间内允许PCE产生的襟翼数量来保护自己免受此类攻击。一旦达到该限制，PCC必须发送错误类型为19（无效操作）且错误值为10（已达到PCE启动的操作频率限制）的PCErr消息，并且可以根据分配给PCE启动的LSP请求的资源将会话视为已达到限制，永久或局部规定的冷却期。
The LSP instantiation mechanism described in this document requires the PCE to keep state for LSPs that it instantiates and relies on the PCC responding (with either a state report or an error message) to requests for LSP instantiation. A malicious PCC or one that reached the limit of the number of PCE-initiated LSPs can ignore PCE requests and consume PCE resources. A PCE can protect itself by imposing a limit on the number of requests pending or by setting a timeout, and it MAY take further action such as closing the session or removing all the LSPs it initiated.
本文档中描述的LSP实例化机制要求PCE保持其实例化的LSP的状态，并依赖PCC对LSP实例化请求的响应（状态报告或错误消息）。恶意PCC或达到PCE启动的LSP数量限制的PCC可以忽略PCE请求并消耗PCE资源。PCE可以通过限制挂起的请求数或设置超时来保护自己，它还可以采取进一步的措施，如关闭会话或删除它启动的所有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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的路径计算元素通信协议（PCEP）扩展”，RFC 8231，DOI 10.17487/RFC82312017年9月<https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>.
[RFC8232]Crabbe，E.，Minei，I.，Medved，J.，Varga，R.，Zhang，X.，和D.Dhody，“有状态PCE标签交换路径状态同步程序的优化”，RFC 8232，DOI 10.17487/RFC8232，2017年9月<https://www.rfc-editor.org/info/rfc8232>.
[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>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]Zhang，X.，Ed.和I.Minei，Ed.“有状态路径计算元素（PCE）的适用性”，RFC 8051，DOI 10.17487/RFC8051，2017年1月<https://www.rfc-editor.org/info/rfc8051>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgments
致谢
We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, Cyril Margaria, Dhruv Dhody, Raveendra Trovi, and Jon Hardwick for their contributions to this document.
我们要感谢Jan Medved、Ambrose Kwong、Ramon Casellas、Cyril Margaria、Dhruv Dhody、Ravendra Trovi和Jon Hardwick对本文件的贡献。
Authors' Addresses
作者地址
Edward Crabbe Individual Contributor
Edward Crabbe可能是个人贡献者
Email: edward.crabbe@gmail.com
Email: edward.crabbe@gmail.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
Siva Sivabalan Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America
Siva Sivabalan Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼博士170号，邮编95134
Email: msiva@cisco.com
Email: msiva@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