Network Working Group JP. Vasseur, Ed.
Request for Comments: 5441 Cisco Systems, Inc
Category: Standards Track R. Zhang
BT Infonet
N. Bitar
Verizon
JL. Le Roux
France Telecom
April 2009
Network Working Group JP. Vasseur, Ed.
Request for Comments: 5441 Cisco Systems, Inc
Category: Standards Track R. Zhang
BT Infonet
N. Bitar
Verizon
JL. Le Roux
France Telecom
April 2009
A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths
一种基于PCE的反向递归计算（BRPC）方法，用于计算最短约束域间流量工程标签交换路径
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 ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers.
在跨多个域的多协议标签交换（MPLS）和广义MPLS（GMPLS）网络中，计算最短约束流量工程标签交换路径（TE LSP）的能力已被确定为一项关键要求。在此上下文中，域是地址管理或路径计算责任的公共范围内的网络元素的集合，例如IGP区域或自治系统。本文件规定了一种程序，该程序依赖于使用多路径计算元素（PCE）来使用反向递归路径计算技术计算跨预定域序列的此类域间最短约束路径。这种技术可以跨域保持机密性，这在由不同的服务提供商管理域时有时是必需的。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 6
4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6
5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8
6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10
8. Usage in Conjunction with Per-Domain Path Computation . . . . 10
9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 10
10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Diverse End-to-End Path Computation . . . . . . . . . . . 11
10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12
11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12
12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12
13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12
14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
14.2. Information and Data Models . . . . . . . . . . . . . . . 13
14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13
14.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 14
14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14
14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15.1. New Flag of the RP Object . . . . . . . . . . . . . . . . 14
15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 6
4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6
5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8
6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10
8. Usage in Conjunction with Per-Domain Path Computation . . . . 10
9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 10
10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Diverse End-to-End Path Computation . . . . . . . . . . . 11
10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12
11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12
12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12
13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12
14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
14.2. Information and Data Models . . . . . . . . . . . . . . . 13
14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13
14.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 14
14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14
14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15.1. New Flag of the RP Object . . . . . . . . . . . . . . . . 14
15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14
15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
16. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . . 16
15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
16. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . . 16
The requirements for inter-area and inter-AS MPLS Traffic Engineering (TE) have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively.
区域间和AS间MPLS流量工程（TE）的要求已由流量工程工作组（TE WG）制定，并分别在[RFC4105]和[RFC4216]中说明。
The framework for inter-domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) has been provided in [RFC4726].
[RFC4726]中提供了域间多协议标签交换（MPLS）流量工程（TE）的框架。
[RFC5152] defines a technique for establishing an inter-domain Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the path is computed during the signaling process on a per-domain basis by the entry boundary node of each domain (each node responsible for triggering the computation of a section of an inter-domain TE LSP path is always along the path of such TE LSP). This path computation technique fulfills some of the requirements stated in [RFC4105] and [RFC4216] but not all of them. In particular, it cannot guarantee to find an optimal (shortest) inter-domain constrained path. Furthermore, it cannot be efficiently used to compute a set of inter-domain diversely routed TE LSPs.
[RFC5152]定义了一种用于建立域间通用MPLS（GMPLS）TE标签交换路径（LSP）的技术，其中，在信令过程中，每个域的入口边界节点根据每个域计算路径（负责触发域间TE LSP路径一部分计算的每个节点始终沿着此类TE LSP的路径）。此路径计算技术满足[RFC4105]和[RFC4216]中所述的一些要求，但并非所有要求。特别是，它不能保证找到最佳（最短）路径域间约束路径。此外，它不能有效地用于计算一组域间不同路由的TE LSP。
The Path Computation Element (PCE) architecture is defined in [RFC4655]. The aim of this document is to describe a PCE-based path computation procedure to compute optimal inter-domain constrained (G)MPLS TE LSPs.
路径计算元素（PCE）体系结构在[RFC4655]中定义。本文档的目的是描述基于PCE的路径计算过程，以计算最优域间约束（G）MPLS TE LSP。
Qualifying a path as optimal requires some clarification. Indeed, a globally optimal TE LSP placement usually refers to a set of TE LSPs whose placements optimize the network resources with regards to a specified objective function (e.g., a placement that reduces the maximum or average network load while satisfying the TE LSP constraints). In this document, an optimal inter-domain constrained TE LSP is defined as the shortest path satisfying the set of required constraints that would be obtained in the absence of multiple domains (in other words, in a totally flat IGP network between the source and destination of the TE LSP). Note that this requires the use of consistent metric schemes in each domain (see Section 13).
将路径限定为最佳路径需要一些澄清。实际上，全局最优TE-LSP布局通常指一组TE-LSP，其布局相对于指定的目标函数优化网络资源（例如，在满足TE-LSP约束的同时降低最大或平均网络负载的布局）。在本文件中，最优域间约束TE LSP被定义为在没有多个域的情况下（换句话说，在TE LSP的源和目标之间的完全平坦的IGP网络中）满足所需约束集的最短路径。注意，这需要在每个域中使用一致的度量方案（参见第13节）。
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]中所述进行解释。
ABR: Area Border Routers. Routers used to connect two IGP areas (areas in OSPF or levels in IS-IS).
区域边界路由器。用于连接两个IGP区域（OSPF中的区域或IS-IS中的级别）的路由器。
ASBR: Autonomous System Border Router. Router used to connect together ASes of the same or different service providers via one or more inter-AS links.
ASBR：自治系统边界路由器。用于通过一个或多个AS间链路将相同或不同服务提供商的AS连接在一起的路由器。
Boundary Node (BN): a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter-AS Traffic Engineering.
边界节点（BN）：边界节点是区域间流量工程上下文中的ABR或区域间流量工程上下文中的ASBR。
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along a determined sequence of domains.
域（n）的条目BN：沿着确定的域序列将域（n-1）连接到域（n）的BN。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains.
域（n）的出口BN：沿着确定的域序列将域（n）连接到域（n+1）的BN。
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
区域间TE LSP：穿过IGP区域边界的TE LSP。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
内部AS TE LSP：跨越AS边界的TE LSP。
LSP: Label Switched Path.
标签交换路径。
LSR: Label Switching Router.
标签交换路由器。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
路径计算客户端。任何请求由路径计算元素执行的路径计算的客户端应用程序。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCE(i) is a PCE with the scope of domain(i).
PCE（i）是具有域（i）范围的PCE。
TED: Traffic Engineering Database.
交通工程数据库。
VSPT: Virtual Shortest Path Tree.
虚拟最短路径树。
The notion of contiguous, stitched, and nested TE LSPs is defined in [RFC4726] and will not be repeated here.
[RFC4726]中定义了连续、缝合和嵌套TE LSP的概念，此处不再重复。
In the rest of this document, we make the following set of assumptions common to inter-area and inter-AS MPLS TE:
在本文档的其余部分中，我们对inter area和inter AS MPLS TE进行了以下一组常见的假设：
o Each IGP area or Autonomous System (AS) is assumed to be Traffic Engineering enabled.
o 假设每个IGP区域或自治系统（AS）启用了交通工程。
o No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality.
o 域之间不分布拓扑或资源信息（按照[RFC4105]和[RFC4216]的规定），这对于保持IGP/BGP的可扩展性和机密性至关重要。
o While certain constraints like bandwidth can be used across different domains, other TE constraints (such as resource affinity, color, metric, etc. [RFC2702]) could be translated at domain boundaries. If required, it is assumed that, at the domain boundary nodes, there will exist some sort of local mapping based on policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process.
o 虽然某些约束（如带宽）可以跨不同的域使用，但其他TE约束（如资源亲和力、颜色、度量等[RFC2702]）可以在域边界处转换。如果需要，假设在域边界节点处，将存在基于策略协议的某种局部映射，以便在PCE间通信过程中跨域边界转换此类约束。
o Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASes made of a single IGP area, or any combination of the above. For the sake of simplicity, each AS will be considered to be made of a single area in this document. The case of an inter-AS TE LSP spanning multiple ASes, where some of those ASes are themselves made of multiple IGP areas, can be easily derived from this case by applying the BRPC procedure described in this document, recursively.
o 每个AS可以由几个IGP区域组成。本文件中描述的路径计算程序适用于由多个IGP区域构成的单个AS、由单个IGP区域构成的多个ASE或上述任意组合的情况。为了简单起见，在本文件中，每个AS将被视为由单个区域组成。跨多个ASE的AS-TE LSP的情况，其中一些ASE本身由多个IGP区域组成，可以通过递归地应用本文档中描述的BRPC程序从该情况中容易地导出。
o The domain path (the set of domains traversed to reach the destination domain) is either administratively predetermined or discovered by some means that is outside of the scope of this document.
o 域路径（为到达目标域而经过的一组域）在管理上是预先确定的，或者是通过某种方式发现的，这超出了本文档的范围。
The BRPC procedure is a multiple-PCE path computation technique as described in [RFC4655]. A possible model consists of hosting the PCE function on boundary nodes (e.g., ABR or ASBR), but this is not mandated by the BRPC procedure.
BRPC程序是一种多PCE路径计算技术，如[RFC4655]所述。一种可能的模型包括在边界节点（如ABR或ASBR）上承载PCE功能，但BRPC程序并不强制要求这样做。
The BRPC procedure relies on communication between cooperating PCEs. In particular, the PCC sends a PCReq to a PCE in its domain. The request is forwarded between PCEs, domain-by-domain, until the PCE responsible for the domain containing the LSP destination is reached. The PCE in the destination domain creates a tree of potential paths
BRPC程序依赖于合作PCE之间的通信。具体而言，PCC向其域中的PCE发送PCReq。请求在PCE之间逐域转发，直到到达负责包含LSP目的地的域的PCE为止。目标域中的PCE创建一个潜在路径树
to the destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path that the PCE sends to the PCC.
到目的地（虚拟最短路径树-VSPT），并将其传递回PCRep中的前一个PCE。每个PCE依次添加到VSPT并将其传回，直到源域中的PCE使用VSPT选择PCE发送到PCC的端到端路径。
The BRPC procedure does not make any assumption with regards to the nature of the inter-domain TE LSP that could be contiguous, nested, or stitched.
BRPC程序未对域间TE LSP的性质做出任何假设，该LSP可以是连续的、嵌套的或缝合的。
Furthermore, no assumption is made on the actual path computation algorithm in use by a PCE (e.g., it can be any variant of Constrained Shortest Path First (CSPF) or an algorithm based on linear programming to solve multi-constraint optimization problems).
此外，没有对PCE使用的实际路径计算算法做出任何假设（例如，它可以是约束最短路径优先（CSPF）的任何变体或基于线性规划的用于解决多约束优化问题的算法）。
The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed is either administratively predetermined or discovered by some means that is outside of the scope of this document. The PCC MAY indicate the sequence of domains to be traversed using the Include Route Object (IRO) defined in [RFC5440] so that it is available to all PCEs. Note also that a sequence of PCEs MAY be enforced by policy on the PCC, and this constraint can be carried in the PCEP path computation request (as defined in [PCE-MONITOR]).
基于PCE的BRPC程序适用于计算最优约束域间TE LSP。要遍历的域序列是管理上预先确定的，或者是通过一些超出本文档范围的方法发现的。PCC可以使用[RFC5440]中定义的包含路由对象（IRO）指示要遍历的域序列，以便所有PCE都可以使用它。还要注意，PCC上的策略可以强制PCE序列，并且该约束可以在PCEP路径计算请求中进行（如[PCE-MONITOR]中所定义）。
The BRPC procedure guarantees to compute the optimal path across a specific sequence of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get the optimal constrained path between the source and the destination of the TE LSP. The BRPC procedure can also be used across a subset of all domain sequences, and the best path among these sequences can then be selected.
BRPC过程保证计算穿越特定域序列（构成附加约束）的最佳路径。对于任意一组网格域，BRPC程序可用于计算每个域集的最佳路径，以获得TE LSP源和目标之间的最佳约束路径。BRPC过程也可以用于所有域序列的子集，然后可以选择这些序列中的最佳路径。
Definition of VSPT(i)
VSPT的定义（一）
In each domain i:
在每个域中，我：
o There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN-en(k,i) is the kth entry BN of domain(i).
o 有一组X-en（i）条目BN，注明BN-en（k，i），其中BN-en（k，i）是域（i）的第k个条目BN。
o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN-ex(k,i) is the kth exit BN of domain(i).
o 存在一组X-ex（i）出口BN，其中BN ex（k，i）是域（i）的第k个出口BN。
VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to PCE(i-1):
VSPT（i）：由PCE（i）返回给PCE（i-1）的MP2P（多点对点）树：
Root (TE LSP destination)
/ | \
BN-en(1,i) BN-en(2,i) ... BN-en(j,i).
Root (TE LSP destination)
/ | \
BN-en(1,i) BN-en(2,i) ... BN-en(j,i).
where [X-en(i)] is the number of
entry BNs in domain i and j<= [X-en(i)]
where [X-en(i)] is the number of
entry BNs in domain i and j<= [X-en(i)]
Figure 1: MP2P Tree
图1:MP2P树
Each link of tree VSPT(i) represents the shortest constrained path between BN-en(j,i) and the TE LSP destination that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.). These are path segments to reach the TE LSP destination from BN-en(j,i).
树VSPT（i）的每个链路表示BN-en（j，i）和TE-LSP目的地之间满足TE-LSP所需约束集（带宽、亲和力等）的最短约束路径。这些是从BN en（j，i）到达TE LSP目的地的路径段。
Note that PCE(i) only considers the entry BNs of domain(i), i.e., only the BNs that provide connectivity from domain(i-1). In other words, the set BN-en(k,i) is only made of those BNs that provide connectivity from domain (i-1) to domain(i). Furthermore, some BNs may be excluded according to policy constraints (either due to local policy or policies signaled in the path computation request).
请注意，PCE（i）仅考虑域（i）的条目BN，即仅考虑从域（i-1）提供连接的BN。换句话说，集合BN en（k，i）仅由那些提供从域（i-1）到域（i）的连接的BN组成。此外，根据策略约束（由于本地策略或路径计算请求中发出信号的策略），可以排除一些BN。
Step 1: First, the PCC needs to determine the PCE capable of serving its path computation request (this can be done with local configuration or via IGP discovery (see [RFC5088] and [RFC5089])). The path computation request is then relayed until reaching a PCE(n) such that the TE LSP destination resides in the domain(n). At each step of the process, the next PCE can either be statically configured or dynamically discovered via IGP/BGP extensions. If no next PCE can be found or the next-hop PCE of choice is unavailable, the procedure stops and a path computation error is returned (see Section 9). If PCE(i-1) discovers multiple PCEs for the adjacent domain(i), PCE(i) may select a subset of these PCEs based on some local policies or heuristics. The PCE selection process is outside of the scope of this document.
步骤1：首先，PCC需要确定能够为其路径计算请求提供服务的PCE（这可以通过本地配置或IGP发现完成（请参见[RFC5088]和[RFC5089]）。然后中继路径计算请求，直到到达PCE（n），使得TE LSP目的地驻留在域（n）中。在流程的每个步骤中，可以静态配置下一个PCE，也可以通过IGP/BGP扩展动态发现下一个PCE。如果找不到下一个PCE或选择的下一个跃点PCE不可用，则过程停止并返回路径计算错误（参见第9节）。如果PCE（i-1）发现相邻域（i）的多个PCE，则PCE（i）可以基于一些本地策略或启发式选择这些PCE的子集。PCE选择过程不在本文件范围内。
Step 2: PCE(n) computes VSPT(n), the tree made of the list of shortest constrained paths between every BN-en(j,n) and the TE LSP destination using a suitable path computation algorithm (e.g., CSPF) and returns the computed VSPT(n) to PCE(n-1).
步骤2：PCE（n）使用合适的路径计算算法（例如，CSPF）计算VSPT（n），该树由每个BN en（j，n）和TE LSP目的地之间的最短约束路径列表组成，并将计算出的VSPT（n）返回给PCE（n-1）。
Step i: For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination. It does this by considering its own TED and the information in VSPT(i+1).
步骤i：对于i=n-1到2:PCE（i）计算VSPT（i），该树由每个BN-en（j，i）和TE-LSP目的地之间的最短约束路径组成。它通过考虑自己的TED和VSPT（i+1）中的信息来实现这一点。
In the case of inter-AS TE LSP computation, this also requires adding the inter-AS TE links that connect the domain(i) to the domain(i+1).
在作为TE间LSP计算的情况下，这还需要添加将域（i）连接到域（i+1）的作为TE间链路。
Step n: Finally, PCE(1) computes the end-to-end shortest constrained path from the source to the destination and returns the corresponding path to the requesting PCC in the form of a PCRep message as defined in [RFC5440].
步骤n：最后，PCE（1）计算从源到目的地的端到端最短约束路径，并以[RFC5440]中定义的PCRep消息的形式将相应路径返回到请求PCC。
Each branch of the VSPT tree (path) may be returned in the form of an explicit path (in which case, all the hops along the path segment are listed) or a loose path (in which case, only the BN is specified) so as to preserve confidentiality along with the respective cost. In the latter case, various techniques can be used in order to retrieve the computed explicit paths on a per-domain basis during the signaling process, thanks to the use of path keys as described in [PATH-KEY].
VSPT树（path）的每个分支可以以显式路径（在这种情况下，沿着路径段的所有跳被列出）或松散路径（在这种情况下，仅指定BN）的形式返回，以便与各自的成本一起保持机密性。在后一种情况下，由于使用了[path-KEY]中所述的路径密钥，可以使用各种技术在信令过程中基于每个域检索计算出的显式路径。
A PCE that can compute the requested path for more than one consecutive domain on the path SHOULD perform this computation for all such domains before passing the PCRep to the previous PCE in the sequence.
能够计算路径上多个连续域的请求路径的PCE应在将PCRep传递给序列中的前一个PCE之前，对所有此类域执行此计算。
BRPC guarantees to find the optimal (shortest) constrained inter-domain TE LSP according to a set of defined domains to be traversed. Note that other variants of the BRPC procedure relying on the same principles are also possible.
BRPC保证根据一组定义的要遍历的域找到最优（最短）约束域间TE LSP。请注意，基于相同原理的BRPC程序的其他变体也是可能的。
Note also that in case of Equal Cost Multi-Path (ECMP) paths, more than one path could be returned to the requesting PCC.
还要注意，在等成本多路径（ECMP）路径的情况下，可以向请求PCC返回多条路径。
The BRPC procedure requires the specification of a new flag of the RP object carried within the PCReq message (defined in [RFC5440]) to specify that the shortest paths satisfying the constraints from the destination to the set of entry boundary nodes are requested (such a set of paths forms the downstream VSPT as specified in Section 4.2).
BRPC程序要求指定PCReq消息（在[RFC5440]中定义）中携带的RP对象的新标志，以指定请求满足从目的地到入口边界节点集的约束的最短路径（如第4.2节所述，该路径集形成下游VSPT）。
The following new flag of the RP object is defined:
定义了RP对象的以下新标志：
VSPT Flag
VSPT标志
Bit Number Name Flag 25 VSPT
位号名称标志25 VSPT
When set, the VSPT Flag indicates that the PCC requests the computation of an inter-domain TE LSP using the BRPC procedure defined in this document.
设置时，VSPT标志表示PCC使用本文档中定义的BRPC过程请求计算域间TE LSP。
Because path segments computed by a downstream PCE in the context of the BRPC procedure MUST be provided along with their respective path costs, the C flag of the METRIC object carried within the PCReq message MUST be set. It is the choice of the requester to appropriately set the O bit of the RP object.
由于下游PCE在BRPC过程的上下文中计算的路径段必须与其各自的路径成本一起提供，因此必须设置PCReq消息中携带的度量对象的C标志。请求者可以选择适当地设置RP对象的O位。
The VSPT is returned within a PCRep message. The encoding consists of a non-ordered list of Explicit Route Objects (EROs) where each ERO represents a path segment from a BN to the destination specified in the END-POINT object of the corresponding PCReq message.
VSPT在PCRep消息中返回。编码由显式路由对象（ERO）的非有序列表组成，其中每个ERO表示从BN到相应PCReq消息的端点对象中指定的目的地的路径段。
Example:
<---- area 1 ----><---- area 0 -----><------ area 2 ------>
ABR1-A-B-+
| |
ABR2-----D
| |
ABR3--C--+
Example:
<---- area 1 ----><---- area 0 -----><------ area 2 ------>
ABR1-A-B-+
| |
ABR2-----D
| |
ABR3--C--+
Figure 2: An Example of VSPT Encoding Using a Set of EROs
图2：使用一组ERO的VSPT编码示例
In the simple example shown in Figure 2, if we make the assumption that a constrained path exists between each ABR and the destination D, the VSPT computed by a PCE serving area 2 consists of the following non-ordered set of EROs:
在图2所示的简单示例中，如果我们假设每个ABR和目的地D之间存在约束路径，则由PCE服务区域2计算的VSPT由以下非有序ERO集组成：
o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP address)-D(TE Router ID)
o ERO1:ABR1（TE路由器ID）-A（接口IP地址）-B（接口IP地址）-D（TE路由器ID）
o ERO2: ABR2(TE Router ID)-D(TE Router ID)
o ERO2:ABR2（TE路由器ID）-D（TE路由器ID）
o ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID)
o ERO3:ABR3（TE路由器ID）-C（接口IP地址）-D（TE路由器ID）
The PCReq message, PCRep message, PCEP END-POINT object, and ERO object are defined in [RFC5440].
PCReq消息、PCRep消息、PCEP端点对象和ERO对象在[RFC5440]中定义。
In the case of inter-AS TE LSP path computation, the BRPC procedure requires the knowledge of the traffic engineering attributes of the inter-AS TE links. The process by which the PCE acquires this information is out of the scope of the BRPC procedure, which is compliant with the PCE architecture defined in [RFC4655].
在AS-TE间LSP路径计算的情况下，BRPC程序需要了解AS-TE间链路的流量工程属性。PCE获取该信息的过程超出BRPC程序的范围，该程序符合[RFC4655]中定义的PCE架构。
That said, a straightforward solution consists of allowing the ASBRs to flood the TE information related to the inter-ASBR links although no IGP TE is enabled over those links (there is no IGP adjacency over the inter-ASBR links). This allows the PCE of a domain to get entire TE visibility up to the set of entry ASBRs in the downstream domain (see the IGP extensions defined in [RFC5316] and [RFC5392]).
这就是说，一个简单的解决方案包括允许ASBR泛滥与ASBR间链路相关的TE信息，尽管这些链路上没有启用IGP TE（ASBR间链路上没有IGP邻接）。这允许域的PCE获得整个TE可见性，直至下游域中的一组条目ASBR（参见[RFC5316]和[RFC5392]中定义的IGP扩展）。
The BRPC procedure may be used to compute path segments in conjunction with other path computation techniques (such as the per-domain path computation technique defined in [RFC5152]) to compute the end-to-end path. In this case, end-to-end path optimality can no longer be guaranteed.
BRPC过程可用于结合其他路径计算技术（例如[RFC5152]中定义的每域路径计算技术）来计算路径段，以计算端到端路径。在这种情况下，无法再保证端到端路径最优。
If the BRPC procedure cannot be completed because a PCE along the domain does not recognize the procedure (VSPT flag of the RP object), as stated in [RFC5440], the PCE sends a PCErr message to the upstream PCE with an Error-Type=4 (Not supported object), Error-value=4 (Unsupported parameter). The PCE may include the parent object (RP object) up to and including (but no further than) the unknown or unsupported parameter. In this case where the unknown or unsupported parameter is a bit flag (VSPT flag), the included RP object should contain the whole bit flag field with all bits after the parameter at issue set to zero. The corresponding path computation request is then cancelled by the PCE without further notification.
如[RFC5440]中所述，如果由于域中的PCE无法识别BRPC过程（RP对象的VSPT标志），因此无法完成BRPC过程，则PCE会向上游PCE发送一条PCErr消息，错误类型为4（不支持的对象），错误值为4（不支持的参数）。PCE可以包括父对象（RP对象），包括（但不超过）未知或不受支持的参数。在这种情况下，如果未知或不支持的参数是位标志（VSPT标志），则包含的RP对象应包含整个位标志字段，且问题参数后的所有位均应设置为零。然后，PCE取消相应的路径计算请求，而无需进一步通知。
If the BRPC procedure cannot be completed because a PCE along the domain path recognizes but does not support the procedure, it MUST return a PCErr message to the upstream PCE with an Error-Type "BRPC procedure completion failure".
如果由于域路径上的PCE识别但不支持BRPC过程而无法完成BRPC过程，则必须向上游PCE返回PCErr消息，错误类型为“BRPC过程完成失败”。
The PCErr message MUST be relayed to the requesting PCC.
PCErr消息必须中继到请求PCC。
PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-value are managed by IANA.
PCEP-ERROR对象用于报告PCEP协议错误，其特征是指定错误类型的错误类型和提供有关错误类型的附加信息的错误值。错误类型和错误值都由IANA管理。
A new Error-Type is defined that relates to the BRPC procedure.
定义了与BRPC过程相关的新错误类型。
Error-Type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or more PCEs along the domain path
错误类型表示13 BRPC过程完成失败错误值1：一个或多个PCE沿域路径不支持BRPC过程
As discussed in Section 3, the requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively. Among the set of requirements, both documents indicate the need for some solution that provides the ability to compute an optimal (shortest) constrained inter-domain TE LSP and to compute a set of diverse inter-domain TE LSPs.
如第3节所述，区域间和As间MPLS流量工程的要求已由流量工程工作组（TE WG）制定，并分别在[RFC4105]和[RFC4216]中说明。在一组需求中，两个文档都指出需要某种解决方案，该解决方案提供计算最优（最短）约束域间TE-LSP和计算一组不同域间TE-LSP的能力。
PCEP (see [RFC5440]) allows a PCC to request the computation of a set of diverse TE LSPs by setting the SVEC object's flags L, N, or S to request link, node, or SRLG (Shared Risk Link Group) diversity, respectively. Such requests MUST be taken into account by each PCE along the path computation chain during the VSPT computation. In the context of the BRPC procedure, a set of diversely routed TE LSPs between two LSRs can be computed since the path segments of the VSPT are simultaneously computed by a given PCE. The BRPC procedure allows for the computation of diverse paths under various objective functions (such as minimizing the sum of the costs of the N diverse paths, etc.).
PCEP（参见[RFC5440]）允许PCC通过将SVEC对象的标志L、N或s分别设置为请求链路、节点或SRLG（共享风险链路组）分集来请求计算一组不同的TE LSP。在VSPT计算期间，沿路径计算链的每个PCE必须考虑此类请求。在BRPC程序的上下文中，可以计算两个LSR之间的一组不同路由的TE LSP，因为VSPT的路径段由给定的PCE同时计算。BRPC程序允许在各种目标函数下计算不同路径（如最小化N条不同路径的成本之和等）。
By contrast, with a 2-step approach consisting of computing the first path followed by computing the second path after having removed the set of network elements traversed by the first path (if that does not violate confidentiality preservation), one cannot guarantee that a solution will be found even if such solution exists. Furthermore, even if a solution is found, it may not be the most optimal one with respect to an objective function such as minimizing the sum of the paths' costs, bounding the path delays of both paths, and so on. Finally, it must be noted that such a 2-step path computation approach is usually less efficient in terms of signaling delays since it requires that two serialized TE LSPs be set up.
相比之下，采用两步方法，即先计算第一条路径，然后在移除第一条路径所穿过的一组网络元素后再计算第二条路径（如果这不违反保密性保护），无法保证即使存在这样的解决方案，也能找到解决方案。此外，即使找到了一个解，它也可能不是关于目标函数的最优解，例如最小化路径成本之和，限制两条路径的路径延迟，等等。最后，必须注意，这种两步路径计算方法通常在信令延迟方面效率较低，因为它需要设置两个序列化的TE lsp。
BRPC guarantees that the optimal (shortest) constrained inter-domain path will always be found, subject to policy constraints. Both in the case where local path computation techniques are used (such as to build stitched or nested TE LSPs), and in the case where a domain has more than one BN-en or more than one BN-ex, it is only possible to guarantee optimality after some network change within the domain by completely re-executing the BRPC procedure.
BRPC保证在受到策略约束的情况下，始终能够找到最优（最短）受约束的域间路径。无论是在使用本地路径计算技术的情况下（例如构建缝合或嵌套的TE LSP），还是在域具有多个BN en或多个BN ex的情况下，只有在域内发生某些网络更改后，通过完全重新执行BRPC过程，才可能保证最优性。
The ability to reoptimize an existing inter-domain TE LSP path has been explicitly listed as a requirement in [RFC4105] and [RFC4216]. In the case of a TE LSP reoptimization request, the reoptimization procedure defined in [RFC5440] applies when the path in use (if available on the head-end) is provided as part of the path computation request so that the PCEs involved in the reoptimization request can avoid double bandwidth accounting.
[RFC4105]和[RFC4216]中明确列出了重新优化现有域间TE LSP路径的能力。在TE LSP重新优化请求的情况下，[RFC5440]中定义的重新优化程序适用于正在使用的路径（如果在前端可用）作为路径计算请求的一部分提供的情况，以便重新优化请求中涉及的PCE可以避免双带宽计费。
If a PCE requires to relay a path computation request according to the BRPC procedure defined in this document to a downstream PCE and no such PCE is available, the PCE MUST send a negative path computation reply to the requester using a PCReq message as specified in [RFC5440] that contains a NO-PATH object. In such case, the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440]) with the newly defined bit named "BRPC path computation chain unavailable" set.
如果PCE需要根据本文件中定义的BRPC程序将路径计算请求中继到下游PCE，并且没有此类PCE可用，则PCE必须使用[RFC5440]中指定的包含无路径对象的PCReq消息向请求者发送否定路径计算回复。在这种情况下，无路径对象必须携带无路径向量TLV（在[RFC5440]中定义），并设置新定义的名为“BRPC路径计算链不可用”的位。
Bit number Name Flag 28 BRPC path computation chain unavailable
位号名称标志28 BRPC路径计算链不可用
In the case of inter-area TE, the same IGP/TE metric scheme is usually adopted for all the IGP areas (e.g., based on the link-speed, propagation delay, or some other combination of link attributes). Hence, the proposed set of mechanisms always computes the shortest path across multiple areas that obey the required set of constraints with respect to a specified objective function. Conversely, in the case of inter-AS TE, in order for this path computation to be meaningful, metric normalization between ASes may be required. One solution to avoid IGP metric modification would be for the service providers to agree on a TE metric normalization scheme and use the TE
在区域间TE的情况下，通常对所有IGP区域采用相同的IGP/TE度量方案（例如，基于链路速度、传播延迟或链路属性的一些其他组合）。因此，所提出的一组机制总是计算跨多个区域的最短路径，这些区域遵守关于指定目标函数的所需约束集。相反，在AS-TE之间的情况下，为了使该路径计算有意义，可能需要AS之间的度量标准化。避免IGP度量修改的一个解决方案是服务提供商就TE度量规范化方案达成一致，并使用TE
metric for TE LSP path computation (in that case, the use of the TE metric must be requested in the PCEP path computation request) using the METRIC object (defined in [RFC5440]).
使用度量对象（在[RFC5440]中定义）计算TE LSP路径的度量（在这种情况下，必须在PCEP路径计算请求中请求使用TE度量）。
This section follows the guidance of [PCE-MANAGE].
本节遵循[PCE-MANAGE]的指导。
The only configurable item is the support of the BRPC procedure on a PCE. The support of the BRPC procedure by the PCE MAY be controlled by a policy module governing the conditions under which a PCE should participate in the BRPC procedure (origin of the requests, number of requests per second, etc.). If the BRPC is not supported/allowed on a PCE, it MUST send a PCErr message as specified in Section 9.
唯一可配置的项目是在PCE上支持BRPC程序。PCE对BRPC程序的支持可由一个策略模块控制，该策略模块控制PCE应在何种条件下参与BRPC程序（请求的来源、每秒请求的数量等）。如果PCE不支持/不允许BRPC，则必须按照第9节的规定发送PCErr消息。
A BRPC MIB module will be specified in a separate document.
BRPC MIB模块将在单独的文件中指定。
The BRPC procedure is a multiple-PCE path computation technique and, as such, a set of PCEs are involved in the path computation chain. If the path computation chain is not operational either because at least one PCE does not support the BRPC procedure or because one of the PCEs that must be involved in the path computation chain is not available, procedures are defined to report such failures in Sections 9 and 12, respectively. Furthermore, a built-in diagnostic tool to check the availability and performances of a PCE chain is defined in [PCE-MONITOR].
BRPC程序是一种多PCE路径计算技术，因此，路径计算链中涉及一组PCE。如果由于至少一个PCE不支持BRPC程序或由于路径计算链中必须涉及的一个PCE不可用而导致路径计算链无法运行，则在第9节和第12节中分别定义了报告此类故障的程序。此外，在[PCE-MONITOR]中定义了一种用于检查PCE链可用性和性能的内置诊断工具。
Verifying the correct operation of BRPC can be performed by monitoring a set of parameters. A BRPC implementation SHOULD provide the following parameters:
可通过监测一组参数来验证BRPC的正确运行。BRPC实施应提供以下参数：
o Number of successful BRPC procedure completions on a per-PCE-peer basis
o 每个PCE同行成功完成BRPC程序的次数
o Number of BRPC procedure completion failures because the VSPT flag was not recognized (on a per-PCE-peer basis)
o 由于未识别VSPT标志而导致BRPC过程完成失败的次数（基于每个PCE对等）
o Number of BRPC procedure completion failures because the BRPC procedure was not supported (on a per-PCE-peer basis)
o 由于BRPC过程不受支持而导致BRPC过程完成失败的次数（基于每个PCE对等）
The BRPC procedure does not put any new requirements on other protocols. That said, since the BRPC procedure relies on the PCEP protocol, there is a dependency between BRPC and PCEP; consequently, the BRPC procedure inherently makes use of the management functions developed for PCEP.
BRPC程序没有对其他协议提出任何新要求。也就是说，由于BRPC程序依赖于PCEP协议，因此BRPC和PCEP之间存在依赖关系；因此，BRPC程序固有地利用了为PCEP开发的管理功能。
The BRPC procedure does not have any significant impact on network operation: indeed, BRPC is a multiple-PCE path computation scheme as defined in [RFC4655] and does not differ from any other path computation request.
BRPC程序对网络运行没有任何重大影响：事实上，BRPC是[RFC4655]中定义的多PCE路径计算方案，与任何其他路径计算请求没有区别。
[PCE-MONITOR] specifies a set of mechanisms that can be used to gather PCE state metrics. Because BRPC is a multiple-PCE path computation technique, such mechanisms could be advantageously used in the context of the BRPC procedure to check the liveness of the path computation chain, locate a faulty component, monitor the overall performance, and so on.
[PCE-MONITOR]指定一组可用于收集PCE状态指标的机制。由于BRPC是一种多PCE路径计算技术，因此此类机制可在BRPC过程的上下文中有利地用于检查路径计算链的活跃度、定位故障组件、监控整体性能等。
A new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
本文件中定义了RP对象的新标志（在[RFC5440]中指定）。IANA在“路径计算元素协议（PCEP）编号”注册表的“RP对象标志字段”子注册表中维护RP对象标志的注册表。
IANA has allocated the following value:
IANA已分配以下值：
Bit Description Reference 25 VSPT This document
位描述参考25 VSPT本文件
IANA maintains a registry of Error-Types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANA维护用于PCEP消息的错误类型和错误值的注册表。它作为“路径计算元素协议（PCEP）编号”注册表的“PCEP-ERROR对象错误类型和值”子注册表进行维护。
A new Error-value is defined for the Error-Type "Not supported object" (type 4).
为错误类型“不支持的对象”（类型4）定义了新的错误值。
Error-Type Meaning and error values Reference 4 Not supported object
错误类型含义和错误值参考4不支持对象
Error-value=4: Unsupported parameter This document
错误值=4:此文档不支持的参数
A new Error-Type is defined in this document as follows:
本文件中定义了一种新的错误类型，如下所示：
Error-Type Meaning Reference 13 BRPC procedure completion failure This document
错误类型意味着参考13 BRPC程序完成失败本文件
Error-value=1: BRPC procedure not This document supported by one or more PCEs along the domain path
错误值=1:BRPC过程域路径上的一个或多个PCE不支持此文档
A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is specified in this document.
本文件规定了[RFC5440]中定义的无路径向量TLV的新标志。
IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANA在“路径计算元素协议（PCEP）编号”注册表的“无路径向量TLV标志字段”子注册表中维护无路径向量TLV的标志注册表。
IANA has allocated the following allocation value:
IANA已分配以下分配值：
Bit number Meaning Reference 4 BRPC path computation This document chain unavailable
位号表示参考4 BRPC路径计算此文档链不可用
The BRPC procedure relies on the use of the PCEP protocol and as such is subjected to the potential attacks listed in Section 10 of [RFC5440]. In addition to the security mechanisms described in [RFC5440] with regards to spoofing, snooping, falsification, and denial of service, an implementation MAY support a policy module governing the conditions under which a PCE should participate in the BRPC procedure.
BRPC程序依赖于PCEP协议的使用，因此受到[RFC5440]第10节中列出的潜在攻击。除了[RFC5440]中描述的关于欺骗、窥探、伪造和拒绝服务的安全机制外，实现还可以支持控制PCE应参与BRPC过程的条件的策略模块。
The BRPC procedure does not increase the information exchanged between ASes and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216].
根据[RFC4105]和[RFC4216]，BRPC程序不会增加ASE之间交换的信息，并保留拓扑机密性。
The authors would like to thank Arthi Ayyangar, Dimitri Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for their useful comments. A special thanks to Adrian Farrel for his useful comments and suggestions.
作者要感谢阿尔西·艾扬加、迪米特里·帕帕迪米特里欧、湿婆·西瓦巴兰、梅拉尔·西拉齐普尔和马赫·陈的有用评论。特别感谢Adrian Farrel提出的有用意见和建议。
[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月。
[RFC5440] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, April 2009.
[RFC5440]Vasseur，J.，Ed.和J.Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年4月。
[PATH-KEY] Bradford, R., Vasseur, J., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, November 2008.
[PATH-KEY]Bradford，R.，Vasseur，J.，和A.Farrel，“使用基于密钥的机制在域间路径计算中保持拓扑机密性”，正在进行的工作，2008年11月。
[PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
[PCE-MANAGE]Farrel，A.，“将可管理性部分纳入PCE工作组草案”，正在进行的工作，2009年1月。
[PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008.
[PCE-MONITOR]Vasseur，J.，Roux，J.，和Y.Ikejiri，“基于元素的路径计算体系结构的一套监控工具”，正在进行的工作，2008年11月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.，Vasseur，J.，和J.Boyle，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.和J.Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月。
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[RFC5152] Vasseur, JP., Ayyangar, A., 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.，Ayyangar，A.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008.
[RFC5316]Chen，M.，Zhang，R.，和X.Duan，“支持自治系统（AS）MPLS和GMPLS流量工程的ISIS扩展”，RFC 5316，2008年12月。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.
[RFC5392]Chen，M.，Zhang，R.，和X.Duan，“支持跨自治系统（AS）MPLS和GMPLS流量工程的OSPF扩展”，RFC 5392，2009年1月。
Authors' Addresses
作者地址
JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（编辑）思科系统公司美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
美国加利福尼亚州埃尔塞贡多大道东2160号雷蒙德·张BT信息网，邮编90025
EMail: raymond.zhang@bt.com
EMail: raymond.zhang@bt.com
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA
美国马萨诸塞州沃尔瑟姆西街117号Nabil Bitar Verizon 02451
EMail: nabil.n.bitar@verizon.com
EMail: nabil.n.bitar@verizon.com
JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion, 22307 FRANCE
法国皮埃尔·马津·拉尼翁大道JL Le Roux法国电信2号，法国22307
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com