Network Working Group E. Oki
Request for Comments: 5521 University of Electro-Communications
Category: Standards Track T. Takeda
NTT
A. Farrel
Old Dog Consulting
April 2009
Network Working Group E. Oki
Request for Comments: 5521 University of Electro-Communications
Category: Standards Track T. Takeda
NTT
A. Farrel
Old Dog Consulting
April 2009
Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
用于路由排除的路径计算元素通信协议（PCEP）的扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
在多协议标签交换（MPLS）和广义MPLS（GMPLS）网络中，路径计算单元（PCE）提供支持流量工程（TE）的路径计算功能。
When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".
当路径计算客户端（PCC）请求用于路由的PCE时，PCC将从计算路由显式排除的抽象节点、资源和共享风险链路组（srlg）指定为路径计算的约束可能是有用的。这种限制被称为“路线排除”。
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions.
PCE通信协议（PCEP）设计为PCC和PCE之间的通信协议。本文件介绍了路线排除的PCEP扩展。
Table of Contents
目录
1. Introduction ................................................. 3
1.1. Conventions Used in This Document .......................3
2. Protocol Procedures and Extensions ........................... 4
2.1. Exclude Route Object (XRO) ............................. 4
2.1.1. Definition ..................................... 4
2.1.2. Processing Rules ............................... 8
2.2. Explicit Route Exclusion ............................... 9
2.2.1. Definition ..................................... 9
2.2.2. Processing Rules .............................. 10
3. Exclude Route with Confidentiality .......................... 11
3.1. Exclude Route Object (XRO) Carrying Path-Key .......... 11
3.1.1. Definition .................................... 11
3.1.2. Processing Rules .............................. 12
4. IANA Considerations ......................................... 13
4.1. PCEP Objects .......................................... 13
4.2. New Subobject for the Include Route Object ............ 13
4.3. Error Object Field Values ............................. 13
4.4. Exclude Route Flags ................................... 14
5. Manageability Considerations ................................ 14
6. Security Considerations ..................................... 14
7. References .................................................. 15
7.1. Normative References .................................. 15
7.2. Informative References ................................ 15
Acknowledgements ................................................ 16
1. Introduction ................................................. 3
1.1. Conventions Used in This Document .......................3
2. Protocol Procedures and Extensions ........................... 4
2.1. Exclude Route Object (XRO) ............................. 4
2.1.1. Definition ..................................... 4
2.1.2. Processing Rules ............................... 8
2.2. Explicit Route Exclusion ............................... 9
2.2.1. Definition ..................................... 9
2.2.2. Processing Rules .............................. 10
3. Exclude Route with Confidentiality .......................... 11
3.1. Exclude Route Object (XRO) Carrying Path-Key .......... 11
3.1.1. Definition .................................... 11
3.1.2. Processing Rules .............................. 12
4. IANA Considerations ......................................... 13
4.1. PCEP Objects .......................................... 13
4.2. New Subobject for the Include Route Object ............ 13
4.3. Error Object Field Values ............................. 13
4.4. Exclude Route Flags ................................... 14
5. Manageability Considerations ................................ 14
6. Security Considerations ..................................... 14
7. References .................................................. 15
7.1. Normative References .................................. 15
7.2. Informative References ................................ 15
Acknowledgements ................................................ 16
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4655]中定义的路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体。路径计算客户端（PCC）可以向PCE请求要计算的路径。
When a PCC requests a PCE for a route, it may be useful for the PCC to specify abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the route.
当PCC为路由请求PCE时，PCC可以指定从路由中明确排除的抽象节点、资源和共享风险链路组（SRLGs）。
For example, disjoint paths for inter-domain Label Switched Paths (LSPs) may be computed by cooperation between PCEs, each of which computes segments of the paths across one domain. In order to achieve path computation for a secondary (backup) path, a PCE may act as a PCC to request another PCE for a route that must be node/link/SRLG disjoint from the primary (working) path. Another example is where a network operator wants a path to avoid specified nodes for administrative reasons, perhaps because the specified nodes will be out-of-service in the near future.
例如，域间标签交换路径（lsp）的不相交路径可以通过pce之间的协作来计算，每个pce计算跨一个域的路径段。为了实现辅助（备份）路径的路径计算，PCE可以充当PCC来请求另一PCE用于必须是节点/链路/SRLG与主（工作）路径不相交的路由。另一个例子是，由于管理原因，网络运营商希望路径避开指定的节点，可能是因为指定的节点在不久的将来将停止服务。
[RFC4657] specifies generic requirements for a communication protocol between PCCs and PCEs. Generic constraints described in [RFC4657] include route exclusions for links, nodes, and SRLGs. That is, the requirement for support of route exclusions within the PCC-PCE communication protocol is already established.
[RFC4657]规定了PCC和PCE之间通信协议的一般要求。[RFC4657]中描述的通用约束包括链路、节点和SRLGs的路由排除。也就是说，已经确定了PCC-PCE通信协议中支持路由排除的要求。
The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [RFC5440]. This document presents PCEP extensions to satisfy the requirements for route exclusions as described in Sections 5.1.4 and 5.1.16 of [RFC4657].
PCE通信协议（PCEP）设计为PCC和PCE之间的通信协议，并在[RFC5440]中定义。本文件介绍了PCEP扩展，以满足[RFC4657]第5.1.4节和第5.1.16节所述的路线排除要求。
Note that MPLS-TE and GMPLS signaling extensions for communicating route exclusions between network nodes for specific Label Switched Paths (LSPs) are described in [RFC4874]. Route exclusions may be specified during provisioning requests for specific LSPs by setting the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812] to false (2).
注意，在[RFC4874]中描述了用于在特定标签交换路径（LSP）的网络节点之间通信路由排除的MPLS-TE和GMPLS信令扩展。通过将[RFC3812]中定义的MPLS-TE-STD-MIB的MPLStunnelHopiInclude对象设置为false（2），可以在特定LSP的设置请求期间指定路由排除。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section describes the procedures adopted by a PCE handling a request for path computation with route exclusions received from a PCC, and defines how those exclusions are encoded.
本节描述PCE使用从PCC接收的路由排除处理路径计算请求所采用的过程，并定义这些排除的编码方式。
There are two types of route exclusion described in [RFC4874].
[RFC4874]中描述了两种类型的路由排除。
1. Exclusion of certain abstract nodes or resources from the whole path. This set of abstract nodes is referred to as the Exclude Route List.
1. 从整个路径中排除某些抽象节点或资源。这组抽象节点称为排除路由列表。
2. Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an explicit path. Such specific exclusions are referred to as an Explicit Route Exclusion.
2. 在显式路径中存在的特定抽象节点对之间排除某些抽象节点或资源。此类特定排除被称为显式路由排除。
This document defines protocol extensions to allow a PCC to specify both types of route exclusions to a PCE on a path computation request.
本文档定义了协议扩展，以允许PCC在路径计算请求中为PCE指定两种类型的路由排除。
A new PCEP object, the Exclude Route Object (XRO), is defined to convey the Exclude Route List. The existing Include Route Object (IRO) in PCEP [RFC5440] is modified by introducing a new IRO subobject, the Explicit Exclusion Route subobject (EXRS), to convey Explicit Route Exclusions.
定义了一个新的PCEP对象，即排除路由对象（XRO），以传递排除路由列表。PCEP[RFC5440]中现有的包含路由对象（IRO）通过引入新的IRO子对象，即显式排除路由子对象（EXRS）进行修改，以传递显式路由排除。
The XRO is OPTIONAL and MAY be carried within Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages.
XRO是可选的，可以在路径计算请求（PCReq）和路径计算回复（PCRep）消息中携带。
When present in a PCReq message, the XRO provides a list of network resources that the PCE is requested to exclude from the path that it computes. Flags associated with each list member instruct the PCE as to whether the network resources must be excluded from the computed path, or whether the PCE should make best efforts to exclude the resources from the computed path.
当出现在PCReq消息中时，XRO会提供一个网络资源列表，请求PCE从其计算的路径中排除这些资源。与每个列表成员关联的标志指示PCE是否必须从计算路径中排除网络资源，或者PCE是否应尽最大努力从计算路径中排除资源。
The XRO MAY be used on a PCRep message that carries the NO-PATH object (i.e., one that reports a path computation failure) to indicate the set of elements of the original XRO that prevented the PCE from finding a path.
XRO可用于承载无路径对象（即，报告路径计算失败的对象）的PCRep消息，以指示阻止PCE查找路径的原始XRO元素集。
The XRO MAY also be used on a PCRep message for a successful path computation when the PCE wishes to provide a set of exclusions to be
当PCE希望提供一组要删除的排除项时，XRO也可用于PCRep消息以进行成功的路径计算
signaled during LSP setup using the extensions to Resource Reservation Protocol (RSVP)-TE [RFC4874].
在LSP设置期间，使用资源预留协议扩展（RSVP）-TE[RFC4874]发出信号。
The XRO Object-Class is 17.
XRO对象类是17。
The XRO Object-Type is 1.
XRO对象类型为1。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: XRO Body Format
图1:XRO正文格式
Reserved: 16 bits - MUST be set to zero on transmission and SHOULD be ignored on receipt.
保留：16位-传输时必须设置为零，接收时应忽略。
Flags: 16 bits - The following flags are currently defined:
标志：16位-当前定义了以下标志：
F (Fail - 1 bit): when set, the requesting PCC requires the computation of a new path for an existing TE LSP that has failed. If the F bit is set, the path of the existing TE LSP MUST be provided in the PCReq message by means of a Record Route Object (RRO) defined in [RFC5440]. This allows the path computation to take into account the previous path and reserved resources to avoid double bandwidth booking should the Traffic Engineering Database (TED) have not yet been updated or the corresponding resources not be yet been released. This will usually be used in conjunction with the exclusion from the path computation of the failed resource that caused the LSP to fail.
F（失败-1位）：设置时，请求PCC需要为失败的现有TE LSP计算新路径。如果设置了F位，则必须通过[RFC5440]中定义的记录路由对象（RRO）在PCReq消息中提供现有TE LSP的路径。这允许路径计算考虑到以前的路径和保留资源，以避免在流量工程数据库（TED）尚未更新或相应资源尚未释放的情况下预订双带宽。这通常与导致LSP失败的失败资源的路径计算排除一起使用。
Subobjects: The XRO is made up of one or more subobject(s). An XRO with no subobjects MUST NOT be sent and SHOULD be ignored on receipt.
子对象：XRO由一个或多个子对象组成。不得发送没有子对象的XRO，并且在收到时应忽略它。
In the following subobject definitions, a set of fields have consistent meaning as follows:
在以下子对象定义中，一组字段具有以下一致含义：
X The X-bit indicates whether the exclusion is mandatory or desired. 0 indicates that the resource specified MUST be excluded from the path computed by the PCE. 1 indicates that the resource specified SHOULD be excluded from the path computed by the PCE, but MAY be
X位表示排除是强制的还是需要的。0表示指定的资源必须从PCE计算的路径中排除。1表示指定的资源应该从PCE计算的路径中排除，但可以是
included subject to PCE policy and the absence of a viable path that meets the other constraints and excludes the resource.
包括受PCE政策约束，且缺乏满足其他约束条件的可行路径，且不包括资源。
Type The type of the subobject. The following subobject types are defined.
键入子对象的类型。定义了以下子对象类型。
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
Length The length of the subobject including the Type and Length fields.
长度子对象的长度，包括类型和长度字段。
Prefix Length Where present, this field can be used to indicate a set of addresses matching a prefix. If the subobject indicates a single address, the prefix length MUST be set to the full length of the address.
前缀长度如果存在，此字段可用于指示与前缀匹配的一组地址。如果子对象指示单个地址，则前缀长度必须设置为地址的全长。
Attribute The Attribute field indicates how the exclusion subobject is to be interpreted.
属性属性字段指示如何解释排除子对象。
0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, and 3.
0接口子对象将被解释为一个接口或一组接口。根据X位的设置，子对象标识的所有接口将从计算路径中排除。此值仅对子对象类型1、2和3有效。
1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, 3, and 4.
1节点子对象将被解释为一个节点或一组节点。根据X位的设置，子对象标识的所有节点将从计算路径中排除。此值仅对子对象类型1、2、3和4有效。
2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects.
2 SRLG子对象明确标识一个SRLG或指示与该子对象标识的一个或多个资源相关联的所有SRLG。根据X位的设置，与已识别资源共享任何SRLG的资源将从计算路径中排除。此值对所有子对象都有效。
Reserved Reserved fields within subobjects MUST be transmitted as zero and SHOULD be ignored on receipt.
子对象中的保留字段必须作为零传输，并且在接收时应忽略。
The subobjects are encoded as follows:
子对象的编码如下所示：
IPv4 prefix Subobject
IPv4前缀子对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 1 | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 1 | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 prefix Subobject
IPv6前缀子对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 2 | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 2 | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unnumbered Interface ID Subobject
未编号的接口ID子对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 3 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 3 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TE Router ID and Interface ID fields are as defined in [RFC3477].
TE路由器ID和接口ID字段如[RFC3477]中所定义。
Autonomous System Number Subobject
自治系统编号子对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 4 | Length | 2-Octet AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 4 | Length | 2-Octet AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that as in other PCEP objects [RFC5440] and RSVP-TE objects [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is provided. It is anticipated that, as 4-octet AS Numbers become more common, both PCEP and RSVP-TE will be updated in a consistent way to add this support.
注意，与其他PCEP对象[RFC5440]和RSVP-TE对象[RFC3209]一样，不支持4-octet自治系统（as）编号。预计随着4-octet数字变得越来越普遍，PCEP和RSVP-TE将以一致的方式进行更新，以增加这种支持。
SRLG Subobject
SRLG子对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 5 | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 5 | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute SHOULD be set to two (2) and SHOULD be ignored on receipt.
该属性应设置为两（2），并在收到时忽略。
A PCC builds an XRO to encode all of the resources that it wishes the PCE to exclude from the path that it is requested to compute. For each exclusion, the PCC clears the X-bit to indicate that the PCE is required to exclude the resources, or sets the X-bit to indicate that the PCC simply desires that the resources are excluded. For each exclusion, the PCC also sets the Attribute field to indicate how the PCE should interpret the contents of the exclusion subobject.
PCC构建一个XRO来编码它希望PCE从其请求计算的路径中排除的所有资源。对于每个排除，PCC清除X位以指示需要PCE排除资源，或者设置X位以指示PCC仅希望排除资源。对于每个排除，PCC还设置属性字段，以指示PCE应如何解释排除子对象的内容。
When a PCE receives a PCReq message it looks for an XRO to see if exclusions are required. If the PCE finds more than one XRO, it MUST use the first one in the message and MUST ignore subsequent instances.
当PCE收到PCReq消息时，它会查找XRO以查看是否需要排除。如果PCE发现多个XRO，则必须使用消息中的第一个XRO，并且必须忽略后续实例。
If the PCE does not recognize the XRO, it MUST return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440].
如果PCE无法识别XRO，则必须返回错误类型为“未知对象”的PCErr消息，如[RFC5440]所述。
If the PCE is unwilling or unable to process the XRO, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440].
如果PCE不愿意或无法处理XRO，则必须返回错误类型为“不支持对象”的PCErr消息，并遵循[RFC5440]中描述的相关过程。
If the PCE processes the XRO and attempts to compute a path, it MUST adhere to the requested exclusions as expressed in the XRO. That is, the returned path MUST NOT include any resources encoded with the X-bit clear, and SHOULD NOT include any with the X-bit set unless alternate paths that match the other constraints expressed in the PCReq are unavailable.
如果PCE处理XRO并尝试计算路径，则必须遵守XRO中表示的请求排除。也就是说，返回的路径不得包含任何使用X位清除编码的资源，也不得包含任何使用X位集编码的资源，除非与PCReq中表示的其他约束匹配的备用路径不可用。
When a PCE returns a path in a PCRep, it MAY also supply an XRO. An XRO in a PCRep message with the NO-PATH object indicates that the set of elements of the original XRO prevented the PCE from finding a path. On the other hand, if an XRO is present in a PCRep message without a NO-PATH object, the PCC SHOULD apply the contents using the same rules as in [RFC4874] and the PCC or a corresponding LSR SHOULD signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs should apply. This may be particularly useful in per-domain path computation scenarios [RFC5152].
当PCE返回PCRep中的路径时，它还可能提供XRO。带有NO-PATH对象的PCRep消息中的XRO表示原始XRO的元素集阻止PCE找到路径。另一方面，如果PCRep消息中存在XRO，且没有NO-PATH对象，则PCC应使用与[RFC4874]中相同的规则应用内容，并且PCC或相应的LSR应向RSVP-TE XRO发送信号，以指示下游LSR应应用的排除。这在每域路径计算场景中可能特别有用[RFC5152]。
Explicit Route Exclusion defines network elements that must not or should not be used on the path between two abstract nodes or resources explicitly indicated in the Include Route Object (IRO) [RFC5440]. This information is encoded by defining a new subobject for the IRO.
显式路由排除定义了不得或不应在包含路由对象（IRO）[RFC5440]中明确指示的两个抽象节点或资源之间的路径上使用的网络元素。该信息通过为IRO定义新的子对象进行编码。
The new IRO subobject, the Explicit Exclusion Route subobject (EXRS), has type 33 (see Section 4). The EXRS contains one or more subobjects in its own right. An EXRS MUST NOT be sent with no subobjects, and if received with no subobjects, MUST be ignored.
新的IRO子对象，即显式排除管线子对象（EXRS），具有类型33（请参见第4节）。EXRS本身包含一个或多个子对象。发送EXRS时不能没有子对象，如果接收时没有子对象，则必须忽略。
The format of the EXRS is as follows:
EXRS的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// One or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// One or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L MUST be set to zero on transmission and MUST be ignored on receipt.
L在传输时必须设置为零，在接收时必须忽略。
Reserved MUST be set to zero on transmission and SHOULD be ignored on receipt.
传输时必须将Reserved设置为零，接收时应忽略Reserved。
The EXRS subobject may carry any of the subobjects defined for inclusion in the XRO by this document or by future documents. The meanings of the fields of the XRO subobjects are unchanged when the subobjects are included in an EXRS, except that scope of the exclusion is limited to the single hop between the previous and subsequent elements in the IRO.
EXRS子对象可能包含本文件或未来文件中定义包含在XRO中的任何子对象。当子对象包含在EXRS中时，XRO子对象字段的含义不变，但排除范围仅限于IRO中先前和后续元素之间的单跳。
A PCC that supplies a partial explicit route to a PCE in an IRO MAY also specify explicit exclusions by including one or more EXRSs in the IRO.
向IRO中的PCE提供部分显式路由的PCC也可以通过在IRO中包含一个或多个EXR来指定显式排除。
If a PCE that does not support the use of EXRS receives an IRO in a PCReq message that contains an EXRS, it will respond according to the rules for a malformed object as described in [RFC5440]. The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized EXRS.
如果不支持使用EXRS的PCE在包含EXRS的PCReq消息中接收到IRO，它将根据[RFC5440]中描述的格式错误对象的规则进行响应。PCE还可以在PCErr中包含IRO，以指示在这种情况下，应在未识别的EXR之后立即终止IRO。
If a PCE that supports the EXRS in an IRO parses an IRO and encounters an EXRS that contains a subobject that it does not support or recognize, it MUST act according to the setting of the X-bit in the subobject. If the X-bit is clear, the PCE MUST respond with a PCErr with Error-Type "Unrecognized EXRS subobject" and set the Error-Value to the EXRS subobject type code (see Section 4). If the X-bit is set, the PCE MAY respond with a PCErr as already stated or MAY ignore the EXRS subobject: this choice is a local policy decision.
如果支持IRO中EXRS的PCE解析IRO并遇到包含其不支持或无法识别的子对象的EXRS，则它必须根据子对象中X位的设置进行操作。如果X位清除，PCE必须使用错误类型为“Unrecognized EXRS subobject”的PCErr响应，并将错误值设置为EXRS subobject类型代码（参见第4节）。如果设置了X位，则PCE可能会如前所述使用PCErr响应，或者可能会忽略EXRS子对象：此选择是本地策略决定。
If a PCE parses an IRO and encounters an EXRS subobject that it recognizes, it MUST act according to the requirements expressed in the subobject. That is, if the X-bit is clear, the PCE MUST NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO. If the X-bit is set, the PCE SHOULD NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO unless it is not possible to construct a path that avoids that resource while still complying with the other constraints expressed in the PCReq message.
如果PCE解析IRO并遇到其识别的EXRS子对象，则必须根据该子对象中表达的要求采取行动。也就是说，如果X位是清除的，则PCE不得在IRO中的上一个抽象节点和IRO中的下一个抽象节点之间的路径中生成包含由EXRS子对象标识的任何资源的路径。如果设置了X位，PCE不应在IRO中的前一个抽象节点和IRO中的下一个抽象节点之间的路径中生成包含EXRS子对象标识的任何资源的路径，除非无法构建一条路径，该路径在避免该资源的同时仍符合PCReq消息中表示的其他约束。
A successful path computation reported in a PCRep message MUST include an ERO to specify the path that has been computed as specified in [RFC5440]. That ERO MAY contain specific route exclusions using the EXRS as specified in [RFC4874].
PCRep消息中报告的成功路径计算必须包括ERO，以指定按照[RFC5440]中的规定计算的路径。ERO可能包含使用[RFC4874]中规定的EXR的特定路线排除。
If the path computation fails and a PCErr is returned with a NO-PATH object, the PCE MAY include an IRO to report the hops that could not be complied with as described in [RFC5440], and that IRO MAY include EXRSs.
如果路径计算失败并且PCErr与无路径对象一起返回，则PCE可以包括一个IRO，以报告[RFC5440]中描述的无法遵守的跳数，并且该IRO可以包括EXRSs。
In PCE-based inter-domain diverse path computation, an XRO may be used to find a backup (secondary) path. A sequential path computation approach may be applied for this purpose, where a working (primary) path route is computed first and a backup path route that must be a node/link/SRLG disjoint route from the working path is then computed [RFC5298]. Backward Recursive Path Computation (BRPC) may be used for inter-domain path computation [RFC5441].
在基于PCE的域间多样化路径计算中，XRO可用于查找备份（辅助）路径。为此，可采用顺序路径计算方法，其中首先计算工作（主）路径路由，然后计算备份路径路由，该备份路径路由必须是与工作路径不相交的节点/链路/SRLG路由[RFC5298]。反向递归路径计算（BRPC）可用于域间路径计算[RFC5441]。
In some cases of inter-domain computation (e.g., where domains are administered by different service providers), confidentiality must be kept. For primary path computation, to preserve confidentiality, instead of explicitly expressing the computed route, Path-Key Subobjects (PKSs) [RFC5520] are carried in the Explicit Route Object (ERO) in the PCRep Message.
在某些域间计算的情况下（例如，域由不同的服务提供商管理），必须保持机密性。对于主路径计算，为了保持机密性，在PCRep消息的显式路由对象（ERO）中携带路径键子对象（PKS）[RFC5520]，而不是显式表示计算的路由。
Therefore, during inter-domain diverse path computation, it may be necessary to request diversity from a path that is not fully known and where a segment of the path is represented by a PKS. This means that a PKS may be present as a subobject of the XRO on a PCReq message.
因此，在域间多样性路径计算期间，可能需要从不完全已知的路径请求多样性，其中路径的一段由PKS表示。这意味着PKS可能作为XRO的子对象出现在PCReq消息中。
The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except for the definition of the L bit. The L bit of the PKS subobject in the XRO MUST be ignored.
当PKS显示为XRO子对象时，其格式和定义如[RFC5520]中所定义，但L位的定义除外。必须忽略XRO中PKS子对象的L位。
Consider that BRPC is applied for both working and backup path computation in a sequential manner. First, PCC requests PCE for the computation of a working path. After BRPC processing has completed, the PCC receives the results of the working-path computation expressed in an ERO in a PCRep message. The ERO may include PKSs if certain segments of the path are to be kept confidential.
考虑BRPC以顺序方式应用于工作和备份路径计算。首先，PCC请求PCE计算工作路径。BRPC处理完成后，PCC接收PCRep消息中ERO中表示的工作路径计算结果。如果路径的某些部分需要保密，ERO可能会包括PKS。
For backup path computation, when the PCC constructs a PCReq Message, it includes the entire working-path in the XRO so that the computed path is node/link disjoint from the working path. The XRO may also include SRLGs to ensure SRLG diversity from the working path. If the working path ERO includes PKS subobjects, these are also included in the XRO to allow the PCE to ensure diversity.
对于备份路径计算，当PCC构造PCReq消息时，它会在XRO中包含整个工作路径，以便计算出的路径与工作路径不相交。XRO还可包括SRLG，以确保SRLG与工作路径的多样性。如果工作路径ERO包括PKS子对象，则这些子对象也包括在XRO中，以允许PCE确保多样性。
A set of PCEs for backup path computation may be the same as ones for working path computation, or they may be different.
用于备份路径计算的一组PCE可能与用于工作路径计算的PCE相同，也可能不同。
- Identical PCEs
- 相同的PCE
In the case where the same PCEs are used for both path computations, the processing is as follows. During the process of BRPC for backup path computation, a PCE may encounter a PKS as it processes the XRO when it creates a virtual path tree (VPT) in its own domain. The PCE retrieves the PCE-ID from the PKS, recognizes itself, and converts the PKS into a set of XRO subobjects that it uses for the local calculation to create the VPT. The XRO subobjects created in this way MUST NOT be shared with other PCEs. Other operations are the same as BRPC.
在两个路径计算使用相同pce的情况下，处理如下。在BRPC进行备份路径计算的过程中，当PCE在其自己的域中创建虚拟路径树（VPT）时，在处理XRO时可能会遇到PKS。PCE从PKS检索PCE-ID，识别自身，并将PKS转换为一组XRO子对象，用于本地计算以创建VPT。以这种方式创建的XRO子对象不得与其他PCE共享。其他操作与BRPC相同。
- Different PCEs
- 不同的PCE
In the case where a set of PCEs for backup path computation is different from the ones used for working path computation, the processing is as follows. If a PCE encounters a PKS in an XRO when it is creating a virtual path tree in its own domain, the PCE retrieves the PCE-ID from the PKS and sends a PCReq message to the identified PCE to expand the PKS. The PCE computing the VPT treats the path segment in the response as a set of XRO subobjects in performing its path computation. The XRO subobjects determined in this way MUST NOT be shared with other PCEs.
在用于备份路径计算的一组pce不同于用于工作路径计算的pce的情况下，处理如下。如果PCE在其自己的域中创建虚拟路径树时在XRO中遇到PKS，则PCE将从PKS检索PCE-ID，并向标识的PCE发送PCReq消息以扩展PKS。计算VPT的PCE在执行其路径计算时，将响应中的路径段视为一组XRO子对象。以这种方式确定的XRO子对象不得与其他PCE共享。
The "PCEP Parameters" registry contains a subregistry "PCEP Objects". IANA has made the following allocations from this registry.
“PCEP参数”注册表包含子目录“PCEP对象”。IANA已从此注册表进行了以下分配。
Object Name Reference Class 17 XRO [RFC5521] Object-Type 1: Route exclusion
对象名称参考类17 XRO[RFC5521]对象类型1：路由排除
This object should be registered as being allowed to carry the following subobjects:
应将此对象注册为允许携带以下子对象：
Subobject Type Reference
1 IPv4 prefix [RFC3209]
2 IPv6 prefix [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
34 SRLG [RFC4874]
64 Path-Key with 32-bit PCE ID [RFC5520]
65 Path-Key with 128-bit PCE ID [RFC5520]
Subobject Type Reference
1 IPv4 prefix [RFC3209]
2 IPv6 prefix [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
34 SRLG [RFC4874]
64 Path-Key with 32-bit PCE ID [RFC5520]
65 Path-Key with 128-bit PCE ID [RFC5520]
The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO).
“PCEP参数”注册表包含一个子区域“PCEP对象”，其中包含包含路由对象（IRO）的条目。
IANA added a further subobject that can be carried in the IRO as follows:
IANA增加了一个子对象，可在IRO中进行，如下所示：
Subobject Type Reference
子对象类型引用
33 Explicit Exclusion Route subobject (EXRS) [RFC4874]
33显式排除路由子对象（EXRS）[RFC4874]
The "PCEP Parameters" registry contains a subregistry "Error Types and Values". IANA made the following allocations from this subregistry.
“PCEP参数”注册表包含一个子目录“错误类型和值”。IANA从该次区域进行了以下分配。
Error Type Meaning Reference
错误类型含义引用
11 Unrecognized EXRS subobject [RFC5521]
11无法识别的EXRS子对象[RFC5521]
IANA created a subregistry of the "PCEP Parameters" for the bits carried in the Flags field of the Exclude Route Object (XRO). The subregistry is called "XRO Flag Field".
IANA为排除路由对象（XRO）的标志字段中携带的位创建了“PCEP参数”子区。该分区称为“XRO标志区”。
New bits may be allocated only by an IETF Consensus action.
新比特只能由IETF一致行动分配。
The field contains 16 bits numbered from bit 0 as the most significant bit.
该字段包含从位0开始编号为最高有效位的16位。
Bit Name Description Reference
位名称描述参考
15 F-bit Fail [RFC5221]
15 F位故障[RFC5221]
A MIB module for management of the PCEP is being specified in a separate document [PCEP-MIB]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors.
在单独的文件[PCEP-MIB]中指定了用于管理PCEP的MIB模块。该MIB模块允许检查单个PCEP消息，特别是请求、响应和错误。
The MIB module MUST be extended to include the ability to view the route exclusion extensions defined in this document.
必须扩展MIB模块，使其能够查看本文档中定义的路由排除扩展。
Several local policy decisions should be made at the PCE. Firstly, the exact behavior with regard to desired exclusions must be available for examination by an operator and may be configurable. Second, the behavior on receipt of an unrecognized XRO or EXRS subobject with the X-bit set should be configurable and must be available for inspection. The inspection and control of these local policy choices may be part of the PCEP MIB module.
PCE应做出几项当地政策决定。首先，关于期望排除的准确行为必须可供操作员检查，并且可以配置。其次，接收到带有X位集的无法识别的XRO或EXRS子对象时的行为应该是可配置的，并且必须可供检查。这些本地策略选择的检查和控制可能是PCEP MIB模块的一部分。
The new exclude route mechanisms defined in this document allow finer and more specific control of the path computed by a PCE. Such control increases the risk if a PCEP message is intercepted, modified, or spoofed because it allows the attacker to exert control over the path that the PCE will compute or to make the path computation impossible. Therefore, the security techniques described in [RFC5440] are considered more important.
本文档中定义的新排除路由机制允许对PCE计算的路径进行更精细和更具体的控制。如果PCEP消息被截获、修改或欺骗，这种控制会增加风险，因为它允许攻击者对PCE将要计算的路径施加控制或使路径计算不可能。因此，[RFC5440]中描述的安全技术被认为更重要。
Note, however, that the route exclusion mechanisms also provide the operator with the ability to route around vulnerable parts of the network and may be used to increase overall network security.
然而，请注意，路由排除机制还为运营商提供了绕网络易受攻击部分路由的能力，并可用于提高整体网络安全性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年4月。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月。
[PCEP-MIB] Koushik, A. S. K., and E. Stephan, "PCE Communication Protocol(PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB]Koushik，A.S.K.和E.Stephan，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2008年11月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.
[RFC5298]Takeda，T.，Ed.，Farrel，A.，Ed.，Ikejiri，Y.，和JP。Vasseur，“域间标签交换路径（LSP）恢复分析”，RFC 5298，2008年8月。
Acknowledgements
致谢
The authors would like to thank Fabien Verhaeghe for valuable comments on subobject formats. Thanks to Magnus Westerlund, Dan Romascanu, Tim Polk, and Dave Ward for comments during IESG review.
作者要感谢Fabien Verhaeghe对子对象格式的宝贵评论。感谢Magnus Westerlund、Dan Romascanu、Tim Polk和Dave Ward在IESG审查期间的评论。
Authors' Addresses
作者地址
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585 JAPAN
伊吉电子通信大学1-5-1 CHOUUGAKA CHOFU，东京182-85 85日本
EMail: oki@ice.uec.ac.jp
EMail: oki@ice.uec.ac.jp
Tomonori Takeda NTT 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan EMail: takeda.tomonori@lab.ntt.co.jp
武田县武藏市武藏町3-9-11 Midori cho，日本东京180-8585，电子邮件：武田。tomonori@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk