Internet Engineering Task Force (IETF) D. King, Ed.
Request for Comments: 6805 A. Farrel, Ed.
Category: Informational Old Dog Consulting
ISSN: 2070-1721 November 2012
Internet Engineering Task Force (IETF) D. King, Ed.
Request for Comments: 6805 A. Farrel, Ed.
Category: Informational Old Dog Consulting
ISSN: 2070-1721 November 2012
The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS
路径计算元素体系结构在MPLS和GMPLS域序列确定中的应用
Abstract
摘要
Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.
在MPLS流量工程（MPLS-TE）和GMPLS网络中，计算跨多个域的标签交换路径（LSP）的最佳路由是一个问题，因为没有一个路径计算点知道每个域中的所有链路和资源。可以使用路径计算元件（PCE）架构来实现解决方案。
Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.
在已知域序列的情况下，可以使用各种技术来推导最佳路径。如果域是简单连接的，或者如果互连的优选点也是已知的，则可以使用每域路径计算技术。如果域之间存在多个连接，并且没有优先选择互连点，则可以使用基于PCE的反向递归计算（BRPC）程序来推导最佳路径。
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains.
本文档研究了在域序列未知时建立最佳路径的技术。本文档展示了如何扩展PCE体系结构，以允许选择最佳的域序列，并通过使用域之间的层次关系导出最佳的端到端路径。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6805.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6805.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Problem Statement ..........................................5
1.2. Definition of a Domain .....................................5
1.3. Assumptions and Requirements ...............................6
1.3.1. Metric Objectives ...................................6
1.3.2. Diversity ...........................................7
1.3.2.1. Physical Diversity .........................7
1.3.2.2. Domain Diversity ...........................7
1.3.3. Existing Traffic Engineering Constraints ............7
1.3.4. Commercial Constraints ..............................8
1.3.5. Domain Confidentiality ..............................8
1.3.6. Limiting Information Aggregation ....................8
1.3.7. Domain Interconnection Discovery ....................8
1.4. Terminology ................................................8
2. Examination of Existing PCE Mechanisms ..........................9
2.1. Per-Domain Path Computation ................................9
2.2. Backward-Recursive PCE-Based Computation ..................10
2.2.1. Applicability of BRPC When the Domain Path
is Not Known .......................................11
3. Hierarchical PCE ...............................................12
4. Hierarchical PCE Procedures ....................................13
4.1. Objective Functions and Policy ............................13
4.2. Maintaining Domain Confidentiality ........................14
4.3. PCE Discovery .............................................14
4.4. Traffic Engineering Database for the Parent Domain ........15
4.5. Determination of Destination Domain .......................16
4.6. Hierarchical PCE Examples .................................16
1. Introduction ....................................................4
1.1. Problem Statement ..........................................5
1.2. Definition of a Domain .....................................5
1.3. Assumptions and Requirements ...............................6
1.3.1. Metric Objectives ...................................6
1.3.2. Diversity ...........................................7
1.3.2.1. Physical Diversity .........................7
1.3.2.2. Domain Diversity ...........................7
1.3.3. Existing Traffic Engineering Constraints ............7
1.3.4. Commercial Constraints ..............................8
1.3.5. Domain Confidentiality ..............................8
1.3.6. Limiting Information Aggregation ....................8
1.3.7. Domain Interconnection Discovery ....................8
1.4. Terminology ................................................8
2. Examination of Existing PCE Mechanisms ..........................9
2.1. Per-Domain Path Computation ................................9
2.2. Backward-Recursive PCE-Based Computation ..................10
2.2.1. Applicability of BRPC When the Domain Path
is Not Known .......................................11
3. Hierarchical PCE ...............................................12
4. Hierarchical PCE Procedures ....................................13
4.1. Objective Functions and Policy ............................13
4.2. Maintaining Domain Confidentiality ........................14
4.3. PCE Discovery .............................................14
4.4. Traffic Engineering Database for the Parent Domain ........15
4.5. Determination of Destination Domain .......................16
4.6. Hierarchical PCE Examples .................................16
4.6.1. Hierarchical PCE Initial Information Exchange ......18
4.6.2. Hierarchical PCE End-to-End Path
Computation Procedure ..............................19
4.7. Hierarchical PCE Error Handling ...........................20
4.8. Requirements for Hierarchical PCEP Protocol Extensions ....20
4.8.1. PCEP Request Qualifiers ............................21
4.8.2. Indication of Hierarchical PCE Capability ..........21
4.8.3. Intention to Utilize Parent PCE Capabilities .......21
4.8.4. Communication of Domain Connectivity Information ...22
4.8.5. Domain Identifiers .................................22
5. Hierarchical PCE Applicability .................................23
5.1. Autonomous Systems and Areas ..............................23
5.2. ASON Architecture .........................................24
5.2.1. Implicit Consistency between Hierarchical
PCE and G.7715.2 ...................................25
5.2.2. Benefits of Hierarchical PCEs in ASON ..............26
6. A Note on BGP-TE ...............................................26
6.1. Use of BGP for TED Synchronization ........................27
7. Management Considerations ......................................27
7.1. Control of Function and Policy ............................27
7.1.1. Child PCE ..........................................27
7.1.2. Parent PCE .........................................27
7.1.3. Policy Control .....................................28
7.2. Information and Data Models ...............................28
7.3. Liveness Detection and Monitoring .........................28
7.4. Verifying Correct Operation ...............................28
7.5. Impact on Network Operation ...............................29
8. Security Considerations ........................................29
9. Acknowledgements ...............................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
11. Contributors ..................................................32
4.6.1. Hierarchical PCE Initial Information Exchange ......18
4.6.2. Hierarchical PCE End-to-End Path
Computation Procedure ..............................19
4.7. Hierarchical PCE Error Handling ...........................20
4.8. Requirements for Hierarchical PCEP Protocol Extensions ....20
4.8.1. PCEP Request Qualifiers ............................21
4.8.2. Indication of Hierarchical PCE Capability ..........21
4.8.3. Intention to Utilize Parent PCE Capabilities .......21
4.8.4. Communication of Domain Connectivity Information ...22
4.8.5. Domain Identifiers .................................22
5. Hierarchical PCE Applicability .................................23
5.1. Autonomous Systems and Areas ..............................23
5.2. ASON Architecture .........................................24
5.2.1. Implicit Consistency between Hierarchical
PCE and G.7715.2 ...................................25
5.2.2. Benefits of Hierarchical PCEs in ASON ..............26
6. A Note on BGP-TE ...............................................26
6.1. Use of BGP for TED Synchronization ........................27
7. Management Considerations ......................................27
7.1. Control of Function and Policy ............................27
7.1.1. Child PCE ..........................................27
7.1.2. Parent PCE .........................................27
7.1.3. Policy Control .....................................28
7.2. Information and Data Models ...............................28
7.3. Liveness Detection and Monitoring .........................28
7.4. Verifying Correct Operation ...............................28
7.5. Impact on Network Operation ...............................29
8. Security Considerations ........................................29
9. Acknowledgements ...............................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
11. Contributors ..................................................32
The capability to compute the routes of end-to-end inter-domain MPLS Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) is expressed as requirements in [RFC4105] and [RFC4216]. This capability may be realized by a Path Computation Element (PCE). The PCE architecture is defined in [RFC4655]. The methods for establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in [RFC4726].
计算端到端域间MPLS流量工程（MPLS-TE）和GMPLS标签交换路径（LSP）路由的能力在[RFC4105]和[RFC4216]中表示为要求。该能力可通过路径计算元件（PCE）实现。PCE架构在[RFC4655]中定义。[RFC4726]中记录了建立和控制域间MPLS-TE和GMPLS LSP的方法。
In this context, a domain can be defined as a separate administrative, geographic, or switching environment within the network. A domain may be further defined as a zone of routing or computational ability. Under these definitions, a domain might be categorized as an Autonomous System (AS) or an Interior Gateway Protocol (IGP) area [RFC4726] [RFC4655]. Domains are connected through ingress and egress boundary nodes (BNs). A more detailed definition is given in Section 1.2.
在这种情况下，域可以定义为网络中单独的管理、地理或交换环境。域可以进一步定义为路由或计算能力区域。根据这些定义，域可能被分类为自治系统（as）或内部网关协议（IGP）区域[RFC4726][RFC4655]。域通过入口和出口边界节点（BN）连接。第1.2节给出了更详细的定义。
In a multi-domain environment, the determination of an end-to-end traffic engineered path is a problem because no single point of path computation is aware of all of the links and resources in each domain. PCEs can be used to compute end-to-end paths using a per-domain path computation technique [RFC5152]. Alternatively, the Backward-Recursive PCE-based Computation (BRPC) mechanism [RFC5441] allows multiple PCEs to collaborate in order to select an optimal end-to-end path that crosses multiple domains. Both mechanisms assume that the sequence of domains to be crossed between ingress and egress is known in advance.
在多域环境中，端到端流量工程路径的确定是一个问题，因为没有单个路径计算点知道每个域中的所有链路和资源。PCE可用于使用每域路径计算技术计算端到端路径[RFC5152]。或者，基于PCE的反向递归计算（BRPC）机制[RFC5441]允许多个PCE协作，以选择跨多个域的最佳端到端路径。这两种机制都假设入口和出口之间要交叉的域序列是预先已知的。
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. It shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived.
本文档研究了在域序列未知时建立最佳路径的技术。它展示了如何扩展PCE体系结构，以允许选择最佳的域序列，并导出最佳的端到端路径。
The model described in this document introduces a hierarchical relationship between domains. It is applicable to environments with small groups of domains where visibility from the ingress Label Switching Router (LSR) is limited. Applying the hierarchical PCE model to large groups of domains such as the Internet, is not considered feasible or desirable, and is out of scope for this document.
本文档中描述的模型引入了域之间的层次关系。它适用于入口标签交换路由器（LSR）可视性有限的域组较小的环境。将分层PCE模型应用于大型领域组（如互联网）被认为是不可行或不可取的，并且超出了本文档的范围。
This document does not specify any protocol extensions or enhancements. That work is left for future protocol specification documents. However, some assumptions are made about which protocols will be used to provide specific functions, and guidelines to future protocol developers are made in the form of requirements statements.
本文档未指定任何协议扩展或增强。这项工作留给未来的协议规范文档。然而，对于将使用哪些协议来提供特定功能，我们做出了一些假设，并以需求声明的形式为未来的协议开发人员提供了指导。
Using a PCE to compute a path between nodes within a single domain is relatively straightforward. Computing an end-to-end path when the source and destination nodes are located in different domains requires co-operation between multiple PCEs, each responsible for its own domain.
使用PCE计算单个域内节点之间的路径相对简单。当源节点和目标节点位于不同的域中时，计算端到端路径需要多个pce之间的合作，每个pce负责自己的域。
Techniques for inter-domain path computation described so far ([RFC5152] and [RFC5441]) assume that the sequence of domains to be crossed from source to destination is well known. No explanation is given (for example, in [RFC4655]) of how this sequence is generated or what criteria may be used for the selection of paths between domains. In small clusters of domains, such as simple cooperation between adjacent ISPs, this selection process is not complex. In more advanced deployments (such as optical networks constructed from multiple sub-domains, or in multi-AS environments), the choice of domains in the end-to-end domain sequence can be critical to the determination of an optimum end-to-end path.
到目前为止描述的域间路径计算技术（[RFC5152]和[RFC5441]）假设要从源到目的地交叉的域序列是众所周知的。没有解释（例如，[RFC4655]）该序列是如何生成的，或者域之间的路径选择可以使用什么标准。在域的小型集群中，例如相邻ISP之间的简单合作，此选择过程并不复杂。在更高级的部署中（如由多个子域构造的光网络，或在多as环境中），端到端域序列中域的选择对于确定最佳端到端路径至关重要。
A domain is defined in [RFC4726] as any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Wholly or partially overlapping domains are not within the scope of this document.
[RFC4726]将域定义为地址管理或路径计算责任公共范围内的任何网络元素集合。此类域的示例包括IGP区域和自治系统。全部或部分重叠的域不在本文档的范围内。
In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork
[G-8080]. In this case, a domain might be an ASON Routing Area
[G-7715]. Furthermore, computation of an end-to-end path requires
the selection of nodes and links within a routing area where some
nodes may, in fact, be subnetworks. A PCE may perform the path
computation function of an ASON Routing Controller as described in
[G-7715-2]. See Section 5.2 for a further discussion of the
applicability to the ASON architecture.
In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork
[G-8080]. In this case, a domain might be an ASON Routing Area
[G-7715]. Furthermore, computation of an end-to-end path requires
the selection of nodes and links within a routing area where some
nodes may, in fact, be subnetworks. A PCE may perform the path
computation function of an ASON Routing Controller as described in
[G-7715-2]. See Section 5.2 for a further discussion of the
applicability to the ASON architecture.
This document assumes that the selection of a sequence of domains for an end-to-end path is in some sense a hierarchical path computation problem. That is, where one mechanism is used to determine a path across a domain, a separate mechanism (or at least a separate set of
本文假设端到端路径的域序列选择在某种意义上是一个层次路径计算问题。也就是说，其中一个机制用于确定跨域的路径，一个单独的机制（或至少一组单独的
paradigms) is used to determine the sequence of domains. The responsibility for the selection of domain interconnection can belong to either or both of the mechanisms.
范例）用于确定域的顺序。选择域互连的责任可以属于这两种机制中的一种或两种。
Networks are often constructed from multiple domains. These domains are often interconnected via multiple interconnect points. It's assumed that the sequence of domains for an end-to-end path is not always well known; that is, an application requesting end-to-end connectivity has no preference for, or no ability to specify, the sequence of domains to be crossed by the path.
网络通常由多个域构成。这些域通常通过多个互连点互连。假设端到端路径的域序列并不总是众所周知；也就是说，请求端到端连接的应用程序对路径要跨越的域序列没有偏好，或者无法指定。
The traffic engineering properties of a domain cannot be seen from outside the domain. Traffic engineering aggregation or abstraction, hides information and can lead to failed path setup or the selection of suboptimal end-to-end paths [RFC4726]. The aggregation process may also have significant scaling issues for networks with many possible routes and multiple TE metrics. Flooding TE information breaks confidentiality and does not scale in the routing protocol. See Section 6 for a discussion of the concept of inter-domain traffic engineering information exchange known as BGP-TE.
无法从域外部查看域的流量工程属性。流量工程聚合或抽象，隐藏信息，可能导致路径设置失败或选择次优端到端路径[RFC4726]。对于具有许多可能路由和多个TE度量的网络，聚合过程也可能存在重大的扩展问题。淹没TE信息会破坏机密性，并且不会在路由协议中扩展。关于域间流量工程信息交换（称为BGP-TE）概念的讨论，请参见第6节。
The primary goal of this document is to define how to derive optimal end-to-end, multi-domain paths when the sequence of domains is not known in advance. The solution needs to be scalable and to maintain internal domain topology confidentiality while providing the optimal end-to-end path. It cannot rely on the exchange of TE information between domains, and for the confidentiality, scaling, and aggregation reasons just cited, it cannot utilize a computation element that has universal knowledge of TE properties and topology of all domains.
本文档的主要目标是定义当域序列事先未知时，如何导出最佳的端到端多域路径。该解决方案需要具有可扩展性，并在提供最佳端到端路径的同时保持内部域拓扑的机密性。它不能依赖域之间TE信息的交换，并且出于刚才提到的机密性、可伸缩性和聚合性原因，它不能利用对所有域的TE属性和拓扑具有普遍知识的计算元素。
The sub-sections that follow set out the primary objectives and requirements to be satisfied by a PCE solution to multi-domain path computation.
接下来的小节列出了多域路径计算的PCE解决方案需要满足的主要目标和要求。
The definition of optimality is dependent on policy and is based on a single objective or a group of objectives. An objective is expressed as an objective function [RFC5541] and may be specified on a path computation request. The following objective functions are identified in this document. They define how the path metrics and TE link qualities are manipulated during inter-domain path computation. The list is not proscriptive and may be expanded in other documents.
最优性的定义取决于政策，并基于单个目标或一组目标。目标表示为目标函数[RFC5541]，可在路径计算请求中指定。本文件确定了以下目标功能。它们定义了域间路径计算期间如何操作路径度量和TE链路质量。该清单不是禁止性的，可以在其他文件中扩展。
o Minimize the cost of the path [RFC5541]. o Select a path using links with the minimal load [RFC5541]. o Select a path that leaves the maximum residual bandwidth [RFC5541]. o Minimize aggregate bandwidth consumption [RFC5541]. o Minimize the load of the most loaded link [RFC5541]. o Minimize the cumulative cost of a set of paths [RFC5541]. o Minimize or cap the number of domains crossed. o Disallow domain re-entry.
o 最小化路径的成本[RFC5541]。o使用负载最小的链接选择路径[RFC5541]。o选择保留最大剩余带宽的路径[RFC5541]。o最小化总带宽消耗[RFC5541]。o最小化负载最大的链路的负载[RFC5541]。o最小化一组路径的累积成本[RFC5541]。o最小化或限制交叉域的数量。o不允许域重新进入。
See Section 4.1 for further discussion of objective functions.
有关目标函数的进一步讨论，请参见第4.1节。
Within a "Carrier's Carrier" environment, MPLS services may share common underlying equipment and resources, including optical fiber and nodes. An MPLS service request may require a path for traffic that is physically disjointed from another service. Thus, if a physical link or node fails on one of the disjoint paths, not all traffic is lost.
在“运营商的运营商”环境中，MPLS服务可以共享公共底层设备和资源，包括光纤和节点。MPLS服务请求可能需要物理上与另一服务分离的流量路径。因此，如果物理链路或节点在其中一条不相交的路径上发生故障，则并非所有通信量都会丢失。
A pair of paths are domain-diverse if they do not transit any of the same domains. A pair of paths that share a common ingress and egress are domain-diverse if they only share the same domains at the ingress and egress (the ingress and egress domains). Domain diversity may be maximized for a pair of paths by selecting paths that have the smallest number of shared domains. (Note that this is not the same as finding paths with the greatest number of distinct domains!)
如果一对路径不通过任何相同的域，则它们是不同的域。共享公共入口和出口的一对路径如果在入口和出口（入口和出口域）处仅共享相同的域，则它们是域多样的。通过选择具有最小数量的共享域的路径，可以最大化一对路径的域多样性。（请注意，这与查找具有最多不同域的路径不同！）
Path computation should facilitate the selection of paths that share ingress and egress domains but do not share any transit domains. This provides a way to reduce the risk of shared failure along any path and automatically helps to ensure path diversity for most of the route of a pair of LSPs.
路径计算应有助于选择共享入口和出口域但不共享任何传输域的路径。这提供了一种降低沿任何路径共享故障风险的方法，并自动帮助确保一对LSP的大部分路由的路径多样性。
Thus, domain path selection should provide the capability to include or exclude specific domains and specific boundary nodes.
因此，域路径选择应提供包含或排除特定域和特定边界节点的能力。
Any solution should take advantage of typical traffic engineering constraints (hop count, bandwidth, lambda continuity, path cost, etc.) to meet the service demands expressed in the path computation request [RFC4655].
任何解决方案都应利用典型的流量工程约束（跳数、带宽、lambda连续性、路径成本等），以满足路径计算请求[RFC4655]中表示的服务需求。
The solution should provide the capability to include commercially relevant constraints such as policy, Service Level Agreements (SLAs), security, peering preferences, and monetary costs.
该解决方案应提供包含商业相关约束的能力，如策略、服务级别协议（SLA）、安全性、对等首选项和货币成本。
Additionally, it may be necessary for the service provider to request that specific domains are included or excluded based on commercial relationships, security implications, and reliability.
此外，服务提供商可能需要基于商业关系、安全含义和可靠性请求包括或排除特定域。
A key requirement is the ability to maintain domain confidentiality when computing inter-domain end-to-end paths. It should be possible for local policy to require that a PCE not disclose to any other PCE the intra-domain paths it computes or the internal topology of the domain it serves. This requirement should have no impact in the optimality or quality of the end-to-end path that is derived.
关键要求是在计算域间端到端路径时保持域机密性的能力。本地策略应该可以要求PCE不向任何其他PCE披露其计算的域内路径或其服务的域的内部拓扑。此要求不应影响所导出的端到端路径的最佳性或质量。
In order to reduce processing overhead and to not sacrifice computational detail, there should be no requirement to aggregate or abstract traffic engineering link information.
为了减少处理开销并且不牺牲计算细节，不应该要求聚合或抽象流量工程链路信息。
To support domain mesh topologies, the solution should allow the discovery and selection of domain interconnections. Pre-configuration of preferred domain interconnections should also be supported for network operators that have bilateral agreement and have a preference for the choice of points of interconnection.
为了支持域网状拓扑，解决方案应允许发现和选择域互连。对于具有双边协议且优先选择互连点的网络运营商，也应支持首选域互连的预配置。
This document uses PCE terminology defined in [RFC4655], [RFC4726], and [RFC5440]. Additional terms are defined below.
本文件使用[RFC4655]、[RFC4726]和[RFC5440]中定义的PCE术语。其他术语定义如下。
Domain Path: The sequence of domains for a path.
域路径：路径的域序列。
Ingress Domain: The domain that includes the ingress LSR of a path.
入口域：包含路径入口LSR的域。
Transit Domain: A domain that has an upstream and downstream neighbor domain for a specific path.
传输域：具有特定路径的上游和下游邻居域的域。
Egress Domain: The domain that includes the egress LSR of a path.
出口域：包含路径出口LSR的域。
Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could be Area Border Routers (ABRs) or Autonomous System Border Routers (ASBRs) depending on the type of domain. They are defined here more generically as Boundary Nodes (BNs).
边界节点：每个域都有入口LSR和出口LSR，根据域的类型可以是区域边界路由器（ABR）或自治系统边界路由器（ASBR）。它们在这里更一般地定义为边界节点（BN）。
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a path.
域（n）的条目BN：在路径上将域（n-1）连接到域（n）的BN。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a path.
域（n）的出口BN：在路径上将域（n）连接到域（n+1）的BN。
Parent Domain: A domain higher up in a domain hierarchy such that it contains other domains (child domains) and potentially other links and nodes.
父域：域层次结构中较高的域，它包含其他域（子域）以及潜在的其他链接和节点。
Child Domain: A domain lower in a domain hierarchy such that it has a parent domain.
子域：域层次结构中较低的一个域，它有一个父域。
Parent PCE: A PCE responsible for selecting a path across a parent domain and any number of child domains by coordinating with child PCEs and examining a topology map that shows domain inter-connectivity.
父PCE：通过与子PCE协调并检查显示域间连接的拓扑图，负责选择父域和任意数量子域之间的路径的PCE。
Child PCE: A PCE responsible for computing the path across one or more specific (child) domains. A child PCE maintains a relationship with at least one parent PCE.
子PCE：负责计算一个或多个特定（子）域的路径的PCE。子PCE与至少一个父PCE保持关系。
Objective Function (OF): A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization), or the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization). See [RFC4655] and [RFC5541].
目标函数（OF）：用于计算单个路径（例如，路径成本最小化）或同步计算一组路径（例如，总带宽消耗最小化）的一组或多个优化标准。参见[RFC4655]和[RFC5541]。
This section provides a brief overview of two existing PCE cooperation mechanisms called the Per-Domain Path Computation method and the BRPC method. It describes the applicability of these methods to the multi-domain problem.
本节简要概述了两种现有的PCE协作机制，即每域路径计算方法和BRPC方法。它描述了这些方法对多领域问题的适用性。
The Per-Domain Path Computation method for establishing inter-domain TE-LSPs [RFC5152] defines a technique whereby the path is computed during the signaling process on a per-domain basis. The entry BN of each domain is responsible for performing the path computation for the section of the LSP that crosses the domain, or for requesting that a PCE for that domain computes that piece of the path.
用于建立域间TE lsp的每域路径计算方法[RFC5152]定义了一种技术，其中在信令过程中基于每域计算路径。每个域的条目BN负责为穿过该域的LSP的部分执行路径计算，或者负责请求该域的PCE计算该路径片段。
During per-domain path computation, each computation results in a path that crosses the domain to provide connectivity to the next domain in the sequence. The chosen path across the domain will be selected as best according to the optimization characteristics of the computation. The next domain in the sequence is usually indicated in signaling by an identifier of the next domain or the identity of the next entry BN.
在逐域路径计算过程中，每次计算都会产生一条穿过域的路径，以提供到序列中下一个域的连接。根据计算的优化特性，选择的跨域路径将被选为最佳路径。序列中的下一个域通常在信令中由下一个域的标识符或下一个条目BN的标识指示。
Per-domain path computation may lead to suboptimal end-to-end paths because the most optimal path in one domain may lead to the choice of an entry BN for the next domain that results in a very poor path across that next domain.
每个域路径计算可能会导致次优的端到端路径，因为一个域中的最佳路径可能会导致为下一个域选择条目BN，从而导致下一个域中的路径非常差。
In the case that the domain path (in particular, the sequence of boundary nodes) is not known, the path computing entity must select an exit BN based on some determination of how to reach the destination that is outside the domain for which the path computing entity has computational responsibility. [RFC5152] suggest that this might be achieved using the IP shortest path as advertised by BGP. Note, however, that the existence of an IP forwarding path does not guarantee the presence of sufficient bandwidth, let alone an optimal TE path. Furthermore, in many GMPLS systems, inter-domain IP routing will not be present. Thus, per-domain path computation may require a significant number of crankback routing attempts to establish even a suboptimal path.
在域路径（尤其是边界节点序列）未知的情况下，路径计算实体必须基于如何到达路径计算实体具有计算责任的域之外的目的地的某种确定来选择出口BN。[RFC5152]建议使用BGP公布的IP最短路径来实现这一点。然而，请注意，IP转发路径的存在并不能保证存在足够的带宽，更不用说最佳TE路径了。此外，在许多GMPLS系统中，域间IP路由将不存在。因此，每域路径计算可能需要大量的回退路由尝试来建立甚至次优的路径。
Note also that the path computing entities in each domain may have different computation capabilities, may run different path computation algorithms, and may apply different sets of constraints and optimization criteria, etc.
还要注意，每个域中的路径计算实体可以具有不同的计算能力，可以运行不同的路径计算算法，并且可以应用不同的约束集和优化标准等。
This can result in the end-to-end path being inconsistent and suboptimal.
这可能导致端到端路径不一致和次优。
Per-domain path computation can suit simply connected domains where the preferred points of interconnection are known.
每域路径计算可适用于已知首选互连点的简单连接域。
The Backward-Recursive PCE-based Computation (BRPC) [RFC5441] procedure involves cooperation and communication between PCEs in order to compute an optimal end-to-end path across multiple domains. The sequence of domains to be traversed can be determined either before or during the path computation. In the case where the sequence of domains is known, the ingress Path Computation Client (PCC) sends a path computation request to a PCE responsible for the ingress domain. This request is forwarded between PCEs, domain-by-domain, to a PCE responsible for the egress domain. The PCE in the
基于PCE的反向递归计算（BRPC）[RFC5441]过程涉及PCE之间的协作和通信，以计算跨多个域的最佳端到端路径。要遍历的域序列可以在路径计算之前或期间确定。在域序列已知的情况下，入口路径计算客户端（PCC）向负责入口域的PCE发送路径计算请求。该请求在PCE之间逐域转发给负责出口域的PCE。中的PCE
egress domain creates a set of optimal paths from all of the domain entry BNs to the egress LSR. This set is represented as a tree of potential paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes it back to the previous PCE on the domain path. As the VSPT is passed back toward the ingress domain, each PCE computes the optimal paths from its entry BNs to its exit BNs that connect to the rest of the tree. It adds these paths to the VSPT and passes the VSPT on until the PCE for the ingress domain is reached and computes paths from the ingress LSR to connect to the rest of the tree. The ingress PCE then selects the optimal end-to-end path from the tree, and returns the path to the initiating PCC.
出口域创建从所有域入口BN到出口LSR的一组最佳路径。该集合表示为一个称为虚拟最短路径树（VSPT）的潜在路径树，PCE将其传递回域路径上的前一个PCE。当VSPT传递回入口域时，每个PCE计算从其入口BN到其出口BN的最佳路径，该出口BN连接到树的其余部分。它将这些路径添加到VSPT，并将VSPT传递到上，直到到达入口域的PCE，并计算来自入口LSR的路径以连接到树的其余部分。然后，入口PCE从树中选择最佳端到端路径，并将该路径返回到发起PCC。
BRPC may suit environments where multiple connections exist between domains and there is no preference for the choice of points of interconnection. It is best suited to scenarios where the domain path is known in advance, but it can also be used when the domain path is not known.
BRPC可适用于域之间存在多个连接且不优先选择互连点的环境。它最适合于域路径事先已知的场景，但也可以在域路径未知时使用。
As described above, BRPC can be used to determine an optimal inter-domain path when the domain sequence is known. Even when the sequence of domains is not known, BRPC could be used as follows.
如上所述，当域序列已知时，BRPC可用于确定最佳域间路径。即使域序列未知，也可以按如下方式使用BRPC。
o The PCC sends a request to a PCE for the ingress domain (the ingress PCE).
o PCC向PCE发送入口域（入口PCE）的请求。
o The ingress PCE sends the path computation request direct to a PCE responsible for the domain containing the destination node (the egress PCE).
o 入口PCE将路径计算请求直接发送到负责包含目的地节点的域的PCE（出口PCE）。
o The egress PCE computes an egress VSPT and passes it to a PCE responsible for each of the adjacent (potentially upstream) domains.
o 出口PCE计算出口VSPT并将其传递给负责每个相邻（可能是上游）域的PCE。
o Each PCE in turn constructs a VSPT and passes it on to all of its neighboring PCEs.
o 每个PCE依次构造一个VSPT并将其传递给所有相邻的PCE。
o When the ingress PCE has received a VSPT from each of its neighboring domains, it is able to select the optimum path.
o 当入口PCE从其每个相邻域接收到VSPT时，它能够选择最佳路径。
Clearly, this mechanism (which could be called path computation flooding) has significant scaling issues. It could be improved by the application of policy and filtering, but such mechanisms are not simple and would still leave scaling concerns.
显然，这种机制（可以称为路径计算泛洪）存在重大的缩放问题。它可以通过应用策略和过滤来改进，但这种机制并不简单，仍然会留下规模问题。
In the hierarchical PCE architecture, a parent PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology). The parent PCE has no information about the content of the child domains; that is, the parent PCE does not know about the resource availability within the child domains, nor does it know about the availability of connectivity across each domain because such knowledge would violate the confidentiality requirement and either would require flooding of full information to the parent (scaling issue) or would necessitate some form of aggregation. The parent PCE is aware of the TE capabilities of the interconnections between child domains as these interconnections are links in its own topology map.
在分层PCE体系结构中，父PCE维护一个域拓扑图，其中包含子域（拓扑中的顶点）及其互连（拓扑中的链接）。父PCE没有关于子域内容的信息；也就是说，父PCE不知道子域内的资源可用性，也不知道跨每个域的连接可用性，因为此类知识将违反保密要求，或者需要向父PCE大量提供完整信息（扩展问题）或者需要某种形式的聚合。父PCE知道子域之间互连的TE能力，因为这些互连是其自身拓扑图中的链路。
Note that, in the case that the domains are IGP areas, there is no link between the domains (the ABRs have a presence in both neighboring areas). The parent domain may choose to represent this in its Traffic Engineering Database (TED) as a virtual link that is unconstrained and has zero cost, but this is entirely an implementation issue.
注意，在域是IGP区域的情况下，域之间没有链路（abr在两个相邻区域中都存在）。父域可以选择在其流量工程数据库（TED）中将其表示为无约束且成本为零的虚拟链接，但这完全是一个实现问题。
Each child domain has at least one PCE capable of computing paths across the domain. These PCEs are known as child PCEs and have a relationship with the parent PCE. Each child PCE also knows the identity of the domains that neighbor its own domain. A child PCE only knows the topology of the domain that it serves and does not know the topology of other child domains. Child PCEs are also not aware of the general domain mesh connectivity (i.e., the domain topology map) beyond the connectivity to the immediate neighbor domains of the domain it serves.
每个子域至少有一个能够计算跨域路径的PCE。这些PCE称为子PCE，与父PCE有关系。每个子PCE还知道与其自己的域相邻的域的标识。子PCE只知道它所服务的域的拓扑，而不知道其他子域的拓扑。子PCE也不知道其所服务的域的直接相邻域的连接之外的一般域网格连接（即域拓扑图）。
The parent PCE builds the domain topology map either from configuration or from information received from each child PCE. This tells it how the domains are interconnected including the TE properties of the domain interconnections. But, the parent PCE does not know the contents of the child domains. Discovery of the domain topology and domain interconnections is discussed further in Section 4.3.
父PCE根据配置或从每个子PCE接收的信息构建域拓扑图。这说明域是如何互连的，包括域互连的TE属性。但是，父PCE不知道子域的内容。第4.3节将进一步讨论域拓扑和域互连的发现。
When a multi-domain path is needed, the ingress PCE sends a request to the parent PCE (using the Path Computation Element Protocol, PCEP [RFC5440]). The parent PCE selects a set of candidate domain paths based on the domain topology and the state of the inter-domain links. It then sends computation requests to the child PCEs responsible for each of the domains on the candidate domain paths. These requests may be sequential or parallel depending on implementation details.
当需要多域路径时，入口PCE向父PCE发送请求（使用路径计算元素协议PCEP[RFC5440]）。父PCE基于域拓扑和域间链路的状态选择一组候选域路径。然后，它向负责候选域路径上每个域的子pce发送计算请求。这些请求可以是顺序的，也可以是并行的，具体取决于实现细节。
Each child PCE computes a set of candidate path segments across its domain and sends the results to the parent PCE. The parent PCE uses this information to select path segments and concatenate them to derive the optimal end-to-end inter-domain path. The end-to-end path is then sent to the child PCE that received the initial path request, and this child PCE passes the path on to the PCC that issued the original request.
每个子PCE计算其域中的一组候选路径段，并将结果发送给父PCE。父PCE使用此信息来选择路径段，并将它们连接起来以导出最佳的端到端域间路径。然后将端到端路径发送到接收初始路径请求的子PCE，并且该子PCE将路径传递到发出原始请求的PCC。
Specific deployment and implementation scenarios are out of scope of this document. However, the hierarchical PCE architecture described does support the function of parent PCE and child PCE being implemented as a common PCE.
具体的部署和实施场景超出了本文档的范围。然而，所描述的分层PCE架构支持作为公共PCE实现的父PCE和子PCE的功能。
The definition of "optimal" in the context of deriving an optimal end-to-end path is dependent on the choices that are made during the path selection. An Objective Function (OF) [RFC5541], or set of OFs, specify the intentions of the path computation and so define the "optimality" in the context of that computation.
在导出最佳端到端路径的上下文中，“最优”的定义取决于路径选择期间所做的选择。目标函数（OF）[RFC5541]或OF集合指定路径计算的意图，从而在该计算的上下文中定义“最优性”。
An OF specifies the desired outcome of a computation: it does not describe or demand the algorithm to use, and an implementation may apply any algorithm or set of algorithms to achieve the result indicated by the OF. OFs can be included in PCEP computation requests to satisfy the policies encoded or configured at the PCC, and a PCE may be subject to policy in determining whether it meets the OFs included in the computation request, or applies its own OFs.
OF指定计算的预期结果：它不描述或要求使用算法，实现可以应用任何算法或一组算法来实现OF指示的结果。OFs可包括在PCEP计算请求中以满足在PCC处编码或配置的策略，并且PCE在确定其是否满足包括在计算请求中的OFs或应用其自己的OFs时可受制于策略。
In inter-domain path computation, the selection of a domain sequence, the computation of each (per-domain) path fragment, and the determination of the end-to-end path may each be subject to different OFs and different policy.
在域间路径计算中，域序列的选择、每个（每个域）路径片段的计算以及端到端路径的确定都可能受制于不同的OFs和不同的策略。
When computing end-to-end paths, OFs may include (see Section 1.3.1):
计算端到端路径时，OFs可能包括（见第1.3.1节）：
o Minimum cost path o Minimum load path o Maximum residual bandwidth path o Minimize aggregate bandwidth consumption o Minimize or cap the number of transit domains o Disallow domain re-entry
o 最小成本路径o最小负载路径o最大剩余带宽路径o最小化总带宽消耗o最小化或限制传输域的数量o不允许域重新进入
The objective function may be requested by the PCC, the ingress domain PCE (according to local policy), or applied by the parent PCE according to inter-domain policy.
目标函数可由PCC、入口域PCE（根据本地策略）请求，或由父PCE根据域间策略应用。
More than one OF (or a composite OF) may be chosen to apply to a single computation provided they are not contradictory. Composite OFs may include weightings and preferences for the fulfillment of pieces of the desired outcome.
可以选择多个（或组合）应用于单个计算，前提是它们不相互矛盾。复合OFs可能包括实现预期结果的权重和偏好。
Information about the content of child domains is not shared for scaling and confidentiality reasons. This means that a parent PCE is aware of the domain topology and the nature of the connections between domains but is not aware of the content of the domains. Similarly, a child PCE cannot know the internal topology of another child domain. Child PCEs also do not know the general domain mesh connectivity; this information is only known by the parent PCE.
出于可扩展性和机密性原因，未共享有关子域内容的信息。这意味着父PCE知道域拓扑和域之间连接的性质，但不知道域的内容。类似地，子PCE无法知道另一个子域的内部拓扑。子PCE也不知道一般网域的连通性；此信息仅由父PCE知道。
As described in the earlier sections of this document, PCEs can exchange path information in order to construct an end-to-end inter-domain path. Each per-domain path fragment reveals information about the topology and resource availability within a domain. Some management domains or ASes will not want to share this information outside of the domain (even with a trusted parent PCE). In order to conceal the information, a PCE may replace a path segment with a path-key [RFC5520]. This mechanism effectively hides the content of a segment of a path.
如本文档前面部分所述，PCE可以交换路径信息以构建端到端域间路径。每个域路径片段都显示域内拓扑和资源可用性的相关信息。某些管理域或ASE不希望在域外共享此信息（即使与受信任的父PCE）。为了隐藏信息，PCE可以用路径密钥替换路径段[RFC5520]。该机制有效地隐藏了路径段的内容。
It is a simple matter for each child PCE to be configured with the address of its parent PCE. Typically, there will only be one or two parents of any child.
为每个子PCE配置其父PCE的地址很简单。通常，任何孩子的父母只有一个或两个。
The parent PCE also needs to be aware of the child PCEs for all child domains that it can see. This information is most likely to be configured (as part of the administrative definition of each domain).
父PCE还需要知道它可以看到的所有子域的子PCE。此信息最有可能被配置（作为每个域的管理定义的一部分）。
Discovery of the relationships between parent PCEs and child PCEs does not form part of the hierarchical PCE architecture. Mechanisms that rely on advertising or querying PCE locations across domain or provider boundaries are undesirable for security, scaling, commercial, and confidentiality reasons.
发现父PCE和子PCE之间的关系并不构成分层PCE体系结构的一部分。基于安全性、可扩展性、商业性和保密性的原因，不希望采用跨域或提供商边界发布广告或查询PCE位置的机制。
The parent PCE also needs to know the inter-domain connectivity. This information could be configured with suitable policy and commercial rules, or could be learned from the child PCEs as described in Section 4.4.
父PCE还需要知道域间连接。这些信息可以通过适当的政策和商业规则进行配置，或者可以从第4.4节所述的子PCE中学习。
In order for the parent PCE to learn about domain interconnection, the child PCE will report the identity of its neighbor domains. The IGP in each neighbor domain can advertise its inter-domain TE link capabilities [RFC5316] [RFC5392]. This information can be collected by the child PCEs and forwarded to the parent PCE, or the parent PCE could participate in the IGP in the child domains.
为了让父PCE了解域互连，子PCE将报告其相邻域的标识。每个相邻域中的IGP可以公布其域间TE链路能力[RFC5316][RFC5392]。该信息可由子PCE收集并转发给父PCE，或者父PCE可参与子域中的IGP。
The parent PCE maintains a domain topology map of the child domains and their interconnectivity. Where inter-domain connectivity is provided by TE links, the capabilities of those links may also be known to the parent PCE. The parent PCE maintains a TED for the parent domain in the same way that any PCE does.
父PCE维护子域及其互连的域拓扑图。当域间连接由TE链路提供时，这些链路的能力也可为父PCE所知。父PCE以与任何PCE相同的方式维护父域的TED。
The parent domain may just be the collection of child domains and their interconnectivity, may include details of the inter-domain TE links, and may contain nodes and links in its own right.
父域可能只是子域及其互连性的集合，可能包括域间TE链路的详细信息，并且可能本身包含节点和链路。
The mechanism for building the parent TED is likely to rely heavily on administrative configuration and commercial issues because the network was probably partitioned into domains specifically to address these issues.
构建父TED的机制可能严重依赖于管理配置和商业问题，因为网络可能被划分为专门用于解决这些问题的域。
In practice, certain information may be passed from the child domains to the parent PCE to help build the parent TED. In theory, the parent PCE could listen to the routing protocols in the child domains, but this would violate the confidentiality and scaling principles that may be responsible for the partition of the network into domains. So, it is much more likely that a suitable solution will involve specific communication from an entity in the child domain (such as the child PCE) to convey the necessary information. As already mentioned, the "necessary information" relates to how the child domains are inter-connected. The topology and available resources within the child domain do not need to be communicated to the parent PCE: doing so would violate the PCE architecture. Mechanisms for reporting this information are described in the examples in Section 4.6 in abstract terms as a child PCE "reports its neighbor domain connectivity to its parent PCE"; the specifics of a solution are out of scope of this document, but the requirements are indicated in Section 4.8. See Section 6 for a brief discussion of BGP-TE.
实际上，某些信息可能会从子域传递到父PCE，以帮助构建父TED。理论上，父PCE可以侦听子域中的路由协议，但这将违反可能负责将网络划分为域的机密性和扩展原则。因此，更可能的是，合适的解决方案将涉及来自子域中的实体（例如子PCE）的特定通信，以传递必要的信息。如前所述，“必要信息”与子域如何相互连接有关。子域内的拓扑和可用资源不需要与父PCE通信：这样做将违反PCE体系结构。第4.6节中的示例抽象地描述了报告此信息的机制，因为子PCE“报告其与其父PCE的邻居域连接”；解决方案的细节不在本文件的范围内，但要求见第4.8节。有关BGP-TE的简要讨论，请参见第6节。
In models such as ASON (see Section 5.2), it is possible to consider a separate instance of an IGP running within the parent domain where the participating protocol speakers are the nodes directly present in that domain and the PCEs (Routing Controllers) responsible for each of the child domains.
在诸如ASON（参见第5.2节）的模型中，可以考虑在父域中运行的IGP的单独实例，其中参与的协议说话者是直接存在于该域中的节点和负责每个子域的PCE（路由控制器）。
The PCC asking for an inter-domain path computation is aware of the identity of the destination node by definition. If it knows the egress domain, it can supply this information as part of the path computation request. However, if it does not know the egress domain, this information must be known by the child PCE or known/determined by the parent PCE.
请求域间路径计算的PCC根据定义知道目的地节点的身份。如果它知道出口域，它可以提供该信息作为路径计算请求的一部分。然而，如果它不知道出口域，则该信息必须由子PCE知道或由父PCE知道/确定。
In some specialist topologies the parent PCE could determine the destination domain based on the destination address, for example, from configuration. However, this is not appropriate for many multi-domain addressing scenarios. In IP-based multi-domain networks, the parent PCE may be able to determine the destination domain by participating in inter-domain routing. Finally, the parent PCE could issue specific requests to the child PCEs to discover if they contain the destination node, but this has scaling implications.
在一些专业拓扑中，父PCE可以基于目标地址（例如，从配置）确定目标域。但是，这不适用于许多多域寻址方案。在基于IP的多域网络中，父PCE可以通过参与域间路由来确定目的域。最后，父PCE可以向子PCE发出特定的请求，以发现它们是否包含目标节点，但这具有可伸缩性。
For the purposes of this document, the precise mechanism of the discovery of the destination domain is left out of scope. Suffice to say that for each multi-domain path computation some mechanism will be required to determine the location of the destination.
在本文档中，目标域的精确发现机制不在范围之内。可以说，对于每个多域路径计算，都需要某种机制来确定目的地的位置。
The following example describes the generic hierarchical domain topology. Figure 1 demonstrates four interconnected domains within a fifth, parent domain. Each domain contains a single PCE:
下面的示例描述了通用分层域拓扑。图1展示了第五个父域中的四个互连域。每个域包含一个PCE：
o Domain 1 is the ingress domain and child PCE 1 is able to compute paths within the domain. Its neighbors are Domain 2 and Domain 4. The domain also contains the source LSR (S) and three egress boundary nodes (BN11, BN12, and BN13).
o 域1是入口域，子PCE 1能够计算域内的路径。它的邻居是域2和域4。域还包含源LSR和三个出口边界节点（BN11、BN12和BN13）。
o Domain 2 is served by child PCE 2. Its neighbors are Domain 1 and Domain 3. The domain also contains four boundary nodes (BN21, BN22, BN23, and BN24).
o 域2由子PCE 2提供服务。它的邻居是域1和域3。域还包含四个边界节点（BN21、BN22、BN23和BN24）。
o Domain 3 is the egress domain and is served by child PCE 3. Its neighbors are Domain 2 and Domain 4. The domain also contains the destination LSR (D) and three ingress boundary nodes (BN31, BN32, and BN33).
o 域3是出口域，由子PCE 3提供服务。它的邻居是域2和域4。域还包含目标LSR（D）和三个入口边界节点（BN31、BN32和BN33）。
o Domain 4 is served by child PCE 4. Its neighbors are Domain 2 and Domain 3. The domain also contains two boundary nodes (BN41 and BN42).
o 域4由子PCE 4提供服务。它的邻居是域2和域3。域还包含两个边界节点（BN41和BN42）。
All of these domains are contained within Domain 5, which is served by the parent PCE (PCE 5).
所有这些域都包含在域5中，由父PCE（PCE 5）提供服务。
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
-----------------------------------------------------------------
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
-----------------------------------------------------------------
Figure 1: Sample Hierarchical Domain Topology
图1：分层域拓扑示例
Figure 2 shows the view of the domain topology as seen by the parent PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of domain connectivity but not of the internal topology within each domain.
图2显示了父PCE（PCE 5）看到的域拓扑视图。这个视图是一个抽象的拓扑结构；PCE 5知道域连接，但不知道每个域内的内部拓扑。
----------------------------
| Domain 5 |
| ---- |
| |PCE5| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
| \ ---- / |
| \ | | / |
| ----| D4 |---- |
| | | |
| ---- |
| |
----------------------------
----------------------------
| Domain 5 |
| ---- |
| |PCE5| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
| \ ---- / |
| \ | | / |
| ----| D4 |---- |
| | | |
| ---- |
| |
----------------------------
Figure 2: Abstract Domain Topology as Seen by the Parent PCE
图2：父PCE看到的抽象域拓扑
Based on the topology in Figure 1, the following is an illustration of the initial hierarchical PCE information exchange.
基于图1中的拓扑结构，以下是初始分层PCE信息交换的图示。
1. Child PCE 1, the PCE responsible for Domain 1, is configured with the location of its parent PCE (PCE 5).
1. 子PCE 1（负责域1的PCE）配置有其父PCE（PCE 5）的位置。
2. Child PCE 1 establishes contact with its parent PCE. The parent applies policy to ensure that communication with PCE 1 is allowed.
2. 子PCE 1与其父PCE建立联系。父级应用策略以确保允许与PCE 1通信。
3. Child PCE 1 listens to the IGP in its domain and learns its inter-domain connectivity. That is, it learns about the links BN11-BN21, BN12-BN22, and BN13-BN41.
3. 子PCE 1在其域中侦听IGP并学习其域间连接。也就是说，它了解链接BN11-BN21、BN12-BN22和BN13-BN41。
4. Child PCE 1 reports its neighbor domain connectivity to its parent PCE.
4. 子PCE 1将其邻居域连接报告给其父PCE。
5. Child PCE 1 reports any change in the resource availability on its inter-domain links to its parent PCE.
5. 子PCE 1报告其到其父PCE的域间链接上的资源可用性的任何更改。
Each child PCE performs steps 1 through 5 so that the parent PCE can create a domain topology view as shown in Figure 2.
每个子PCE执行步骤1到5，以便父PCE可以创建域拓扑视图，如图2所示。
The procedure below is an example of a source PCC requesting an end-to-end path in a multi-domain environment. The topology is represented in Figure 1. It is assumed that the each child PCE has connected to its parent PCE and exchanged the initial information required for the parent PCE to create its domain topology view as described in Section 4.6.1.
以下过程是源PCC在多域环境中请求端到端路径的示例。拓扑如图1所示。假设每个子PCE已连接到其父PCE，并交换父PCE创建其域拓扑视图所需的初始信息，如第4.6.1节所述。
1. The source PCC (the ingress LSR in our example) sends a request to the PCE responsible for its domain (PCE 1) for a path to the destination LSR (D).
1. 源PCC（在我们的示例中是入口LSR）向负责其域（PCE 1）的PCE发送一个请求，请求到目标LSR（D）的路径。
2. PCE 1 determines the destination is not in domain 1.
2. PCE 1确定目标不在域1中。
3. PCE 1 sends a computation request to its parent PCE (PCE 5).
3. PCE 1向其父PCE（PCE 5）发送计算请求。
4. The parent PCE determines that the destination is in Domain 3. (See Section 4.5.)
4. 父PCE确定目标位于域3中。（见第4.5节。）
5. PCE 5 determines the likely domain paths according to the domain interconnectivity and TE capabilities between the domains. For example, assuming that the link BN12-BN22 is not suitable for the requested path, three domain paths are determined:
5. PCE 5根据域之间的域互连性和TE能力确定可能的域路径。例如，假设链路BN12-BN22不适合所请求的路径，则确定三个域路径：
S-BN11-BN21-D2-BN23-BN31-D S-BN11-BN21-D2-BN24-BN32-D S-BN13-BN41-D4-BN42-BN33-D
S-BN11-BN21-D2-BN23-BN31-D S-BN11-BN21-D2-BN24-BN32-D S-BN13-BN41-D4-BN42-BN33-D
6. PCE 5 sends edge-to-edge path computation requests to PCE 2, which is responsible for Domain 2 (i.e., BN21-to-BN23 and BN21-to-BN24), and to PCE 4 for Domain 4 (i.e., BN41-to-BN42).
6. PCE 5向PCE 2发送边到边路径计算请求，PCE 2负责域2（即BN21到BN23和BN21到BN24），向PCE 4发送域4（即BN41到BN42）。
7. PCE 5 sends source-to-edge path computation requests to PCE 1, which is responsible for Domain 1 (i.e., S-to-BN11 and S-to-BN13).
7. PCE 5向负责域1（即S-to-BN11和S-to-BN13）的PCE 1发送源到边缘路径计算请求。
8. PCE 5 sends edge-to-egress path computation requests to PCE 3, which is responsible for Domain 3 (i.e., BN31-to-D, BN32-to-D, and BN33-to-D).
8. PCE 5向PCE 3发送边缘到出口路径计算请求，PCE 3负责域3（即BN31到D、BN32到D和BN33到D）。
9. PCE 5 correlates all the computation responses from each child PCE, adds in the information about the inter-domain links, and applies any requested and locally configured policies.
9. PCE 5关联来自每个子PCE的所有计算响应，添加关于域间链路的信息，并应用任何请求的和本地配置的策略。
10. PCE 5 then selects the optimal end-to-end multi-domain path that meets the policies and objective functions, and supplies the resulting path to PCE 1.
10. 然后，PCE 5选择满足策略和目标函数的最佳端到端多域路径，并将结果路径提供给PCE 1。
11. PCE 1 forwards the path to the PCC (the ingress LSR).
11. PCE 1将路径转发到PCC（入口LSR）。
Note that there is no requirement for steps 6, 7, and 8 to be carried out in parallel or in series. Indeed, they could be overlapped with step 5. This is an implementation issue.
请注意，不要求并行或串联执行步骤6、7和8。事实上，它们可以与步骤5重叠。这是一个执行问题。
In the event that a child PCE in a domain cannot find a suitable path to the egress, the child PCE should return the relevant error to notify the parent PCE. Depending on the error response, the parent PCE selects one of the following actions:
如果域中的子PCE无法找到合适的出口路径，则子PCE应返回相关错误以通知父PCE。根据错误响应，父PCE选择以下操作之一：
o Cancel the request and send the relevant response back to the initial child PCE that requested an end-to-end path;
o 取消请求并将相关响应发送回请求端到端路径的初始子PCE；
o Relax some of the constraints associated with the initial path request; or
o 放松与初始路径请求相关的一些约束；或
o Select another candidate domain and send the path request to the child PCE responsible for the domain.
o 选择另一个候选域并将路径请求发送给负责该域的子PCE。
If the parent PCE does not receive a response from a child PCE within an allotted time period, the parent PCE can elect to:
如果父PCE在分配的时间段内未收到子PCE的响应，则父PCE可以选择：
o Cancel the request and send the relevant response back to the initial child PCE that requested an end-to-end path; o Send the path request to another child PCE in the same domain, if a secondary child PCE exists; o Select another candidate domain and send the path request to the child PCE responsible for that domain.
o 取消请求并将相关响应发送回请求端到端路径的初始子PCE；o如果存在辅助子PCE，则向同一域中的另一个子PCE发送路径请求；o选择另一个候选域，并将路径请求发送给负责该域的子PCE。
The parent PCE may also want to prune any unresponsive child PCE domain paths from the candidate set.
父PCE还可能希望从候选集中删除任何无响应的子PCE域路径。
This section lists the high-level requirements for extensions to the PCEP to support the hierarchical PCE model. It is provided to offer guidance to PCEP protocol developers in designing a solution suitable for use in a hierarchical PCE framework.
本节列出了PCEP扩展的高级要求，以支持分层PCE模型。本手册旨在为PCEP协议开发人员提供指导，帮助他们设计适用于分层PCE框架的解决方案。
Path Computation Request (PCReq) messages are used by a PCC or a PCE to make a computation request or enquiry to a PCE. The requests are qualified so that the PCE knows what type of action is required.
PCC或PCE使用路径计算请求（PCReq）消息向PCE发出计算请求或查询。对请求进行限定，以便PCE知道需要什么类型的操作。
Support of the hierarchical PCE architecture will introduce two new qualifications as follows:
对分级PCE架构的支持将引入以下两个新资格：
o It must be possible for a child PCE to indicate that the response it receives from the parent PCE should consist of a domain sequence only (i.e., not a fully specified end-to-end path). This allows the child PCE to initiate Per-Domain or BRPC.
o 子PCE必须能够指示其从父PCE接收的响应应仅包含域序列（即，不是完全指定的端到端路径）。这允许子PCE按域或BRPC启动。
o A parent PCE may need to be able to ask a child PCE whether a particular node address (the destination of an end-to-end path) is present in the domain that the child PCE serves.
o 父PCE可能需要能够询问子PCE在其服务的域中是否存在特定节点地址（端到端路径的目的地）。
In PCEP, such request qualifications are carried as bit flags in the RP object (Request Parameter object) within the PCReq message.
在PCEP中，此类请求限定作为PCReq消息内RP对象（请求参数对象）中的位标志携带。
Although parent/child PCE relationships are likely configured, it will assist network operations if the parent PCE is able to indicate to the child that it really is capable of acting as a parent PCE. This will help to trap misconfigurations.
尽管可能配置了父/子PCE关系，但如果父PCE能够向子PCE指示它确实能够充当父PCE，则它将有助于网络操作。这将有助于捕获错误配置。
In PCEP, such capabilities are carried in the Open Object within the Open message.
在PCEP中，这些功能在开放消息中的开放对象中进行。
A PCE that is capable of acting as a parent PCE might not be configured or willing to act as the parent for a specific child PCE. This fact could be determined when the child sends a PCReq that requires parental activity (such as querying other child PCEs), and could result in a negative response in a PCEP Error (PCErr) message.
能够充当父PCE的PCE可能未配置或不愿意充当特定子PCE的父PCE。当孩子发送需要家长活动（如查询其他孩子PCE）的PCReq时，可以确定这一事实，并可能导致PCEP错误（PCErr）消息中的负面响应。
However, the expense of a poorly targeted PCReq can be avoided if the child PCE indicates that it might wish to use the parent-capable PCE as a parent (for example, on the Open message), and if the parent-capable PCE determines at that time whether it is willing to act as a parent to this child.
然而，如果子PCE指示其可能希望将具有父级能力的PCE用作父级（例如，在打开消息上），并且如果具有父级能力的PCE当时确定其是否愿意充当该子级的父级，则可以避免目标差的PCReq的费用。
Section 4.4 describes how the parent PCE needs a parent TED and indicates that the information might be supplied from the child PCEs in each domain. This requires a mechanism whereby information about inter-domain links can be supplied by a child PCE to a parent PCE, for example, on a PCEP Notify (PCNtf) message.
第4.4节描述了父PCE如何需要父TED，并指出信息可能由每个域中的子PCE提供。这需要一种机制，通过该机制，子PCE可以向父PCE提供关于域间链路的信息，例如，通过PCEP Notify（PCNtf）消息。
The information that would be exchanged includes:
将交换的信息包括：
o Identifier of advertising child PCE o Identifier of PCE's domain o Identifier of the link o TE properties of the link (metrics, bandwidth) o Other properties of the link (technology-specific) o Identifier of link endpoints o Identifier of adjacent domain
o 广告子PCE的标识符o PCE域的标识符o链路的标识符o链路的属性（度量、带宽）o链路的其他属性（特定于技术）o链路端点的标识符o相邻域的标识符
It may be desirable for this information to be periodically updated, for example, when available bandwidth changes. In this case, the parent PCE might be given the ability to configure thresholds in the child PCE to prevent flapping of information.
例如，当可用带宽改变时，可能希望定期更新该信息。在这种情况下，父PCE可以被赋予在子PCE中配置阈值的能力，以防止信息的抖动。
Domain identifiers are already present in PCEP to allow a PCE to indicate which domains it serves, and to allow the representation of domains as abstract nodes in paths. The wider use of domains in the context of this work on hierarchical PCE will require that domains can be identified in more places within objects in PCEP messages. This should pose no problems.
PCEP中已经存在域标识符，以允许PCE指示其服务的域，并允许将域表示为路径中的抽象节点。在分层PCE工作的上下文中更广泛地使用域将需要在PCEP消息中的对象内的更多位置识别域。这应该不会造成任何问题。
However, more attention may need to be applied to the precision of domain identifier definitions to ensure that it is always possible to unambiguously identify a domain from its identifier. This work will be necessary in configuration, and also in protocol specifications (for example, an OSPF area identifier is sufficient within an Autonomous System, but becomes ambiguous in a path that crosses multiple Autonomous Systems).
然而，可能需要更多地注意域标识符定义的精度，以确保始终可以从其标识符中明确地识别域。这项工作在配置和协议规范中都是必要的（例如，OSPF区域标识符在自治系统中是足够的，但在跨多个自治系统的路径中变得不明确）。
As per [RFC4655], PCE can inherently support inter-domain path computation for any definition of a domain as set out in Section 1.2 of this document.
根据[RFC4655]，PCE固有地支持本文件第1.2节规定的任何域定义的域间路径计算。
Hierarchical PCE can be applied to inter-domain environments, including autonomous Systems and IGP areas. The hierarchical PCE procedures make no distinction between, autonomous Systems and IGP area applications, although it should be noted that the TED maintained by a parent PCE must be able to support the concept of child domains connected by inter-domain links or directly connected at boundary nodes (see Section 3).
分层PCE可应用于域间环境，包括自治系统和IGP区域。分层PCE程序不区分自治系统和IGP区域应用，但应注意，由父PCE维护的TED必须能够支持子域通过域间链路连接或直接连接到边界节点的概念（见第3节）。
This section sets out the applicability of hierarchical PCE to three environments:
本节阐述了分级PCE对三种环境的适用性：
o MPLS traffic engineering across multiple Autonomous Systems o MPLS traffic engineering across multiple IGP areas o GMPLS traffic engineering in the ASON architecture
o 跨多个自治系统的MPLS流量工程o跨多个IGP区域的MPLS流量工程o ASON架构中的GMPLS流量工程
Networks are comprised of domains. A domain can be considered to be a collection of network elements within an AS or area that has a common sphere of address management or path computational responsibility.
网络由域组成。域可以被认为是AS或区域内的网络元素集合，具有共同的地址管理或路径计算职责。
As networks increase in size and complexity it may be required to introduce scaling methods to reduce the amount information flooded within the network and make the network more manageable. An IGP hierarchy is designed to improve IGP scalability by dividing the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries. This restricts a router's visibility to information about links and other routers within the single area. If a router needs to compute a route to destination located in another area, a method is required to compute a path across the area boundary.
随着网络规模和复杂性的增加，可能需要引入缩放方法，以减少网络中的信息量，并使网络更易于管理。IGP层次结构旨在通过将IGP域划分为多个区域并将拓扑信息的泛洪范围限制在区域边界内来提高IGP的可伸缩性。这将限制路由器对单个区域内链路和其他路由器信息的可见性。如果路由器需要计算到位于另一个区域的目的地的路由，则需要一种方法来计算跨越区域边界的路径。
When an LSR within an AS or area needs to compute a path across an area or AS boundary, it must also use an inter-AS computation technique. Hierarchical PCE is equally applicable to computing inter-area and inter-AS MPLS and GMPLS paths across domain boundaries.
当AS或区域内的LSR需要计算穿过区域或AS边界的路径时，它还必须使用AS间计算技术。分层PCE同样适用于跨域边界计算区域间和区域间AS MPLS和GMPLS路径。
The International Telecommunication Union (ITU) defines the ASON architecture in [G-8080]. [G-7715] defines the routing architecture for ASON and introduces a hierarchical architecture. In this architecture, the Routing Areas (RAs) have a hierarchical relationship between different routing levels, which means a parent (or higher-level) RA can contain multiple child RAs. The interconnectivity of the lower RAs is visible to the higher-level RA. Note that the RA hierarchy can be recursive.
国际电信联盟（ITU）在[G-8080]中定义了ASON架构。[G-7715]定义了ASON的路由架构，并引入了分层架构。在该体系结构中，路由区域（RA）在不同的路由级别之间具有层次关系，这意味着父级（或更高级别）RA可以包含多个子RA。较低RAs的互连性对较高RA可见。请注意，RA层次结构可以是递归的。
In the ASON framework, a path computation request is termed a Route Query. This query is executed before signaling is used to establish an LSP termed a Switched Connection (SC) or a Soft Permanent Connection (SPC). [G-7715-2] defines the requirements and architecture for the functions performed by Routing Controllers (RCs) during the operation of remote route queries -- an RC is synonymous with a PCE. For an end-to-end connection, the route may be computed by a single RC or multiple RCs in a collaborative manner (i.e., RC federations). In the case of RC federations, [G-7715-2] describes three styles during remote route query operation:
在ASON框架中，路径计算请求称为路由查询。此查询在信令用于建立称为交换连接（SC）或软永久连接（SPC）的LSP之前执行。[G-7715-2]定义了路由控制器（RCs）在远程路由查询操作期间执行的功能的要求和体系结构——RC与PCE同义。对于端到端连接，路由可由单个RC或多个RCs以协作方式（即RC联邦）计算。对于RC联邦，[G-7715-2]描述了远程路由查询操作期间的三种样式：
o step-by-step remote path computation o hierarchical remote path computation o a combination of the above.
o 逐步远程路径计算o分层远程路径计算o上述组合。
In a hierarchical ASON routing environment, a child RC may communicate with its parent RC (at the next higher level of the ASON routing hierarchy) to request the computation of an end-to-end path across several RAs. It does this using a route query message (known as the abstract message RI_QUERY). The corresponding parent RC may communicate with other child RCs that belong to other child RAs at the next lower hierarchical level. Thus, a parent RC can act as either a Route Query Requester or Route Query Responder.
在分层ASON路由环境中，子RC可以与其父RC（在ASON路由层次的下一个更高级别）通信，以请求跨多个RAs的端到端路径的计算。它使用路由查询消息（称为抽象消息RI_查询）来实现这一点。相应的父RC可以与属于下一个较低层次结构级别的其他子RA的其他子RC通信。因此，父RC可以充当路由查询请求者或路由查询响应者。
It can be seen that the hierarchical PCE architecture fits the hierarchical ASON routing architecture well. It can be used to provide paths across subnetworks and to determine end-to-end paths in networks constructed from multiple subnetworks or RAs.
可以看出，分层PCE架构非常适合分层ASON路由架构。它可用于提供跨子网的路径，并确定由多个子网或RAs构成的网络中的端到端路径。
When hierarchical PCE is applied to implement hierarchical remote path computation in [G-7715-2], it is very important for operators to understand the different terminology and implicit consistency between hierarchical PCE and [G-7715-2].
当在[G-7715-2]中应用分层PCE实现分层远程路径计算时，操作员理解分层PCE和[G-7715-2]之间的不同术语和隐含一致性非常重要。
This section highlights the correspondence between features of the hierarchical PCE architecture and the ASON routing architecture.
本节重点介绍分层PCE体系结构和ASON路由体系结构之间的对应关系。
(1) RC (Routing Controller) and PCE (Path Computation Element)
(1) RC（路由控制器）和PCE（路径计算元件）
[G-8080] describes the Routing Controller component as an abstract entity, which is responsible for responding to requests for path (route) information and topology information. It can be implemented as a single entity, or as a distributed set of entities that make up a cooperative federation.
[G-8080]将路由控制器组件描述为一个抽象实体，负责响应路径（路由）信息和拓扑信息的请求。它可以实现为单个实体，也可以实现为组成协作联邦的一组分布式实体。
[RFC4655] describes PCE (Path Computation Element) is 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.
[RFC4655]描述PCE（路径计算元素）是一个实体（组件、应用程序或网络节点），能够基于网络图计算网络路径或路由并应用计算约束。
Therefore, in the ASON architecture, a PCE can be regarded as a realization of the RC.
因此，在ASON架构中，PCE可以被视为RC的实现。
(2) Route Query Requester/Route Query Responder and PCC/PCE
(2) 路由查询请求者/路由查询响应者和PCC/PCE
[G-7715-2] describes the Route Query Requester as a Connection Controller or Routing Controller that sends a route query message to a Routing Controller requesting one or more paths that satisfy a set of routing constraints. The Route Query Responder is a Routing Controller that performs path computation upon receipt of a route query message from a Route Query Requester, sending a response back at the end of the path computation.
[G-7715-2]将路由查询请求者描述为连接控制器或路由控制器，向路由控制器发送路由查询消息，请求满足一组路由约束的一条或多条路径。路由查询响应器是一个路由控制器，它在从路由查询请求者接收到路由查询消息时执行路径计算，并在路径计算结束时发送响应。
In the context of ASON, a Signaling Controller initiates and processes signaling messages and is closely coupled to a Signaling Protocol Speaker. A Routing Controller makes routing decisions and is usually coupled to configuration entities and/or a Routing Protocol Speaker.
在ASON的上下文中，信令控制器发起和处理信令消息，并且与信令协议扬声器紧密耦合。路由控制器做出路由决策，并且通常与配置实体和/或路由协议扬声器耦合。
It can be seen that a PCC corresponds to a Route Query Requester, and a PCE corresponds to a Route Query Responder. A PCE/RC can also act as a Route Query Requester sending requests to another Route Query Responder.
可以看出，PCC对应于路由查询请求者，PCE对应于路由查询响应者。PCE/RC还可以充当路由查询请求者，向另一个路由查询响应者发送请求。
The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages between PCC and PCE correspond to the RI_QUERY and RI_UPDATE messages in [G-7715-2].
PCC和PCE之间的路径计算请求（PCReq）和路径计算回复（PCRep）消息对应于[G-7715-2]中的RI_查询和RI_更新消息。
(3) Routing Area Hierarchy and Hierarchical Domain
(3) 路由区域层次和层次域
The ASON routing hierarchy model is shown in Figure 6 of [G-7715] through an example that illustrates routing area levels. If the hierarchical remote path computation mechanism of [G-7715-2] is applied in this scenario, each routing area should have at least one RC to perform the route query function, and the child RCs within the area should have a parent RC.
[G-7715]的图6通过一个示例显示了ASON路由层次结构模型，该示例说明了路由区域级别。如果在该场景中应用[G-7715-2]的分层远程路径计算机制，则每个路由区域应至少有一个RC来执行路由查询功能，并且该区域内的子RCs应具有一个父RC。
According to [G-8080], the parent RC has visibility of the structure of the lower level, so it knows the interconnectivity of the RAs in the lower level. Each child RC can compute edge-to-edge paths across its own child RA.
根据[G-8080]，父RC具有较低级别结构的可见性，因此它知道较低级别中RAs的互连性。每个子RC可以计算跨越其子RA的边到边路径。
Thus, an RA corresponds to a domain in the PCE architecture, and the hierarchical relationship between RAs corresponds to the hierarchical relationship between domains in the hierarchical PCE architecture. Furthermore, a parent PCE in a parent domain can be regarded as parent RC in a higher routing level, and a child PCE in a child domain can be regarded as child RC in a lower routing level.
因此，RA对应于PCE架构中的域，并且RAs之间的层次关系对应于层次PCE架构中的域之间的层次关系。此外，父域中的父PCE可以被视为较高路由级别中的父RC，而子域中的子PCE可以被视为较低路由级别中的子RC。
RCs in an ASON environment can use the hierarchical PCE model to fully match the ASON hierarchical routing model, so the hierarchical PCE mechanisms can be applied to fully satisfy the architecture and requirements of [G-7715-2] without any changes. If the hierarchical PCE mechanism is applied in ASON, it can be used to determine end-to-end optimized paths across subnetworks and RAs before initiating signaling to create the connection. It can also improve the efficiency of connection setup to avoid crankback.
ASON环境中的RCs可以使用分层PCE模型来完全匹配ASON分层路由模型，因此分层PCE机制可以在不做任何更改的情况下完全满足[G-7715-2]的架构和要求。如果在ASON中应用分层PCE机制，则在启动信令以创建连接之前，它可用于确定子网和RAs之间的端到端优化路径。它还可以提高连接设置的效率，以避免拖转。
The concept of exchange of TE information between Autonomous Systems (ASes) is discussed in [BGP-TE]. The information exchanged in this way could be the full TE information from the AS, an aggregation of that information, or a representation of the potential connectivity across the AS. Furthermore, that information could be updated frequently (for example, for every new LSP that is set up across the AS) or only at threshold-crossing events.
在[BGP-TE]中讨论了自治系统（ASE）之间TE信息交换的概念。以这种方式交换的信息可以是来自AS的完整TE信息、该信息的聚合或AS间潜在连接性的表示。此外，该信息可以经常更新（例如，对于在AS中设置的每个新LSP），或者仅在阈值交叉事件时更新。
There are a number of discussion points associated with the use of [BGP-TE] concerning the volume of information, the rate of churn of information, the confidentiality of information, the accuracy of aggregated or potential-connectivity information, and the processing required to generate aggregated information. The PCE architecture
关于[BGP-TE]的使用，有许多讨论点涉及信息量、信息流失率、信息保密性、聚合或潜在连接信息的准确性以及生成聚合信息所需的处理。PCE体系结构
and the architecture enabled by [BGP-TE] make different assumptions about the operational objectives of the networks, and this document does not attempt to make one of the approaches "right" and the other "wrong". Instead, this work assumes that a decision has been made to utilize the PCE architecture.
[BGP-TE]启用的体系结构对网络的运营目标做出了不同的假设，本文件并不试图使其中一种方法“正确”而另一种方法“错误”。相反，这项工作假设已经做出了利用PCE体系结构的决定。
Indeed, [BGP-TE] may have some uses within the PCE model. For example, [BGP-TE] could be used as a "northbound" TE advertisement such that a PCE does not need to listen to an IGP in its domain, but has its TED populated by messages received (for example) from a Route Reflector. Furthermore, the inter-domain connectivity and capabilities that are required information for a parent PCE could be obtained as a filtered subset of the information available in [BGP-TE]. This scenario is discussed further in [PCE-AREA-AS].
实际上，[BGP-TE]在PCE模型中可能有一些用途。例如，[BGP-TE]可以用作“北向”TE广告，使得PCE不需要监听其域中的IGP，而是通过从路由反射器接收（例如）的消息填充其TED。此外，作为父PCE所需信息的域间连接性和能力可以作为[BGP-TE]中可用信息的过滤子集获得。该场景将在[PCE-AREA-AS]中进一步讨论。
General PCE management considerations are discussed in [RFC4655]. In the case of the hierarchical PCE architecture, there are additional management considerations.
[RFC4655]中讨论了PCE管理的一般注意事项。在分级PCE体系结构的情况下，还有其他管理注意事项。
The administrative entity responsible for the management of the parent PCEs must be determined. In the case of multi-domains (e.g., IGP areas or multiple ASes) within a single service provider network, the management responsibility for the parent PCE would most likely be handled by the service provider. In the case of multiple ASes within different service provider networks, it may be necessary for a third party to manage the parent PCEs according to commercial and policy agreements from each of the participating service providers.
必须确定负责管理母公司PCE的行政实体。在单个服务提供商网络内的多个域（例如，IGP区域或多个ASE）的情况下，父PCE的管理责任最有可能由服务提供商处理。在不同服务提供商网络内的多个ASE的情况下，第三方可能需要根据来自每个参与服务提供商的商业和政策协议来管理父PCE。
Support of the hierarchical procedure will be controlled by the management organization responsible for each child PCE. A child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. The child PCE must also be authorized to peer with the parent PCE.
分级程序的支持将由负责每个儿童PCE的管理组织控制。子PCE必须配置其父PCE的地址，以便与父PCE交互。子PCE还必须被授权与父PCE对等。
The parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives requests from an unauthorized child PCE, the request should be dropped.
父PCE必须仅接受来自授权子PCE的路径计算请求。如果父PCE收到来自未经授权的子PCE的请求，则应放弃该请求。
This means that a parent PCE must be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE.
这意味着必须为父PCE配置其所有子PCE的身份和安全凭据，或者必须存在某种形式的共享机密，以允许父PCE授权未知的子PCE。
It may be necessary to maintain a policy module on the parent PCE [RFC5394]. This would allow the parent PCE to apply commercially relevant constraints such as SLAs, security, peering preferences, and monetary costs.
可能需要在父PCE上维护策略模块[RFC5394]。这将允许母PCE应用商业相关约束，如SLA、安全性、对等首选项和货币成本。
It may also be necessary for the parent PCE to limit end-to-end path selection by including or excluding specific domains based on commercial relationships, security implications, and reliability.
父PCE还可能需要通过基于商业关系、安全含义和可靠性包括或排除特定域来限制端到端路径选择。
A PCEP MIB module is defined in [PCEP-MIB] that describes managed objects for modeling of PCEP communication. An additional PCEP MIB will be required to report parent PCE and child PCE information, including:
[PCEP-MIB]中定义了PCEP MIB模块，该模块描述了用于PCEP通信建模的托管对象。需要额外的PCEP MIB来报告父PCE和子PCE信息，包括：
o parent PCE configuration and status,
o 父PCE配置和状态，
o child PCE configuration and information,
o 子PCE配置和信息，
o notifications to indicate session changes between parent PCEs and child PCEs, and
o 指示父PCE和子PCE之间会话更改的通知，以及
o notification of parent PCE TED updates and changes.
o 通知父PCE TED更新和更改。
The hierarchical procedure requires interaction with multiple PCEs. Once a child PCE requests an end-to-end path, a sequence of events occurs that requires interaction between the parent PCE and each child PCE. If a child PCE is not operational, and an alternate transit domain is not available, then a failure must be reported.
分层程序需要与多个PCE交互。一旦子PCE请求端到端路径，就会发生一系列事件，需要父PCE和每个子PCE之间进行交互。如果子PCE不工作，且备用传输域不可用，则必须报告故障。
Verifying the correct operation of a parent PCE can be performed by monitoring a set of parameters. The parent PCE implementation should provide the following parameters monitored by the parent PCE:
可以通过监测一组参数来验证父PCE的正确操作。父PCE实施应提供由父PCE监控的以下参数：
o number of child PCE requests,
o 子PCE请求数，
o number of successful hierarchical PCE procedures completions on a per-PCE-peer basis,
o 每个PCE同行成功完成分级PCE程序的数量，
o number of hierarchical PCE procedure completion failures on a per-PCE-peer basis, and
o 每个PCE同行的分层PCE程序完成失败次数，以及
o number of hierarchical PCE procedure requests from unauthorized child PCEs.
o 来自未经授权的子PCE的分级PCE程序请求数。
The hierarchical PCE procedure is a multiple-PCE path computation scheme. Subsequent requests to and from the child and parent PCEs do not differ from other path computation requests and should not have any significant impact on network operations.
分层PCE程序是一种多PCE路径计算方案。与子PCE和父PCE之间的后续请求与其他路径计算请求没有区别，并且不应对网络操作产生任何重大影响。
The hierarchical PCE procedure relies on PCEP and inherits the security requirements defined in [RFC5440]. As noted in Section 7, there is a security relationship between child and parent PCEs. This relationship, like any PCEP relationship, assumes pre-configuration of identities, authority, and keys, or can operate through any key distribution mechanism outside the scope of PCEP. As PCEP operates over TCP, it may make use of any TCP security mechanism.
分级PCE程序依赖于PCEP，并继承[RFC5440]中定义的安全要求。如第7节所述，子女和父母PCE之间存在担保关系。与任何PCEP关系一样，此关系假定预先配置身份、权限和密钥，或者可以通过PCEP范围之外的任何密钥分发机制进行操作。由于PCEP通过TCP进行操作，因此它可以使用任何TCP安全机制。
The hierarchical PCE architecture makes use of PCE policy [RFC5394] and the security aspects of the PCE Communication Protocol documented in [RFC5440]. It is expected that the parent PCE will require all child PCEs to use full security when communicating with the parent and that security will be maintained by not supporting the discovery by a parent of child PCEs.
分层PCE体系结构利用PCE策略[RFC5394]和[RFC5440]中记录的PCE通信协议的安全方面。预计父PCE将要求所有子PCE在与父PCE通信时使用完全安全性，并且将通过不支持父PCE的发现来维护安全性。
PCE operation also relies on information used to build the TED. Attacks on a PCE system may be achieved by falsifying or impeding this flow of information. The child PCE TEDs are constructed as described in [RFC4655] and are unchanged in this document: if the PCE listens to the IGP for this information, then normal IGP security measures may be applied, and it should be noted that an IGP routing system is generally assumed to be a trusted domain such that router subversion is not a risk. The parent PCE TED is constructed as described in this document and may involve:
PCE的运行也依赖于用于构建TED的信息。对PCE系统的攻击可以通过伪造或阻止信息流来实现。子PCE TED的构造如[RFC4655]中所述，在本文件中未作更改：如果PCE侦听IGP以获取此信息，则可以应用正常的IGP安全措施，并且应注意，IGP路由系统通常被假定为可信域，因此路由器颠覆不存在风险。母PCE TED的构造如本文件所述，可能涉及：
- multiple parent-child relationships using PCEP (as already described)
- 使用PCEP的多个父子关系（如上所述）
- the parent PCE listening to child domain IGPs (with the same security features as a child PCE listening to its IGP)
- 侦听子域IGP的父PCE（与侦听其IGP的子PCE具有相同的安全功能）
- an external mechanism (such as [BGP-TE]), which will need to be authorized and secured.
- 需要授权和保护的外部机制（如[BGP-TE]）。
Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This is bound to represent a significant security and confidentiality risk especially when the child domains are controlled by different commercial concerns. PCEP allows individual PCEs to maintain confidentiality of their domain path information using path-keys [RFC5520], and the hierarchical PCE architecture is specifically designed to enable as much isolation of domain topology and capabilities information as is possible.
任何多域操作都必然涉及跨域边界的信息交换。这必然会带来重大的安全和保密风险，尤其是当子域由不同的商业关注点控制时。PCEP允许单个PCE使用路径密钥[RFC5520]维护其域路径信息的机密性，并且分层PCE体系结构专门设计用于尽可能多地隔离域拓扑和功能信息。
For further considerations of the security issues related to inter-AS path computation, see [RFC5376].
有关与AS间路径计算相关的安全问题的进一步考虑，请参阅[RFC5376]。
The authors would like to thank David Amzallag, Oscar Gonzalez de Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini, Dhruv Dhody, and Julien Meuric for their comments and suggestions.
作者要感谢David Amzallag、Oscar Gonzalez de Dios、Franz Rambach、Ramon Casellas、Olivier Dugeon、Filippo Cugini、Dhruv Dhody和Julien Meuri的评论和建议。
[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月。
[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月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年4月。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月。
[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月。
[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月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[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月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376]Bitar，N.，Zhang，R.，和K.Kumaki，“路径计算元素通信协议（PCECP）的内部AS要求”，RFC 5376，2008年11月。
[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月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 55412009年6月。
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for the automatically switched optical network (ASON).
[G-8080]ITU-T建议G.8080/Y.1304，自动交换光网络（ASON）架构。
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture and Requirements for the Automatically Switched Optical Network (ASON).
[G-7715]ITU-T建议G.7715（2002），自动交换光网络（ASON）的体系结构和要求。
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing architecture and requirements for remote route query.
[G-7715-2]ITU-T建议G.7715.2（2007），ASON路由体系结构和远程路由查询要求。
[BGP-TE] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, October 2012.
[BGP-TE]Gredler，H.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和TE信息的北向分布”，正在进行的工作，2012年10月。
[PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de Dios, O., and F. Chico, "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", Work in Progress, January 2012.
[PCE-AREA-AS]King，D.，Meuria，J.，Dugeon，O.，Zhao，Q.，Gonzalez de Dios，O.，和F.Chico，“路径计算元素对区域间和区域间MPLS和GMPLS流量工程的适用性”，正在进行的工作，2012年1月。
[PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D., and J. Hardwick, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2012.
[PCEP-MIB]Koushik，A.，Emile，S.，Zhao，Q.，King，D.，和J.Hardwick，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2012年7月。
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US
昆廷赵华为技术125美国马萨诸塞州阿克顿市纳戈科技园01719
EMail: qzhao@huawei.com
EMail: qzhao@huawei.com
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China
中国深圳市龙岗区华为基地坂田华为技术有限公司F3-5-B研发中心，邮编：518129
EMail: zhangfatai@huawei.com
EMail: zhangfatai@huawei.com
Authors' Addresses
作者地址
Daniel King Old Dog Consulting UK
丹尼尔·金老狗咨询英国
EMail: daniel@olddog.co.uk
EMail: daniel@olddog.co.uk
Adrian Farrel Old Dog Consulting UK
阿德里安·法雷尔英国老狗咨询公司
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk