Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 8408 Cisco Systems, Inc.
Category: Standards Track J. Tantsura
ISSN: 2070-1721 Nuage Networks
I. Minei
Google, Inc.
R. Varga
Pantheon Technologies SRO
J. Hardwick
Metaswitch Networks
July 2018
Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 8408 Cisco Systems, Inc.
Category: Standards Track J. Tantsura
ISSN: 2070-1721 Nuage Networks
I. Minei
Google, Inc.
R. Varga
Pantheon Technologies SRO
J. Hardwick
Metaswitch Networks
July 2018
Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
PCE通信协议（PCEP）消息中的传输路径设置类型
Abstract
摘要
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.
路径计算单元（PCE）可以计算通过网络的流量工程（TE）路径；这些路径受到各种约束。目前，TE路径是使用RSVP-TE信令协议设置的标签交换路径（LSP）。然而，其他TE路径设置方法在PCE架构内也是可能的。本文档建议对PCE通信协议（PCEP）进行扩展，以允许在给定PCEP会话上支持不同的路径设置方法。
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/rfc8408.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8408.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Additions to PCEP TLV Type Indicators Registry . . . . . 9
8.2. New PCEP Path Setup Types Registry . . . . . . . . . . . 9
8.3. Additions to PCEP-ERROR Object Error Types and Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Additions to PCEP TLV Type Indicators Registry . . . . . 9
8.2. New PCEP Path Setup Types Registry . . . . . . . . . . . 9
8.3. Additions to PCEP-ERROR Object Error Types and Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
[RFC5440] describes the PCE Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a PCE and a PCE. A PCC requests, from a PCE, a path subject to various constraints and optimization criteria. The PCE responds to the PCC with a hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the ERO to set up the path in the network.
[RFC5440]描述用于路径计算客户端（PCC）和路径计算元件（PCE）之间或PCE和PCE之间通信的PCE通信协议（PCEP）。PCC从PCE请求受各种约束和优化标准约束的路径。PCE通过显式路由对象（ERO）中的逐跳路径响应PCC。PCC使用ERO在网络中设置路径。
[RFC8231] specifies extensions to PCEP that allow a PCC to delegate its LSPs to a PCE. The PCE can then update the state of LSPs delegated to it. In particular, the PCE may modify the path of an LSP by sending a new ERO. The PCC uses this ERO to reroute the LSP in a make-before-break fashion. [RFC8281] specifies a mechanism that allows a PCE to dynamically instantiate an LSP on a PCC by sending the ERO and the characteristics of the LSP. The PCC creates the LSP using the ERO and other attributes sent by the PCE.
[RFC8231]指定PCEP的扩展，允许PCC将其LSP委托给PCE。然后，PCE可以更新委托给它的LSP的状态。具体地，PCE可以通过发送新的ERO来修改LSP的路径。PCC使用此ERO以先通后断的方式重新路由LSP。[RFC8281]指定一种机制，允许PCE通过发送ERO和LSP的特征，在PCC上动态实例化LSP。PCC使用ERO和PCE发送的其他属性创建LSP。
So far, PCEP and its extensions have assumed that the TE paths are label switched and are established via the RSVP-TE signaling protocol. However, other methods of LSP setup are possible in the PCE architecture (see [RFC4655] and [RFC4657]). This document generalizes PCEP to allow other LSP setup methods to be used. It defines two new TLVs and specifies the base procedures to facilitate this:
到目前为止，PCEP及其扩展假定TE路径是标签交换的，并通过RSVP-TE信令协议建立。但是，在PCE体系结构中也可以使用其他LSP设置方法（请参见[RFC4655]和[RFC4657]）。本文档概括了PCEP，以允许使用其他LSP设置方法。它定义了两个新的TLV，并规定了促进这一点的基本程序：
o The PATH-SETUP-TYPE-CAPABILITY TLV allows a PCEP speaker to announce which LSP setup methods it supports when the PCEP session is established.
o PATH-SETUP-TYPE-CAPABILITY TLV允许PCEP扬声器在建立PCEP会话时宣布其支持的LSP设置方法。
o The PATH-SETUP-TYPE TLV allows a PCEP speaker to specify which setup method should be used for a given LSP. When multiple path setup types are deployed in a network, a given PCEP session may have to simultaneously support more than one path setup type. A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate the intended path setup type in the appropriate PCEP messages, unless the path setup type is RSVP-TE (which is assumed to be the path setup type if no other setup type is indicated). This is so that both the PCC and the PCE can take the necessary steps to set up the path.
o PATH-SETUP-TYPE TLV允许PCEP扬声器指定给定LSP应使用哪种设置方法。在网络中部署多个路径设置类型时，给定的PCEP会话可能必须同时支持多个路径设置类型。PCEP扬声器使用PATH-SETUP-TYPE TLV在适当的PCEP消息中明确指示预期的路径设置类型，除非路径设置类型为RSVP-TE（如果未指示其他设置类型，则假定为路径设置类型）。这样，PCC和PCE都可以采取必要的步骤来设置路径。
This document defines a path setup type code for RSVP-TE. When a new path setup type (other than RSVP-TE) is introduced for setting up a path, a path setup type code and, optionally, a sub-TLV pertaining to the new path setup type will be defined by the document that specifies the new path setup type.
本文档定义了RSVP-TE的路径设置类型代码。当引入新的路径设置类型（RSVP-TE除外）来设置路径时，指定新路径设置类型的文档将定义路径设置类型代码以及与新路径设置类型相关的子TLV（可选）。
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]所述进行解释。
The following terminology is used in this document:
本文件使用以下术语：
ERO: Explicit Route Object
显式路由对象
PCC: Path Computation Client
路径计算客户端
PCE: Path Computation Element
路径计算元素
PCEP: PCE Communication Protocol
PCE通信协议
PST: Path Setup Type
路径设置类型
TLV: Type, Length, and Value
TLV：类型、长度和值
A PCEP speaker indicates which PSTs it supports during the PCEP initialization phase using the following process. When the PCEP session is created, it sends an Open message with an OPEN object containing the PATH-SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows.
PCEP扬声器使用以下过程指示其在PCEP初始化阶段支持的PST。创建PCEP会话时，它会发送一条Open消息，其中包含PATH-SETUP-TYPE-CAPABILITY TLV的Open对象。本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 (34) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (34) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
图1：路径设置类型能力TLV
The TLV Type is 34. Its Reserved field MUST be set to zero by the sender and MUST be ignored by the receiver. The other fields in the TLV are as follows.
TLV类型为34。发送方必须将其保留字段设置为零，接收方必须忽略该字段。TLV中的其他字段如下所示。
Length: The total length in bytes of the remainder of the TLV, that is, excluding the Type and Length fields.
长度：TLV其余部分的总长度（字节），即不包括类型和长度字段。
Num of PSTs: The number of PSTs in the following list, excluding padding.
PST数：以下列表中的PST数，不包括填充。
List of PSTs: A list of the PSTs that the PCEP speaker supports. Each PST is a single byte in length. Duplicate entries in this list MUST be ignored. The PCEP speaker MUST pad the list with zeros so that it is a multiple of four bytes in length. This document defines the following PST value:
PST列表：PCEP扬声器支持的PST列表。每个PST的长度为一个字节。必须忽略此列表中的重复条目。PCEP扬声器必须用零填充列表，使其长度为四个字节的倍数。本文件定义了以下PST值：
* PST = 0: Path is set up using the RSVP-TE signaling protocol
* PST=0：使用RSVP-TE信令协议设置路径
Optional sub-TLVs: A list of sub-TLVs associated with the supported PSTs. Each PST has zero or one sub-TLVs associated with it, and each sub-TLV is associated with exactly one PST. Each sub-TLV MUST obey the rules for TLV formatting defined in [RFC5440]. That is, each sub-TLV is padded to a four-byte alignment, and the Length field of each sub-TLV does not include the padding bytes. This document does not define any sub-TLVs; an example sub-TLV can be found in [PCEP-EXTENSIONS].
可选子TLV：与支持的PST关联的子TLV列表。每个PST都有零个或一个子TLV与其关联，而每个子TLV恰好与一个PST关联。每个子TLV必须遵守[RFC5440]中定义的TLV格式规则。也就是说，每个子TLV填充为四字节对齐，并且每个子TLV的长度字段不包括填充字节。本文件未定义任何子TLV；子TLV示例可在[PCEP-EXTENSIONS]中找到。
A PCEP speaker MUST check that this TLV is correctly formatted, as follows.
PCEP扬声器必须检查该TLV的格式是否正确，如下所示。
o If there are no sub-TLVs, then the TLV Length field MUST be equal to four bytes plus the size of the PST list, excluding any padding bytes.
o 如果没有子TLV，则TLV长度字段必须等于四个字节加上PST列表的大小，不包括任何填充字节。
o If there are sub-TLVs, then the TLV Length field MUST be equal to four bytes plus the size of the PST list (rounded up to the nearest multiple of four) plus the size of the appended sub-TLVs, excluding any padding bytes in the final sub-TLV.
o 如果存在子TLV，则TLV长度字段必须等于四个字节加上PST列表的大小（四舍五入到四的最接近倍数）加上附加的子TLV的大小，不包括最后一个子TLV中的任何填充字节。
o The Num of PSTs field MUST be greater than zero.
o PSTs字段的数量必须大于零。
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV that violates these rules, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 (Reception of an invalid object) and Error-value = 11 (Malformed object) and MUST close the PCEP session. The PCEP speaker MAY include the malformed OPEN object in the PCErr message as well.
如果PCEP扬声器接收到违反这些规则的PATH-SETUP-TYPE-CAPABILITY TLV，则PCEP扬声器必须发送错误类型=10（接收无效对象）和错误值=11（错误对象）的PCErr消息，并且必须关闭PCEP会话。PCEP扬声器也可能在PCErr消息中包含格式错误的打开对象。
If a PCEP speaker receives an OPEN object with more than one PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST ignore all but the first instance of this TLV.
如果PCEP扬声器接收到具有多个PATH-SETUP-TYPE能力TLV的开放对象，则必须忽略该TLV的所有实例，但第一个实例除外。
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a single PST value of 0 (Path is set up using the RSVP-TE signaling protocol) and no sub-TLVs. A PCEP speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST it supports is RSVP-TE. If a PCEP speaker supports other PSTs besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE-CAPABILITY TLV in its OPEN object.
开放对象中没有PATH-SETUP-TYPE-CAPABILITY TLV相当于包含单个PST值0（使用RSVP-TE信令协议设置路径）且没有子TLV的PATH-SETUP-TYPE-CAPABILITY TLV。如果PCEP扬声器支持的唯一PST是RSVP-TE，则可以省略PATH-SETUP-TYPE能力TLV。如果PCEP扬声器支持RSVP-TE以外的其他PST，则应在其开放对象中包含PATH-SETUP-TYPE-CAPABILITY TLV。
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY TLV, it will ignore the TLV in accordance with [RFC5440].
如果PCEP扬声器无法识别PATH-SETUP-TYPE能力TLV，它将根据[RFC5440]忽略TLV。
When a PCEP session is used to set up TE paths using different methods, the corresponding PCE and PCC must be aware of the path setup method used. This means that a PCE must be able to specify paths in the correct format, and a PCC must be able to take control-plane and forwarding-plane actions appropriate to the PST.
当PCEP会话用于使用不同方法设置TE路径时，相应的PCE和PCC必须知道所使用的路径设置方法。这意味着PCE必须能够以正确的格式指定路径，并且PCC必须能够采取适合PST的控制平面和转发平面操作。
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 (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-SETUP-TYPE TLV
图2：路径设置类型TLV
The PATH-SETUP-TYPE TLV is an optional TLV associated with the Request Parameters (RP) [RFC5440] and the Stateful PCE Request Parameters (SRP) [RFC8231] objects. Its format is shown in Figure 2. The TLV type is 28. Its Reserved field MUST be set to zero. The one-byte PST field contains the PST as defined for the PATH-SETUP-TYPE-CAPABILITY TLV.
PATH-SETUP-TYPE TLV是与请求参数（RP）[RFC5440]和有状态PCE请求参数（SRP）[RFC8231]对象关联的可选TLV。其格式如图2所示。TLV类型为28。其保留字段必须设置为零。单字节PST字段包含为PATH-SETUP-TYPE-CAPABILITY TLV定义的PST。
The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-TYPE TLV with a PST value of 0 (Path is set up using the RSVP-TE signaling protocol). A PCEP speaker MAY omit the TLV if the PST is RSVP-TE. If the RP or SRP object contains more than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed, and the rest MUST be ignored.
缺少PATH-SETUP-TYPE TLV相当于PST值为0的PATH-SETUP-TYPE TLV（使用RSVP-TE信令协议设置路径）。如果PST为RSVP-TE，则PCEP扬声器可省略TLV。如果RP或SRP对象包含多个PATH-SETUP-TYPE TLV，则只需处理第一个TLV，其余TLV必须忽略。
If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will ignore the TLV in accordance with [RFC5440] and use RSVP-TE to set up the path.
如果PCEP扬声器无法识别PATH-SETUP-TYPE TLV，它将根据[RFC5440]忽略TLV，并使用RSVP-TE设置路径。
During the PCEP initialization phase, if a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the peer supports only the PSTs listed in the TLV. If the PCEP speaker and its peer have no PSTs in common, then the PCEP speaker MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 2 (Mismatched path setup type) and close the PCEP session.
在PCEP初始化阶段，如果PCEP扬声器从其对等方接收到路径设置类型功能TLV，则必须假定对等方仅支持TLV中列出的PST。如果PCEP扬声器及其对等机没有共同的PST，则PCEP扬声器必须发送错误类型为21（无效的流量工程路径设置类型）且错误值为2（不匹配的路径设置类型）的PCErr消息，并关闭PCEP会话。
If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP speaker MUST infer that the peer supports path setup using at least RSVP-TE. The PCEP speaker MAY also infer that the peer supports other path setup types, but the means of inference are outside the scope of this document.
如果对等方未发送路径设置类型功能TLV，则PCEP扬声器必须推断对等方至少支持使用RSVP-TE进行路径设置。PCEP演讲者还可以推断对等方支持其他路径设置类型，但推断方法不在本文档范围内。
When a PCC sends a PCReq message to a PCE [RFC5440], it MUST include the PATH-SETUP-TYPE TLV in the RP object, unless the intended PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCE is capable of expressing the path in a format appropriate to the intended PST, it MUST use the appropriate ERO format in the PCRep message.
当PCC向PCE[RFC5440]发送PCReq消息时，它必须在RP对象中包含PATH-SETUP-TYPE TLV，除非预期的PST是RSVP-TE（在这种情况下，它可能忽略PATH-SETUP-TYPE TLV）。如果PCE能够以适合预期PST的格式表示路径，则必须在PCRep消息中使用适当的ERO格式。
When a PCE sends a PCRep message to a PCC [RFC5440], it MUST include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCE does not support the intended PST, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 1 (Unsupported path setup type) and close the PCEP session. If the PSTs corresponding to the PCReq and PCRep messages do not match, the PCC MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 2 (Mismatched path setup type) and close the PCEP session.
当PCE向PCC[RFC5440]发送PCRep消息时，它必须在RP对象中包含PATH-SETUP-TYPE TLV，除非PST是RSVP-TE（在这种情况下，它可能忽略PATH-SETUP-TYPE TLV）。如果PCE不支持预期的PST，则必须发送错误类型为21（无效的流量工程路径设置类型）且错误值为1（不支持的路径设置类型）的PCErr消息，并关闭PCEP会话。如果与PCReq和PCRep消息对应的PST不匹配，PCC必须发送错误类型为21（无效的流量工程路径设置类型）和错误值为2（不匹配的路径设置类型）的PCErr消息，并关闭PCEP会话。
When a stateful PCE sends a PCUpd message [RFC8231] or a PCInitiate message [RFC8281] to a PCC, it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCC does not support the PST associated with the PCUpd or PCInitiate message, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 1 (Unsupported path setup type) and close the PCEP session.
When a stateful PCE sends a PCUpd message [RFC8231] or a PCInitiate message [RFC8281] to a PCC, it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCC does not support the PST associated with the PCUpd or PCInitiate message, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 1 (Unsupported path setup type) and close the PCEP session.translate error, please retry
When a PCC sends a PCRpt message to a stateful PCE [RFC8231], it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). The PCC MUST include the SRP object in the PCRpt message if the PST is not RSVP-TE, even when the SRP-ID-number is the reserved value of 0x00000000. If the PCRpt message is triggered by a PCUpd or PCInitiate message, then the PST that the PCC indicates in the PCRpt message MUST match the PST that the stateful PCE intended in the PCUpd or PCInitiate message. If it does not match, then the PCE MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 2 (Mismatched path setup type) and close the PCEP session.
当PCC向有状态PCE发送PCRpt消息[RFC8231]时，它必须在SRP对象中包含PATH-SETUP-TYPE TLV，除非PST是RSVP-TE（在这种情况下，它可能忽略PATH-SETUP-TYPE TLV）。如果PST不是RSVP-TE，即使SRP ID号是保留值0x00000000，PCC也必须在PCRpt消息中包含SRP对象。如果PCRpt消息由PCUpd或PCInitiate消息触发，则PCC在PCRpt消息中指示的PST必须与PCUpd或PCInitiate消息中预期的有状态PCE的PST匹配。如果不匹配，则PCE必须发送错误类型为21（无效的流量工程路径设置类型）和错误值为2（不匹配的路径设置类型）的PCErr消息，并关闭PCEP会话。
This document generalizes PCEP to allow path setup methods other than RSVP-TE to be used by the network (but does not define any new path setup types besides RSVP-TE). It is possible that, in a given network, multiple path setup methods will be used. It is also possible that not all devices will support the same set of path setup methods. Managing networks that combine multiple path setup methods may therefore raise some challenges from a configuration and observability point of view.
本文档概括了PCEP，允许网络使用RSVP-TE以外的路径设置方法（但未定义RSVP-TE以外的任何新路径设置类型）。在给定的网络中，可能会使用多路径设置方法。也可能并非所有设备都支持相同的路径设置方法。因此，从配置和可观测性的角度来看，管理结合了多路径设置方法的网络可能会带来一些挑战。
Each document that defines a new path setup type in the "PCEP Path Setup Types" registry (Section 8.2) must include a Manageability Considerations section. The Manageability Considerations section must explain how operators can manage PCEP with the new path setup type. It must address the following questions, which are generally applicable when working with multiple path setup types in PCEP.
在“PCEP路径设置类型”注册表（第8.2节）中定义新路径设置类型的每个文档必须包括可管理性注意事项部分。可管理性注意事项部分必须解释操作员如何使用新的路径设置类型管理PCEP。它必须解决以下问题，这些问题通常适用于在PCEP中处理多路径设置类型。
o What are the criteria for when devices will use the new path setup type in PCEP, and how can the operator control this?
o 设备何时在PCEP中使用新路径设置类型的标准是什么，操作员如何控制？
o How can the network be migrated to the new path setup type, and are there any backwards-compatibility issues that operators need to be aware of?
o 如何将网络迁移到新的路径设置类型，运营商是否需要注意任何向后兼容性问题？
o Are paths set up using the new path setup type intended to coexist with other paths over the long term, and if so, how is this situation managed with PCEP?
o 使用新路径设置类型设置的路径是否打算长期与其他路径共存？如果是，如何使用PCEP管理这种情况？
o How can operators verify the correct operation of PCEP in the network with respect to the new path setup type? Which fault conditions must be reported to the operators?
o 操作员如何根据新的路径设置类型验证PCEP在网络中的正确操作？必须向操作员报告哪些故障情况？
o Are there any existing management interfaces (such as YANG models) that must be extended to model the operation of PCEP in the network with respect to the new path setup type?
o 是否存在任何必须扩展的现有管理接口（如YANG模型），以针对新的路径设置类型对网络中的PCEP操作进行建模？
See [RFC5706] for further guidance on how to write Manageability Considerations sections in Standards Track documents.
有关如何在标准跟踪文档中编写可管理性注意事项部分的更多指导，请参见[RFC5706]。
The security considerations described in [RFC5440] and [RFC8281] are applicable to this specification. No additional security measure is required.
[RFC5440]和[RFC8281]中描述的安全注意事项适用于本规范。不需要额外的安全措施。
Note that if the security mechanisms of [RFC5440] and [RFC8281] are not used, then the protocol described in this document could be attacked in the following new way. An attacker, using a TCP man-in-the-middle attack, could inject error messages into the PCEP session when a particular PST is (or is not) used. Doing this could potentially force the use of a specific PST, which may allow the attacker to subsequently attack a weakness in that PST.
请注意，如果未使用[RFC5440]和[RFC8281]的安全机制，则本文档中描述的协议可能会受到以下新方式的攻击。当使用（或未使用）特定PST时，攻击者可使用TCP中间人攻击将错误消息注入PCEP会话。这样做可能会强制使用特定PST，从而允许攻击者随后攻击该PST中的弱点。
IANA has allocated the following code points in the "PCEP TLV Type Indicators" registry.
IANA已在“PCEP TLV类型指示器”注册表中分配了以下代码点。
Value Description Reference
----- -------------------------- ---------
28 PATH-SETUP-TYPE RFC 8408
34 PATH-SETUP-TYPE-CAPABILITY RFC 8408
Value Description Reference
----- -------------------------- ---------
28 PATH-SETUP-TYPE RFC 8408
34 PATH-SETUP-TYPE-CAPABILITY RFC 8408
IANA has created a new sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". The allocation policy for this new registry is IETF Review [RFC8126]. This new registry contains the following value:
IANA在“路径计算元素协议（PCEP）编号”注册表中创建了一个名为“PCEP路径设置类型”的新子注册表。此新注册表的分配策略为IETF Review[RFC8126]。此新注册表包含以下值：
Value Description Reference
----- -------------------------- ---------
0 Path is set up using the RFC 8408
RSVP-TE signaling protocol
Value Description Reference
----- -------------------------- ---------
0 Path is set up using the RFC 8408
RSVP-TE signaling protocol
IANA has allocated the following code points in the "PCEP-ERROR Object Error Types and Values" registry.
IANA已在“PCEP-ERROR对象错误类型和值”注册表中分配了以下代码点。
Error-Type Meaning Reference
---------- ------------------------------------------- ---------
10 Reception of an invalid object RFC 5440
Error-Type Meaning Reference
---------- ------------------------------------------- ---------
10 Reception of an invalid object RFC 5440
Error-value = 11: Malformed object RFC 8408
错误值=11：格式错误的对象RFC 8408
21 Invalid traffic engineering path setup type RFC 8408
21无效的流量工程路径设置类型RFC 8408
Error-value = 0: Unassigned RFC 8408
Error-value = 1: Unsupported path setup type RFC 8408
Error-value = 2: Mismatched path setup type RFC 8408
Error-value = 0: Unassigned RFC 8408
Error-value = 1: Unsupported path setup type RFC 8408
Error-value = 2: Mismatched path setup type RFC 8408
[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>.
[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>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8281]Crabbe，E.，Minei，I.，Sivabalan，S.，和R.Varga，“有状态PCE模型中PCE启动LSP设置的路径计算元素通信协议（PCEP）扩展”，RFC 8281，DOI 10.17487/RFC8281，2017年12月<https://www.rfc-editor.org/info/rfc8281>.
[PCEP-EXTENSIONS] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.
[PCEP-扩展]Sivabalan，S.，Filsfils，C.，Tantsura，J.，Henderickx，W.，和J.Hardwick，“分段布线的PCEP扩展”，在建工程，草案-ietf-pce-分段布线-12，2018年6月。
[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>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，DOI 10.17487/RFC5706，2009年11月<https://www.rfc-editor.org/info/rfc5706>.
[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>.
Acknowledgements
致谢
We would like to thank Marek Zavodsky for valuable comments.
我们要感谢马雷克·扎沃茨基的宝贵评论。
Contributors
贡献者
The following people contributed to this document:
以下人员对此文件作出了贡献：
- Jan Medved - Edward Crabbe
- 简·梅德维德-爱德华·克拉布
Authors' Addresses
作者地址
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Siva Sivabalan思科系统公司，加拿大安大略省卡纳塔创新大道2000号K2K 3E8
Email: msiva@cisco.com
Email: msiva@cisco.com
Jeff Tantsura Nuage Networks 755 Ravendale Drive Mountain View, CA 94043 United States of America
Jeff Tantsura Nuage Networks 755 Ravendale Drive Mountain View，加利福尼亚州，美国94043
Email: jefftant.ietf@gmail.com
Email: jefftant.ietf@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
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56 Bratislava, 821 05 Slovakia
罗伯特·瓦尔加万神殿科技有限公司SRO Mlynske Nivy 56布拉迪斯拉发，邮编：821 05斯洛伐克
Email: nite@hq.sk
Email: nite@hq.sk
Jon Hardwick Metaswitch Networks 100 Church Street Enfield, Middlesex United Kingdom
Jon Hardwick Metaswitch Networks英国米德尔塞克斯郡恩菲尔德教堂街100号
Email: jonathan.hardwick@metaswitch.com
Email: jonathan.hardwick@metaswitch.com