Network Working Group A. Farrel
Request for Comments: 4655 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
J. Ash
AT&T
August 2006
Network Working Group A. Farrel
Request for Comments: 4655 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
J. Ash
AT&T
August 2006
A Path Computation Element (PCE)-Based Architecture
基于路径计算元素（PCE）的体系结构
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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
基于约束的路径计算是多协议标签交换（MPLS）和广义多协议标签交换（GMPLS）网络等流量工程系统的基本组成部分。大型、多域、多区域或多层网络中的路径计算非常复杂，可能需要特殊的计算组件以及不同网络域之间的协作。
This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.
本文档指定了基于路径计算元素（PCE）的模型的体系结构，以解决此问题空间。本文档并不试图提供所有体系结构组件的详细描述，而是描述了可用于构建解决方案的PCE体系结构的一组构建块。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility .........................................7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............7
4.4. Node Outside the Routing Domain ............................8
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility .........................................7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............7
4.4. Node Outside the Routing Domain ............................8
4.5. Network Element Lacks Control Plane or Routing Capability ..8
4.6. Backup Path Computation for Bandwidth Protection ...........8
4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ......................................9
4.9. Non-Motivations ...........................................10
4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................11
5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE
Communication .............................................14
5.5. Management-Based PCE Usage ................................15
5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model .............................16
6.2. Distributed Computation Model .............................17
6.3. Synchronization ...........................................17
6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ...................................22
6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................25
6.10. Confidentiality ..........................................25
6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................28
6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ......................31
8. Evaluation Metrics .............................................32
9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring .........................34
9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional
Components ................................................35
9.6. Impact on Network Operation ...............................36
9.7. Other Considerations ......................................36
10. Security Considerations .......................................37
11. Acknowledgements ..............................................37
12. Informative References ........................................38
4.5. Network Element Lacks Control Plane or Routing Capability ..8
4.6. Backup Path Computation for Bandwidth Protection ...........8
4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ......................................9
4.9. Non-Motivations ...........................................10
4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................11
5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE
Communication .............................................14
5.5. Management-Based PCE Usage ................................15
5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model .............................16
6.2. Distributed Computation Model .............................17
6.3. Synchronization ...........................................17
6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ...................................22
6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................25
6.10. Confidentiality ..........................................25
6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................28
6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ......................31
8. Evaluation Metrics .............................................32
9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring .........................34
9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional
Components ................................................35
9.6. Impact on Network Operation ...............................36
9.7. Other Considerations ......................................36
10. Security Considerations .......................................37
11. Acknowledgements ..............................................37
12. Informative References ........................................38
Constraint-based path computation is a fundamental building block for traffic engineering in MPLS [RFC3209] and GMPLS [RFC3473] networks. [RFC2702] describes requirements for traffic engineering in MPLS networks, while [RFC4105] and [RFC4216] describe traffic engineering requirements in inter-area and inter-AS environments, respectively.
基于约束的路径计算是MPLS[RFC3209]和GMPLS[RFC3473]网络中流量工程的基本构建块。[RFC2702]描述了MPLS网络中的流量工程需求，[RFC4105]和[RFC4216]分别描述了区域间和AS间环境中的流量工程需求。
Path computation in large, multi-domain networks is complex and may require special computational components and cooperation between the elements in different domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.
大型多域网络中的路径计算非常复杂，可能需要特殊的计算组件以及不同域中元素之间的协作。本文档指定了基于路径计算元素（PCE）的模型的体系结构，以解决此问题空间。
This document describes a set of building blocks for the PCE architecture from which solutions may be constructed. For example, it discusses PCE-based implementations including composite, external, and multiple PCE path computation. Furthermore, it discusses architectural considerations including centralized computation, distributed computation, synchronization, PCE discovery and load balancing, detection of PCE liveness, communication between Path Computation Clients (PCCs) and the PCE (PCC-PCE communication) and PCE-PCE communication, Traffic Engineering Database (TED) synchronization, stateful and stateless PCEs, monitoring, policy and confidentiality, and evaluation metrics.
本文档描述了PCE体系结构的一组构建块，可以从中构建解决方案。例如，本文讨论了基于PCE的实现，包括复合、外部和多PCE路径计算。此外，还讨论了体系结构方面的考虑因素，包括集中计算、分布式计算、同步、PCE发现和负载平衡、PCE活动性检测、路径计算客户端（PCC）与PCE之间的通信（PCC-PCE通信）以及PCE-PCE通信、流量工程数据库（TED）同步、有状态和无状态PCE、监控、策略和机密性以及评估指标。
The model of the Internet is to distribute network functionality (e.g., routing) within the network. PCE functionality is not intended to contradict this model and can be used to match the model exactly, for example, when the PCE functionality coexists with each Label Switching Router (LSR) in the network. PCE is also able to augment functionality in the network where the Internet model cannot supply adequate solutions, for example, where traffic engineering information is not exchanged between network domains.
Internet的模型是在网络内分发网络功能（例如路由）。PCE功能无意与此模型相矛盾，可用于精确匹配模型，例如，当PCE功能与网络中的每个标签交换路由器（LSR）共存时。PCE还能够增强互联网模型无法提供足够解决方案的网络中的功能，例如，在网络域之间不交换流量工程信息的网络中。
CSPF: Constraint-based Shortest Path First.
CSPF：基于约束的最短路径优先。
LER: Label Edge Router.
标签边缘路由器。
LSDB: Link State Database.
链接状态数据库。
LSP: Label Switched Path.
标签交换路径。
LSR: Label Switching Router.
标签交换路由器。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element.
路径计算客户端。请求由路径计算元素执行的路径计算的任何客户端应用程序。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints (see further description in Section 3).
PCE：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）（参见第3节中的进一步描述）。
TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means.
TED：流量工程数据库，包含域的拓扑和资源信息。TED可以通过内部网关协议（IGP）扩展或可能通过其他方式提供。
TE LSP: Traffic Engineering MPLS Label Switched Path.
TE LSP：流量工程MPLS标签交换路径。
A Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc. For example, a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request.
路径计算元素（PCE）是能够基于网络图计算网络路径或路由并在计算期间应用计算约束的实体。PCE实体是可位于网络节点或组件内、网络外服务器等上的应用程序。例如，PCE将能够通过在TED上操作并考虑适用于TE LSP服务请求的带宽和其他约束来计算TE LSP的路径。
A domain is any collection of network elements within a common sphere of address management or path computation responsibility. Examples of domains include IGP areas, Autonomous Systems (ASes), and multiple ASes within a Service Provider network. Domains of path computation responsibility may also exist as sub-domains of areas or ASes.
域是地址管理或路径计算责任的公共范围内的任何网络元素集合。域的示例包括IGP区域、自治系统（ASE）和服务提供商网络内的多个ASE。路径计算责任域也可以作为区域或ASE的子域存在。
In order to fully characterize a PCE and clarify these definitions, the following important considerations must also be examined:
为了全面描述PCE并澄清这些定义，还必须检查以下重要注意事项：
1) Path computation is applicable in intra-domain, inter-domain, and inter-layer contexts.
1) 路径计算适用于域内、域间和层间上下文。
a. Inter-domain path computation may involve the association of topology, routing, and policy information from multiple domains from which relationships may be deduced in order to help in performing path computation.
a. 域间路径计算可能涉及来自多个域的拓扑、路由和策略信息的关联，从中可以推断关系，以帮助执行路径计算。
b. Inter-layer path computation refers to the use of PCE where multiple layers are involved and when the objective is to perform path computation at one or multiple layers while taking into account topology and resource information at these layers.
b. 层间路径计算是指在涉及多个层的情况下，当目标是在一个或多个层上执行路径计算，同时考虑这些层上的拓扑和资源信息时，使用PCE。
Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or to multiple Service Providers.
重叠域不在本文档的范围内。在域间情况下，域可能属于单个或多个服务提供商。
2) a. In "single PCE path computation", a single PCE is used to compute a given path in a domain. There may be multiple PCEs in a domain, but only one PCE per domain is involved in any single path computation.
2) A.在“单PCE路径计算”中，单PCE用于计算域中的给定路径。一个域中可能有多个PCE，但在任何单路径计算中，每个域仅涉及一个PCE。
b. In "multiple PCE path computation", multiple PCEs are used to compute a given path in a domain.
b. 在“多PCE路径计算”中，多个PCE用于计算域中的给定路径。
3) a. "Centralized computation model" refers to a model whereby all paths in a domain are computed by a single, centralized PCE.
3) A.“集中式计算模型”是指一个域中的所有路径都由一个集中式PCE计算的模型。
b. Conversely, "distributed computation model" refers to the computation of paths in a domain being shared among multiple PCEs.
b. 相反，“分布式计算模型”指在多个PCE之间共享的域中的路径计算。
Paths that span multiple domains may be computed using the distributed model with one or more PCEs responsible for each domain, or the centralized model by defining a domain that encompasses all the other domains.
可以使用一个或多个PCE负责每个域的分布式模型来计算跨越多个域的路径，或者通过定义包含所有其他域的域来计算集中式模型。
From these definitions, a centralized computation model inherently uses single PCE path computation. However, a distributed computation model could use either single PCE path computation or multiple PCE path computations. There would be no such thing as a centralized model that uses multiple PCEs.
根据这些定义，集中式计算模型本质上使用单PCE路径计算。然而，分布式计算模型可以使用单个PCE路径计算或多个PCE路径计算。没有使用多个PCE的集中式模型。
4) The PCE may or may not be located at the head-end of the path. For example, a conventional intra-domain solution is to have path computation performed by the head-end LSR of an MPLS TE LSP; in this case, the head-end LSR contains a PCE. But solutions also exist where other nodes on the path must contribute to the path computation (for example, loose hops), making them PCEs in their own right. At the same time, the path computation may be made by some other PCE physically distinct from the computed path.
4) PCE可能位于也可能不位于路径的前端。例如，传统的域内解决方案是由MPLS-TE-LSP的前端LSR执行路径计算；在这种情况下，前端LSR包含PCE。但是，如果路径上的其他节点必须参与路径计算（例如，松散跳数），则也存在解决方案，使它们能够自行进行PCE。同时，路径计算可以由物理上不同于所计算的路径的一些其他PCE进行。
5) The path computed by the PCE may be an "explicit path" (that is, the full explicit path from start to destination, made of a list of strict hops) or a "strict/loose path" (that is, a mix of strict and loose hops comprising at least one loose hop representing the destination), where a hop may be an abstract node such as an AS.
5) 由PCE计算的路径可以是“显式路径”（即，从开始到目的地的完整显式路径，由严格跳列表构成）或“严格/松散路径”（即，严格和松散跳的混合，包括表示目的地的至少一个松散跳），其中跳可以是诸如as的抽象节点。
6) A PCE-based path computation model does not mean to be exclusive and can be used in conjunction with other path computation models. For instance, the path of an inter-AS TE LSP may be computed using
6) 基于PCE的路径计算模型并不意味着是排他性的，可以与其他路径计算模型结合使用。例如，可以使用以下公式计算内部AS TE LSP的路径：
a PCE-based path computation model in some ASes, whereas the set of traversed ASes may be specified by other means (not determined by a PCE). Furthermore, different path computation models may be used for different TE LSPs.
在某些ASE中，基于PCE的路径计算模型，而遍历的ASE集可以通过其他方式指定（不由PCE确定）。此外，不同的TE-lsp可以使用不同的路径计算模型。
7) This document does not make any assumptions about the nature or implementation of a PCE. A PCE could be implemented on a router, an LSR, a dedicated network server, etc. Moreover, the PCE function is orthogonal to the forwarding capability of the node on which it is implemented.
7) 本文件不对PCE的性质或实施做出任何假设。PCE可以在路由器、LSR、专用网络服务器等上实现。此外，PCE功能与实现它的节点的转发能力正交。
Several motivations for a PCE-based architecture (described in Section 5) are listed below. This list is not meant to be exhaustive and is provided for the sake of illustration.
以下列出了基于PCE的体系结构（第5节中描述）的几个动机。本清单并非详尽无遗，仅供说明。
It should be highlighted that the aim of this section is to provide some application examples for which a PCE-based path may be suitable: this also clearly states that such a model does not aim to replace existing path computation models but would apply to specific existing or future situations.
应该强调的是，本节的目的是提供一些基于PCE的路径可能适用的应用示例：这也清楚地表明，此类模型的目的不是取代现有的路径计算模型，而是适用于特定的现有或未来情况。
As can be seen from these examples, PCE does not replace the existing Internet model where intelligence is distributed within the network. Instead, it builds on this model and makes use of distributed centers of information or computational ability. PCE should not, therefore, necessarily be seen as a centralized, "all-seeing oracle in the sky", but as the cooperative operation of distributed functionality used to address specific challenges such as the computation of a shortest inter-domain constrained path.
从这些例子中可以看出，PCE并没有取代现有的互联网模式，在这种模式中，智能分布在网络中。相反，它建立在这个模型之上，并利用分布式信息中心或计算能力。因此，PCE不一定被视为一个集中的“空中看不见的甲骨文”，而是一种分布式功能的协作操作，用于解决特定的挑战，如计算域间最短的受限路径。
There are many situations where the computation of a path may be highly CPU-intensive; examples of CPU-intensive path computations include the resolution of problems such as:
在许多情况下，路径的计算可能会占用大量CPU；CPU密集型路径计算的示例包括解决以下问题：
- Placing a set of TE LSPs within a domain so as to optimize an objective function (for example, minimization of the maximum link utilization)
- 在域内放置一组TE LSP，以优化目标函数（例如，最大链路利用率的最小化）
- Multi-criteria path computation (for example, delay and link utilization, inclusion of switching capabilities, adaptation features, encoding types and optical constraints within a GMPLS optical network)
- 多准则路径计算（例如，GMPLS光网络中的延迟和链路利用率、交换能力的包含、自适应特性、编码类型和光约束）
- Computation of minimal cost Point to Multipoint trees (Steiner trees)
- 最小代价点对多点树（Steiner树）的计算
In these situations, it may not be possible or desirable for some routers to perform path computation because of the constraints on their CPUs, in which case the path computations may be off-loaded to some other PCE(s) that may, themselves, be routers or may be dedicated PCE servers.
在这些情况下，由于其cpu上的约束，一些路由器可能不可能或不希望执行路径计算，在这种情况下，路径计算可能卸载到一些其他PCE，这些PCE本身可能是路由器或可能是专用PCE服务器。
There are several scenarios where the node responsible for path computation has limited visibility of the network topology to the destination. This limitation may occur, for instance, when an ingress router attempts to establish a TE LSP to a destination that lies in a separate domain, since TE information is not exchanged across the domain boundaries. In such cases, it is possible to use loose routes to establish the TE LSP, relying on routers at the domain borders to establish the next piece of the path. However, it is not possible to guarantee that the optimal (shortest) path will be used, or even that a viable path will be discovered except, possibly, through repeated trial and error using crankback or other signaling extensions.
有几种情况下，负责路径计算的节点对目标的网络拓扑可见性有限。例如，当入口路由器试图建立到位于单独域中的目的地的TE LSP时，可能会发生这种限制，因为TE信息不会跨域边界交换。在这种情况下，可以使用松散路由来建立TE LSP，依靠域边界处的路由器来建立下一段路径。然而，不可能保证使用最佳（最短）路径，甚至不可能发现可行路径，除非可能通过使用回退或其他信令扩展的反复试验和错误。
This problem of inter-domain path computation may most probably be addressed through distributed computation with cooperation among PCEs within each of the domains, and potentially using crankback between the domains to dynamically resolve provisioning issues. Alternatively, a central "all-seeing" PCE that has access to the complete set of topology information may be used, but in this case there are challenges of scalability (both the size of the TED and the responsiveness of a single PCE handling requests for many domains) and of preservation of confidentiality when the domains belong to different Service Providers.
域间路径计算的这个问题最有可能通过分布式计算解决，在每个域内的pce之间进行协作，并可能在域之间使用回退来动态解决供应问题。或者，可以使用能够访问完整拓扑信息集的中央“全视”PCE，但在这种情况下，存在可伸缩性方面的挑战（TED的大小和处理多个域请求的单个PCE的响应能力）以及当域属于不同的服务提供商时的保密性。
Note that the issues described here can be further highlighted in the context of TE LSP reoptimization, or the establishment of multiple diverse TE LSPs for protection or load sharing.
注意，这里描述的问题可以在TE LSP重新优化或建立多个不同的TE LSP以进行保护或负载共享的背景下进一步强调。
The traffic engineering database (TED) may be a large drain on the resources of a network node (such as an edge router or LER). Maintaining the TED may require a lot of memory and may require non-negligible CPU activity. The use of a distinct PCE may be appropriate in such circumstances, and a separate node can be used to establish and maintain the TED, and to make it available for path computation.
流量工程数据库（TED）可能是网络节点（如边缘路由器或LER）资源的巨大消耗。维护TED可能需要大量内存，并且可能需要不可忽略的CPU活动。在这种情况下，可以适当地使用不同的PCE，并且可以使用单独的节点来建立和维护TED，并使其可用于路径计算。
The IGPs run within some networks are not sufficient to build a full TED. For example, a network may run OSPF/IS-IS without the OSPF-TE/ISIS-TE extensions, or some routers in the network may not support the TE extensions. In these cases, in order to successfully compute paths through the network, the TED must be constructed or supplemented through configuration action and updated as network resources are reserved or released. Such a TED could be distributed to the routers that need to perform path computation or held centrally (on a distinct node that supports PCE) for centralized computation.
在某些网络中运行的IGP不足以构建完整的TED。例如，网络可能在没有OSPF-TE/ISIS-TE扩展的情况下运行OSPF/IS-IS，或者网络中的一些路由器可能不支持TE扩展。在这些情况下，为了成功计算通过网络的路径，必须通过配置操作构建或补充TED，并在保留或释放网络资源时更新TED。这样的TED可以分布到需要执行路径计算的路由器，或者集中（在支持PCE的不同节点上）进行集中计算。
An LER might not be part of the routing domain for administrative reasons (for example, a customer-edge (CE) router connected to the provider-edge (PE) router in the context of MPLS VPN [RFC4364] and for which it is desired to provide a CE to CE TE LSP path).
出于管理原因，LER可能不是路由域的一部分（例如，在MPLS VPN[RFC4364]的上下文中连接到提供商边缘（PE）路由器的客户边缘（CE）路由器，并且希望为其提供CE到CE TE LSP路径）。
This scenario suggests a solution that does not involve doing computation on the ingress (TE LSP head-end, CE) router, and that does not rely on the configuration of static loose hops. In this case, optimal shortest paths cannot be guaranteed. A solution that a distinct PCE can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops.
该场景提出了一种解决方案，该解决方案不涉及在入口（TE LSP头端，CE）路由器上进行计算，也不依赖于静态松散跃点的配置。在这种情况下，无法保证最优最短路径。一个独特的PCE可以在这里提供帮助的解决方案。注意，在这种情况下，PCE本身可以提供包括松散跃点的路径。
It is common in legacy optical networks for the network elements not to have a control plane or routing capability. Such network elements only have a data plane and a management plane, and all cross-connections are made from the management plane. It is desirable in this case to run the path computation on the PCE, and to send the cross-connection commands to each node on the computed path. That is, the PCC would be an element of the management plane, perhaps residing in the Network Management System (NMS) or Operations Support System (OSS).
在传统光网络中，网元通常不具有控制平面或路由能力。这种网元只有一个数据平面和一个管理平面，所有交叉连接都是从管理平面进行的。在这种情况下，希望在PCE上运行路径计算，并将交叉连接命令发送到计算路径上的每个节点。也就是说，PCC将是管理平面的一个元素，可能位于网络管理系统（NMS）或操作支持系统（OSS）中。
This scenario is important for Automatically Switched Optical Network (ASON)-capable networks and may also be used for interworking between GMPLS-capable and GMPLS-incapable networks.
该场景对于支持自动交换光网络（ASON）的网络非常重要，也可用于支持GMPLS和不支持GMPLS的网络之间的互通。
A PCE can be used to compute backup paths in the context of fast reroute protection of TE LSPs. In this model, all backup TE LSPs protecting a given facility are computed in a coordinated manner by a PCE. This allows complete bandwidth sharing between backup tunnels protecting independent elements, while avoiding any extensions to TE
PCE可用于在TE LSP的快速重路由保护上下文中计算备份路径。在该模型中，保护给定设施的所有备用TE LSP由PCE以协调方式计算。这允许备份隧道之间完全共享带宽，以保护独立的元素，同时避免对TE的任何扩展
LSP signaling. Both centralized and distributed computation models are applicable. In the distributed case each LSR can be a PCE to compute the paths of backup tunnels to protect against the failure of adjacent network links or nodes.
LSP信令。集中式和分布式计算模型都适用。在分布式情况下，每个LSR可以是一个PCE，用于计算备份隧道的路径，以防止相邻网络链路或节点出现故障。
A server-layer network of one switching capability may support multiple networks of another (more granular) switching capability. For example, a Time-Division Multiplexing (TDM) network may provide connectivity for client-layer networks such as IP, MPLS, or Layer 2 [MLN].
一个交换能力的服务器层网络可以支持另一个（更细粒度）交换能力的多个网络。例如，时分复用（TDM）网络可以为诸如IP、MPLS或第2层MLN之类的客户端层网络提供连接。
The server-layer network is unlikely to provide the same connectivity paradigm as the client networks, so bandwidth granularity in the server-layer network may be much coarser than in the client-layer network. Similarly, there is likely to be a management separation between the two networks providing independent address spaces. Furthermore, where multiple client-layer networks make use of the same server-layer network, those client-layer networks may have independent policies, control parameters, address spaces, and routing preferences.
服务器层网络不可能提供与客户端网络相同的连接范例，因此服务器层网络中的带宽粒度可能比客户端层网络中的带宽粒度粗得多。类似地，提供独立地址空间的两个网络之间可能存在管理分离。此外，当多个客户端层网络使用同一服务器层网络时，这些客户端层网络可能具有独立的策略、控制参数、地址空间和路由首选项。
The different client- and server-layer networks may be considered distinct path computation regions within a PCE domain, so the PCE architecture is useful to allow path computation from one client-layer network region, across the server-layer network, to another client-layer network region.
不同的客户端和服务器层网络可被视为PCE域内的不同路径计算区域，因此PCE架构可用于允许从一个客户端层网络区域跨服务器层网络到另一个客户端层网络区域的路径计算。
In this case, the PCEs are responsible for resolving address space issues, handling differences in policy and control parameters, and coordinating resources between the networks. Note that, because of the differences in bandwidth granularity, connectivity across the server-layer network may be provided through virtual TE links or Forwarding Adjacencies: the PCE may offer a point of control responsible for the decision to provision new TE links or Forwarding Adjacencies across the server-layer network.
在这种情况下，PCE负责解决地址空间问题，处理策略和控制参数的差异，并协调网络之间的资源。注意，由于带宽粒度的差异，跨服务器层网络的连接可以通过虚拟TE链路或转发邻接来提供：PCE可以提供一个控制点，负责决定跨服务器层网络提供新TE链路或转发邻接。
A PCE may have a local policy that impacts path computation and selection in response to a path computation request. Such policy may act on information provided by the requesting PCC. The result of applying such policy includes, for example, rejection of the path computation request, or provision of a path that does not meet all of the requested constraints. Further, the policy may support
PCE可以具有响应于路径计算请求而影响路径计算和选择的本地策略。此类政策可根据请求PCC提供的信息采取行动。应用这种策略的结果包括，例如，拒绝路径计算请求，或提供不满足所有请求约束的路径。此外，该政策可能支持
administratively configured paths, or selection among transit providers. Inclusion of policy within PCE may simplify the application of policy within the path computation/selection process.
管理配置的路径，或传输提供程序之间的选择。在PCE中包含策略可以简化路径计算/选择过程中策略的应用。
Similarly, a PCC may apply local policy to the selection of a PCE to compute a specific path, and to the constraints that are requested.
类似地，PCC可将本地策略应用于PCE的选择以计算特定路径，以及应用于所请求的约束。
In a PCE context, the policy may be sensitive to the type of path that is being computed. For example, a different set of policies may be applied for an intra-area or single-layer path than would be provided for an inter-area or multi-layer path.
在PCE上下文中，策略可能对正在计算的路径类型敏感。例如，可以为区域内或单层路径应用与将为区域间或多层路径提供的不同的策略集。
Note that synchronization of policy between PCEs or between PCCs and PCEs may be necessary. Such issues are outside the scope of the PCE architecture, but within scope for the PCE policy framework and application which is described in a separate document.
请注意，可能需要在PCE之间或PCC与PCE之间同步策略。此类问题不在PCE体系结构的范围内，但在单独文件中描述的PCE政策框架和应用的范围内。
PCE is not considered to be a solution that is applicable to the entire Internet. That is, the applicability of PCE is limited to a set of domains with known relationships. The scale of this limitation is similar to the peering relationships between Service Providers.
PCE不被认为是适用于整个互联网的解决方案。也就是说，PCE的适用性仅限于一组具有已知关系的域。这种限制的规模类似于服务提供商之间的对等关系。
When two or more paths for TE LSPs are computed on the same set of TE link state information, it is possible that the resultant paths will compete for limited resources within the network. This may result in success for only the first TE LSP to be signaled, or it might even mean that no TE LSP can be established.
当根据同一组TE链路状态信息计算TE lsp的两个或多个路径时，结果路径可能会在网络内竞争有限的资源。这可能导致仅发送第一个TE LSP成功，或者甚至可能意味着无法建立TE LSP。
Batch processing of computation requests, back-off times, computation of alternate paths, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup. However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state.
批量处理计算请求、退避时间、计算备用路径和回退有助于缓解此类问题，PCE也可以提高成功设置TE LSP的机会。然而，单个集中式PCE不被视为能够保证TE LSP建立的解决方案，因为在集中式TED不能完全反映当前（即实时）网络状态的情况下，仍然存在网络故障或资源争用的可能性。
This section gives an overview of the architecture of the PCE model. It needs to be read in conjunction with the details provided in the next section to provide a full view of the flexibility of the model.
本节概述了PCE模型的体系结构。需要结合下一节中提供的详细信息阅读，以全面了解模型的灵活性。
Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests to provision TE LSPs are received by the node and converted into signaling requests, but this conversion may require path computation that is requested from a PCE. The PCE operates on the TED subject to local policy in order to respond with the requested path.
下面的图1显示了利用路径计算的典型复合PCE节点（即，也实现PCE功能的路由器）的组件。路由协议用于交换构造TED的TE信息。提供TE lsp的服务请求由节点接收并转换为信令请求，但是该转换可能需要从PCE请求的路径计算。PCE根据本地政策在TED上运行，以便使用请求的路径进行响应。
---------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- | | |
| | | | | Adjacent |
| | PCE | | | Node |
| | | | | |
| --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------
---------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- | | |
| | | | | Adjacent |
| | PCE | | | Node |
| | | | | |
| --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------
Figure 1. Composite PCE Node
图1。复合PCE节点
Note that the routing adjacency between the composite PCE node and any other router may be performed by means of direct connectivity or any tunneling mechanism.
注意，复合PCE节点和任何其他路由器之间的路由邻接可以通过直接连接或任何隧道机制来执行。
Figure 2 shows a PCE that is external to the requesting network element. A service request is received by the head-end node, and before it can initiate signaling to establish the service, it makes a path computation request to the external PCE. The PCE uses the TED subject to local policy as input to the computation and returns a response.
图2显示了请求网元外部的PCE。前端节点接收到服务请求，并且在其能够发起信令以建立服务之前，它向外部PCE发出路径计算请求。PCE使用受本地策略约束的TED作为计算的输入，并返回响应。
----------
| ----- |
| | TED |<-+----------->
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
----------
| ----- |
| | TED |<-+----------->
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
Figure 2. External PCE Node
图2。外部PCE节点
Note that in this case, the node that supports the PCE function may also be an LSR or router performing forwarding in its own right (i.e., it may be a composite PCE node), but those functions are purely orthogonal to the operation of the function in the instance being considered here.
注意，在这种情况下，支持PCE功能的节点也可以是本身执行转发的LSR或路由器（即，它可以是复合PCE节点），但是这些功能与这里考虑的实例中的功能的操作完全正交。
Figure 3 illustrates how multiple PCE path computations may be performed along the path of a signaled service. As in the previous example, the head-end PCC makes a request to an external PCE, but the path that is returned is such that the next network element finds it necessary to perform further computation. This may be the case when the path returned is a partial path that does not reach the intended destination or when the computed path is loose. The downstream network element consults another PCE to establish the next hop(s) in the path. In this case, all policy decisions are made independently at each PCE based on information passed from the PCC.
图3说明了如何沿信号服务的路径执行多个PCE路径计算。如前一示例中所示，前端PCC向外部PCE发出请求，但是返回的路径使得下一个网元发现有必要执行进一步的计算。当返回的路径是未到达预期目的地的部分路径时，或者当计算的路径松散时，可能会出现这种情况。下游网元咨询另一PCE以建立路径中的下一跳。在这种情况下，所有政策决策都是在每个PCE根据PCC传递的信息独立做出的。
Note that either or both PCEs in this case could be composite PCE nodes, as in Section 5.1.
注意，在这种情况下，一个或两个PCE可以是复合PCE节点，如第5.1节所示。
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request |Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request |Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 3. Multiple PCE Path Computation
图3。多PCE路径计算
The PCE in Section 5.3 was not able to supply a full path for the requested service, and as a result the adjacent node needs to make its own computation request. As illustrated in Figure 4, the same problem may be solved by introducing inter-PCE communication, and cooperation between PCEs so that the PCE consulted by the head-end network node makes a request of another PCE to help with the computation.
第5.3节中的PCE无法为请求的服务提供完整路径，因此相邻节点需要发出自己的计算请求。如图4所示，可以通过引入PCE间通信和PCE之间的协作来解决相同的问题，以便由前端网络节点咨询的PCE请求另一PCE来帮助计算。
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
图4。具有PCE间通信的多PCE路径计算
Multiple PCE path computation with inter-PCE communication involves coordination between distinct PCEs such that the result of the computation performed by one PCE depends on path fragment information supplied by other PCEs. This model does not provide a distributed computation algorithm, but it allows distinct PCEs to be responsible for computation of parts (segments) of the path.
具有PCE间通信的多PCE路径计算涉及不同PCE之间的协调，使得由一个PCE执行的计算的结果取决于由其他PCE提供的路径片段信息。该模型不提供分布式计算算法，但允许不同的PCE负责路径部分（段）的计算。
PCE-PCE communication is discussed further in Section 6.6.
第6.6节将进一步讨论PCE-PCE通信。
Note that a PCC might not see the difference between centralized computation and multiple PCE path computation with inter-PCE communication. That is, the PCC network node or component that requests the computation makes a single request and receives a full or partial path in response, but the response is actually achieved through the coordinated, cooperative efforts of more than one PCE.
注意，PCC可能看不到集中计算和具有PCE间通信的多PCE路径计算之间的区别。也就是说，请求计算的PCC网络节点或组件发出单个请求并接收完整或部分路径作为响应，但是该响应实际上是通过多个PCE的协调、协作努力来实现的。
In this model, all policy decisions may be made independently at each PCE based on computation information passed from the previous PCE. Alternatively, there may be explicit communication of policy information between PCEs.
在该模型中，所有策略决策可在每个PCE处基于从先前PCE传递的计算信息独立作出。或者，PCE之间可能存在政策信息的明确沟通。
It must be observed that the PCC is not necessarily an LSR. For example, in Figure 5 the NMS supplies the head-end LSR with a fully computed explicit path for the TE LSP that it is to establish through signaling. The NMS uses a management plane mechanism to send this request and encodes the data using a representation such as the TE MIB module [RFC3812].
必须注意，PCC不一定是LSR。例如，在图5中，NMS为前端LSR提供了一个完全计算的显式路径，供TE LSP通过信令建立。NMS使用管理平面机制发送该请求，并使用诸如TE MIB模块[RFC3812]之类的表示对数据进行编码。
The NMS constructs the explicit path that it supplies to the head-end LSR using information provided by the operator. It consults the PCE, which returns a path for the NMS to use.
NMS使用操作员提供的信息构造提供给前端LSR的显式路径。它咨询PCE，后者返回NMS使用的路径。
Although Figure 5 shows the PCE as remote from the NMS, it could, of course, be collocated with the NMS.
尽管图5显示PCE远离NMS，但它当然可以与NMS并置。
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 5. Management-Based PCE Usage
图5。基于管理的PCE使用
The following areas require standardization within the PCE architecture.
以下领域需要PCE架构内的标准化。
- communication between PCCs and PCEs, and between cooperating PCEs, including the communication of policy-related information
- PCC和PCE之间以及合作PCE之间的通信，包括政策相关信息的通信
- requirements for extending existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths
- 扩展现有路由和信令协议以支持PCE发现和域间路径信令的要求
- definition of metrics to evaluate path quality, scalability, responsiveness, robustness, and policy support of path computation models.
- 定义用于评估路径计算模型的路径质量、可伸缩性、响应性、健壮性和策略支持的度量。
- MIB modules related to communication protocols, routing and signaling extensions, metrics, and PCE monitoring information
- 与通信协议、路由和信令扩展、度量和PCE监控信息相关的MIB模块
This section provides a list of the PCE architectural components. Specific realizations and implementation details (state machines or algorithms, etc.) of PCE-based solutions are out of the scope of this document.
本节提供了PCE体系结构组件的列表。基于PCE的解决方案的具体实现和实现细节（状态机或算法等）不在本文档范围内。
Note also that PCE-based path computation does not affect in any way the use of the computed paths. For example, the use of PCE does not change the way in which Traffic Engineering LSPs are signaled, maintained, and torn down, but it strictly relates to the path computation aspects of such TE LSPs.
还要注意，基于PCE的路径计算不会以任何方式影响计算路径的使用。例如，PCE的使用不会改变交通工程LSP的信号发送、维护和拆除方式，但它严格地与此类TE LSP的路径计算方面相关。
This section presents an architectural view of PCE. That is, it describes the components that exist and how they interact. Note that the architectural model, and in particular the functional model, may be perceived differently by different components of the PCE system. For example, the PCC will not be aware of whether a PCE consults other PCEs. The PCC view of the PCE architecture is discussed in Section 7.
本节介绍PCE的体系结构视图。也就是说，它描述了存在的组件及其交互方式。请注意，架构模型，尤其是功能模型，可能会被PCE系统的不同组件以不同的方式感知。例如，PCC将不知道一个PCE是否会咨询其他PCE。PCE架构的PCC视图在第7节中讨论。
A "centralized computation model" considers that all path computations for a given domain will be performed by a single, centralized PCE. This may be a dedicated server (for example, an external PCE node), or a designated router (for example, a composite PCE node) in the network. In this model, all PCCs in the domain would send their path computation requests to the central PCE. While
“集中式计算模型”认为给定域的所有路径计算将由单个集中式PCE执行。这可以是网络中的专用服务器（例如，外部PCE节点）或指定路由器（例如，复合PCE节点）。在该模型中，域中的所有PCC将向中心PCE发送其路径计算请求。虽然
a domain in this context might be an IGP area or AS, it might also be a sub-group of network nodes that is defined by its dependence on the PCE.
在此上下文中的域可能是IGP区域或AS，也可能是由其对PCE的依赖性定义的网络节点的子组。
This model has a single point of failure: the PCE. In order to avoid this issue, the centralized computation model may designate a backup PCE that can take over the computation responsibility in a controlled manner in the event of a failure of the primary PCE. Any policies present on the primary PCE should also be present on the backup, although the primary policies may themselves be subject to policy governing how they are implemented on the backup. Note that at any moment in time there is only one active PCE in any domain.
该模型只有一个故障点：PCE。为了避免这个问题，集中计算模型可以指定一个备份PCE，该备份PCE可以在主PCE发生故障时以受控方式接管计算责任。主PCE上存在的任何策略也应存在于备份上，尽管主策略本身可能受控制如何在备份上实施它们的策略的约束。请注意，在任何时刻，任何域中都只有一个活动PCE。
A "distributed computation model" refers to a domain or network that may include multiple PCEs, and where computation of paths is shared among the PCEs. A given path may in turn be computed by a single PCE ("single PCE path computation") or multiple PCEs ("multiple PCE path computation"). A PCC may be linked to a particular PCE or may be able to choose freely among several PCEs; the method of choice between PCEs is out of scope of this document, but see Section 6.4 for a discussion of PCE discovery that affects this choice. Implementation of policy should be consistent across the set of available PCEs.
“分布式计算模型”是指可以包括多个pce的域或网络，其中路径计算在pce之间共享。给定路径可依次由单个PCE（“单PCE路径计算”）或多个PCE（“多PCE路径计算”）计算。PCC可以链接到特定PCE，或者可以在多个PCE中自由选择；PCE之间的选择方法超出了本文件的范围，但有关影响此选择的PCE发现的讨论，请参见第6.4节。政策的实施应在所有可用PCE之间保持一致。
Often, the computation of an individual path is performed entirely by a single PCE. For example, this is usually the case in MPLS TE within a single IGP area where the ingress LSR/composite PCE node is responsible for computing the path or for contacting an external PCE. Conversely, multiple PCE path computation implies that more than one PCE is involved in the computation of a single path. An example of this is where loose hop expansion is performed by transit LSRs/composite PCE nodes on an MPLS TE LSP. Another example is the use of multiple cooperating PCEs to compute the path of a single TE LSP across multiple domains.
通常，单个路径的计算完全由单个PCE执行。例如，这通常是在单个IGP区域内的MPLS TE中的情况，其中入口LSR/复合PCE节点负责计算路径或联系外部PCE。相反，多PCE路径计算意味着一条路径的计算涉及多个PCE。这方面的一个例子是，通过MPLS TE LSP上的传输lsr/复合PCE节点执行松跳扩展。另一个例子是使用多个协作pce来计算跨多个域的单个TE LSP的路径。
Often, multiple paths need to be computed to support a single service (for example, for protection or load sharing). A PCC that determines that it requires more than one path to be computed may send a series of individual requests to the PCE. In this case of non-synchronized path computation requests, the PCE may make multiple individual path computations to generate the paths, and the PCC may send its individual requests to different PCEs.
通常，需要计算多条路径以支持单个服务（例如，用于保护或负载共享）。确定需要计算多条路径的PCC可以向PCE发送一系列单独的请求。在非同步路径计算请求的这种情况下，PCE可以进行多个单独的路径计算以生成路径，并且PCC可以将其单独的请求发送到不同的PCE。
Alternatively, the PCC may send a single request to a PCE asking for a set of paths to be computed, but specifying that non-synchronized path computation is acceptable. The PCE may compute each path in turn exactly as it would have done had the PCC made multiple requests, and the PCE may devolve some computations to other PCEs if it chooses. On the other hand, the PCE is not prohibited from performing all computations together in a synchronized manner as described below.
或者，PCC可以向PCE发送单个请求，请求计算一组路径，但指定非同步路径计算是可接受的。PCE可以像PCC发出多个请求一样依次计算每条路径，并且如果PCE选择，可以将一些计算转移到其他PCE。另一方面，不禁止PCE以如下所述的同步方式一起执行所有计算。
The PCC may also issue a single request to the PCE asking for all the paths to be computed in a synchronized manner. The PCE will then perform simultaneous computation of the set of requested paths. Such synchronized computation can often provide better results.
PCC还可以向PCE发出单个请求，请求以同步方式计算所有路径。然后，PCE将同时执行所请求路径集的计算。这种同步计算通常可以提供更好的结果。
The involvement of more than one PCE in the computation of a series of paths is by its nature non-synchronized. However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC may send a request to a PCE that invokes domain-specific computations by other PCEs before supplying a result to the PCC.
多个PCE参与一系列路径的计算本质上是不同步的。然而，可以在单个PCE的控制下同步一组协作PCE。例如，PCC可以向PCE发送请求，该请求在向PCC提供结果之前调用其他PCE的域特定计算。
It is desirable to add a parameter to the PCC-PCE protocol to request that the PCE supply a set of alternate paths for use by the PCC, should the establishment of the TE LSP using the principal path fail to complete. While alternate paths may not always be successful if the first path fails, including alternate paths in a PCE response could have less overhead than having the PCC make separate requests for subsequent path computations as the need arises. This technique is used in some existing CSPF implementations.
希望向PCC-PCE协议添加一个参数，以请求PCE提供一组备用路径供PCC使用，前提是使用主路径的TE LSP的建立未能完成。然而，如果第一条路径失败，则备用路径可能并不总是成功的，包括PCE响应中的备用路径可能比PCC在需要时为后续路径计算发出单独请求的开销更小。这种技术在一些现有的CSPF实现中使用。
In order that a PCC can communicate efficiently with a PCE, it must know the location of the PCE. That is, it is an architectural decision made here that PCC requests be targeted to a specific PCE, and not broadcast to the network for any PCE to respond. This decision means that only the selected PCE will operate on any single request, and it saves network resources during request propagation and processing resources at the PCEs that are not required to respond.
为了使PCC能够有效地与PCE通信，它必须知道PCE的位置。也就是说，这里做出的架构决策是，PCC请求以特定PCE为目标，而不是广播到网络以供任何PCE响应。此决定意味着只有选定的PCE将对任何单个请求进行操作，并且它在请求传播期间节省网络资源，并在PCE处处理不需要响应的资源。
The knowledge of the location of a PCE may be achieved through local configuration at the PCC or may rely on a protocol-based discovery mechanism that may be governed by policy.
PCE的位置的知识可以通过PCC处的本地配置来实现，或者可以依赖于可由策略管理的基于协议的发现机制。
Where more than one PCE is known to a PCC, the PCC must have sufficient information to select an appropriate PCE for its purposes, under the control of policy. Such a selection procedure allows for
如果PCC知道一个以上的PCE，PCC必须有足够的信息在政策的控制下为其目的选择合适的PCE。这样的选择程序允许
load sharing between PCEs and supports PCEs with different computation capabilities including different visibility scopes. Thus, the information available to the PCC must include details of the PCE capabilities, which may be fixed or may vary dynamically in time.
PCE之间的负载共享，支持具有不同计算能力（包括不同可见性范围）的PCE。因此，PCC可用的信息必须包括PCE能力的详细信息，这些信息可能是固定的，也可能随时间动态变化。
The PCC may learn PCE capabilities through static configuration, or it may discover the information dynamically. Note that even when the location of the PCE is configured at the PCC, the PCC may still discover the PCE capabilities dynamically. Dynamic PCE capabilities cannot be configured and can only be discovered.
PCC可以通过静态配置学习PCE能力，也可以动态发现信息。注意，即使在PCC处配置了PCE的位置，PCC仍然可以动态地发现PCE能力。动态PCE功能无法配置，只能被发现。
Proxy PCE advertisement whereby the existence of a PCE is advertised via a proxy PCE is a viable alternative, should the PCE be incapable of such advertisement itself. In this case, it is a requirement that the proxy adequately advertise the PCE status and capability in a timely and synchronized fashion.
如果PCE本身无法进行此类广告，则通过代理PCE广告PCE的存在是可行的替代方案。在这种情况下，要求代理及时同步地充分公布PCE状态和能力。
In the event that multiple PCEs are available to serve a particular path computation request, the PCC must select a PCE to satisfy the request. The details of such a selection (for instance, to efficiently share the computation load across multiple PCEs or to request secondary computations after partial or failed computations) are local to the PCC, may be based on policy, and are out of the scope of this document.
在多个PCE可用于服务特定路径计算请求的情况下，PCC必须选择一个PCE来满足该请求。此类选择的详细信息（例如，在多个PCE之间有效地共享计算负载或在部分或失败计算后请求二次计算）是PCC的本地信息，可能基于策略，不在本文档的范围内。
PCE capabilities that may be advertised or configured could include (and are not be limited to):
可公布或配置的PCE功能包括（但不限于）：
- a set of constraints that it can account for (diversity, shared risk link groups (SRLGs), optical impairments, wavelength continuity, etc.)
- 它可以解释的一组约束（多样性、共享风险链路组（SRLGs）、光学损伤、波长连续性等）
- computational capacity (for example, the number of computations it can perform per second)
- 计算能力（例如，它每秒可以执行的计算数量）
- the number of switching capability layers (and which ones)
- 交换能力层的数量（以及哪些层）
- the number of path selection criteria (and which ones)
- 路径选择条件的数量（以及哪些条件）
- whether it is a stateless PCE or it can send updates about better paths that might be available in the future
- 无论它是无状态PCE还是可以发送关于将来可能可用的更好路径的更新
- whether it can compute P2MP trees (and which types)
- 是否可以计算P2MP树（以及哪些类型）
- whether it can ensure resource sharing between backup tunnels
- 是否可以确保备份隧道之间的资源共享
This information would help a PCC to decide which PCE to use.
这些信息将有助于PCC决定使用哪种PCE。
Requirements for PCE advertisement will be documented separately. Note that there is no restriction within the architecture about how location and capabilities are advertised, and the two elements should be considered functionally distinct.
PCE广告的要求将单独记录。请注意，体系结构中没有关于位置和功能的广告方式的限制，这两个元素在功能上应该是不同的。
A PCC might also ask a PCE to perform a particular type of service without knowledge of the PCE's capabilities and receive a response that says that the PCE is unable to perform the service. The response could specify the capabilities of the PCE and might also suggest another PCE that has the requested capabilities.
PCC还可能要求PCE在不了解PCE能力的情况下执行特定类型的服务，并接收到PCE无法执行服务的响应。该响应可以指定PCE的能力，还可以建议另一个具有所请求能力的PCE。
The ability to detect a PCE's liveness is a mandatory piece of the overall architecture and could be achieved by several means. If some form of regular advertisement (such as through IGP extensions) is used for PCE discovery, it is expected that the PCE liveness will be determined by means of status advertisement (for example, IGP LSA/LSPs).
检测PCE活性的能力是整个体系结构的一部分，可以通过多种方式实现。如果某种形式的常规广告（例如通过IGP扩展）用于PCE发现，则预计PCE活性将通过状态广告（例如，IGP LSA/LSP）来确定。
The inability of a PCE to service a request (perhaps due to excessive load) may be reported to the PCC through a failure message, but the failure of a PCE or the communications mechanism while processing a request cannot be reported in this way. Furthermore, in the case of excessive load, the PCE may not have sufficient resources to send a failure message. Thus, the PCC should employ other mechanisms, such as protocol timers, to determine the liveness of the PCE. This is particularly important in the case of inter-domain path computation where the PCE liveness may not be detected by means of the IGP that runs in the PCC's domain.
PCE不能服务于请求（可能由于过度负载）可以通过故障消息报告给PCC，但是在处理请求时不能以这种方式报告PCE或通信机制的故障。此外，在过度负载的情况下，PCE可能没有足够的资源来发送故障消息。因此，PCC应该采用其他机制，例如协议定时器，来确定PCE的活跃度。这在域间路径计算的情况下尤其重要，其中PCE活性可能无法通过在PCC的域中运行的IGP来检测。
Once the PCC has selected a PCE, and provided that the PCE is not local to the PCC, a request/response protocol is required for the PCC to communicate the path computation requests to the PCE and for the PCE to return the path computation response. Discussion of the security requirements and implications for this protocol is provided in Section 10 of this document.
一旦PCC选择了PCE，并且假设PCE不是PCC本地的，则PCC需要请求/响应协议来将路径计算请求传送到PCE并且PCE返回路径计算响应。本文件第10节讨论了本协议的安全要求和影响。
The path computation request may include a significant set of requirements, including the following:
路径计算请求可以包括一组重要的需求，包括以下内容：
- the source and destination of the path
- 路径的源和目标
- the bandwidth and other Quality of Service (QoS) parameters desired
- 所需的带宽和其他服务质量（QoS）参数
- resources, resource affinities, and shared risk link groups (SRLGs) to use/avoid
- 要使用/避免的资源、资源亲缘关系和共享风险链接组（SRLGs）
- the number of disjoint paths required and whether near-disjoint paths are acceptable
- 所需的不相交路径数，以及是否可以接受接近不相交的路径
- the levels of resiliency, reliability, and robustness of the path resources
- 路径资源的弹性、可靠性和健壮性级别
- policy-related information
- 政策相关信息
The level of robustness of the path resources covers a qualitative assessment of the vulnerability of the resources that may be used. For example, one might grade resources based on empirical evidence (mean time between failures), on known risks (there is major building work going on near this conduit), or on prejudice (vendor X's software is always crashing). A PCC could request that only robust resources be used, or it could allow any resource.
路径资源的稳健性水平包括对可能使用的资源的脆弱性进行定性评估。例如，可以根据经验证据（平均无故障时间）、已知风险（该管道附近正在进行重大建筑工程）或偏见（供应商X的软件总是崩溃）对资源进行评级。PCC可以请求只使用健壮的资源，也可以允许使用任何资源。
In case of a positive response from the PCE, one or more paths would be returned to the requesting node. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure(s), and potentially with advice about which constraints might be relaxed so that a positive result is more likely in a future request.
在来自PCE的肯定响应的情况下，一个或多个路径将返回到请求节点。在计算所需路径失败的情况下，将返回一个错误，并尽可能多地提供有关失败原因的信息，还可能提供关于哪些约束可能会被放宽的建议，以便在未来的请求中更可能得到积极的结果。
Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
注意，结果路径可以由一组严格跳或松散跳组成，或者由严格跳和松散跳的任意组合组成。此外，跳可以具有非显式抽象节点的形式。
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for the PCE to return the path computation response. The path computation request may include a significant set of requirements including those defined above. In case of a positive response from the PCE, one or more paths would be returned to the requesting PCE. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed so that a positive result is more likely. Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
PCE还需要请求/响应协议来将路径计算请求传送到另一PCE，并且PCE返回路径计算响应。路径计算请求可以包括一组重要的需求，包括上面定义的需求。在来自PCE的肯定响应的情况下，一个或多个路径将返回到请求PCE。如果无法计算所需的路径，则会返回一个错误，并尽可能多地提供有关失败原因的信息，以及关于哪些约束可能会被放宽的建议，以便更有可能得到积极的结果。注意，结果路径可以由一组严格跳或松散跳组成，或者由严格跳和松散跳的任意组合组成。此外，跳可以具有非显式抽象节点的形式。
An important feature of PCEs that are cooperating to compute a path is that they apply compatible or identical computation algorithms and coordinated policies. This may require coordination through the communication between the PCEs.
协同计算路径的PCE的一个重要特征是，它们应用兼容或相同的计算算法和协调策略。这可能需要通过PCE之间的通信进行协调。
Note that when multiple PCEs cooperate to compute a path, it is important that they have a coordinated view of the meaning of constraints such as costs, resource affinities, and class of service. This is particularly significant where the PCEs are responsible for different domains. It is assumed that this is a matter of policy between domains and between PCEs.
请注意，当多个PCE合作计算路径时，重要的是它们对约束的含义（如成本、资源亲缘关系和服务类别）有一个协调的视图。这在PCE负责不同领域的情况下尤为重要。假设这是域之间和PCE之间的政策问题。
No assumption is made in this architecture about whether the PCC-PCE and PCE-PCE communication protocols are identical.
在该体系结构中，没有假设PCC-PCE和PCE-PCE通信协议是否相同。
As previously described, the PCE operates on a TED. Information on network status to build the TED may be provided in the domain by various means:
如前所述，PCE在TED上工作。可通过各种方式在域中提供构建TED的网络状态信息：
1) Participation in IGP distribution of TE information. The standard method of distribution of TE information within an IGP area is through the use of extensions to the IGP [RFC3630, RFC3748]. This mechanism allows participating nodes to build a TED, and this is the standard technique, for example, within a single area MPLS or GMPLS network. A node that hosts the PCE function may collect TE information in this way by maintaining at least one routing adjacency with a router in the domain. The PCE node may be adjacent or non-adjacent (via some tunneling techniques) to the router. Such a technique provides a mechanism for ensuring that the TED is efficiently synchronized with the network state and is the normal case, for example, when the PCE is co-resident with the LSRs in an MPLS or GMPLS network.
1) 参与IGP TE信息的分发。IGP区域内TE信息分布的标准方法是通过使用IGP的扩展[RFC3630，RFC3748]。该机制允许参与节点构建TED，这是标准技术，例如，在单区域MPLS或GMPLS网络中。承载PCE功能的节点可以通过与域中的路由器保持至少一个路由邻接来以这种方式收集TE信息。PCE节点可以与路由器相邻或不相邻（通过一些隧道技术）。这种技术提供了确保TED与网络状态有效同步的机制，并且是正常情况，例如，当PCE与MPLS或GMPLS网络中的lsr共存时。
2) Out-of-band TED synchronization. It may not be convenient or possible for a PCE to participate in the IGPs of one or more domains (for example, when there are very many domains, when IGP participation is not desired, or when some domains are not running TE-aware IGPs). In this case, some mechanism may need to be defined to allow the PCE node to retrieve the TED from each domain. Such a mechanism could be incremental (like the IGP in the previous case), or it could involve a bulk transfer of the complete TED. The latter might significantly limit the capability to ensure TED synchronization, which might result in an increase in the failure rate of computed paths, or the computation of sub-optimal paths. Consideration should also be given to the impact of the TED distribution on the network and on the network node within the domain that is asked to distribute the database. This is particularly relevant in the case of frequent network state changes.
2) 带外TED同步。PCE参与一个或多个域的IGP可能不方便或不可能（例如，当存在很多域时，当不需要IGP参与时，或当一些域没有运行TE感知IGP时）。在这种情况下，可能需要定义一些机制，以允许PCE节点从每个域检索TED。这种机制可以是增量的（如前一个案例中的IGP），也可以涉及整个TED的批量传输。后者可能会显著限制确保TED同步的能力，这可能导致计算路径的故障率增加或次优路径的计算。还应考虑TED分发对网络和要求分发数据库的域内网络节点的影响。这在网络状态频繁变化的情况下尤为重要。
3) Information in the TED can include information obtained from sources other than the IGP. For example, information about link usage policies can be configured by the operator. Path computation can also act on a far wider set of information that includes data about the TE LSPs provisioned within the network. This information can include TE LSP routes, reserved bandwidth, and measured traffic volume passing through the TE LSP.
3) TED中的信息可以包括从IGP以外的来源获得的信息。例如，有关链路使用策略的信息可以由操作员配置。路径计算还可以作用于更广泛的信息集，该信息集包括关于网络内供应的TE lsp的数据。该信息可以包括TE-LSP路由、保留带宽和通过TE-LSP的测量流量。
Such TE LSP information can enhance TE LSP (re)optimization to provide "full network" (re)optimization and can allow traffic fluctuations to be taken into account. Detailed TE LSP information may also facilitate reconfiguration of the Virtual Network Topology (VNT) [MLN], in which lower-layer TE LSPs, such as optical paths, provide TE links for use by the higher layer, since this reconfiguration is also a "full network" problem.
此类TE-LSP信息可增强TE-LSP（re）优化以提供“全网络”（re）优化，并可允许考虑流量波动。详细的TE-LSP信息还可促进虚拟网络拓扑（VNT）[MLN]的重新配置，其中较低层TE-LSP（例如光路径）提供TE链路供较高层使用，因为该重新配置也是“全网络”问题。
Note that synchronization techniques may apply to both intra- and inter-domain TEDs. Furthermore, the techniques can be mixed for use in different domains. The degree of synchronization between the PCE and the network is subject to implementation and/or policy. However, better synchronization generally leads to paths that are more likely to succeed.
注意，同步技术可应用于域内和域间TED。此外，这些技术可以混合用于不同的领域。PCE和网络之间的同步程度取决于实施和/或策略。但是，更好的同步通常会导致更可能成功的路径。
Note also that the PCE may have access to only a partial TED: for instance, in the case of inter-domain path computation where each such domain may be managed by different entities. In such cases, each PCE may have access to a partial TED, and cooperative techniques between PCEs may be used to achieve end-to-end path computation without any requirement that any PCE handle the complete TED related to the set of traversed domains by the TE LSP in question.
还要注意，PCE可以仅访问部分TED：例如，在域间路径计算的情况下，其中每个这样的域可以由不同的实体管理。在这种情况下，每个PCE可以访问部分TED，并且可以使用PCE之间的协作技术来实现端到端路径计算，而不需要任何PCE处理与所述TE LSP遍历的域集相关的完整TED。
A PCE can be either stateful or stateless. In the former case, there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network. In other words, the PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests. Note that although this allows for optimal path computation and increased path computation success, stateful PCEs require reliable state synchronization mechanisms, with potentially significant control plane overhead and the maintenance of a large amount of data/states (for example, full mesh of TE LSPs).
PCE可以是有状态的，也可以是无状态的。在前一种情况下，PCE不仅与网络状态（根据拓扑和资源信息），而且与网络中使用的计算路径和保留资源集之间存在严格的同步。换句话说，PCE在处理新请求时利用来自TED的信息以及关于网络中现有路径（例如，TE lsp）的信息。注意，尽管这允许最佳路径计算和增加路径计算成功率，但有状态PCE需要可靠的状态同步机制，具有潜在的显著控制平面开销和大量数据/状态的维护（例如，TE LSP的全网格）。
For example, if there is only one PCE in the domain, all TE LSP computation is done by this PCE, which can then track all the existing TE LSPs and stay synchronized (each TE LSP state change must
例如，如果域中只有一个PCE，则所有TE LSP计算都由该PCE完成，然后该PCE可以跟踪所有现有TE LSP并保持同步（每个TE LSP状态更改必须
be tracked by the PCE). However, this model could require substantial control plane resources. If there are multiple PCEs in the network, TE LSP computation and information are distributed among PCEs and so the resources required to perform the computations are also distributed. However, synchronization issues discussed in Section 6.7 also come into play.
由PCE跟踪）。然而，该模型可能需要大量的控制平面资源。如果网络中有多个pce，则TE LSP计算和信息分布在pce之间，因此执行计算所需的资源也分布。但是，第6.7节中讨论的同步问题也起作用。
The maintenance of a stateful database can be non-trivial. However, in a single centralized PCE environment, a stateful PCE is almost a simple matter of remembering all the TE LSPs the PCE has computed, that the TE LSPs were actually set up (if this can be known), and when they were torn down. Out-of-band TED synchronization can also be complex, with multiple PCE setup in a distributed PCE computation model, and could be prone to race conditions, scalability concerns, etc. Even if the PCE has detailed information on all paths, priorities, and layers, taking such information into account for path computation could be highly complex. PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation performed among several PCEs, the problems of synchronization and race condition avoidance become larger and more complex.
有状态数据库的维护是非常重要的。然而，在单个集中式PCE环境中，有状态PCE几乎只需记住PCE计算的所有TE LSP、TE LSP的实际设置（如果可以知道的话）以及它们被拆除的时间。带外TED同步也可能很复杂，在分布式PCE计算模型中设置了多个PCE，并且可能容易出现竞争条件、可伸缩性问题等。即使PCE具有关于所有路径、优先级和层的详细信息，将这些信息考虑到路径计算也可能非常复杂。pce可以通过相互通信来同步状态，但是当使用在多个pce之间执行的分布式计算来建立TE-lsp时，同步和竞争条件避免的问题变得更大、更复杂。
There is benefit in knowing which TE LSPs exist, and their routing, to support such applications as placing a high-priority TE LSP in a crowded network such that it preempts as few other TE LSPs as possible (also known as the "minimal perturbation" problem). Note that preempting based on the minimum number of links might not result in the smallest number of TE LSPs being disrupted. Another application concerns the construction and maintenance of a Virtual Network Topology [MLN]. It is also helpful to understand which other TE LSPs exist in the network in order to decide how to manage the forward adjacencies that exist or need to be set up. The cost-benefit of stateful PCE computation would be helpful to determine if the benefit in path computation is sufficient to offset the additional drain on the network and computational resources.
了解存在哪些TE-LSP及其路由有助于支持这样的应用，例如在拥挤的网络中放置高优先级TE-LSP，从而尽可能少地抢占其他TE-LSP（也称为“最小扰动”问题）。请注意，基于最小链路数的抢占可能不会导致最小数量的TE LSP中断。另一个应用涉及虚拟网络拓扑的构建和维护[MLN]。了解网络中存在哪些其他TE-lsp也有助于决定如何管理存在的或需要设置的前向邻接。有状态PCE计算的成本效益将有助于确定路径计算的效益是否足以抵消网络和计算资源的额外消耗。
Conversely, stateless PCEs do not have to remember any computed path and each set of request(s) is processed independently of each other. For example, stateless PCEs may compute paths based on current TED information, which could be out of sync with actual network state given other recent PCE-computed paths changes. Note that a PCC may include a set of previously computed paths in its request, in order to take them into account, for instance, to avoid double bandwidth accounting or to try to minimize changes (minimum perturbation problem).
相反，无状态PCE不必记住任何计算路径，并且每组请求都是彼此独立处理的。例如，无状态PCE可基于当前TED信息计算路径，考虑到其他最近PCE计算路径的变化，该信息可能与实际网络状态不同步。注意，PCC可以在其请求中包括一组先前计算的路径，以便将它们考虑在内，例如，避免双重带宽记帐或尝试最小化更改（最小扰动问题）。
Note that the stateless PCE does operate on information about network state. The TED contains link state and bandwidth availability information as distributed by the IGPs or collected through some other means. This information could be further enhanced to provide increased granularity and more detail to cover, for example, the current bandwidth usage on certain links according to resource affinities or forwarding equivalence classes. Such information is, however, not PCE state information and so a model that uses it is still described as stateless in the PCE context.
请注意，无状态PCE确实根据有关网络状态的信息进行操作。TED包含由IGPs分发或通过其他方式收集的链路状态和带宽可用性信息。该信息可以进一步增强，以提供更高的粒度和更详细的信息，例如，根据资源亲和力或转发等价类，覆盖某些链路上的当前带宽使用情况。然而，这些信息不是PCE状态信息，因此在PCE上下文中使用它的模型仍然被描述为无状态。
A limited form of statefulness might be applied within an otherwise stateless PCE. The PCE may retain some context from paths it has recently computed so that it avoids suggesting the use of the same resources for other TE LSPs.
有状态性的有限形式可以应用于其他无状态的PCE中。PCE可以保留其最近计算的路径的一些上下文，以避免建议对其他TE LSP使用相同的资源。
PCE monitoring is undoubtedly of the utmost importance in any PCE architecture. This must include the collection of variables related to the PCE status and operation. For example, it will be necessary to understand the way in which the TED is being kept synchronized, the rate of arrival of new requests and the computation times, the range of PCCs that are using the PCE, and the operation of any PCC-PCE protocol.
在任何PCE架构中，PCE监控无疑是最重要的。这必须包括与PCE状态和操作相关的变量集合。例如，有必要了解TED保持同步的方式、新请求的到达率和计算时间、使用PCE的PCC的范围以及任何PCC-PCE协议的操作。
As stated in [RFC4216], the case of inter-provider TE LSP computation requires the ability to compute a path while preserving confidentiality across multiple Service Providers cores. That is, one Service Provider must not be required to divulge any information about its resources or topology in order to support inter-provider TE LSP path computation. Thus, any PCE architecture solution must support the ability to return partial paths by means of loose hops (for example, where each loose hop would, for instance, identify a boundary LSR).
如[RFC4216]中所述，提供商间TE LSP计算的情况需要能够计算路径，同时保持多个服务提供商核心之间的机密性。也就是说，为了支持提供商间TE LSP路径计算，不能要求一个服务提供商泄露其资源或拓扑的任何信息。因此，任何PCE体系结构解决方案都必须支持通过松散跃点返回部分路径的能力（例如，每个松散跃点将识别边界LSR）。
This requirement is not a security issue, but relates to Service Provider policy. Confidentiality, integrity, and authentication of PCC-PCE and PCE-PCE messages must also be ensured and are described in Section 10.
此要求不是安全问题，但与服务提供商策略有关。还必须确保PCC-PCE和PCE-PCE消息的机密性、完整性和身份验证，并在第10节中进行说明。
The ability to compute a path at the request of the head-end PCC, but to supply the path in segments to the domain boundary PCCs, may also be desirable.
在前端PCC的请求下计算路径，但将路径分段提供给域边界PCC的能力也是可取的。
Policy impacts multiple aspects of the PCE architecture. There are two applications of policy for consideration:
政策影响PCE体系结构的多个方面。有两种政策应用需要考虑：
- application of policy within an architectural entity (PCC or PCE)
- 在体系结构实体（PCC或PCE）内应用策略
- application of policy to PCE-related communications
- 政策在PCE相关沟通中的应用
As directly applicable to TE LSPs, policy forms part of the signaling mechanism for the establishment of the TE LSPs and is not described here.
由于直接适用于TE-lsp，因此策略形成了用于建立TE-lsp的信令机制的一部分，这里不进行描述。
It is envisioned that policy will be largely applied as a local matter within each PCC and PCE. However, this document needs to define policy models that can be supported within the PCE architecture and by PCE-related communication.
预计政策将作为每个PCC和PCE内的一个局部事项广泛应用。但是，本文档需要定义PCE体系结构内以及PCE相关通信支持的策略模型。
Some example policies include:
一些示例政策包括：
- selection of a PCE by a PCC
- PCC选择PCE
- rejection of a request by the PCE based on the identity of the requesting PCC
- PCE基于请求PCC的身份拒绝请求
- selection by the PCE of a path or application of additional constraints to a computation based on the PCC, the computation target, the time of day, etc.
- PCE根据PCC、计算目标、一天中的时间等选择路径或对计算应用附加约束。
Two examples of the use of policy components within the PCE architecture are illustrated in Figures 6 and 7. Policy components could equally be applied to the other PCE configurations shown in Section 5. In each configuration, policy may be consulted before a response is provided by a PCE and may also be consulted by the PCC/PCE that receives the response.
PCE体系结构中使用策略组件的两个示例如图6和图7所示。策略组件同样可以应用于第5节所示的其他PCE配置。在每个配置中，可以在PCE提供响应之前咨询策略，也可以由接收响应的PCC/PCE咨询策略。
A PCE may have a local policy that impacts the paths selected to satisfy a particular PCE request. A policy may be applied based on any information provided from a PCC.
PCE可能具有影响为满足特定PCE请求而选择的路径的本地策略。可以根据PCC提供的任何信息应用策略。
In Figure 6, the policy component is shown providing input to the PCE component. This policy component may consult an external policy database, but this is outside the scope of this document.
在图6中，显示了向PCE组件提供输入的策略组件。此策略组件可以查阅外部策略数据库，但这超出了本文档的范围。
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| |Component|--->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| |Component|--->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
Figure 6. Policy Component in the Composite PCE Node
图6。复合PCE节点中的策略组件
Note that policy information may be conveyed on the internal interfaces, and on the external protocol interfaces.
注意，策略信息可以在内部接口和外部协议接口上传送。
Figure 7 displays the case of a distinct PCE function through the example of the multiple PCE with inter-PCE communication example (compare with Figure 4). Each PCE takes input from local policy as part of the router computation/determination process. The local policy components may consult external policy components or databases, but that is out of the scope of this document.
图7通过具有PCE间通信的多个PCE示例显示了不同PCE功能的情况（与图4比较）。每个PCE从本地策略获取输入，作为路由器计算/确定过程的一部分。本地策略组件可以查阅外部策略组件或数据库，但这超出了本文档的范围。
Note that policy information may be conveyed on the external protocol interfaces, including the inter-PCE interface.
注意，策略信息可以在外部协议接口（包括PCE间接口）上传送。
------------------ ------------------
| | Inter-PCE Request/Response| |
| PCE |<------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
------------------ ------------------
| | Inter-PCE Request/Response| |
| PCE |<------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 7. Policy Components in Multiple PCEs
图7。多个PCE中的策略组件
There are multiple options for how policy information is coordinated.
对于如何协调策略信息，有多种选择。
- Policy decisions may be made by PCCs before consulting PCEs. This type of decision includes selection of PCE, application of constraints, and interpretation of service requests.
- 政策决策可由PCC在咨询PCE之前作出。此类决策包括PCE的选择、约束的应用和服务请求的解释。
- Policy decisions may be made independently at a PCE, or at each cooperating PCE. That is, the PCE(s) may make policy decisions independent of other policy decisions made at PCCs or other PCEs.
- 政策决策可以在一个PCE上独立作出，也可以在每个合作的PCE上作出。也就是说，PCE可以独立于PCC或其他PCE做出的其他政策决定做出政策决定。
- There may also be explicit communication of policy information between PCC and PCE, or between PCEs to achieve some level of coordination of policy between entities. The type of information conveyed to support policy has important implications on what policies may be applied at each PCE, and the requirements for the exchange of policy information inform the choice or implementation of communication protocols including PCC-PCE, PCE-PCE, and discovery protocols.
- PCC和PCE之间或PCE之间也可能有明确的政策信息沟通，以实现实体之间某种程度的政策协调。传达给支持策略的信息类型对每个PCE可以应用哪些策略具有重要影响，策略信息交换的要求通知通信协议的选择或实施，包括PCC-PCE、PCE-PCE和发现协议。
Within the context of PCE, we identify several types of policies:
在PCE的背景下，我们确定了几种类型的政策：
o User-specific policies operate on information that is specific to the user of a service or the service itself, that is, the service for which the path is being computed, not the computation service. Examples of such information includes the contents of objects of a
o 特定于用户的策略对特定于服务用户或服务本身的信息进行操作，即，为其计算路径的服务，而不是计算服务。此类信息的示例包括
signaling or provisioning message, the port ID over which the message was received, a VPN ID, a reference point type, or the identity of the user initiating the request. User-specific policies could be applied by a PCC while building a path computation request, or by a PCE while processing the request provided that sufficient information is supplied by the PCC to the PCE.
信令或配置消息、接收消息的端口ID、VPN ID、参考点类型或发起请求的用户的身份。用户特定策略可由PCC在构建路径计算请求时应用，或由PCE在处理请求时应用，前提是PCC向PCE提供足够的信息。
o Request-specific policies operate on information that is specific to a path computation request and is carried in the request. Examples of such information include constraints, diversities, constraint and diversity relaxation strategies, and optimization functions. Request-specific policies directly affect the path selection process because they specify which links, nodes, path segments, and/or paths are not acceptable or, on the contrary, may be desirable in the resulting paths.
o 特定于请求的策略对特定于路径计算请求并在请求中携带的信息进行操作。此类信息的示例包括约束、多样性、约束和多样性松弛策略以及优化函数。特定于请求的策略直接影响路径选择过程，因为它们指定哪些链接、节点、路径段和/或路径是不可接受的，或者相反，在结果路径中可能是可取的。
o Domain-specific policies operate on the identify of the domain in which the requesting PCC exists, and upon the identities of the domains through which the resulting paths are routed. These policies have the same effect as user-specific policies, with the difference that they can be applied to a group of users rather than an individual user. One example of domain-specific policy is a restriction on what information a PCE publishes within a given domain. In such a case, PCEs in some domains may advertise just their presence, while others may advertise details regarding their capabilities, client authentication process, and computation resource availability.
o 特定于域的策略根据请求PCC所在域的标识以及结果路径路由通过的域的标识进行操作。这些策略与特定于用户的策略具有相同的效果，不同之处在于它们可以应用于一组用户而不是单个用户。特定于域的策略的一个示例是限制PCE在给定域中发布的信息。在这种情况下，某些域中的PCE可能只公布其存在，而其他域可能公布有关其能力、客户端身份验证过程和计算资源可用性的详细信息。
When a path for an inter-domain TE LSP is being computed, it is not required to consider signaling plane policy. However, failure to do so may result in the TE LSP failing to be established, or being assigned fewer resources than intended resulting in a substandard service. Thus, where a PCE invoked by a head-end LSR has visibility into other domains, it should be capable of applying policy considerations to the computation and should be aware of the inter-domain policy agreements. Where path computation is the result of cooperation between PCEs, each of which is responsible for a particular domain, the policy issues should, where possible, be resolved at the time of computation so that the TE LSP is more likely to be signaled successfully. In this context, policy violation during inter-domain TE LSP computation may lead to path computation interruption, about which the requester should be notified along with the cause.
当计算域间TE LSP的路径时，不需要考虑信令平面策略。但是，如果不这样做，可能会导致TE LSP无法建立，或分配的资源少于预期，从而导致服务不达标。因此，如果前端LSR调用的PCE可以看到其他域，那么它应该能够将策略考虑应用到计算中，并且应该知道域间策略协议。如果路径计算是pce之间合作的结果，其中每个pce负责特定域，则在可能的情况下，应在计算时解决策略问题，以便更有可能成功地用信号通知TE LSP。在这种情况下，域间TE LSP计算期间的策略违反可能导致路径计算中断，应将中断的原因通知请求者。
It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction. For example, the PCE and PCC could exchange capabilities using this protocol. Additionally, the protocol could be used to collect and report information in support of a stateful PCE.
PCC-PCE通信（见第6.6节）可以有效地扩展到简单的请求/响应交互之外。例如，PCE和PCC可以使用此协议交换功能。此外，该协议可用于收集和报告支持有状态PCE的信息。
Furthermore, it may be the case that a PCE is able to update a path that it computed earlier (perhaps in reaction to a change in the network or a change in policy), and in this case the PCE-PCC communication could support an "unsolicited" path computation message to supply this new path to the PCC. Note, however, that this function would require that the PCE retained a record of previous computations and had a clear trigger for performing recomputations. The PCC would also need to be able to identify the new path with the old path and determine whether it should act on the new path. Further, the PCC should be able to report the outcome of such path changes to the requesting PCE. Note that the PCE-PCC interaction is not a management interaction and the PCC is not obliged to utilize any additional path supplied by the PCE.
此外，可能的情况是，PCE能够更新其先前计算的路径（可能是响应于网络的变化或策略的变化），并且在这种情况下，PCE-PCC通信可以支持“未经请求的”路径计算消息以向PCC提供该新路径。但是，请注意，此功能要求PCE保留以前计算的记录，并具有执行重新计算的明确触发器。PCC还需要能够识别新路径和旧路径，并确定是否应在新路径上采取行动。此外，PCC应当能够向请求PCE报告这种路径更改的结果。请注意，PCE-PCC交互不是管理交互，PCC没有义务使用PCE提供的任何附加路径。
These functions fit easily within the architecture described here but are left for further discussion within separate requirements documents.
这些功能很容易适应这里描述的体系结构，但在单独的需求文档中留作进一步讨论。
Crankback routing is a mechanism whereby a failure to establish a path or a failure of an existing path may be corrected by a new path computation and fresh signaling. Crankback routing relies on the distribution of crankback information along with the failure notification so that the new computation can be performed avoiding the failure or blockage point.
回退路由是一种机制，通过这种机制，建立路径失败或现有路径失败可以通过新的路径计算和新的信令进行纠正。回退路由依赖于回退信息以及故障通知的分布，以便可以执行新的计算以避免故障或阻塞点。
In the context of PCE, crankback information may be passed back to the head-end where the process of computation and signaling can be repeated using the failed resource as an exclusion in the computation process. But crankback may be used to attempt to correct the problem at intermediate points along the path. Such crankback recomputation nodes are most likely to be domain boundaries where the PCC had already invoked a PCE. Thus, a failure within a domain is reported to the ingress domain boundary, which will attempt to compute an alternate path across the domain. Failing this, the problem may be reported to the previous domain and communicated to the ingress boundary for that domain, which may attempt to select a more
在PCE的上下文中，可将回退信息传递回前端，其中可使用失效资源作为计算过程中的排除来重复计算和信令过程。但是，可以使用回退来尝试在路径的中间点纠正问题。此类回退重新计算节点很可能是PCC已调用PCE的域边界。因此，域内的故障报告给入口域边界，入口域边界将尝试计算跨域的备用路径。否则，问题可能会报告给前一个域，并传达给该域的入口边界，该入口边界可能会尝试选择一个更大的域
successful path either by choosing a different entry point into the next domain, or by selecting a route through a different set of domains.
通过选择进入下一个域的不同入口点，或通过选择通过一组不同域的路由，可以获得成功的路径。
The view of the PCE architecture, and particularly the functional model, is subtly different from the PCC's perspective. This is partly because the PCC has limited knowledge of the way in which the PCEs cooperate to answer its requests, but depends more on the fact that the PCC is concerned with different questions.
PCE体系结构的视图，尤其是功能模型，与PCC的视角略有不同。这部分是因为PCC对PCE合作回答其请求的方式了解有限，但更多地取决于PCC关注不同问题的事实。
The PCC is interested in the following:
PCC对以下方面感兴趣：
- Selecting a PCE that is able to promptly provide a computed path that meets the supplied constraints.
- 选择能够迅速提供满足所提供约束的计算路径的PCE。
- How many computation requests will the PCC have to send? Will the desired path be computed by the first PCE contacted (possibly in cooperation with other PCEs), or will the PCC have to consult other PCEs to fill in gaps in the path?
- PCC必须发送多少计算请求？所需路径是否由联系的第一个PCE计算（可能与其他PCE合作），或者PCC是否必须咨询其他PCE以填补路径中的空白？
- How many other path computations will need to be issued from within the network in order to establish the TE LSP?
- 为了建立TE LSP，需要从网络内发出多少其他路径计算？
This last question might be considered out of scope for the head-end LSR, but an important constraint that the PCC may wish to apply is that the path should be computed in its entirety and supplied without loose hops or non-simple abstract nodes.
最后一个问题可能被认为超出了头端LSR的范围，但是PCC可能希望应用的一个重要约束是，应该完整地计算路径，并且在没有松散跳数或非简单抽象节点的情况下提供路径。
Thus, with its limited perspective, the PCC will see Multiple PCE Path Computation (Section 5.3) as important and will distinguish two subcases. The first is as shown in Figure 3 with subsequent computation requests made by other PCCs along the path of the TE LSP. In the second, multiple computation requests are issued by the head-end LSR. On the other hand, the PCC will not be aware of Multiple PCE Path Computation with Inter-PCE Communication (Section 5.4), which it will perceive as no different from the simple External PCE Node case (Section 5.2).
因此，鉴于其有限的视角，PCC将多个PCE路径计算（第5.3节）视为重要的，并将区分两个子类别。第一个如图3所示，其他PCC沿TE LSP路径发出后续计算请求。在第二种情况下，由前端LSR发出多个计算请求。另一方面，PCC将不知道具有PCE间通信的多个PCE路径计算（第5.4节），PCC将认为这与简单的外部PCE节点情况（第5.2节）没有区别。
The PCC, therefore, will be acutely aware that a Centralized PCE Model (Section 6.1) might still require Multiple PCE Path Computations with the head-end or subsequent PCCs required to issue further requests to the central PCE. Conversely, the PCC may be protected from the Distributed PCE Model (Section 6.2) because the first PCE it consults uses inter-PCE communication to achieve a complete computation result so that no further computation requests are required.
因此，PCC将敏锐地意识到，集中式PCE模型（第6.1节）可能仍然需要多个PCE路径计算，前端或后续PCC需要向中央PCE发出进一步请求。相反，PCC可能受到分布式PCE模型的保护（第6.2节），因为它咨询的第一个PCE使用PCE间通信来实现完整的计算结果，因此不需要进一步的计算请求。
These distinctions can be completely classified by determining whether the computation response includes all necessary paths, and whether those paths are fully explicit (that is, containing only strict hops between simple abstract nodes).
这些区别可以通过确定计算响应是否包括所有必要的路径以及这些路径是否完全显式（即，仅包含简单抽象节点之间的严格跳数）来完全分类。
Evaluation metrics that may be used to evaluate the efficiency and applicability of any PCE-based solution are listed below. Note that these metrics are not being used to determine paths, but are used to evaluate potential solutions to the PCE architecture.
下面列出了可用于评估任何基于PCE的解决方案的效率和适用性的评估指标。请注意，这些指标不用于确定路径，而是用于评估PCE体系结构的潜在解决方案。
- Optimality: The ability to maximize network utilization and minimize cost, considering QoS objectives, multiple regions, and network layers. Note that models that require the sequential involvement of multiple PCEs (for example, the multiple PCE model described in Section 5.3) might create path loops unless careful policy is applied.
- 最佳性：考虑到QoS目标、多个区域和网络层，最大限度地提高网络利用率和最小化成本的能力。请注意，需要多个PCE顺序参与的模型（例如，第5.3节中描述的多个PCE模型）可能会创建路径循环，除非应用谨慎的策略。
- Scalability: The implications of routing, TE LSP signaling, and PCE communication overhead, such as the number of messages and the size of messages (including LSAs, crankback information, queries, distribution mechanisms, etc.).
- 可伸缩性：路由、TE LSP信令和PCE通信开销的含义，如消息数量和消息大小（包括LSA、回溯信息、查询、分发机制等）。
- Load sharing: The ability to allow multiple PCEs to spread the path computation load by allowing multiple PCEs each to take responsibility for a subset of the total path computation requests.
- 负载共享：允许多个PCE各自负责总路径计算请求的子集，从而允许多个PCE分散路径计算负载的能力。
- Multi-path computation: The ability to compute multiple and potentially diverse paths to satisfy load-sharing of traffic and protection/restoration needs including end-to-end diversity and protection within individual domains.
- 多路径计算：能够计算多条可能不同的路径，以满足流量负载共享和保护/恢复需求，包括各个域内的端到端多样性和保护。
- Reoptimization: The ability to perform TE LSP path reoptimization. This also includes the ability to perform inter-layer correlation when considering the reoptimization at any specific layer.
- 重新优化：执行TE LSP路径重新优化的能力。这还包括在考虑任何特定层的重新优化时执行层间关联的能力。
- Path computation time: The time to compute individual paths and multiple diverse paths and to satisfy bulk path computation requests. (Note that such a metric can only be applied to problems that are not NP-complete.)
- 路径计算时间：计算单个路径和多个不同路径以及满足批量路径计算请求的时间。（请注意，这种度量只能应用于非NP完全问题。）
- Network stability: The ability to minimize any perturbation on existing TE state resulting from the computation and establishment of new TE paths.
- 网络稳定性：能够最小化由于计算和建立新TE路径而对现有TE状态产生的任何扰动。
- Ability to maintain accurate synchronization between TED and network topology and resource states.
- 能够在TED与网络拓扑和资源状态之间保持精确同步。
- Speed with which TED synchronization is achieved.
- 实现TED同步的速度。
- Impact of the synchronization process on the data flows in the network.
- 同步过程对网络中数据流的影响。
- Ability to deal with situations where paths satisfying a required set of constraints cannot be found by the PCE.
- 能够处理PCE无法找到满足所需约束集的路径的情况。
- Policy: Application of policy to the PCC-PCE and PCE-PCE communications as well as to the computation of paths that respect inter-domain TE LSP establishment policies.
- 策略：将策略应用于PCC-PCE和PCE-PCE通信，以及计算遵守域间TE LSP建立策略的路径。
Note that other metrics may also be considered. Such metrics should be used when evaluating a particular PCE-based architecture. The potential tradeoffs of the optimization of such metrics should be evaluated (for instance, increasing the path optimality is likely to have consequences on the computation time).
注意，也可以考虑其他指标。在评估基于PCE的特定体系结构时，应使用此类指标。应评估此类指标优化的潜在权衡（例如，增加路径最优性可能会对计算时间产生影响）。
The PCE architecture introduces several elements that are subject to manageability. The PCE itself must be managed, as must its communications with PCCs and other PCEs. The mechanism by which PCEs and PCCs discover each other are also subject to manageability.
PCE体系结构引入了几个受可管理性约束的元素。PCE本身必须进行管理，其与PCC和其他PCE的通信也必须进行管理。PCE和PCC相互发现的机制也受可管理性的约束。
Many of the issues of manageability are already covered in other sections of this document.
本文档的其他部分已经介绍了许多可管理性问题。
It must be possible to enable and disable the PCE function at a PCE, and this will lead to the PCE accepting, rejecting, or simply not receiving requests from PCCs. Graceful shutdown of the PCE function should also be considered so that in controlled circumstances (such as software upgrade) a PCE does not just 'disappear' but warns its PCCs and gracefully handles any queued computation requests (perhaps by completing them, forwarding them to another PCE, or rejecting them).
必须能够在PCE上启用和禁用PCE功能，这将导致PCE接受、拒绝或根本不接收来自PCC的请求。还应考虑合理关闭PCE功能，以便在受控环境（如软件升级）中，PCE不仅“消失”，而且向其PCC发出警告，并优雅地处理任何排队的计算请求（可能通过完成它们、将它们转发给另一个PCE或拒绝它们）。
Similarly it must be possible to control the application of policy at the PCE through configuration. This control may include the restriction of certain functions or algorithms, the configuration of access rights and priorities for PCCs, and the relationships with other PCEs both inside and outside the domain.
同样，必须能够通过配置在PCE上控制策略的应用。该控制可包括对某些功能或算法的限制、pcc的访问权限和优先级的配置以及与域内外的其他pce的关系。
The policy configuration interface is yet to be determined. The interface may be purely a local matter, or it may be supported via a standardized interface (such as a MIB module).
策略配置接口尚未确定。接口可以是纯本地的，也可以通过标准化接口（例如MIB模块）来支持。
It is expected that the operations of PCEs and PCCs will be modeled and controlled through appropriate MIB modules. The tables in the new MIB modules will need to reflect the relationships between entities and to control and report on configurable options.
预计PCE和PCC的操作将通过适当的MIB模块进行建模和控制。新MIB模块中的表需要反映实体之间的关系，并控制和报告可配置选项。
Statistics gathering will form an important part of the operation of PCEs. The operator must be able to determine the historical interactions of a PCC with its PCEs, the performance that it has seen, and the success rate of its requests. Similarly, it is important for an operator to be able to inspect a PCE and determine its load and whether an individual PCC is responsible for a disproportionate amount of the load. It will also be important to be able to record and inspect statistics about the communications between the PCC and PCE, including issues such as malformed messages, unauthorized messages, and messages discarded because of congestion. In this respect, there is clearly an overlap between manageability and security.
统计数据收集将构成PCE运作的重要组成部分。运营商必须能够确定PCC与其PCE的历史交互、所看到的性能以及请求的成功率。同样，操作员能够检查PCE并确定其负载以及单个PCC是否对负载量不成比例负责也很重要。能够记录和检查PCC和PCE之间通信的统计数据也很重要，包括诸如格式错误的消息、未经授权的消息和由于拥塞而丢弃的消息等问题。在这方面，可管理性和安全性之间显然存在重叠。
Statistics for the PCE architecture can be made available through appropriate tables in the new MIB modules.
PCE体系结构的统计数据可通过新MIB模块中的适当表格获得。
The new MIB modules should also be used to provide notifications when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with Simple Network Management Protocol (SNMP) notifications. Thus, it might be inappropriate to issue a notification every time a PCE receives a request to compute a path. In any case, full control must be provided to allow notifications to be disabled using, for example, the mechanisms defined in the SNMP-NOTIFICATION-MIB module in [RFC3413].
新的MIB模块还应用于在超过关键阈值或发生重要事件时提供通知。必须非常小心，以确保网络不会充斥着简单网络管理协议（SNMP）通知。因此，每次PCE收到计算路径的请求时发出通知可能是不合适的。在任何情况下，必须提供完全控制，以允许使用[RFC3413]中SNMP-NOTIFICATION-MIB模块中定义的机制禁用通知。
Section 6.5 discusses the importance of a PCC being able to detect the liveness of a PCE. PCE-PCC communications techniques must enable a PCC to determine the liveness of a PCE both before it sends a request and in the period between sending a request and receiving a response.
第6.5节讨论了PCC能够检测PCE活性的重要性。PCE-PCC通信技术必须使PCC能够在发送请求之前以及在发送请求和接收响应之间确定PCE的活跃度。
It is less important for a PCE to know about the liveness of PCCs, and within the simple request/response model, this is only helpful
对于PCE来说，了解PCC的活跃度并不重要，在简单的请求/响应模型中，这只是有用的
- to gain a predictive view of the likely loading of a PCE in the future, or
- 获得PCE未来可能负载的预测视图，或
- to allow a PCE to abandon processing of a received request.
- 允许PCE放弃对接收到的请求的处理。
Correct operation for the PCE architecture can be classified as determining the correct point-to-point connectivity between PCCs and PCEs, and as assessing the validity of the computed paths. The former is a security issue that may be enhanced by authentication and monitored through event logging and records as described in Section 9.1. It may also be a routing issue to ensure that PCC-PCE connectivity is possible.
PCE体系结构的正确操作可分为确定PCC和PCE之间的正确点对点连接，以及评估计算路径的有效性。前者是一个安全问题，可通过第9.1节所述的身份验证和事件日志和记录来增强和监控。这也可能是一个路由问题，以确保PCC-PCE连接是可能的。
Verifying computed paths is more complex. The information to perform this function can, however, be made available to the operator through MIB tables, provided that full records are kept of the constraints passed on the request, the path computed and provided on the response, and any additional information supplied by the PCE such as the constraint relaxation policies applied.
验证计算的路径更复杂。但是，执行此功能的信息可以通过MIB表提供给操作员，前提是保留请求上传递的约束、响应上计算和提供的路径以及PCE提供的任何附加信息（如应用的约束放松策略）的完整记录。
At the architectural stage, it is impossible to make definitive statements about the impact on other protocols and functional components since the solution's work has not been completed. However, it is possible to make some observations.
在架构阶段，由于解决方案的工作尚未完成，因此不可能对其他协议和功能组件的影响做出明确的陈述。然而，可以进行一些观察。
- Dependence on underlying transport protocols
- 对底层传输协议的依赖
PCE-PCC communications may choose to utilize underlying protocols to provide transport mechanisms. In this case, some of the manageability considerations described in the previous sections may be devolved to those protocols.
PCE-PCC通信可以选择利用底层协议来提供传输机制。在这种情况下，前面章节中描述的一些可管理性考虑因素可能会转移到这些协议中。
- Re-use of existing protocols for discovery
- 重复使用现有协议进行发现
Without prejudicing the requirements and solutions work for PCE discovery (see Section 6.4), it is possible that use will be made of existing protocols to facilitate this function. In this case some of the manageability considerations described in the previous sections may be devolved to those protocols.
在不影响PCE发现的要求和解决方案的情况下（见第6.4节），可以使用现有协议来促进该功能。在这种情况下，前面章节中描述的一些可管理性考虑因素可能会转移到这些协议中。
- Impact on LSRs and TE LSP signaling
- 对LSRs和TE-LSP信令的影响
The primary example of a PCC identified in this architecture is an MPLS or a GMPLS LSR. Consideration must therefore be given to the manageability of the LSRs and the additional manageability constraints applicable to the TE LSP signaling protocols.
该体系结构中标识的PCC的主要示例是MPLS或GMPLS LSR。因此，必须考虑LSR的可管理性以及适用于TE LSP信令协议的附加可管理性约束。
In addition to allowing the PCC management described in the previous sections, an LSR must be configurable to determine whether it will use a remote PCE at all, the options being to use hop-by-hop routing or to supply the PCE function itself. It is likely to be important to be able to distinguish within an LSR whether the route used for a TE LSP was supplied in a signaling message from another LSR, by an operator, or by a PCE, and, in the case where it was supplied in a signaling message, whether it was enhanced or expanded by a PCE.
除了允许前面章节中描述的PCC管理外，LSR必须可配置，以确定它是否将使用远程PCE，选项包括使用逐跳路由或提供PCE功能本身。能够在LSR内区分用于TE LSP的路由是由运营商还是由PCE在来自另一LSR的信令消息中提供的，并且在其在信令消息中提供的情况下，是由PCE增强还是扩展的，这可能很重要。
- Reuse of existing policy models and mechanisms
- 重用现有的策略模型和机制
As policy support mechanisms can be quite extensive, it is worthwhile to explore to what extent this prior work can be leveraged and applied to PCE. This desire to leverage prior work should not be interpreted as a requirement to use any particular solution or protocol.
由于政策支持机制可能相当广泛，因此值得探讨在多大程度上可以利用这项先前的工作并将其应用于PCE。这种利用先前工作的愿望不应被解释为使用任何特定解决方案或协议的要求。
This architecture may have two impacts on the operation of a network. It increases TE LSP setup times while requests are sent to and processed by a remote PCE, and it may cause congestion within the network if a significant number of computation requests are issued in a small period of time. These issues are most severe in busy networks and after network failures, although the effect may be mitigated if the protection paths are precomputed or if the path computation load is distributed among a set of PCEs.
这种体系结构可能对网络的运行产生两种影响。当请求被发送到远程PCE并由远程PCE处理时，它增加了TE LSP设置时间，并且如果在很短的时间内发出大量的计算请求，它可能会导致网络内的拥塞。这些问题在繁忙网络和网络故障后最为严重，尽管如果预先计算保护路径或如果路径计算负载分布在一组pce之间，则影响可能会减轻。
Issues of potential congestion during recovery from failures may be mitigated through the use of pre-established protection schemes such as fast reroute.
通过使用预先建立的保护方案（如快速重路由），可以缓解故障恢复期间的潜在拥塞问题。
It is important that network congestion be managed proactively because it may be impossible to manage it reactively once the network is congested. It should be possible for an operator to rate limit the requests that a PCC sends to a PCE, and a PCE should be able to report impending congestion (according to a configured threshold) both to the operator and to its PCCs.
主动管理网络拥塞非常重要，因为一旦网络拥塞，就不可能对其进行反应式管理。运营商应该能够对PCC发送给PCE的请求进行速率限制，并且PCE应该能够向运营商及其PCC报告即将发生的拥塞（根据配置的阈值）。
No other management considerations have been identified.
尚未确定其他管理考虑事项。
The impact of the use of a PCE-based architecture must be considered in the light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. The impact may be less likely to be an issue in the case of intra-domain use of PCE, but an increase in inter-domain information flows and the facilitation of inter-domain path establishment may increase the vulnerability to security attacks.
必须考虑使用基于PCE的体系结构对网络中使用的现有路由和信令协议及技术的安全性的影响。在域内使用PCE的情况下，影响不太可能成为问题，但域间信息流的增加和域间路径建立的便利可能会增加安全攻击的脆弱性。
Of particular relevance are the implications for confidentiality inherent in a PCE-based architecture for multi-domain networks. It is not necessarily the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their effects in this area.
特别相关的是基于PCE的多域网络体系结构中固有的保密性含义。多域PCE解决方案不一定会危及安全性，但解决方案必须检查其在这方面的影响。
Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections.
信令、路由和路径计算技术的特定组合的适用性声明预计将包含详细的安全部分。
Note that the use of a non-local PCE (that is, one not co-resident with the PCC) does introduce additional security issues. Most notable among these are:
请注意，使用非本地PCE（即与PCC非共同居住的PCE）会带来额外的安全问题。其中最值得注意的是：
- interception of PCE requests or responses;
- 拦截PCE请求或响应；
- impersonation of PCE or PCC;
- 假冒PCE或PCC；
- falsification of TE information, policy information, or PCE capabilities; and
- 伪造TE信息、政策信息或PCE能力；和
- denial-of-service attacks on PCE or PCE communication mechanisms.
- 对PCE或PCE通信机制的拒绝服务攻击。
It is expected that PCE solutions will address these issues in detail using authentication and security techniques.
预计PCE解决方案将使用身份验证和安全技术详细解决这些问题。
The authors would like to extend their warmest thanks to (in alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for their review and suggestions. Lou Berger provided valuable and detailed contributions to the discussion of policy in this document.
作者谨（按字母顺序）向阿尔西·艾扬加、扎法尔·阿里、卢·伯杰、穆罕默德·布卡达尔、伊戈尔·布莱斯金、郑院长、维韦克·杜比、基里蒂·康佩拉、让·路易斯·勒鲁、斯蒂芬·莫里斯、艾吉·奥基、迪米特里·帕帕迪米特里欧、理查德·拉巴特、帕亚姆·托拉布、清水高雄表示最热烈的感谢，以及张雷蒙的评论和建议。Lou Berger为本文件中的政策讨论提供了宝贵和详细的贡献。
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review and constructive discussions during the final stages of publication.
还感谢Pekka Savola、Russ Housley和Dave Kessens在出版的最后阶段进行了回顾和建设性讨论。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]Levi，D.，Meyer，P.，和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3748] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3748]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 3784，2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Vasseur，J.-P.，和J.Boyle，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.和J.-P.Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", Work in Progress, June 2006.
[MLN]Shiomoto，K.，Papdimitriou，D.，Le Roux，J.-L.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，正在进行的工作，2006年6月。
Authors' Addresses
作者地址
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur 1414 Massachussetts Avenue Boxborough, MA 01719 USA
Jean-Philippe Vasseur 1414马萨诸塞州博克斯伯勒大道，马萨诸塞州01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
Jerry Ash AT&T室MT D5-2A01美国新泽西州劳雷尔大道中城200号，邮编07748
Phone: (732)-420-4578 Fax: (732)-368-8659 EMail: gash@att.com
电话：（732）-420-4578传真：（732）-368-8659电子邮件：gash@att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。