Network Working Group J.-L. Le Roux, Ed.
Request for Comments: 4927 France Telecom
Category: Informational June 2007
Network Working Group J.-L. Le Roux, Ed.
Request for Comments: 4927 France Telecom
Category: Informational June 2007
Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering
区域间MPLS和GMPLS流量工程的路径计算元素通信协议（PCECP）特定要求
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) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol.
出于可伸缩性目的，网络可包括多个内部网关协议（IGP）区域。区域间流量工程标签交换路径（TE-LSP）是通过至少两个IGP区域的LSP。在多区域网络中，拓扑可见性保持在给定区域的局部，并且前端标签交换路由器（LSR）无法计算区域间最短约束路径。基于路径计算元素（PCE）的体系结构的一个关键应用是计算区域间TE-LSP路径。PCE通信协议（PCECP）用于将来自路径计算客户端（PCC）的计算请求通信到PCE，并在响应中返回计算路径。本文件列出了支持区域间TE-LSP路径计算的一组详细PCECP特定要求。它补充了PCE通信协议的一般要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................4
3. Motivations for PCE-Based Inter-Area Path Computation ...........4
4. Detailed Inter-Area Specific Requirements on PCECP ..............5
4.1. Control and Recording of Area Crossing .....................5
4.2. Area Recording .............................................6
4.3. Strict Explicit Path and Loose Path ........................6
4.4. PCE List Enforcement and Recording in Multiple-PCE
Computation ................................................6
4.5. Inclusion of Area IDs in Request ...........................7
4.6. Area Inclusion/Exclusion ...................................7
4.7. Inter-Area Diverse Path Computation ........................7
4.8. Inter-Area Policies ........................................8
4.9. Loop Avoidance .............................................8
5. Manageability Considerations ....................................9
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
9. Contributors ...................................................10
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................4
3. Motivations for PCE-Based Inter-Area Path Computation ...........4
4. Detailed Inter-Area Specific Requirements on PCECP ..............5
4.1. Control and Recording of Area Crossing .....................5
4.2. Area Recording .............................................6
4.3. Strict Explicit Path and Loose Path ........................6
4.4. PCE List Enforcement and Recording in Multiple-PCE
Computation ................................................6
4.5. Inclusion of Area IDs in Request ...........................7
4.6. Area Inclusion/Exclusion ...................................7
4.7. Inter-Area Diverse Path Computation ........................7
4.8. Inter-Area Policies ........................................8
4.9. Loop Avoidance .............................................8
5. Manageability Considerations ....................................9
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
9. Contributors ...................................................10
[RFC4105] lists a set of motivations and requirements for setting up TE-LSPs across IGP area boundaries. These LSPs are called inter-area TE-LSPs. These requirements include the computation of inter-area shortest constrained paths with a key guideline being to respect the IGP hierarchy concept, and particularly the containment of topology information. The main challenge with inter-area MPLS-TE lies in path computation. Indeed, the head-end LSR cannot compute an explicit path across areas, as its topology visibility is limited to its own area.
[RFC4105]列出了跨IGP区域边界建立TE LSP的一系列动机和要求。这些LSP称为区域间TE LSP。这些要求包括计算区域间最短约束路径，关键准则是尊重IGP层次概念，尤其是包含拓扑信息。区域间MPLS-TE的主要挑战在于路径计算。实际上，前端LSR无法计算跨区域的显式路径，因为其拓扑可见性仅限于其自身区域。
Inter-area path computation is one of the key applications of the PCE-based architecture [RFC4655]. The computation of optimal inter-area paths may be achieved using the services of one or more PCEs.
区域间路径计算是基于PCE的体系结构[RFC4655]的关键应用之一。可以使用一个或多个pce的服务来实现最佳区域间路径的计算。
Such PCE-based inter-area path computation could rely for instance on a single multi-area PCE that has the TE database of all the areas in the IGP domain and can directly compute an end-to-end constrained shortest path. Alternatively, this could rely on the cooperation between PCEs whereby each PCE covers one or more IGP areas and the full set of PCEs covers all areas.
这种基于PCE的区域间路径计算可以依赖于例如具有IGP域中所有区域的TE数据库的单个多区域PCE，并且可以直接计算端到端约束的最短路径。或者，这可以依赖PCE之间的合作，每个PCE覆盖一个或多个IGP区域，全套PCE覆盖所有区域。
The generic requirements for a PCE Communication Protocol (PCECP), which allows a PCC to send path computation requests to a PCE and the PCE to send path computation responses to a PCC, are set forth in [RFC4657]. The use of a PCE-based approach for inter-area path computation implies specific requirements on a PCE Communication Protocol, in addition to the generic requirements already listed in [RFC4657]. This document complements these generic requirements by listing a detailed set of PCECP requirements specific to inter-area path computation.
[RFC4657]中规定了PCE通信协议（PCECP）的一般要求，该协议允许PCC向PCE发送路径计算请求，并允许PCE向PCC发送路径计算响应。除了[RFC4657]中已经列出的一般要求外，使用基于PCE的区域间路径计算方法意味着对PCE通信协议的特定要求。本文件通过列出一组特定于区域间路径计算的详细PCECP要求来补充这些通用要求。
It is expected that PCECP procedures be defined to satisfy these requirements.
预计将定义PCECP程序以满足这些要求。
Note that PCE-based inter-area path computation may require a mechanism for automatic PCE discovery across areas, which is out of the scope of this document. Detailed requirements for such a mechanism are discussed in [RFC4674].
请注意，基于PCE的区域间路径计算可能需要跨区域自动发现PCE的机制，这超出了本文档的范围。[RFC4674]中讨论了此类机制的详细要求。
LSR: Label Switching Router.
标签交换路由器。
LSP: MPLS Label Switched Path.
LSP:MPLS标签交换路径。
TE-LSP: Traffic Engineered Label Switched Path.
TE-LSP：流量工程标签交换路径。
IGP area: OSPF area or IS-IS level.
IGP区域：OSPF区域或IS-IS级别。
ABR: IGP Area Border Router, a router that is attached to more than one IGP area (ABR in OSPF or L1/L2 router in IS-IS).
ABR:IGP区域边界路由器，连接到多个IGP区域的路由器（OSPF中的ABR或is-is中的L1/L2路由器）。
Inter-Area TE-LSP: TE-LSP that traverses more than one IGP area.
区域间TE-LSP：穿越多个IGP区域的TE-LSP。
CSPF: Constrained Shortest Path First.
CSPF：约束最短路径优先。
SRLG: Shared Risk Link Group.
SRLG：共享风险链接组。
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：路径计算元素：能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCC: Path Computation Client, any application that request path computation to be performed by a PCE.
PCC：路径计算客户端，任何请求由PCE执行路径计算的应用程序。
PCECP: PCE Communication Protocol, a protocol for communication between PCCs and PCEs, and between PCEs.
PCECP：PCE通信协议，用于PCC和PCE之间以及PCE之间通信的协议。
ERO: Resource Reservation Protocol (RSVP)-TE Explicit Route Object. It encodes the explicit path followed by a TE-LSP.
资源预留协议（RSVP）-TE显式路由对象。它编码显式路径，后跟TE-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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
IGP hierarchy enables improved IGP scalability by dividing the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries. A router in an area has full topology information for its own area, but only information about reachability to destinations in other areas. Thus, a head-end LSR cannot compute an end-to-end path that crosses the boundary of its IGP area(s).
IGP层次结构通过将IGP域划分为多个区域并将拓扑信息的泛洪范围限制在区域边界内，实现了改进的IGP可伸缩性。一个区域中的路由器有其自身区域的完整拓扑信息，但只有关于到达其他区域中目的地的信息。因此，前端LSR无法计算穿过其IGP区域边界的端到端路径。
A current solution for computing inter-area TE-LSP path relies on a per-domain path computation [PD-COMP]. It is based on loose hop routing with an ERO expansion on each ABR. This allows an LSP to be set up following a constrained path, but faces two major limitations:
当前用于计算区域间TE-LSP路径的解决方案依赖于每域路径计算[PD-COMP]。它基于松散跃点路由，每个ABR上都有一个ERO扩展。这允许按照受约束的路径设置LSP，但面临两个主要限制：
- This does guarantee the use of an optimal constrained path.
- 这确实保证了最佳约束路径的使用。
- This may lead to several crankback signaling messages and hence delay the LSP setup, and may also invoke possible alternate routing activities.
- 这可能会导致若干回退信令消息，从而延迟LSP设置，还可能调用可能的备用路由活动。
Note that, here, by optimal constrained path we mean the shortest constrained path across multiple areas, taking into account either the IGP or TE metric [RFC3785]. In other words, such a path is the path that would have been computed by making use of some CSPF algorithm in the absence of multiple IGP areas.
请注意，这里的最优约束路径指的是跨多个区域的最短约束路径，同时考虑IGP或TE度量[RFC3785]。换句话说，这样的路径是在没有多个IGP区域的情况下，通过使用某些CSPF算法计算的路径。
The PCE-based architecture [RFC4655] is well suited to inter-area path computation. It allows the path computation limitations resulting from the limited topology visibility to be overcome by introducing path computation entities with more topology visibility, or by allowing cooperation between path computation entities in each area.
基于PCE的体系结构[RFC4655]非常适合于区域间路径计算。它允许通过引入具有更高拓扑可见性的路径计算实体，或通过允许每个区域中的路径计算实体之间的协作，来克服由于有限的拓扑可见性而导致的路径计算限制。
There are two main approaches for the computation of an inter-area optimal path:
计算区域间最佳路径有两种主要方法：
- Single-PCE computation: The path is computed by a single PCE that has topology visibility in all areas and can compute an end-to-end optimal constrained path on its own.
- 单个PCE计算：路径由单个PCE计算，该PCE在所有区域都具有拓扑可见性，并且可以自行计算端到端的最佳约束路径。
- Multiple-PCE computation with inter-PCE communication: The path computation is distributed on multiple PCEs, which have partial topology visibility. They compute path segments in their domains of visibility and collaborate with each other so as to arrive at an end-to-end optimal constrained path. Such collaboration is ensured thanks to inter-PCE communication.
- 具有PCE间通信的多PCE计算：路径计算分布在多个PCE上，这些PCE具有部分拓扑可见性。它们在各自的可视域中计算路径段，并相互协作，以获得端到端的最优约束路径。由于PCE之间的沟通，确保了这种协作。
Note that the use of a PCE-based approach to perform inter-area path computation implies specific functional requirements in a PCECP, in addition to the generic requirements listed in [RFC4657]. These specific requirements are discussed in the next section.
注意，除了[RFC4657]中列出的一般要求外，使用基于PCE的方法执行区域间路径计算意味着PCECP中的特定功能要求。这些具体要求将在下一节中讨论。
This section lists a set of additional requirements for the PCECP that complement requirements listed in [RFC4657] and are specific to inter-area (G)MPLS-TE path computation.
本节列出了PCECP的一组附加要求，这些要求补充了[RFC4657]中列出的要求，并且特定于区域间（G）MPLS-TE路径计算。
In addition to the path constraints specified in [RFC4657], the request message MUST allow indicating whether or not area crossing is permitted. Indeed, when the source and destination reside in the same IGP area, there may be intra-area and inter-area feasible paths. As set forth in [RFC4105], if the shortest path is an inter-area path, an operator either may want to avoid, as far as possible, crossing areas and thus may prefer selecting a sub-optimal intra-area path or, conversely, may prefer to use a shortest path, even if it crosses areas.
除了[RFC4657]中指定的路径约束外，请求消息必须允许指示是否允许区域交叉。实际上，当源和目的地位于同一IGP区域中时，可能存在区域内和区域间可行路径。如[RFC4105]中所述，如果最短路径是区域间路径，则操作员可能希望尽可能避免交叉区域，因此可能倾向于选择次优区域内路径，或者相反，可能倾向于使用最短路径，即使它交叉区域。
Also, when the source and destination reside in the same area it may be useful to know whether the returned path is an inter-area path. Hence, the response message MUST allow indicating whether the computed path is crossing areas.
此外，当源和目标位于同一区域时，了解返回的路径是否为区域间路径可能很有用。因此，响应消息必须允许指示计算的路径是否跨越区域。
It may be useful for the PCC to know the set of areas crossed by an inter-area path and the corresponding path segments. Hence, the response message MUST allow identifying the crossed areas. Also, the response message MUST allow segmenting the returned path and marking each segment so that it is possible to tell which piece of the path lies within which area.
对于PCC来说，了解由区域间路径和相应的路径段交叉的区域集合可能是有用的。因此，响应消息必须允许识别交叉区域。此外，响应消息必须允许对返回的路径进行分段并标记每个分段，以便能够分辨路径的哪一部分位于哪个区域内。
A Strict Explicit Path is defined as a set of strict hops, while a Loose Path is defined as a set of at least one loose hop and zero, one or more strict hops. An inter-area path may be strictly explicit or loose (e.g., a list of ABRs as loose hops). It may be useful to indicate to the PCE if a Strict Explicit path is required or not. Hence, the PCECP request message MUST allow indicating whether a Strict Explicit Path is required/desired.
严格显式路径定义为一组严格跃点，而松散路径定义为至少一个松散跃点和零个、一个或多个严格跃点的集合。区域间路径可以是严格明确的或松散的（例如，作为松散跳的abr列表）。向PCE指示是否需要严格的显式路径可能很有用。因此，PCECP请求消息必须允许指示是否需要/需要严格的显式路径。
In case of multiple-PCE inter-area path computation, a PCC may want to indicate a preferred list of PCEs to be used, one per area. In each area, the preferred PCE should be tried before another PCE is selected. Note that if there is no preferred PCE indicated for an area, any PCE in that area may be used.
在多个PCE区域间路径计算的情况下，PCC可能希望指示要使用的PCE的优选列表，每个区域一个。在每个区域，应先试用首选PCE，然后再选择另一个PCE。请注意，如果没有为某个区域指定首选PCE，则可以使用该区域中的任何PCE。
Hence, the PCECP request message MUST support the inclusion of a list of preferred PCEs per area. Note that this requires that a PCC in one area has knowledge of PCEs in other areas. This could rely on configuration or on a PCE discovery mechanism, allowing discovery across area boundaries (see [RFC4674]).
因此，PCECP请求消息必须支持包含每个区域的首选PCE列表。请注意，这要求一个地区的PCC了解其他地区的PCE。这可能依赖于配置或PCE发现机制，允许跨区域边界进行发现（请参见[RFC4674]）。
Also, it would be useful to know the list of PCEs that effectively participated in the computation. Hence, the request message MUST support a request for PCE recording, and the response message MUST support the recording of the set of one or more PCEs that took part in the computation.
此外，了解有效参与计算的PCE名单也很有用。因此，请求消息必须支持PCE记录请求，响应消息必须支持记录参与计算的一组或多个PCE。
It may also be useful to know the path segments computed by each PCE. Hence, the request message SHOULD allow a request for the identification of path segments computed by a PCE, and the response message SHOULD allow identifying the path segments computed by each PCE.
了解每个PCE计算的路径段也可能有用。因此，请求消息应允许识别由PCE计算的路径段的请求，并且响应消息应允许识别由每个PCE计算的路径段。
Knowledge of the areas in which the source and destination lie would allow a PCE to select an appropriate downstream PCE. This would be useful when the area ID(s) of a PCE (i.e., the area(s) where it has visibility) is/are known, which can be achieved by the PCE Discovery Protocol (see [RFC4674]) or by any other means.
了解来源和目的地所在的区域将允许PCE选择适当的下游PCE。当PCE的区域ID（即具有可见性的区域）已知时，这将非常有用，可通过PCE发现协议（参见[RFC4674]）或任何其他方式实现。
A PCE may not have any visibility of the source/destination area and hence may not be able to determine the area of the source/destination. In such a situation, it would be useful for a PCC to indicate the source and destination area IDs in its request message.
PCE可能对源/目的地区域没有任何可见性，因此可能无法确定源/目的地的区域。在这种情况下，PCC在其请求消息中指示源和目标区域ID将非常有用。
For that purpose, the request message MUST support the inclusion of the source and destination area IDs. Note that this information could be learned by the PCC through configuration.
为此，请求消息必须支持包含源和目标区域ID。请注意，PCC可通过配置了解此信息。
In some situations, it may be useful for the request message to indicate one or more area(s) that must be followed by the path to be computed. It may also be useful for the request message to indicate one or more area(s) that must be avoided by the path to be computed (e.g., request for a path between LSRs in two stub areas connected to the same ABR(s), which must not cross the backbone area). Hence, the request message MUST allow indicating a set of one or more area(s) that must be explicitly included in the path, and a set of one or more area(s) that must be explicitly excluded from the path.
在某些情况下，请求消息指示一个或多个必须跟随要计算的路径的区域可能很有用。对于请求消息来说，指示一个或多个必须由要计算的路径避免的区域也是有用的（例如，请求连接到相同ABR的两个存根区域中的lsr之间的路径，其不得穿过主干区域）。因此，请求消息必须允许指示一组必须显式包含在路径中的一个或多个区域，以及一组必须显式排除在路径之外的一个或多个区域。
For various reasons, including protection and load balancing, the computation of diverse inter-area paths may be required. There are various levels of diversity in an inter-area context:
出于各种原因，包括保护和负载平衡，可能需要计算不同的区域间路径。区域间环境中存在不同程度的多样性：
- Per-area diversity (intra-area path segments are link, node, or SRLG disjoint)
- 每区域分集（区域内路径段为链路、节点或SRLG不相交）
- Inter-area diversity (end-to-end inter-area paths are link, node, or SRLG disjoint)
- 区域间分集（端到端区域间路径为链路、节点或SRLG不相交）
Note that two paths may be disjoint in the backbone area but non-disjoint in peripheral areas. Also two paths may be node-disjoint within areas but may share ABRs, in which case path segments within an area are node-disjoint, but end-to-end paths are not node disjoint.
注意，两条路径在主干区域可能不相交，但在外围区域可能不相交。另外，两条路径在区域内可以是节点不相交的，但是可以共享abr，在这种情况下，区域内的路径段是节点不相交的，但是端到端路径不是节点不相交的。
The request message MUST allow requesting the computation of a set of inter-area diverse paths between the same node pair or between distinct node pairs. It MUST allow indicating the required level of diversity of a set of inter-area paths (link, node, and SRLG diversity), as well as the required level of diversity of a set of intra-area segments of inter-area paths (link, node, and SRLG diversity) on a per-area basis.
请求消息必须允许请求计算同一节点对之间或不同节点对之间的一组区域间不同路径。它必须允许在每个区域的基础上指示一组区域间路径（链路、节点和SRLG多样性）的所需多样性水平，以及一组区域间路径（链路、节点和SRLG多样性）的区域内段的所需多样性水平。
The response message MUST allow indicating the level of diversity of a set of computed inter-area loose paths (link, node, and SRLG diversity), globally, and on a per-area basis (link, node, and SRLG diversity of intra-area path segments).
响应消息必须允许指示一组计算的区域间松散路径（链路、节点和SRLG多样性）的多样性水平，全局和每个区域（区域内路径段的链路、节点和SRLG多样性）。
Note that, in order to ensure SRLG consistency, SRLG identifiers within the IGP domain should be assigned and allocated by the same entity.
注意，为了确保SRLG一致性，IGP域内的SRLG标识符应由同一实体分配。
Note that specific objective functions may be requested for diverse path computation, such as minimizing the cumulated cost of a set of diverse paths as set forth in [RFC4657].
注意，对于不同路径的计算，可能需要特定的目标函数，例如最小化[RFC4657]中规定的一组不同路径的累积成本。
In addition to the policy requirements discussed in [RFC4657], the application of inter-area path computation policies requires some additional information to be carried in the PCECP request messages. The request message MUST allow for the inclusion of the address of the originating PCC. This may be useful in a multiple-PCE computation, so as to apply policies not only based on the PCECP peer but also based on the originating PCC.
除了[RFC4657]中讨论的策略要求外，应用区域间路径计算策略需要在PCECP请求消息中携带一些附加信息。请求消息必须允许包含发起PCC的地址。这在多PCE计算中可能有用，以便不仅基于PCECP对等方而且基于发起PCC应用策略。
Note that work on supported policy models and the corresponding requirements/implications is being undertaken as a separate work item in the PCE working group [PCE-POL-FMWK].
请注意，关于支持的政策模型和相应要求/影响的工作正在PCE工作组[PCE-POL-FMWK]中作为一个单独的工作项目进行。
In case of multiple-PCE inter-area path computation, there may be risks of PCECP request loops. A mechanism MUST be defined to detect and correct PCECP request message loops. This may rely, for instance, on the recording, in the request message, of the set of traversed PCEs.
在多个PCE区域间路径计算的情况下，可能存在PCECP请求循环的风险。必须定义一种机制来检测和纠正PCECP请求消息循环。例如，这可以依赖于在请求消息中记录所遍历pce的集合。
Also, the returned path in a response message MUST be loop free.
此外，响应消息中返回的路径必须是无循环的。
The inter-area application implies some new manageability requirements in addition to those already listed in [RFC4657]. The PCECP PCC and PCE MIB modules MUST allow recording the proportion of inter-area requests and the success rate of inter-area requests. The PCECP PCC MIB module MUST also allow recording the performances of a PCE chain (minimum, maximum, and average response times), in case of multiple-PCE inter-area path computation.
除[RFC4657]中已列出的要求外，区域间应用程序还包含一些新的可管理性要求。PCECP PCC和PCE MIB模块必须允许记录区域间请求的比例和区域间请求的成功率。PCECP PCC MIB模块还必须允许在多个PCE区域间路径计算的情况下记录PCE链的性能（最小、最大和平均响应时间）。
It is really important, for diagnostic and troubleshooting reasons, to monitor the availability and performances of each PCE of a PCE chain used for inter-area path computation. Particularly, it is really important to identify the PCE(s) responsible for a delayed reply.
出于诊断和故障排除的原因，监控用于区域间路径计算的PCE链的每个PCE的可用性和性能非常重要。尤其重要的是，确定哪些PCE对延迟回复负责。
Hence, a mechanism MUST be defined to monitor the performances of a PCE chain. It MUST allow determining the availability of each PCE of the chain as well as its minimum, maximum, and average response times.
因此，必须定义一种机制来监控PCE链的性能。它必须允许确定链中每个PCE的可用性及其最小、最大和平均响应时间。
IGP areas are administrated by the same entity. Hence, the inter-area application does not imply a new trust model or new security issues beyond those already defined in [RFC4657].
IGP区域由同一实体管理。因此，区域间应用程序并不意味着新的信任模型或[RFC4657]中已经定义的安全问题之外的新安全问题。
We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, Bruno Decraene, Yannick Le Louedec, Dimitri Papadimitriou, and Lou Berger for their useful comments and suggestions. Thanks also to Ross Callon, Catherine Meadow, and Dan Romascanu for their review during the final stages of publication.
我们还要感谢阿德里安·法雷尔、让·菲利普·瓦修尔、布鲁诺·德雷恩、扬尼克·勒卢埃代克、迪米特里·帕帕迪米特里欧和卢·伯杰提出了有益的意见和建议。还要感谢罗斯·卡隆、凯瑟琳·梅多和丹·罗马斯卡努在出版的最后阶段所作的评论。
[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月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Ed.，Vasseur，J.-P.，Ed.，和J.Boyle，Ed.，“区域间MPLS流量工程的要求”，RFC 4105，2005年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月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]Le Roux，J.，编辑，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
[PD-COMP] Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", Work in Progress, April 2007.
[PD-COMP]Vasseur，J.P.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“计算域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，正在进行的工作，2007年4月。
[PCE-POL-FMWK] Bryskin, I., Papadimitriou, D., Berger L., and J. Ash, "Policy-Enabled Path Computation Framework", Work in Progress, March 2007.
[PCE-POL-FMWK]Bryskin，I.，Papadimitriou，D.，Berger L.，和J.Ash，“策略支持的路径计算框架”，正在进行的工作，2007年3月。
[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[RFC3785]Le Faucheur，F.，Uppili，R.，Vedrene，A.，Merckx，P.，和T.Telkamp，“内部网关协议（IGP）度量作为第二个MPLS流量工程（TE）度量的使用”，BCP 87，RFC 3785，2004年5月。
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 EMail: gash5107@yahoo.com
Jerry Ash AT&T室MT D5-2A01美国新泽西州劳雷尔大道中城200号，邮编07748电话：+1-（732）-420-4578电子邮件：gash5107@yahoo.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon马萨诸塞州沃尔瑟姆Sylvan路40号02145电子邮件：Nabil.n。bitar@verizon.com
Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose, CA 95134 USA Phone: +1 408 527 0677 EMail: dcheng@cisco.com
Dean Cheng Cisco Systems Inc.美国加利福尼亚州圣何塞市思科路3700号电话：+1 408 527 0677电子邮件：dcheng@cisco.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 EMail: ke-kumaki@kddi.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi，Chiyoda ku，东京102-8460，日本电话：+81-3-6678-3103电子邮件：ke-kumaki@kddi.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN EMail: oki.eiji@lab.ntt.co.jp
日本东京武藏野史3-9-11，180-8585，邮编：Oki。eiji@lab.ntt.co.jp
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: raymond.zhang@bt.com
雷蒙德张BT 2160东大大道埃尔塞贡多，加利福尼亚州90245美国电子邮件：雷蒙德。zhang@bt.com
Renhai Zhang Huawei Technologies No. 3 Xinxi Road, Shangdi, Haidian District, Beijing City, P. R. China EMail: zhangrenhai@huawei.com
中国北京市海淀区上地新西路3号仁海张华为技术有限公司电子邮件：zhangrenhai@huawei.com
Editor's Address
编辑地址
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：jeanlouis。leroux@orange-ftgroup.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。