Network Working Group N. Bitar
Request for Comments: 5376 Verizon
Category: Informational R. Zhang
BT
K. Kumaki
KDDI R&D Labs
November 2008
Network Working Group N. Bitar
Request for Comments: 5376 Verizon
Category: Informational R. Zhang
BT
K. Kumaki
KDDI R&D Labs
November 2008
Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)
路径计算元素通信协议（PCECP）的内部AS要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.
多协议标签交换流量工程（MPLS TE）标签交换路径（LSP）可以完全建立在自治系统（AS）内，也可以跨越AS边界。
The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE.
路径计算元素（PCE）是能够计算（G）MPLS TE lsp的约束路径的组件。PCE通信协议（PCECP）定义为允许路径计算客户端（PCC）和PCE之间以及PCE之间的通信。PCECP用于请求受约束的路径，并作为响应提供计算路径。PCECP的一般要求见RFC 4657“路径计算元件（PCE）通信协议一般要求”。本文件扩展了这些要求，以涵盖PCECP在支持内部AS MPLS TE中的使用。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Reference Model .................................................4
3.1. Scope of Deployment Model ..................................5
4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
Computation .....................................................6
4.1. PCE Communication Protocol Requirements ....................6
4.1.1. Requirements for Path Computation Requests ..........6
4.1.2. Requirements for Path Computation Responses .........7
4.2. Scalability and Performance Considerations .................8
4.3. Management Considerations ..................................8
4.4. Confidentiality ............................................9
4.5. Policy Controls Affecting Inter-AS PCECP ...................9
4.5.1. Inter-AS PCE Peering Policy Controls ...............10
4.5.2. Inter-AS PCE Re-Interpretation Policies ............10
5. Security Considerations ........................................10
5.1. Use and Distribution of Keys ..............................11
5.2. Application of Policy .....................................11
5.3. Confidentiality ...........................................12
5.4. Falsification of Information ..............................12
6. Acknowledgments ................................................12
7. Normative References ...........................................13
8. Informative References .........................................13
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Reference Model .................................................4
3.1. Scope of Deployment Model ..................................5
4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
Computation .....................................................6
4.1. PCE Communication Protocol Requirements ....................6
4.1.1. Requirements for Path Computation Requests ..........6
4.1.2. Requirements for Path Computation Responses .........7
4.2. Scalability and Performance Considerations .................8
4.3. Management Considerations ..................................8
4.4. Confidentiality ............................................9
4.5. Policy Controls Affecting Inter-AS PCECP ...................9
4.5.1. Inter-AS PCE Peering Policy Controls ...............10
4.5.2. Inter-AS PCE Re-Interpretation Policies ............10
5. Security Considerations ........................................10
5.1. Use and Distribution of Keys ..............................11
5.2. Application of Policy .....................................11
5.3. Confidentiality ...........................................12
5.4. Falsification of Information ..............................12
6. Acknowledgments ................................................12
7. Normative References ...........................................13
8. Informative References .........................................13
[RFC4216] defines the scenarios motivating the deployment of inter-AS Multiprotocol Label Switching Traffic Engineering (MPLS TE) and specifies the requirements for inter-AS MPLS TE when the ASes are under the administration of one Service Provider (SP) or the administration of different SPs.
[RFC4216]定义了促使部署AS间多协议标签交换流量工程（MPLS TE）的场景，并规定了当ASE由一个服务提供商（SP）管理或由不同SP管理时，对AS间MPLS TE的要求。
Three signaling options are defined for setting up an inter-AS TE Label Switched Path (LSP):
定义了三个信令选项，用于设置AS TE间标签交换路径（LSP）：
1) contiguous TE LSP as documented in [RFC5151];
2) stitched inter-AS TE LSP discussed in [RFC5150];
3) nested TE LSP as in [RFC4206].
1) contiguous TE LSP as documented in [RFC5151];
2) stitched inter-AS TE LSP discussed in [RFC5150];
3) nested TE LSP as in [RFC4206].
[RFC5152] defines mechanisms for the computation of inter-domain TE LSPs using network elements along the signaling paths to compute per-domain constrained path segments. The mechanisms in [RFC5152] do not guarantee an optimum constrained path across multiple ASes where an optimum path for a TE LSP is one that has the smallest cost, according to a normalized TE metric (based upon a TE metric or Interior Gateway Protocol (IGP) metric adopted in each transit AS) among all possible paths that satisfy the LSP TE constraints.
[RFC5152]定义了使用信令路径上的网络元素计算域间TE LSP的机制，以计算每个域受约束的路径段。[RFC5152]中的机制不保证跨多个ASE的最佳约束路径，其中TE LSP的最佳路径是根据规范化TE度量（基于每个传输AS中采用的TE度量或内部网关协议（IGP）度量）具有最小成本的路径在满足LSP TE约束的所有可能路径中。
The Path Computation Element (PCE) [RFC4655] is a component that is capable of computing paths for MPLS TE and Generalized Multiprotocol Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a PCE have come from SP demands to compute optimum constrained paths across multiple areas and/or domains, and to be able to separate the path computation elements from the forwarding elements.
路径计算元件（PCE）[RFC4655]是能够计算MPLS TE和通用多协议标签交换协议（G）MPLS TE）LSP的路径的组件。对PCE的要求来自于SP要求计算跨多个区域和/或域的最佳约束路径，并能够将路径计算元素与转发元素分离。
The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is used to request (G)MPLS TE paths and to supply computed paths in response. Generic requirements for the PCECP are discussed in [RFC4657]. This document provides a set of PCECP requirements that are specific to inter-AS (G)MPLS TE path computation.
PCE通信协议（PCECP）定义为允许路径计算客户端（PCC）和PCE之间以及PCE之间的通信。PCECP用于请求（G）MPLS TE路径，并作为响应提供计算路径。[RFC4657]中讨论了PCECP的一般要求。本文档提供了一组特定于AS（G）MPLS TE路径计算的PCECP要求。
This document adopts the definitions and acronyms defined in Section 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the following terminology:
本文件采用[RFC4216]第3节和[RFC4655]第2节中定义的定义和首字母缩略词。此外，我们使用以下术语：
ASBR: Autonomous System Border Router (see section 3 of RFC 4216)
ASBR：自治系统边界路由器（见RFC 4216第3节）
PCECP: PCE Communication Protocol
PCECP:PCE通信协议
(G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering
（G） MPLS TE:MPLS或广义MPLS流量工程
Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) path that traverses two or more ASes.
内部AS（G）MPLS TE路径：穿过两个或多个AS的MPLS TE或通用MPLS（GMPLS）路径。
Intra-AS (G)MPLS TE path: An MPLS TE or GMPLS path that is confined to a single AS. It may traverse one or more IGP areas.
内部AS（G）MPLS TE路径：仅限于单个AS的MPLS TE或GMPLS路径。它可以穿过一个或多个IGP区域。
Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths remaining within a single AS.
内部AS PCE：负责计算单个AS中剩余的（G）MPLS TE路径的PCE。
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths or path segments, possibly by cooperating with intra-AS PCEs.
内部AS PCE：负责计算内部AS（G）MPLS路径或路径段的PCE，可能通过与内部AS PCE协作。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Figure 1 depicts the reference model for PCEs in an inter-AS application. We refer to two types of PCE functions in this document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures needed for inter-AS (G)MPLS TE path computation while intra-AS PCEs perform the functions needed for intra-AS (G)MPLS TE path computation.
图1描述了AS间应用程序中PCE的参考模型。在本文档中，我们提到两种类型的PCE功能：内部AS PCE和内部AS PCE。内部AS PCE执行内部AS（G）MPLS TE路径计算所需的过程，而内部AS PCE执行内部AS（G）MPLS TE路径计算所需的功能。
Inter-AS Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2<---------------->PCE3
:: :: :: ::
:: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
| | | | | |
| | | | | |
R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
::
::
Intra-AS
PCE
Inter-AS Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2<---------------->PCE3
:: :: :: ::
:: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
| | | | | |
| | | | | |
R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
::
::
Intra-AS
PCE
<==AS1==> <=====AS2=====> <====AS3====>
<==AS1==> <=====AS2=====> <====AS3====>
Figure 1: Inter- and Intra-AS PCE Reference Model
图1：内部和内部AS PCE参考模型
Let's follow a scenario that illustrates the interaction among PCCs, inter-AS PCEs, and intra-AS PCEs, as shown in Figure 1. R1 in AS1 wants to setup a (G)MPLS TE path, call it LSP1, with certain constraints to R7 in AS3. R1 determines, using mechanisms out of the
让我们按照一个场景演示PCC、内部AS PCE和内部AS PCE之间的交互，如图1所示。AS1中的R1想要设置一个（G）MPLS TE路径，称之为LSP1，对AS3中的R7有一定的限制。R1使用外部的机制进行确定
scope of this document, that R7 is an inter-AS route and that R1 (itself) needs to contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a PCECP path computation request to PCE1. PCE1 determines that R7 is reachable via AS2 and that PCE2 is the PCE to ask for path computation across AS2. PCE1 sends a PCECP path computation request to PCE2. Inter-AS PCE2, in turn, sends a PCECP path computation request to Intra-AS PCE R4 to compute a path within AS2 (in certain cases, the same router such as R3 can assume both inter-AS and intra-AS path computation functions). R4 may for instance return a PCECP path computation response to PCE2 with ASBR3 as the entry point to AS2 from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a PCECP path computation request to PCE3 to compute the path segment across AS3, starting at ASBR7 and terminating at R7. PCE3 returns a PCECP path computation response to PCE2 with the path segment ASBR7-R7. PCE2 then returns path ASBR3- ASBR5-ASBR7-R7 to PCE1, which, in turn, returns path ASBR1-ASBR3- ASBR5-ASBR7-R7 to PCC R1.
本文件的范围是，R7是一个内部AS路由，R1（自身）需要联系其内部AS PCE1来计算路径。R1作为PCC向PCE1发送PCECP路径计算请求。PCE1确定R7可通过AS2到达，并且PCE2是请求跨AS2进行路径计算的PCE。PCE1向PCE2发送PCECP路径计算请求。Inter-AS-PCE2依次向Intra-AS-PCE-R4发送PCECP路径计算请求，以计算AS2内的路径（在某些情况下，诸如R3的同一路由器可以承担Inter-AS和Intra-AS路径计算功能）。例如，R4可以向PCE2返回PCECP路径计算响应，其中ASBR3作为AS1到AS2的入口点，ASBR7作为AS3的出口点。然后，PCE2向PCE3发送PCECP路径计算请求，以计算AS3上的路径段，从ASBR7开始，在R7结束。PCE3向PCE2返回PCECP路径计算响应，路径段为BR7-R7。PCE2然后将路径ASBR3-ASBR5-ASBR7-R7返回给PCE1，PCE1又将路径ASBR1-ASBR3-ASBR5-ASBR7-R7返回给PCC R1。
As described in the above scenario, in general, a PCC may contact an inter-AS PCE to request the computation of an inter-AS path. That PCE may supply the path itself or may solicit the services of other PCEs, which may themselves be inter-AS PCEs, or may be intra-AS PCEs with the responsibility for computing path segments within just one AS.
如在上述场景中所描述的，通常，PCC可以联系As间PCE以请求As间路径的计算。该PCE可以提供路径本身，或者可以请求其他PCE的服务，这些PCE本身可以是作为PCE的内部PCE，或者可以是作为PCE的内部PCE，负责在一个AS内计算路径段。
This document describes the PCE Communication Protocol requirements for inter-AS path computation, i.e., for PCCs to communicate path computation requests for inter-AS (G)MPLS TE paths to PCEs, and for the PCEs to respond. It also includes the requirements for PCEs to communicate inter-AS path computation requests and responses.
本文件描述了AS间路径计算的PCE通信协议要求，即PCC将AS间（G）MPLS TE路径的路径计算请求传送到PCE，以及PCE响应。它还包括PCE作为路径计算请求和响应进行通信的要求。
All attempts to predict future deployment scopes within the Internet have proven fruitless. Nevertheless, it may be helpful to provide some discussion of the scope of the inter-AS deployment model as envisioned at the time of writing.
所有预测互联网未来部署范围的尝试都被证明是徒劳的。尽管如此，在撰写本文时，对inter-AS部署模型的范围进行一些讨论可能会有所帮助。
It is expected that most, if not all, inter-AS PCECP-based communications will be between PCEs operating in the cooperative PCE model described in [RFC4655]. Clearly, in this model, the requesting PCE acts as a PCC for the purpose of issuing a path computation request, but nevertheless, the requesting node fills the wider role of a PCE in its own AS. It is currently considered unlikely that a PCC (for example, a normal Label Switching Router) will make a path computation request to a PCE outside its own AS. This means that the PCECP relationships between ASes are limited to at most n squared (n^2), where n is the number of peering PCEs in the various ASes
预计大多数（如果不是全部的话）基于AS-PCECP的内部通信将在[RFC4655]中描述的协作PCE模型中运行的PCE之间进行。显然，在该模型中，为了发出路径计算请求，请求PCE充当PCC，但是，请求节点在其自身的as中充当PCE的更广泛角色。目前认为PCC（例如，普通标签交换路由器）不太可能向其自身AS之外的PCE发出路径计算请求。这意味着ASE之间的PCECP关系最多被限制为n平方（n^2），其中n是各种ASE中对等PCE的数量
(considered to be no greater than 100 in [RFC4657]). In practice, however, it is likely that only a few PCEs in one AS will be designated for PCECP communications with a PCE in an adjacent AS, and each of these will only have a few PCEs in the adjacent AS to choose from. A deployment model might place the PCEs as co-resident with the ASBRs, resulting in a manageable scaling of the PCE-PCE relationships. Scaling considerations (Section 4.2), manageability considerations (Section 4.3), and security considerations (Section 5) should be examined in the light of these deployment expectations.
（被认为不大于100英寸[RFC4657]）。然而，在实践中，很可能一个AS中只有几个PCE将被指定用于与相邻AS中的PCE的PCECP通信，并且这些PCE中的每一个在相邻AS中只有几个PCE可供选择。部署模型可能将PCE作为ASBR的共同居民，从而实现PCE-PCE关系的可管理扩展。扩展考虑（第4.2节）、可管理性考虑（第4.3节）和安全考虑（第5节）应根据这些部署预期进行检查。
This section discusses detailed PCECP requirements for inter-AS (G)MPLS TE LSPs. Depending on the deployment environment, some or all of the requirements described here may be utilized. Specifically, some requirements are more applicable to inter-provider inter-AS (G)MPLS TE operations than to intra-provider operations.
本节讨论了AS（G）MPLS TE LSP间的详细PCECP要求。根据部署环境的不同，这里描述的部分或全部需求可能会被利用。具体而言，一些要求更适用于提供商间AS（G）MPLS TE操作，而不是提供商内操作。
Requirements specific to inter-AS PCECP path computation requests and responses are discussed in the following sections.
以下各节讨论了AS间PCECP路径计算请求和响应的特定要求。
The following are inter-AS specific requirements for PCECP requests for path computation:
以下是路径计算PCECP请求的AS间具体要求：
1. [RFC4657] states the requirement for a priority level to be associated with each path computation request. This document does not change that requirement. However, PCECP should include a mechanism that enables an inter-AS PCE to inform the requesting inter-AS PCE of a change in the request priority level that may have resulted from the application of a local policy.
1. [RFC4657]说明了与每个路径计算请求关联的优先级要求。本文件不会改变该要求。然而，PCECP应包括一种机制，该机制使AS间PCE能够通知请求的AS间PCE可能由于应用本地策略而导致的请求优先级的变化。
2. A path computation request by an inter-AS PCE or a PCC to another inter-AS PCE MUST be able to specify the sequence of ASes and/or ASBRs across the network by providing ASBRs and/or ASes as hops in the desired path of the TE LSP to the destination. For instance, an inter-AS PCE MUST be able to specify to the inter-AS PCE serving the neighboring AS a preferred ASBR for exiting to that AS and reach the destination. That is, where multiple ASBRs exist, the requester MUST be able to indicate a preference for one of them. The PCE must be able to indicate whether the specified ASBR or AS is mandatory or non-mandatory on the (G)MPLS TE path.
2. 由inter-AS PCE或PCC向另一inter-AS PCE的路径计算请求必须能够通过在到目的地的TE-LSP的期望路径中提供asbr和/或ASes作为跳来指定网络上ase和/或asbr的序列。例如，inter-AS PCE必须能够将服务于相邻的inter-AS PCE指定为首选ASBR，以退出到该AS并到达目的地。也就是说，如果存在多个ASBR，请求者必须能够指示其中一个ASBR的首选项。PCE必须能够指示指定的ASBR或AS在（G）MPLS TE路径上是强制性的还是非强制性的。
3. PCECP MUST allow a requester to provide a list of ASes and/or ASBRs to be excluded from the computed path.
3. PCECP必须允许请求者提供要从计算路径中排除的ASE和/或ASBR列表。
4. A PCECP path computation request from one inter-AS PCE to another MUST include the AS number of the requesting AS to enable the correct application of local policy at the second inter-AS PCE.
4. 从一个inter-AS-PCE到另一个inter-AS-PCE的PCECP路径计算请求必须包括请求AS的AS编号，以便能够在第二个inter-AS-PCE处正确应用本地策略。
5. A path computation request from a PCC to an inter-AS PCE or an inter-AS PCE to another MUST be able to specify the need for protection against node, link, or Shared Risk Link Group (SRLG) failure using 1:1 detours or facility backup. It MUST be possible to request protection across all ASes or across specific ASes.
5. 从PCC到inter-AS PCE或从inter-AS PCE到另一个PCE的路径计算请求必须能够使用1:1绕道或设施备份指定针对节点、链路或共享风险链路组（SRLG）故障的保护需求。必须能够跨所有ASE或特定ASE请求保护。
6. PCECP MUST support the disjoint path requirements as specified in [RFC4657]. In addition, it MUST allow the specification of AS-diversity for the computation of a set of two or more paths.
6. PCECP必须支持[RFC4657]中规定的不相交路径要求。此外，它必须允许指定AS多样性，以计算一组两条或多条路径。
7. A PCECP path computation request message MUST be able to identify the scope of diversified path computation to be end-to-end (i.e., between the endpoints of the (G)MPLS TE tunnel) or to be limited to a specific AS.
7. PCECP路径计算请求消息必须能够识别端到端（即，（G）MPLS TE隧道的端点之间）或受限于特定AS的多样化路径计算的范围。
The following are inter-AS specific requirements for PCECP responses for path computation:
以下是路径计算PCECP响应的AS间具体要求：
1. A PCECP path computation response from one inter-AS PCE to another MUST be able to include both ASBRs and ASes in the computed path while preserving path segment and topology confidentiality.
1. 从一个inter-AS-PCE到另一个inter-AS-PCE的PCECP路径计算响应必须能够在保持路径段和拓扑机密性的同时在计算路径中包括asbr和ase。
2. A PCECP path computation response from one inter-AS PCE to the requesting inter-AS PCE MUST be able to carry an identifier for a path segment it computes to preserve path segment and topology confidentiality. The objective of the identifier is to be included in the TE LSP signaling, whose mechanism is out of scope of this document, to be used for path expansion during LSP signaling.
2. 从一个inter-AS PCE到请求inter-AS PCE的PCECP路径计算响应必须能够携带其计算的路径段的标识符，以保持路径段和拓扑机密性。标识符的目标包括在TE LSP信令中，其机制不在本文档的范围内，用于LSP信令期间的路径扩展。
3. If a constraint for a desired ASBR (see Section 4.1.1, requirement 2) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE to notify the requester of that fact as an error in a path computation response.
3. 如果PCE无法满足所需ASBR的约束（见第4.1.1节，要求2），PCECP应允许PCE将该事实作为路径计算响应中的错误通知请求者。
4. A PCECP path computation response from an inter-AS PCE to a requesting inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS path cost. Path cost normalization across ASes is out of scope of this document.
4. 从inter-AS PCE到请求的inter-AS PCE或PCC的PCECP路径计算响应必须能够携带累积的inter-AS路径成本。ASes之间的路径成本标准化超出了本文档的范围。
5. A PCECP path computation response from an inter-AS PCE to a PCC SHOULD be able to carry the intra-AS cost of the path segment within the PCC AS.
5. 从内部AS PCE到PCC的PCECP路径计算响应应当能够携带PCC AS内路径段的内部AS代价。
6. A PCECP path computation response MUST be able to identify diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e., between the two endpoints of the (G)MPLS TE tunnel) disjoint paths are paths that do not share nodes, links, or SRLGs except for the LSP head-end and tail-end. In cases where diversified path segments are desired within one or more ASes, the disjoint path segments may share only the ASBRs of the first AS and the ASBR of the last AS across these ASes.
6. PCECP路径计算响应必须能够识别相同（G）MPLS TE LSP的不同路径。端到端（即，（G）MPLS TE隧道的两个端点之间）不相交路径是不共享节点、链路或srlg的路径，LSP前端和后端除外。在一个或多个ASE内需要多样化的路径段的情况下，不相交的路径段可以在这些ASE之间仅共享第一个AS的ASBR和最后一个AS的ASBR。
PCECP design for use in the inter-AS case SHOULD consider the following criteria:
在国际互联互通系统中使用的PCECP设计应考虑以下标准：
- PCE message processing load. - Scalability as a function of the following parameters: o number of PCCs within the scope of an inter-AS PCE o number of intra-AS PCEs within the scope of an inter-AS PCE o number of peering inter-AS PCEs per inter-AS PCE - Added complexity caused by inter-AS features.
- PCE消息处理负载。-可伸缩性是以下参数的函数：o内部as PCE范围内的PCC数量o内部as PCE范围内的内部as PCE数量o每个内部as PCE的对等内部as PCE数量-增加了内部as功能造成的复杂性。
[RFC4657] specifies generic requirements for PCECP management. This document specifies new requirements that apply to inter-AS operations.
[RFC4657]规定了PCECP管理的一般要求。本文件规定了适用于AS间操作的新要求。
The PCECP MIB module MUST provide objects to control the behavior of PCECP in inter-AS applications. These objects include the ASes within the scope of an inter-AS PCE, inter-AS PCEs in neighboring ASes to which the requesting PCE will or will not communicate, confidentiality, and policies.
PCECP MIB模块必须提供对象来控制AS间应用程序中PCECP的行为。这些对象包括inter-AS-PCE范围内的ase、请求PCE将与或不与之通信的相邻ase中的inter-AS-PCE、机密性和策略。
The built-in diagnostic tools MUST enable failure detection and status checking of PCC/PCE-PCE PCECP. Diagnostic tools include statistics collection on the historical behavior of PCECP as specified in [RFC4657], but additionally it MUST be possible to analyze these statistics on a neighboring AS basis (i.e., across the inter-AS PCEs that belong to a neighboring AS).
内置诊断工具必须能够对PCC/PCE-PCE PCECP进行故障检测和状态检查。诊断工具包括[RFC4657]中规定的PCECP历史行为的统计数据收集，但另外，必须能够在相邻as基础上分析这些统计数据（即，跨属于相邻as的as间PCE）。
The MIB module MUST support trap functions when thresholds are crossed or when important events occur as stated in [RFC4657]. These thresholds SHOULD be specifiable per neighbor AS as well as per peer inter-AS PCE, and traps should be accordingly generated.
如[RFC4657]所述，当超过阈值或发生重要事件时，MIB模块必须支持陷阱功能。这些阈值应可指定为每个邻居以及每个对等内部PCE，并且应相应地生成陷阱。
Basic liveliness detection for PCC/PCE-PCE PCECP is described in [RFC4657]. The PCECP MIB module SHOULD allow control of liveliness check behavior by providing a liveliness message frequency MIB object, and this frequency object SHOULD be specified per inter-AS PCE peer. In addition, there SHOULD be a MIB object that specifies the dead-interval as a multiplier of the liveliness message frequency so that if no liveliness message is received within that time from an inter-AS PCE, the inter-AS PCE is declared unreachable.
[RFC4657]中描述了PCC/PCE-PCE PCECP的基本活性检测。PCECP MIB模块应允许通过提供活跃消息频率MIB对象来控制活跃性检查行为，并且该频率对象应按照inter作为PCE对等方指定。此外，应该有一个MIB对象，它将死区间隔指定为活跃消息频率的倍增，这样，如果在该时间内没有从inter-as-PCE接收到活跃消息，那么inter-as-PCE将被声明为不可访问。
Confidentiality mainly applies to inter-provider (inter-AS) PCE communication. It is about protecting the information exchanged between PCEs and about protecting the topology information within an SP's network. Confidentiality rules may also apply among ASes owned by a single SP. Each SP will in most cases designate some PCEs for inter-AS (G)MPLS TE path computation within its own administrative domain and some other PCEs for inter-provider inter-AS (G)MPLS TE path computation. Among the inter-provider-scoped inter-AS PCEs in each SP domain, there may also be a subset of the PCEs specifically enabled for path computation across a specific set of ASes of different peer SPs.
保密性主要适用于提供商间（AS间）PCE通信。它涉及到保护PCE之间交换的信息，以及保护SP网络中的拓扑信息。保密规则也可能适用于单个SP所拥有的ASE。在大多数情况下，每个SP将在其自己的管理域内指定一些PCE用于AS（G）MPLS TE路径间计算，并指定一些其他PCE用于提供商AS（G）MPLS TE路径间计算。在每个SP域中的提供商范围内的AS间PCE中，还可能存在专门用于跨不同对等SP的特定ASE集合进行路径计算的PCE子集。
PCECP MUST allow an SP to hide from other SPs the set of hops within its own ASes that are traversed by an inter-AS inter-provider TE LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative domain environment, SPs may want to hide their network topologies for security or commercial reasons. Thus, for each inter-AS TE LSP path segment an inter-AS PCE computes, it may return to the requesting inter-AS PCE an inter-AS TE LSP path segment from its own ASes without detailing the explicit intra-AS hops. As stated earlier, PCECP responses SHOULD be able to carry path-segment identifiers that replace the details of that path segment. The potential use of that identifier for path expansion, for instance, during LSP signaling is out of scope of this document.
PCECP必须允许SP向其他SP隐藏其自身ASE内的一组由AS间提供商TE LSP穿越的跃点（参见[RFC4216]第5.2.1节）。在多SP管理域环境中，SP出于安全或商业原因可能希望隐藏其网络拓扑。因此，对于inter-AS-PCE计算的每个inter-AS-TE LSP路径段，它可以从其自己的ase返回到请求的inter-AS-PCE-AS-TE LSP路径段，而不详细说明显式的intra-AS跳。如前所述，PCECP响应应能够携带路径段标识符，以替换该路径段的详细信息。例如，在LSP信令期间，该标识符用于路径扩展的潜在用途超出了本文档的范围。
Section 5.2.2 of [RFC4216] discusses the policy control requirements for inter-AS RSVP-TE signaling at the AS boundaries for the enforcement of interconnect agreements, attribute/parameter translation and security hardening.
[RFC4216]第5.2.2节讨论了AS边界处AS间RSVP-TE信令的策略控制要求，以执行互连协议、属性/参数转换和安全强化。
This section discusses those policy control requirements that are similar to what are discussed in section 5.2.2 of [RFC4216] for PCECP. Please note that SPs may still require policy controls during
本节讨论的政策控制要求与[RFC4216]第5.2.2节中针对PCECP讨论的类似。请注意，SP在运行期间可能仍需要策略控制
signaling of TE LSPs to enforce their bilateral or multilateral agreements at AS boundaries, but signaling is out of scope for this document.
向TE LSP发出信号，以在AS边界执行其双边或多边协议，但信号不在本文件范围内。
An inter-AS PCE sends path computation requests to its neighboring inter-AS PCEs, and an inter-AS PCE that receives such a request enforces policies applicable to the sender of the request. These policies may include rewriting some of the parameters or rejecting requests based on parameter values. Such policies may be applied for PCEs belonging to different SPs or to PCEs responsible for ASes within a single SP administrative domain. Parameters that might be subject to policy include bandwidth, setup/holding priority, Fast Reroute request, Differentiated Services Traffic Engineering (DS-TE) Class Type (CT), and others as specified in section 5.2.2.1 of [RFC4216].
inter-AS-PCE向其相邻的inter-AS-PCE发送路径计算请求，并且接收该请求的inter-AS-PCE实施适用于该请求的发送者的策略。这些策略可能包括重写某些参数或基于参数值拒绝请求。此类政策可适用于属于不同SP的PCE或负责单个SP管理域内ASE的PCE。可能受政策约束的参数包括带宽、设置/保持优先级、快速重路由请求、区分服务流量工程（DS-TE）类类型（CT）以及[RFC4216]第5.2.2.1节中规定的其他参数。
For path computation requests that are not compliant with locally configured policies, PCECP SHOULD enable a PCE to send an error message to the requesting PCC or PCE indicating that the request has been rejected because a specific parameter did not satisfy the local policy.
对于不符合本地配置策略的路径计算请求，PCECP应使PCE能够向请求PCC或PCE发送错误消息，指示该请求已被拒绝，因为特定参数不符合本地策略。
Each SP may have different definitions in its use of, for example, DS-TE TE classes. An inter-AS PCE receiving a path computation request needs to interpret the parameters and constraints and adapt them to the local environment. Specifically, a request constructed by a PCC or PCE in one AS may have parameters and constraints that should be interpreted differently or translated by the receiving PCE that is in a different AS. A list of signaling parameters subject to policy re-interpretation at AS borders can be found in section 5.2.2.2 of [RFC4216], and the list for path computation request parameters and constraints is the same. In addition, the transit SPs along the inter-AS TE path may be GMPLS transport providers, which may require re-interpretation of MPLS-specific PCECP path computation request objects in order to enable path computation over a GMPLS network or vice versa.
每个SP在使用DS-TE类时可能有不同的定义。接收路径计算请求的AS间PCE需要解释参数和约束，并使其适应本地环境。具体地说，由一个AS中的PCC或PCE构造的请求可以具有参数和约束，这些参数和约束应当由不同AS中的接收PCE进行不同的解释或翻译。在[RFC4216]的第5.2.2.2节中可以找到在AS边界进行策略重新解释的信令参数列表，路径计算请求参数和约束的列表相同。此外，沿AS TE路径的传输sp可以是GMPLS传输提供者，这可能需要重新解释MPLS特定的PCECP路径计算请求对象，以便能够通过GMPLS网络进行路径计算，反之亦然。
The PCECP is a communications protocol for use between potentially remote entities (PCCs and PCEs) over an IP network. Security concerns arise in order to protect the PCC, PCE, and the information they exchange. [RFC4758] specifies requirements on the PCECP to protect against spoofing, snooping, and DoS attacks. That document
PCECP是通过IP网络在潜在远程实体（PCC和PCE）之间使用的通信协议。出现安全问题是为了保护PCC、PCE及其交换的信息。[RFC4758]规定了PCECP上防止欺骗、窥探和DoS攻击的要求。那份文件
is concerned with general protocol requirements applicable to the basic use of the PCECP. This document is specific to the application of the PCE architecture in an inter-AS environment, and so it is appropriate to highlight the security considerations that apply in that environment.
涉及适用于PCECP基本用途的一般协议要求。本文档专门针对AS间环境中PCE体系结构的应用，因此有必要强调在该环境中应用的安全注意事项。
Security requirements that exist within a single administrative domain become critical in the multi-AS case when the control of IP traffic and access to the network may leave the authority of a single administration.
当IP流量的控制和对网络的访问可能离开单一管理的权限时，单个管理域中存在的安全要求在多AS情况下变得至关重要。
How the participants in a PCECP session discover each other and the need for the session is out of scope of this document. It may be through configuration or automatic discovery. However, when a PCECP session is established, the PCECP speakers MUST have mechanisms to authenticate each other's identities and validate the data they exchange. They also SHOULD have mechanisms to protect the data that they exchange via encryption. Such mechanisms usually require the use of keys, and so the PCECP MUST describe techniques for the exchange and use of security keys. Where inter-AS PCE discovery is used, and PCECP security is required, automated key distribution mechanisms MUST also be used. Since such key exchange must (necessarily) operate over an AS boundary, proper consideration needs to be given to how inter-AS key exchanges may be carried out and how the key exchange, itself, may be secured. Key distribution mechanisms MUST be defined with consideration of [RFC4107]. Where a PCECP session is configured between a pair of inter-AS PCEs, a security key may be manually set for that session.
PCECP会话的参与者如何发现彼此以及会话的需求超出了本文档的范围。它可以通过配置或自动发现实现。但是，当建立PCECP会话时，PCECP演讲者必须具有相互验证身份和验证他们交换的数据的机制。他们还应该有机制来保护他们通过加密交换的数据。这种机制通常需要使用密钥，因此PCECP必须描述交换和使用安全密钥的技术。如果使用内部AS PCE发现，并且需要PCECP安全性，则还必须使用自动密钥分发机制。由于此类密钥交换必须（必然）在AS边界上运行，因此需要适当考虑如何进行AS间密钥交换以及密钥交换本身如何安全。密钥分配机制的定义必须考虑[RFC4107]。在一对AS-pce之间配置PCECP会话的情况下，可以手动为该会话设置安全密钥。
Policy forms an important part of the operation of PCEs in an inter-AS environment as described in Section 4.5, especially when ASes are administrated by different SPs. A wider discussion of the application of policy to the PCE architecture can be found in [PCE-POLICY].
政策构成第4.5节所述的AS间环境中PCE运行的重要部分，特别是当ASE由不同SP管理时。有关政策在PCE体系结构中的应用的更广泛讨论，请参见[PCE-policy]。
Policy may also form part of the security model for the PCECP and may be particularly applicable to inter-AS path computation requests. A fundamental element of the application of policy at a PCE is the identity of the requesting PCC/PCE. This makes the use of authentication described in Section 5.1 particularly important. Where policy information is exchanged as part of the computation request and/or response, the policy object is transparent to the PCECP being delivered un-inspected and unmodified to the policy component of a PCE or PCC. Therefore, the policy components are
策略还可以构成PCECP的安全模型的一部分，并且可以特别适用于AS间路径计算请求。在PCE上应用策略的一个基本要素是请求PCC/PCE的身份。这使得第5.1节中描述的身份验证的使用特别重要。在策略信息作为计算请求和/或响应的一部分进行交换的情况下，策略对象对于未经检查和未经修改地交付给PCE或PCC的策略组件的PCECP是透明的。因此，策略组件是
responsible for protecting (for example, encrypting) the policy information and using additional identification and authentication if a higher level of validation is required than is provided by the base protocol elements of the PCECP.
负责保护（例如，加密）策略信息，并在需要比PCECP的基本协议元素提供的验证级别更高的验证级别时使用额外的标识和身份验证。
The PCECP MUST provide a mechanism to preserve the confidentiality of path segments computed by a PCE in one AS and provided in a computation response to another AS.
PCECP必须提供一种机制，以保护PCE在一个AS中计算的路径段以及在对另一个AS的计算响应中提供的路径段的机密性。
Furthermore, a PCE SHOULD be provided with a mechanism to mask its identity such that its presence in the path computation chain in a cooperative PCE model (such as described in [BRPC]) cannot be derived from the computed path. This will help to protect the PCE from targeted attacks. Clearly, such confidentiality does not extend to the PCECP peer (i.e., a PCC or another PCE) that invokes the PCE with a path computation request.
此外，应为PCE提供掩盖其身份的机制，以使得其在协作PCE模型（如[BRPC]中所述）中的路径计算链中的存在不能从计算路径导出。这将有助于保护PCE免受有针对性的攻击。显然，这种保密性不扩展到通过路径计算请求调用PCE的PCECP对等方（即PCC或另一PCE）。
In the PCE architecture, when PCEs cooperate, one PCE may return a path computation result that is composed of multiple path segments, each computed by a different PCE. In the inter-AS case, each PCE may belong to a different administrative domain, and the source PCC might not know about the downstream PCEs, nor fully trust them. Although it is possible and RECOMMENDED to establish a chain of trust between PCEs, this might not always be possible. In this case, it becomes necessary to guard against a PCE changing the information provided by another downstream PCE. Some mechanism MUST be available in the PCECP, and echoed in the corresponding signaling, that allows an AS to verify that the signaled path conforms to the path segment computed by the local PCE and returned on the path computation request.
在PCE架构中，当PCE协作时，一个PCE可以返回由多个路径段组成的路径计算结果，每个路径段由不同的PCE计算。在AS间的情况下，每个PCE可能属于不同的管理域，并且源PCC可能不知道下游PCE，也不完全信任它们。虽然可以并建议在PCE之间建立信任链，但这并不总是可能的。在这种情况下，有必要防止PCE改变另一下游PCE提供的信息。某些机制必须在PCECP中可用，并在相应的信令中回声，从而允许AS验证信令路径是否符合本地PCE计算并在路径计算请求中返回的路径段。
We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean Louis Le Roux for their useful comments and suggestions. Pasi Eronen and Sandy Murphy provided valuable early Security Directorate reviews. Adrian Farrel re-wrote the Security Considerations section.
我们要感谢阿德里安·法雷尔、让·菲利普·瓦瑟尔和让·路易斯·勒鲁提出的有益的意见和建议。帕西·埃隆和桑迪·墨菲提供了有价值的早期安全理事会审查。Adrian Farrel重新编写了安全注意事项部分。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[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月。
[BRPC] Vasseur, JP., 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", Work in Progress, April 2008.
[BRPC]Vasseur，JP.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，正在进行的工作，2008年4月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4758] Nystroem, M., "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, November 2006.
[RFC4758]Nystroem，M.，“加密令牌密钥初始化协议（CT-KIP）版本1.0修订版1”，RFC 4758，2006年11月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[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月。
[PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", Work in Progress, October 2007.
[PCE-POLICY]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“基于策略的路径计算框架”，正在进行的工作，2007年10月。
Authors' Addresses
作者地址
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon 117 West Street Waltham，MA 02451美国电子邮件：Nabil.n。bitar@verizon.com
Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN EMail: ke-kumaki@kddi.com
Kenji Kumaki KDDI研发实验室有限公司2-1-15 Ohara Fujimino Saitama 356-8502，日本电子邮件：ke-kumaki@kddi.com
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: Raymond.zhang@bt.com
雷蒙德张BT 2160东大大道埃尔塞贡多，加利福尼亚州90245美国电子邮件：雷蒙德。zhang@bt.com