Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7399 Juniper Networks
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
October 2014
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7399 Juniper Networks
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
October 2014
Unanswered Questions in the Path Computation Element Architecture
路径计算元素体系结构中未回答的问题
Abstract
摘要
The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.
RFC 4655中规定了路径计算元件（PCE）体系结构。通过在RFC 5623中引入虚拟网络拓扑管理器（VNTM），该体系结构扩展到多层网络，并在RFC 6805中推广到分层PCE（H-PCE）。
These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.
PCE的这三个架构视图故意留下一些关键问题没有回答，特别是关于架构组件之间的交互。本文档提出了这些问题，并参考其他体系结构组件、现有协议和最近的IETF工作，在体系结构上下文中对其进行了讨论。
This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.
本文档不更新体系结构文档，也不定义必须如何使用协议或组件。然而，它确实建议了如何组合架构组件以提供高级PCE功能。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7399.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7399.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. What Is Topology Information? ...................................4
3. How Is Topology Information Gathered? ...........................5
4. How Do I Find My PCE? ...........................................6
5. How Do I Select between PCEs? ...................................7
6. How Do Redundant PCEs Synchronize TEDs? .........................8
7. Where Is the Destination? .......................................9
8. Who Runs or Owns a Parent PCE? .................................10
9. How Do I Find My Parent PCE? ...................................11
10. How Do I Find My Child PCEs? ..................................11
11. How Is the Parent PCE Domain Topology Built? ..................12
12. Does H-PCE Solve the Internet? ................................12
13. What are Sticky Resources? ....................................13
14. What Is a Stateful PCE for? ...................................14
15. How Is the LSP-DB Built? ......................................14
16. How Do Redundant Stateful PCEs Synchronize State? .............15
17. What Is an Active PCE? What Is a Passive PCE? .................16
18. What is LSP Delegation? .......................................17
19. Is an Active PCE with LSP Delegation Just a Fancy NMS? ........18
20. Comparison of Stateless and Stateful PCE ......................18
21. How Does a PCE Work with a Virtual Network Topology? ..........19
22. How Does PCE Communicate with VNTM ............................21
23. How Does Service Scheduling and Calendering Work? .............21
24. Where Does Policy Fit In? .....................................22
25. Does PCE Play a Role in SDN? ..................................23
26. Security Considerations .......................................23
27. References ....................................................25
27.1. Normative References .....................................25
27.2. Informative References ...................................25
Acknowledgements ..................................................29
Authors' Addresses ................................................29
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. What Is Topology Information? ...................................4
3. How Is Topology Information Gathered? ...........................5
4. How Do I Find My PCE? ...........................................6
5. How Do I Select between PCEs? ...................................7
6. How Do Redundant PCEs Synchronize TEDs? .........................8
7. Where Is the Destination? .......................................9
8. Who Runs or Owns a Parent PCE? .................................10
9. How Do I Find My Parent PCE? ...................................11
10. How Do I Find My Child PCEs? ..................................11
11. How Is the Parent PCE Domain Topology Built? ..................12
12. Does H-PCE Solve the Internet? ................................12
13. What are Sticky Resources? ....................................13
14. What Is a Stateful PCE for? ...................................14
15. How Is the LSP-DB Built? ......................................14
16. How Do Redundant Stateful PCEs Synchronize State? .............15
17. What Is an Active PCE? What Is a Passive PCE? .................16
18. What is LSP Delegation? .......................................17
19. Is an Active PCE with LSP Delegation Just a Fancy NMS? ........18
20. Comparison of Stateless and Stateful PCE ......................18
21. How Does a PCE Work with a Virtual Network Topology? ..........19
22. How Does PCE Communicate with VNTM ............................21
23. How Does Service Scheduling and Calendering Work? .............21
24. Where Does Policy Fit In? .....................................22
25. Does PCE Play a Role in SDN? ..................................23
26. Security Considerations .......................................23
27. References ....................................................25
27.1. Normative References .....................................25
27.2. Informative References ...................................25
Acknowledgements ..................................................29
Authors' Addresses ................................................29
Over the years since the architecture for the Path Computation Element (PCE) was documented in [RFC4655], many new people have become involved in the work of the PCE working group and wish to use or understand the PCE architecture. These people often missed out on early discussions within the working group and are unfamiliar with questions that were raised during the development of the documentation.
自[RFC4655]中记录了路径计算元素（PCE）的体系结构以来，许多新人参与了PCE工作组的工作，并希望使用或理解PCE体系结构。这些人往往错过了工作组内的早期讨论，并且不熟悉在编制文件过程中提出的问题。
Furthermore, the base architecture has been extended to handle other situations and requirements: the architecture was extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) [RFC5623] and was generalized to include Hierarchical PCE (H-PCE) [RFC6805].
此外，基本体系结构已扩展到处理其他情况和需求：随着虚拟网络拓扑管理器（VNTM）[RFC5623]的引入，该体系结构已扩展到多层网络，并被推广到包括分层PCE（H-PCE）[RFC6805]。
These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.
PCE的这三个架构视图故意留下一些关键问题没有回答，特别是关于架构组件之间的交互。本文档提出了这些问题，并参考其他体系结构组件、现有协议和最近的IETF工作，在体系结构上下文中对其进行了讨论。
This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.
本文档不更新体系结构文档，也不定义必须如何使用协议或组件。然而，它确实建议了如何组合架构组件以提供高级PCE功能。
Readers are assumed to be thoroughly familiar with terminology defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], and [RFC6805]. More information about terms related to stateful PCE can be found in [STATEFUL-PCE].
假定读者完全熟悉[RFC4655]、[RFC4726]、[RFC5440]、[RFC5623]和[RFC6805]中定义的术语。有关有状态PCE相关术语的更多信息，请参见[stateful-PCE]。
Throughout this document, the term "area" is used to refer equally to an OSPF area and an IS-IS level. It is assumed that the reader is able to map the small differences between these two use cases.
在本文件中，术语“区域”等同于指OSPF区域和is-is级别。假设读者能够映射这两个用例之间的微小差异。
[RFC4655] specifies that a PCE performs path computations based on a view of the available network resources and network topology. This information is collected into a Traffic Engineering Database (TED).
[RFC4655]指定PCE基于可用网络资源和网络拓扑的视图执行路径计算。这些信息被收集到交通工程数据库（TED）中。
However, [RFC4655] does not provide a detailed description of what information is present in the TED. It simply says that the TED "contains the topology and resource information of the domain." The precise information that needs to be held in a TED depends on the type of network and nature of the computation that has to be performed. As a basic minimum, the TED must contain the nodes and links that form the domain, and it must identify the connectivity in the domain.
但是，[RFC4655]没有提供TED中存在哪些信息的详细说明。它只是说TED“包含域的拓扑和资源信息”。TED中需要保存的精确信息取决于网络类型和必须执行的计算的性质。作为最低要求，TED必须包含构成域的节点和链接，并且必须标识域中的连接。
For most traffic-engineering needs (for example, MPLS Traffic Engineering - MPLS-TE), the TED would additionally contain a basic metric for each link and knowledge of the available (unallocated) resources on each link.
对于大多数流量工程需求（例如，MPLS流量工程-MPLS-TE），TED还将包含每个链路的基本指标以及每个链路上可用（未分配）资源的知识。
More advanced use cases might require that the TED contain additional data that represents qualitative information such as:
更高级的用例可能要求TED包含表示定性信息的附加数据，例如：
- link delay - link jitter - node throughput capabilities - optical impairments - switching capabilities - limited node cross-connect capabilities
- 链路延迟-链路抖动-节点吞吐量能力-光损伤-交换能力-有限节点交叉连接能力
Additionally, an important information element for computing paths, especially for protected services, is the Shared Risk Group (SRG). This is an indication of resources in the TED that have a common risk of failure. That is, they have a shared risk of failure from a single event.
此外，计算路径（尤其是受保护服务）的一个重要信息元素是共享风险组（SRG）。这表明TED中的资源具有常见的失败风险。也就是说，他们有一个单一事件的共同失败风险。
In short, the TED needs to contain as much information as is needed to satisfy the path computation requests subject to the objective functions (OFs). This, in itself, may not be a trivial issue in some network technologies. For example, in some optical networks, the path computation for a new Label Switched Path (LSP) may need to consider the impact that turning up a new laser would have on the optical signals already being carried by fibers. It may be possible to abstract this information as parameters of the optical links and nodes in the TED, but it may be easier to capture this information through a database of existing LSPs (see Sections 14 and 15).
简而言之，TED需要包含满足目标函数（OFs）下的路径计算请求所需的尽可能多的信息。这本身在某些网络技术中可能不是一个微不足道的问题。例如，在一些光网络中，一个新的标签交换路径（LSP）的路径计算可能需要考虑新的激光器的出现对光纤已经承载的光信号的影响。可以将该信息抽象为TED中的光链路和节点的参数，但是通过现有LSP的数据库捕获该信息可能更容易（参见第14和15节）。
Clearly, the information in the TED discussed in Section 2 needs to be gathered and maintained somehow. [RFC4655] simply says "The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means." In this context, "fed" means built and maintained.
显然，第2节讨论的TED中的信息需要以某种方式收集和维护。[RFC4655]简单地说，“TED可以通过内部网关协议（IGP）扩展或潜在的其他方式提供。”在这种情况下，“提供”意味着构建和维护。
Thus, one way that the PCE may construct its TED is by participating in the IGP running in the network. In an MPLS-TE network, this would depend on OSPF TE [RFC3630] and IS-IS TE [RFC5305]. In a GMPLS network, it would utilize the GMPLS extensions to OSPF and IS-IS, [RFC4203] and [RFC5307].
因此，PCE可以构造其TED的一种方式是通过参与网络中运行的IGP。在MPLS-TE网络中，这取决于OSPF TE[RFC3630]和IS-IS TE[RFC5305]。在GMPLS网络中，它将利用OSPF和IS-IS[RFC4203]和[RFC5307]的GMPLS扩展。
However, participating in an IGP, even as a passive receiver of IGP information, can place a significant load on the PCE. The IGP can be quite "chatty" when there are frequent updates to the use of the network, meaning that the PCE must dedicate significant processing to parsing protocol messages and updating the TED. Furthermore, to be truly useful, a PCE implementation would need to support OSPF and IS-IS.
然而，参与IGP，即使是作为IGP信息的被动接收器，也会对PCE施加显著的负载。当网络使用频繁更新时，IGP可能非常“健谈”，这意味着PCE必须对解析协议消息和更新TED进行重要处理。此外，要真正有用，PCE实施需要支持OSPF和IS-IS。
An alternative feed from the network to the PCE's TED is offered by BGP-LS [LS-DISTRIB]. This approach offers the alternative of leveraging an in-network BGP speaker (such as an Autonomous System Border Router or a Route Reflector) that already has to participate in the IGP and that is specifically designed to apply filters to IGP advertisements. In this usage, the BGP speaker filters and aggregates topology information according to configured policy before advertising it "north-bound" to the PCE to update the TED. The PCE implementation has to support just a simplified subset of BGP rather than two full IGPs.
BGP-LS[LS-DISTRIB]提供了从网络到PCE TED的另一个馈源。该方法提供了利用已经必须参与IGP并且专门设计用于将滤波器应用于IGP广告的网络内BGP扬声器（例如自治系统边界路由器或路由反射器）的替代方案。在这种情况下，BGP扬声器根据配置的策略过滤和聚合拓扑信息，然后将其“北向”播发到PCE以更新TED。PCE实现必须只支持BGP的一个简化子集，而不是两个完整的IGP。
But BGP might not be convenient in all networks (for example, where BGP is not run, such as in an optical network or a BGP-free core). Furthermore, not all relevant information is made available through standard TE extensions to the IGPs. In these cases, the TED must be built or supplemented from other sources such as the Network Management System (NMS), inventory management systems, and directly configured data.
但BGP在所有网络中可能都不方便（例如，在没有运行BGP的情况下，例如在光网络或无BGP的核心中）。此外，并非所有相关信息都通过IGP的标准TE扩展提供。在这些情况下，TED必须从网络管理系统（NMS）、库存管理系统和直接配置的数据等其他来源构建或补充。
It has also been proposed that the PCE Communication Protocol (PCEP) [RFC5440] could be extended to serve as an information collection protocol to supply information from network devices to a PCE. The logic is that the network devices may already speak PCEP; so, the protocol could easily be used to report details about the resources and state in the network, including the LSP state discussed in Sections 14 and 15.
也有人提出，PCE通信协议（PCEP）[RFC5440]可以扩展为用作信息收集协议，以从网络设备向PCE提供信息。逻辑是网络设备可能已经讲了PCEP；因此，该协议可以很容易地用于报告有关网络中资源和状态的详细信息，包括第14节和第15节中讨论的LSP状态。
Note that a PCE that is responsible for more than one domain must, of course, collect TE information from each domain to build its TED or TEDs.
请注意，负责多个域的PCE当然必须从每个域收集TE信息，以构建其TED或TED。
A Path Computation Client (PCC) needs to know the identity/location of a PCE in order to be able to make computation requests. This is because PCEP is a transaction-based protocol carried over TCP, and the architectural decision made in Section 6.4 of RFC 4655 required targeted PCC-PCE communications.
路径计算客户端（PCC）需要知道PCE的身份/位置，以便能够发出计算请求。这是因为PCEP是通过TCP传输的基于事务的协议，RFC 4655第6.4节中做出的架构决策要求有针对性的PCC-PCE通信。
As described in [RFC4655], a PCC could be configured with the knowledge of the IP address of its PCE. This is a relatively lightweight option considering all of the other configuration that a router may require, but it is open to configuration errors, and does not meet the need for minimal-configuration operation. Furthermore, configuration communication with multiple PCEs could become onerous, while handling changes in PCE identities and coping with failure events would be an issue for a configured system.
如[RFC4655]中所述，PCC可以根据其PCE的IP地址进行配置。考虑到路由器可能需要的所有其他配置，这是一个相对轻量级的选项，但它容易出现配置错误，并且不能满足最小配置操作的需要。此外，与多个PCE的配置通信可能会变得繁重，而处理PCE身份的更改和处理故障事件对于已配置的系统来说是一个问题。
[RFC4655] offers the possibility for PCEs to advertise themselves in the IGP, and this requirement is developed in [RFC4674] and made possible in OSPF and IS-IS through [RFC5088] and [RFC5089]. In general, these mechanisms should be sufficient for PCCs in a network where an IGP is used and where the PCE participates in the IGP.
[RFC4655]为PCE在IGP中宣传自己提供了可能性，该要求在[RFC4674]中制定，并通过[RFC5088]和[RFC5089]在OSPF和is-is中实现。一般来说，对于使用IGP且PCE参与IGP的网络中的PCC，这些机制应足够。
Note, however, that not all PCEs will participate in the IGP (see Section 3). In these cases, assuming configuration is not appropriate as a discovery mechanism, some other server announcement/discovery function may be needed, such as DNS [RFC4848] as used for discovery of the Local Location Information Server (LIS) [RFC5986] and in the Application-Layer Traffic Optimization (ALTO) discovery function [ALTO-SERVER-DISC].
但是，请注意，并非所有PCE都将参与IGP（见第3节）。在这些情况下，假设配置不适合作为发现机制，则可能需要一些其他服务器公告/发现功能，例如用于发现本地位置信息服务器（LIS）[RFC5986]和应用层流量优化（ALTO）发现功能[ALTO-server-DISC]中的DNS[RFC4848]。
When more than one PCE is discovered or configured, a PCC will need to select which PCE to use. It may make this decision on any arbitrary algorithm (for example, first-listed, or round robin), but it may also be the case that different PCEs have different capabilities and path computation scope; in which case, the PCC will want to select the PCE most likely to be able to satisfy any one request. The first requirement, of course, is that the PCE can compute paths for the relevant domain.
当发现或配置多个PCE时，PCC需要选择要使用的PCE。它可以对任何任意算法（例如，首次列出或循环）作出此决定，但也可能是不同的pce具有不同的能力和路径计算范围的情况；在这种情况下，PCC将希望选择最有可能满足任何一个请求的PCE。当然，第一个要求是PCE可以计算相关域的路径。
PCE advertisement in OSPF or IS-IS per [RFC5088] and [RFC5089] allows a PCE to announce its capabilities as required in [RFC4657]. A PCC can select between PCEs based on the capabilities that they have announced. However, these capabilities are expressed as flags in the PCE advertisement so only the core capabilities are presented, and there is not scope for including detailed information (such as support for specific objective functions) in the advertisement.
根据[RFC5088]和[RFC5089]在OSPF或IS-IS中发布PCE广告，允许PCE根据[RFC4657]的要求宣布其能力。PCC可以根据其宣布的功能在PCE之间进行选择。然而，这些能力在PCE广告中表示为标志，因此仅显示核心能力，并且在广告中没有包括详细信息（例如对特定目标功能的支持）的范围。
Additional and more complex PCE capabilities, including the capability to perform point-to-multipoint (P2MP) path computations [RFC6006], may be announced by the PCE as optional PCEP type-length-value (TLV) Type Indicators in the Open message described in [RFC5440]. This mechanism is not limited to just a set of flags, and detailed capability information may be presented in sub-TLVs.
PCE可以在[RFC5440]中所述的开放消息中宣布附加的和更复杂的PCE能力，包括执行点对多点（P2MP）路径计算[RFC6006]的能力，作为可选的PCEP类型长度值（TLV）类型指示符。该机制不限于一组标志，详细的能力信息可以在子TLV中显示。
Note that this exchange of PCE capabilities is in the form of an announcement, not a negotiation. That is, a PCC that wants specific function from a PCE must examine the advertised capabilities and select which PCE to use for a specific request. There is no scope for a PCC to request a PCE to support features or functions that it does not offer or announce.
请注意，PCE能力的交换是以公告的形式进行的，而不是协商。也就是说，想要从PCE获得特定功能的PCC必须检查公布的功能，并选择用于特定请求的PCE。PCC无权要求PCE支持其未提供或未宣布的功能。
A PCC may also vary which PCE it uses according to congestion information reported by the PCEs using the Notification Object and Notification Type [RFC5440]. In a heavily overloaded PCE system, note that reports from one PCE that it is overloaded may simply result in all PCCs switching to another PCE, which will, itself, immediately become overloaded. Thus, PCCs should exercise a certain amount of discretion and queueing theory before selecting a PCE purely based on reported load.
PCC还可以根据PCE使用通知对象和通知类型报告的拥塞信息改变其使用的PCE[RFC5440]。在严重过载的PCE系统中，请注意，来自一个PCE的过载报告可能只会导致所有PCC切换到另一个PCE，而另一个PCE本身会立即过载。因此，PCC在纯粹根据报告的负载选择PCE之前，应行使一定的自由裁量权和排队理论。
Note that a PCC could send all requests to all PCEs that it knows about. It can then select between the results, perhaps choosing the first result it receives, but this approach is very likely to overload all the PCEs in the network considering that one of the reasons for multiple PCEs is to share the load.
请注意，PCC可以向其知道的所有PCE发送所有请求。然后，它可以在结果之间进行选择，也许可以选择它接收到的第一个结果，但是考虑到多个pce的原因之一是共享负载，这种方法很可能会使网络中的所有pce过载。
A network may have more than one PCE, as discussed in the previous sections. These PCEs may provide redundancy for load-sharing, resilience, or partitioning of computation features.
如前几节所述，一个网络可能有多个PCE。这些PCE可为负载共享、弹性或计算功能分区提供冗余。
In order to achieve some consistency between the results of different PCEs, it is desirable that they operate on the same TE information.
为了在不同PCE的结果之间实现某种一致性，希望它们使用相同的TE信息。
The TED reflects the actual state of the network and is not a resource reservation or booking scheme. Therefore, a PCE-based system does not prevent competition for network resources during the provisioning phase, although a process of "sticky resources" that are temporarily reduced in the TED after a computation may be applied purely as a local implementation feature.
TED反映了网络的实际状态，不是资源预订或预订计划。因此，基于PCE的系统不会阻止在供应阶段期间对网络资源的竞争，尽管在计算之后在TED中临时减少的“粘性资源”的过程可以纯粹地作为本地实现特征应用。
One option for ensuring that multiple PCEs use the same TE information is simply to have the PCEs driven from the same TED. This could be achieved in implementations by utilizing a shared database, but it is unlikely to be efficient.
确保多个PCE使用相同TE信息的一个选项是简单地让PCE从相同的TED驱动。这可以通过使用共享数据库在实现中实现，但不太可能是有效的。
More likely is that each PCE is responsible for building its own TED independently, using the techniques described in Section 3. If the PCEs participate in the IGP, it is likely that they will attach at different points in the network; so, there may be minor and temporary inconsistencies between their TEDs caused by IGP convergence issues. If the PCEs gather TE information via BGP-LS [LS-DISTRIB] from different sources, the same inconsistencies may arise. However, if the PCEs attach to the same BGP speaker, it may be possible to achieve consistency between TEDs modulo the BGP-LS process itself.
更可能的情况是，每个PCE负责使用第3节中描述的技术独立构建自己的TED。如果PCE参与IGP，则它们很可能会连接到网络中的不同点；因此，由于IGP收敛问题，它们的TED之间可能存在微小和暂时的不一致。如果PCE通过BGP-LS[LS-DISTRIB]从不同来源收集TE信息，则可能会出现相同的不一致。但是，如果PCE连接到同一个BGP扬声器，则可以通过BGP-LS过程本身实现TED之间的一致性。
A final option is to provide an explicit synchronization process between the TED of a "master" PCE and the TEDs of other PCEs. Such a process could be achieved using BGP-LS or a database synchronization protocol (which would allow check-pointing and sequential updates). This approach is fraught with issues around selection of the master PCE and handling failures. It is, in fact, a mirrored database scenario: a problem that is well known and the subject of plenty of work.
最后一个选项是在“主”PCE的TED和其他PCE的TED之间提供显式同步过程。这种过程可以使用BGP-LS或数据库同步协议（允许检查点和顺序更新）来实现。这种方法充满了选择主PCE和处理故障的问题。事实上，这是一个镜像数据库场景：这是一个众所周知的问题，也是大量工作的主题。
Noting that the provisioning protocols such as RSVP-TE [RFC3209] already handle contention for resources, that the differences between TEDs are likely to be relatively small with moderate arrival rates for new services, and that contention in all but the most busy networks is relatively unlikely, there may be no value in any attempt to synchronize TEDs between PCEs.
注意到诸如RSVP-TE[RFC3209]之类的供应协议已经处理资源争用，TED之间的差异可能相对较小，新服务的到达率适中，并且除了最繁忙的网络外，在所有网络中争用的可能性相对较小，在PCE之间同步TED的任何尝试中可能没有任何价值。
However, see Section 16 for a discussion of synchronizing other state between redundant PCEs.
但是，有关在冗余PCE之间同步其他状态的讨论，请参见第16节。
Path computation provides an end-to-end path between a source and a destination. If the destination lies in the source domain, then its location will be known to the PCE and there are no issues to be solved. However, in a multi-domain system a path must be found to a remote domain that contains the destination, and that can only be achieved by knowledge of the location of the destination or at least knowing the next domain in the path toward the domain that contains the destination.
路径计算提供源和目标之间的端到端路径。如果目标位于源域中，则PCE将知道其位置，并且没有需要解决的问题。但是，在多域系统中，必须找到到包含目的地的远程域的路径，并且这只能通过了解目的地的位置或至少知道指向包含目的地的域的路径中的下一个域来实现。
The simplest solution here is achieved when a PCE has visibility into multiple domains. Such may be the case in a multi-area network where the PCE is aware of the contents of all of the IGP areas. This approach is only likely to be appropriate where the number of nodes is manageable, and it is unlikely to extend over administrative boundaries.
这里最简单的解决方案是当一个PCE可以看到多个域时。在多区域网络中可能是这样的情况，其中PCE知道所有IGP区域的内容。这种方法可能只适用于节点数量可管理的情况，并且不太可能扩展到管理边界。
The per-domain path computation method for establishing inter-domain traffic engineering LSPs [RFC5152] simply requires a PCE to compute a path to the next domain toward the destination. As the LSP setup (through signaling) progresses domain by domain, the Label Switching Router (LSR) at the entry point to each domain requests its local PCE to compute the next segment of the path, that is from that LSR to the next domain in the sequence toward the destination. Thus, it is not necessary for any PCE (except the last) to know in which domain the destination exists. But, in this approach, each PCE must somehow determine the next domain toward the destination, and it is not obvious how this is achieved.
用于建立域间流量工程lsp[RFC5152]的每域路径计算方法只需要PCE计算到下一个域到目的地的路径。随着LSP设置（通过信令）逐域进行，每个域的入口点处的标签交换路由器（LSR）请求其本地PCE计算路径的下一段，即从该LSR到朝向目的地的序列中的下一个域。因此，任何PCE（最后一个除外）都不必知道目标存在于哪个域中。但是，在这种方法中，每个PCE必须以某种方式确定目标的下一个域，而这是如何实现的并不明显。
[RFC5152] suggests that, in an IP/MPLS network, it is good enough to leverage the IP reachability information distributed by BGP and assume that TE reachability can follow the same Autonomous System (AS) path. This approach might not guarantee the optimal TE path and, of course, might result in no path being found in degenerate cases. Furthermore, in many network technologies (such as optical networks operated by GMPLS) there may be limited or no end-to-end IP connectivity.
[RFC5152]建议，在IP/MPLS网络中，充分利用BGP分发的IP可达性信息，并假设TE可达性可以遵循相同的自治系统（AS）路径。这种方法可能无法保证最佳TE路径，当然，可能会导致在退化情况下找不到路径。此外，在许多网络技术（如GMPLS运营的光网络）中，端到端IP连接可能有限或没有。
The Backward Recursive PCE-based Computation (BRPC) procedure [RFC5441] is able to achieve a more optimal end-to-end path than the per-domain method, but depends on the knowledge of both the domain in which the destination is located and the sequence of domains toward the destination. This information is described in [RFC5441] as being known a priori. Clearly, however, information is not always known a priori, and it may be hard for the PCE that serves the source PCC to discover the necessary details. While there are several approaches to solving the question of establishing the domain sequence (for example, BRPC trial and error or H-PCE [RFC6805]), none of them addresses the issue of determining where the destination lies.
基于PCE的反向递归计算（BRPC）程序[RFC5441]能够实现比每域方法更优化的端到端路径，但取决于目标所在域的知识和朝向目标的域序列。[RFC5441]中对该信息的描述是先验的。然而，显然，信息并不总是先验的，为源PCC服务的PCE可能很难发现必要的细节。虽然有几种方法可以解决建立域序列的问题（例如，BRPC试错或H-PCE[RFC6805]），但没有一种方法能够解决确定目标位置的问题。
One argument that is often made is that an end-to-end connection expressed as an LSP is a feature of a service agreement between source and destination. If that is the case, it is argued, it stands to reason that the location of the destination must be known to the source node in the same way that the source has determined the IP address of the destination. Presumably, this would be through a commercial process or an administrative protocol.
经常提出的一个论点是，表示为LSP的端到端连接是源和目标之间的服务协议的一个特征。如果是这种情况，则有人认为，源节点必须知道目的地的位置，其方式与源确定目的地的IP地址的方式相同。据推测，这将通过商业流程或管理协议实现。
[RFC4974] introduced the concept of Calls and Connections for LSPs. A Call does not provide the actual connectivity for transmitting user traffic, but builds a relationship that will allow subsequent Connections to be made. A Call might be considered an agreement to support an end-to-end LSP that is made between the endpoint nodes. Call messages are sent and routed as normal IP messages, so the sender does not need to know the location of the destination.
[RFC4974]介绍了LSP调用和连接的概念。呼叫不提供传输用户流量的实际连接，而是建立一种允许进行后续连接的关系。调用可能被视为支持端点节点之间进行的端到端LSP的协议。呼叫消息作为普通IP消息发送和路由，因此发送者不需要知道目的地的位置。
Furthermore, Call requests are responded, and the Call Response can carry information (such as the identity of the domain containing the destination) for use by Call initiator. Thus, the use of GMPLS Calls might provide a mechanism to discover destination's location.
此外，呼叫请求被响应，并且呼叫响应可以携带信息（例如包含目的地的域的标识）以供呼叫发起方使用。因此，使用GMPLS调用可能会提供一种发现目的地位置的机制。
A parent PCE [RFC6805] is responsible for selecting inter-domain path by coordinating with child PCEs and maintaining a domain topology map.
父PCE[RFC6805]负责通过与子PCE协调并维护域拓扑图来选择域间路径。
In the case of multi-domains (e.g., IGP areas or multiple ASes) within a single service provider network, the management responsibility for the parent PCE would most likely be handled by the service provider.
在单个服务提供商网络内的多个域（例如，IGP区域或多个ASE）的情况下，父PCE的管理责任最有可能由服务提供商处理。
In the case of multiple ASes within different service provider networks, it may be necessary for a third party to manage the parent PCEs according to commercial and policy agreements from each of the participating service providers. Note that the H-PCE architecture does not require disclosure of internals of a child domain to the parent PCE. Thus, there is ample scope for a parent PCE to be run by one of the connected service providers or by a third party without compromising commercial issues. In fact, each service provider could run its own parent PCE while allowing its child PCEs to be contacted by outsider parent PCEs according to configured policy and security.
在不同服务提供商网络内的多个ASE的情况下，第三方可能需要根据来自每个参与服务提供商的商业和政策协议来管理父PCE。请注意，H-PCE体系结构不要求向父PCE披露子域的内部结构。因此，在不损害商业问题的情况下，由连接的服务提供商之一或第三方运行父PCE有足够的空间。事实上，每个服务提供商都可以运行自己的父PCE，同时允许外部父PCE根据配置的策略和安全性联系其子PCE。
[RFC6805] specifies that a child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. There is no scope for parent PCEs to advertise their presence; however, there is potential for directory systems (such as DNS [RFC4848] as used in the ALTO discovery function [ALTO-SERVER-DISC]) to be used as described in Section 4.
[RFC6805]指定必须使用其父PCE的地址配置子PCE，以便它与其父PCE交互。母公司PCE没有空间宣传其存在；但是，目录系统（如ALTO发现功能[ALTO-SERVER-DISC]中使用的DNS[RFC4848]）有可能如第4节所述使用。
According to [RFC6805], note that the child PCE must also be authorized to peer with the parent PCE. This is discussed from the viewpoint of the parent PCE in Section 10. The child PCE may need to participate in a key distribution protocol in order to properly authenticate its identity to the parent PCE.
根据[RFC6805]，注意子PCE也必须被授权与父PCE对等。第10节从母PCE的角度对此进行了讨论。子PCE可能需要参与密钥分发协议，以便向父PCE正确地认证其身份。
Within the hierarchical PCE framework [RFC6805], the parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives a request from an unauthorized child PCE, the request should be dropped.
在分层PCE框架[RFC6805]中，父PCE必须只接受来自授权子PCE的路径计算请求。如果父PCE收到来自未经授权的子PCE的请求，则应放弃该请求。
This requires a parent PCE to be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE.
这要求父PCE配置其所有子PCE的身份和安全凭据，或者必须存在某种形式的共享机密，允许未知子PCE由父PCE授权。
The parent PCE maintains a domain topology map of the child domains and their interconnectivity. This map does not include any visibility into the child domains. Where inter-domain connectivity is provided by TE links, the capabilities of those links may also be known to the parent PCE.
父PCE维护子域及其互连的域拓扑图。此映射不包括对子域的任何可见性。当域间连接由TE链路提供时，这些链路的能力也可为父PCE所知。
The parent PCE maintains a TED for the parent domain in the same way that any PCE does. The nodes in the parent domain will be abstractions of the child domains (connected by real or virtual TE links), but the parent domain may also include real nodes and links.
父PCE以与任何PCE相同的方式维护父域的TED。父域中的节点将是子域的抽象（通过真实或虚拟TE链接连接），但父域也可能包括真实节点和链接。
The mechanism for building the parent TED is likely to rely heavily on administrative configuration and commercial issues because the network was probably partitioned into domains specifically to address these issues. However, note that in some configurations (for example, collections of small optical domains) a separate instance of a routing protocol (probably an IGP) may be run within the parent domain to advertise the domain interconnectivity. Additionally, since inter-domain TE links can be advertised by the IGPs operating in the child domains, this information could be exported to the parent PCE either by the child PCEs or using a north-bound export mechanism such as BGP-LS [LS-DISTRIB].
构建父TED的机制可能严重依赖于管理配置和商业问题，因为网络可能被划分为专门用于解决这些问题的域。然而，请注意，在一些配置中（例如，小型光学域的集合），路由协议的单独实例（可能是IGP）可在父域内运行，以公布域互连。此外，由于域间TE链路可由在子域中操作的igp播发，因此该信息可由子PCE或使用诸如BGP-LS[LS-DISTRIB]的北向导出机制导出到父PCE。
The model described in [RFC6805] introduced a hierarchical relationship between domains. It is applicable to environments with small groups of domains where visibility from the ingress LSRs is limited. Applying the hierarchical PCE model to large groups of domains such as the Internet is not considered feasible or desirable.
[RFC6805]中描述的模型引入了域之间的层次关系。它适用于具有少量域组的环境，其中来自入口LSR的可见性受到限制。将分层PCE模型应用于大型领域组（如互联网）被认为是不可行或不可取的。
This does open up a harder question: how many domains can be handled by an H-PCE system? In other words: what is a small group of domains? The answer is not clear and might be "I know it when I see it." At the moment, a rough guide might be around 20 domains as a maximum.
这确实打开了一个更难的问题：一个H-PCE系统可以处理多少个域？换句话说：什么是一小群域？答案并不清楚，可能是“我看到它时就知道了。”目前，一份粗略的指南最多可能有20个域名。
An associated question would be: how many hierarchy levels can be handled by H-PCE? Architecturally, the answer is that there is no limit, but it is hard to construct practical examples where more than two or possibly three levels are needed.
一个相关的问题是：H-PCE可以处理多少层级？在架构上，答案是没有限制，但很难构建需要两个或三个以上级别的实际示例。
When a PCE computes a path, it has a reasonable idea that an LSP will be set up and that resources will be allocated within the network. If the arrival rate of computation requests is faster than the LSP setup rate combined with the IGP convergence time, it is quite possible that the PCE will perform its next computation before the TED has been updated to reflect the setup of the previous LSP. This can result in LSP setup failures if there is contention for resources. The likelihood of this problem is particularly high during recovery from network failures when a large number of LSPs might need new paths.
当PCE计算路径时，它有一个合理的想法，即将建立LSP，并在网络内分配资源。如果计算请求的到达速率快于LSP设置速率加上IGP收敛时间，则PCE很可能在更新TED以反映先前LSP的设置之前执行其下一次计算。如果存在资源争用，这可能导致LSP安装失败。在从网络故障恢复期间，当大量LSP可能需要新路径时，出现此问题的可能性特别高。
A PCE may choose to make a provisional assignment of the resources that would be needed for an LSP and to reduce the available resources in its TED so that the problem is mitigated. Such resources are informally known as "sticky resources".
PCE可以选择临时分配LSP所需的资源，并减少其TED中的可用资源，从而缓解问题。这种资源非正式地称为“粘性资源”。
Note that using sticky resources introduces a number of other problems that can make managing the TED difficult. For example:
请注意，使用粘性资源会带来许多其他问题，使TED的管理变得困难。例如：
- When the TED is updated as a result of new information from the IGP, how does the PCE know whether the reduction in available resources is due to the successful setup of the LSP for which it is holding sticky resources or due to some other network event (such as the setup of another LSP)? This problem may be particularly evident if there are multiple PCEs that do not synchronize their sticky resources or if not all LSPs utilize PCE computation.
- 当TED因来自IGP的新信息而更新时，PCE如何知道可用资源的减少是由于成功设置了其持有粘性资源的LSP，还是由于某些其他网络事件（例如设置了另一个LSP）？如果有多个PCE不同步其粘性资源，或者并非所有LSP都使用PCE计算，则此问题可能特别明显。
- When LSP setup fails, how are the sticky resources released? Since the PCE doesn't know about the failure of the LSP setup, it needs some other mechanism to release them.
- 当LSP安装失败时，如何释放粘性资源？因为PCE不知道LSP设置的失败，所以它需要一些其他机制来释放它们。
- What happens if a path computation was made only to investigate the potential for an LSP but not to actually set one up?
- 如果进行路径计算只是为了调查LSP的可能性，而不是实际设置LSP，会发生什么情况？
- What if the path used by the LSP does not match that provided by the PCE (for example, because the control plane routes around some problem)?
- 如果LSP使用的路径与PCE提供的路径不匹配（例如，因为控制平面围绕某个问题布线），该怎么办？
Some of these issues can be mitigated by using a Stateful PCE (see Section 14) or by timers.
其中一些问题可以通过使用有状态PCE（见第14节）或定时器来缓解。
A Stateless PCE can perform path computations that take into account the existence of other LSPs if the paths of those LSPs are supplied on the computation request. This function can be particularly useful when arranging protection paths so that a working and protection LSP do not share any links or nodes. It can also be used when a group of LSPs are to be reoptimized at the same time in the process known as Global Concurrent Optimization (GCO) [RFC5557].
如果在计算请求中提供了其他LSP的路径，则无状态PCE可以执行考虑其他LSP存在的路径计算。该功能在安排保护路径时特别有用，以便工作和保护LSP不共享任何链路或节点。当一组LSP在称为全局并发优化（GCO）的过程中同时进行重新优化时，也可以使用该方法[RFC5557]。
However, this mechanism can be quite a burden on the protocol messages, especially when large numbers of LSP paths need to be reported.
然而，这种机制可能会对协议消息造成相当大的负担，特别是当需要报告大量LSP路径时。
A Stateful PCE [STATEFUL-PCE] maintains a database of LSPs (the LSP-DB) that are active in the network, i.e., have been provisioned such that they use network resources although they might or might not be carrying traffic. This database allows a PCC to refer to an LSP using only its identifier -- all other details can be retrieved by the PCE from the LSP-DB.
有状态PCE[Stateful-PCE]维护网络中活动的LSP（LSP-DB）的数据库，即，已设置为使用网络资源，尽管它们可能承载或不承载流量。该数据库允许PCC仅使用其标识符引用LSP——PCE可以从LSP-DB检索所有其他详细信息。
A Stateful PCE can use the LSP-DB for many other functions, such as balancing the distribution of LSPs in the network. Furthermore, the PCE can correlate LSPs with network resource availability placing new LSPs more cleverly.
有状态PCE可以将LSP-DB用于许多其他功能，例如平衡LSP在网络中的分布。此外，PCE可以将lsp与网络资源可用性关联起来，从而更巧妙地放置新的lsp。
A Stateful PCE that is also an Active PCE (see Section 17) can respond to changes in network resource availability and predicted demands to reroute LSPs that it knows about.
同时也是活动PCE的有状态PCE（参见第17节）可以响应网络资源可用性的变化和它所知道的重新路由LSP的预测需求。
Section 20 offers a brief comparison of the different modes of PCE with reference to stateful and stateless PCE.
第20节简要比较了有状态和无状态PCE的不同模式。
The LSP-DB contains information about the LSPs that are active in the network, as mentioned in Section 14. This state information can be constructed by the PCE from information it receives from a number of sources including from provisioning tools and from the network, but no matter how the information is gleaned, a Stateful PCE needs to synchronize its LSP-DB with the state in the network. Just as described in Section 13, the PCE cannot rely on knowledge about previous computations it has made, but it must find out the actual LSPs in the network.
LSP-DB包含关于网络中活动的LSP的信息，如第14节所述。该状态信息可由PCE根据其从多个来源（包括供应工具和网络）接收到的信息构建，但无论如何收集信息，有状态PCE都需要将其LSP-DB与网络中的状态同步。正如第13节中所述，PCE不能依赖其先前进行的计算的知识，但必须找出网络中的实际LSP。
A simple solution is for all ingress LSRs to report all LSPs to the PCE as they are set up, modified, or torn down. Since PCEP already has the facility to fully describe LSP routes and resources in the protocol messages, this is not a difficult problem, and the LSP State Report (PCRpt) message has been defined for this purpose [STATEFUL-PCE].
一个简单的解决方案是，所有入口LSR在设置、修改或拆除LSP时向PCE报告所有LSP。由于PCEP已经具备在协议消息中完整描述LSP路由和资源的功能，因此这不是一个难题，LSP状态报告（PCRpt）消息已为此目的定义[STATEFUL-PCE]。
The situation can be more complex, however, if there are ingress LSRs that do not support PCEP, support PCEP but not the PCRpt, or that are unaware of the requirement to report LSPs to the PCE. This might happen if the LSRs are able to compute paths themselves or if they receive LSP setup instructions with pre-computed paths from an NMS.
但是，如果存在不支持PCEP、支持PCEP但不支持PCRpt的入口LSR，或者不知道向PCE报告LSP的要求，则情况可能更复杂。如果LSR能够自己计算路径，或者从NMS接收到带有预先计算路径的LSP设置指令，则可能会发生这种情况。
An alternative approach is to note that any LSR on the path of an LSP can probably see the whole path (through the Record Route object in RSVP-TE signaling [RFC3209]) and knows the bandwidth reserved for the LSP. Thus, any LSR could report the LSP to the PCE, noting that it will not hurt (beyond additional message processing and potential overload of the PCE or the network) for the LSP to be reported multiple times because it is clearly identified. In fact, this would also provide a cross-check mechanism.
另一种方法是注意，LSP路径上的任何LSR都可能看到整个路径（通过RSVP-TE信令[RFC3209]中的记录路由对象），并且知道为LSP保留的带宽。因此，任何LSR都可以向PCE报告LSP，注意到LSP被多次报告不会造成伤害（除了额外的消息处理和PCE或网络的潜在过载之外），因为它被清楚地识别。事实上，这也将提供一个交叉检查机制。
Nevertheless, it is possible that some LSPs will traverse only LSRs that are not aware of the PCE's need to learn LSP state and build an LSP-DB. In these cases, the stateful PCE must either only have limited knowledge of the LSPs in the network or must learn about LSPs through some other mechanism (such as reading the MPLS and GMPLS MIB modules [RFC3812] [RFC4802]).
然而，一些LSP可能只遍历不知道PCE需要了解LSP状态和构建LSP-DB的LSR。在这些情况下，有状态PCE必须仅对网络中的lsp具有有限的知识，或者必须通过一些其他机制（例如读取MPLS和GMPLS MIB模块[RFC3812][RFC4802]）了解lsp。
Ultimately, there may be no substitute for all LSRs being aware of Stateful PCEs and able to respond to requests for reports on all LSPs that they know about. This will allow a Stateful PCE to build its LSP-DB from scratch (which it may need to do at start of day) and to verify its LSP-DB against the network (which may be important if the PCE has suffered some form of outage).
最终，可能没有什么可以替代所有LSR了解有状态的PCE，并能够响应他们所知道的所有LSP的报告请求。这将允许有状态PCE从头开始构建其LSP-DB（可能需要在一天开始时进行），并根据网络验证其LSP-DB（如果PCE遭受某种形式的中断，这可能很重要）。
It is important that two PCEs operating in a network have similar views of the available resources. That is, they should have the same or substantially similar TEDs. This is easy to achieve either by building the TEDs from the network in the same way or by one PCE synchronizing its TED to the other PCE using a TED export protocol such as BGP-LS [LS-DISTRIB] or the Network Configuration Protocol (NETCONF) [RFC6241] (see Section 6).
重要的是，在网络中运行的两个PCE对可用资源的看法相似。也就是说，它们应该具有相同或基本相似的TED。通过以相同的方式从网络构建TED，或者通过一个PCE使用TED导出协议（如BGP-LS[LS-DISTRIB]或网络配置协议（NETCONF）[RFC6241]（参见第6节）将其TED同步到另一个PCE，这很容易实现。
Synchronizing the LSP-DB can be a more complicated issue. As described in Section 15, building the LSP-DB can be an involved process, so it would be best to not have multiple PCEs each trying to build an LSP-DB from the network. However, it is still important that where multiple PCEs operate in the network (either as distributed PCEs or with one acting as a backup for the other), their LSP-DBs are kept synchronized.
同步LSP-DB可能是一个更复杂的问题。如第15节所述，构建LSP-DB可能是一个复杂的过程，因此最好不要让多个PCE各自尝试从网络构建LSP-DB。然而，当多个pce在网络中运行时（作为分布式pce或一个pce作为另一个pce的备份），它们的LSP DBs保持同步仍然很重要。
Thus, there is likely to be a need for a protocol mechanism for one PCE to update its LSP-DB with that of another PCE. This is no different from any other database-synchronization problem and could use existing mechanisms or a new protocol. Note, however, that in the case of distributed PCEs that are also Active PCEs (see Section 17), each PCE will be creating entries in its own LSP-DB; so, the synchronization of databases must be incremental and bidirectional, not just simply a database dump.
因此，可能需要一种协议机制，用于一个PCE用另一个PCE的LSP-DB更新其LSP-DB。这与任何其他数据库同步问题没有区别，可以使用现有机制或新协议。但是，请注意，如果分布式PCE也是活动PCE（参见第17节），则每个PCE将在其自己的LSP-DB中创建条目；因此，数据库的同步必须是增量和双向的，而不仅仅是数据库转储。
It may be helpful to clarify the word "redundant" in the context of this question. One interpretation is that a redundant PCE exists solely as a backup such that it only performs a function in the network in the event of a failure of the primary PCE. This seems like a waste of expensive resources, and it would make more sense for the redundant PCE to take its share of computation load all the time. However, that scenario of two (or more) active PCEs creates exactly the state synchronization issue described above.
在这个问题的背景下澄清“多余”一词可能会有所帮助。一种解释是，冗余PCE仅作为备份存在，因此它仅在主PCE发生故障时在网络中执行功能。这似乎是对昂贵资源的浪费，而让冗余PCE一直承担其计算负载的份额更有意义。然而，两个（或更多）活动PCE的场景恰恰产生了上述状态同步问题。
Various deployment options have been suggested where one PCE serves a set of PCCs as the primary computation server, and only addresses requests from other PCCs in the event of the failure of some other PCE; however, this mode of operation still raises questions about the need for synchronized state even in non-failure scenarios if the LSPs that will be computed by the different PCEs may traverse the same network resources.
已经提出了各种部署选项，其中一个PCE将一组PCC用作主计算服务器，并且仅在某些其他PCE发生故障时处理来自其他PCC的请求；然而，如果将由不同pce计算的lsp可能穿越相同的网络资源，则这种操作模式仍然会引起关于即使在非故障场景中也需要同步状态的问题。
A Passive PCE is one that only responds to path computation requests. It takes no autonomous actions. A Passive PCE may be stateless or stateful.
被动PCE是只响应路径计算请求的PCE。它不采取自主行动。被动PCE可以是无状态的或有状态的。
An Active PCE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs or routes for new LSPs (that is, an Active PCE may recommend the instantiation of new LSPs). An Active PCE may be stateless or stateful, but in order for it to reroute existing LSPs effectively, it is likely to hold state for at least those LSPs that it will reroute.
活动PCE是向网络发布供应“建议”的PCE。这些建议可以是现有LSP的新路由或新LSP的路由（即，活动PCE可以建议新LSP的实例化）。活动PCE可能是无状态的或有状态的，但为了有效地重新路由现有LSP，它可能会保持至少它将重新路由的那些LSP的状态。
Many people consider that the PCE, itself, cannot be Active. That is, they hold that the PCE's function is purely to compute paths. In that worldview, the "Active PCE" is actually the combination of a normal, passive PCE and an additional architectural component responsible for issuing commands or recommendations to the network.
许多人认为PCE本身不能激活。也就是说，他们认为PCE的功能纯粹是计算路径。在这个世界观中，“主动PCE”实际上是普通、被动PCE和负责向网络发出命令或建议的附加架构组件的组合。
In some configurations, the VNTM discussed in Sections 21 and 22 provides this additional component.
在某些配置中，第21节和第22节中讨论的VNTM提供了此附加组件。
Section 20 offers a brief comparison of the different modes of PCE with reference to passive and active PCE.
第20节简要比较了被动和主动PCE的不同模式。
LSP delegation [STATEFUL-PCE] is the process where a PCC (usually an ingress LSR) passes responsibility for triggering updates to the attributes of an LSP (such as bandwidth or path) to the PCE. In this case, the PCE would need to be both Stateful and Active.
LSP委派[STATEFUL-PCE]是PCC（通常是入口LSR）将触发LSP属性（如带宽或路径）更新的责任传递给PCE的过程。在这种情况下，PCE需要是有状态的和活动的。
LSP delegation allows an LSP to be set up under the control of the ingress LSR potentially using the services of a PCE. Once the LSP has been set up, the LSR (a PCC) tells the PCE about the LSP by providing details of the path and resources used. It delegates responsibility for the LSP to the PCE so that the PCE can make adjustments to the LSP as dictated by changes to the TED and the policies in force at the PCE. The PCE makes the adjustments by sending a new path to the LSR with the instruction/recommendation that the LSP be re-signaled.
LSP委派允许在入口LSR的控制下设置LSP，该入口LSR可能使用PCE的服务。LSP设置完成后，LSR（PCC）通过提供所用路径和资源的详细信息告知PCE有关LSP的信息。它将LSP的责任委托给PCE，以便PCE可以根据TED和PCE现行政策的变化对LSP进行调整。PCE通过向LSR发送一条新路径以及指示/建议重新发送LSP信号来进行调整。
There may be some debate over whether the PCE "owns" the LSP after delegation. That is, if the PCE supplies a new path, is the ingress LSR required to act or can it take the information "under advisement"? It may be too soon to answer this question definitively; however, there is certainly an expectation that the LSR will act on the advice it receives. A comparison may be drawn with a visit to the doctor: the doctor has an expectation that the patient will take the medicine, but the patient has free will.
可能会有一些关于PCE在授权后是否“拥有”LSP的争论。也就是说，如果PCE提供了一条新路径，那么入口LSR是否需要采取行动，或者它是否可以“在建议下”获取信息？现在回答这个问题可能还为时过早；然而，人们当然期望地方选区代表会根据其收到的建议采取行动。可以通过拜访医生来进行比较：医生期望患者服用药物，但患者有自由意志。
It is important, however, to distinguish between an LSP established within the network and subsequently delegated to a PCE and an LSP that was established as the result of an Active PCE's recommendation for LSP instantiation.
然而，重要的是区分在网络内建立并随后委托给PCE的LSP和作为活动PCE建议LSP实例化的结果而建立的LSP。
Section 20 offers a brief comparison of the different modes of PCE with reference to LSP delegation.
第20节提供了关于LSP委托的PCE不同模式的简要比较。
In many ways the answer here is "yes". But the PCE architecture forms part of a new way of looking at network operation and management. In this new view, the network operation is more dynamic and under the control of software applications without direct intervention from operators. This is not to say that the operator has no say in how their network runs, but it does mean that the operator sets policies (see Section 24) and that new components (such as an Active PCE) are responsible for acting on those policies to dynamically control the network.
在许多方面，这里的答案是“是”。但PCE体系结构构成了看待网络运营和管理的新方式的一部分。在这一新观点中，网络运行更加动态，在软件应用程序的控制下，无需运营商的直接干预。这并不是说运营商对其网络如何运行没有发言权，而是说运营商设置策略（见第24节），新组件（如活动PCE）负责根据这些策略采取行动，以动态控制网络。
There is a subtle distinction between an NMS and an Active PCE with LSP delegation. An NMS is in control of the LSPs in the network and can command that they are set up, modified, or torn down. An Active PCE can only make suggestions about LSPs that have been delegated to the PCE by a PCC, or make recommendations for the instantiation of new LSPs.
NMS和具有LSP委托的活动PCE之间存在细微的区别。NMS控制网络中的LSP，并可以命令设置、修改或拆除LSP。活动PCE只能对PCC委托给PCE的LSP提出建议，或对新LSP的实例化提出建议。
For more details, see the discussion of an architecture for Application-Based Network Operation (ABNO) in [NET-OPS]
有关更多详细信息，请参阅[NET-OPS]中关于基于应用程序的网络操作（ABNO）体系结构的讨论
Table 1 shows a comparison of stateless and stateful PCEs to show how they how might be instantiated as passive or active PCEs with or without control of LSPs. The terms used relate to the concepts introduced in the previous sections. The entries in the table refer to the notes that follow.
表1显示了无状态和有状态PCE的比较，以显示它们如何在有或无LSP控制的情况下被实例化为被动或主动PCE。所使用的术语与前面章节中介绍的概念有关。表中的条目指的是以下注释。
| Stateless | Stateful |
------------------------+-----------+-----------+
Passive | 1 | 2 |
Active delegated LSPs | 3 | 4 |
Active suggest new LSPs | 5 | 6 |
Active instantiate LSPs | 7 | 7 |
| Stateless | Stateful |
------------------------+-----------+-----------+
Passive | 1 | 2 |
Active delegated LSPs | 3 | 4 |
Active suggest new LSPs | 5 | 6 |
Active instantiate LSPs | 7 | 7 |
Notes: 1. Passive is the normal mode for a stateless PCE. 2. A passive mode stateful PCE may have value for more complex environments and for computing protected services. 3. Delegation of LSPs to a stateless PCE is relatively pointless, but could add value at moment of delegation. 4. This is the normal mode for a stateful PCE. 5. There is only marginal potential for a stateless PCE to recommend new LSPs because without a view of existing LSPs, the PCE cannot determine when new ones might be needed. 6. This mode has potential for recommending the instantiation of new LSPs. 7. These modes are out of scope for PCE as currently described. That is, the PCE can recommend instantiation, but cannot actually instantiate the LSPs.
注：1。被动是无状态PCE的正常模式。2.被动模式有状态PCE对于更复杂的环境和计算受保护的服务可能有价值。3.将LSP委托给无状态PCE相对来说毫无意义，但可以在委托时增加价值。4.这是有状态PCE的正常模式。5.无状态PCE推荐新LSP的可能性很小，因为没有现有LSP的视图，PCE无法确定何时可能需要新LSP。6.这种模式有可能推荐新LSP的实例化。7.如目前所述，这些模式不适用于PCE。也就是说，PCE可以建议实例化，但不能实际实例化LSP。
Table 1 : Comparing Stateless and Stateful PCE
表1：比较无状态和有状态PCE
A Virtual Network Topology (VNT) is described in [RFC4397] as a set of Hierarchical LSPs that is created (or could be created) in a particular network layer to provide network flexibility (data links) in other layers. Thus, the TE topology of a network can be constructed from TE links that are simply data links, from TE links that are supported by LSPs in another layer of the network, or from TE links that could be supported by LSPs ("potential LSPs") that would be set up on demand in another network layer. This third type of TE link is known as a Virtual TE Link in [RFC5212].
[RFC4397]将虚拟网络拓扑（VNT）描述为在特定网络层中创建（或可以创建）的一组分层LSP，以在其他层中提供网络灵活性（数据链路）。因此，网络的TE拓扑可以由简单的数据链路的TE链路、由网络的另一层中的lsp支持的TE链路、或由将在另一网络层中根据需要设置的lsp（“潜在lsp”）支持的TE链路来构造。第三种类型的TE链路在[RFC5212]中称为虚拟TE链路。
[RFC5212] also gives a more detailed explanation of a VNT, and it should be noted that the network topology in a packet network could be supported by LSPs in a number of different lower-layer networks. For example, the TE links in the packet network could be achieved by connections (LSPs) in underlying Synchronous Optical Network or Synchronous Digital Hierarchy (SONET/SDH) and photonic networks. Furthermore, because of the hierarchical nature of MPLS, the TE links in a packet network may be achieved by setting up packet LSPs in the same packet network.
[RFC5212]还对VNT进行了更详细的解释，并且应当注意，分组网络中的网络拓扑可以由许多不同的低层网络中的LSP支持。例如，分组网络中的TE链路可以通过底层同步光网络或同步数字体系（SONET/SDH）和光子网络中的连接（lsp）来实现。此外，由于MPLS的分层性质，分组网络中的TE链路可以通过在同一分组网络中设置分组lsp来实现。
A PCE obviously works with the TED that contains information about the TE links in the network. Those links may be already established or may be virtual TE links. In a simple TED, there is no distinction between the types of TE link; however, there may be advantages to selecting TE links that are based on real data links over those based on dynamic LSPs in lower layers because the data links may be more stable. Conversely, the TE links based on dynamic LSPs may be able to be repaired dynamically giving better resilience. Similarly, a PCE may prefer to select a TE link that is supported by a data link or existing LSP in preference to using a virtual TE link because the latter may need to be set up (taking time) and the setup could potentially fail. Thus, a PCE might want to employ additional metrics or indicators to help it view the TED and select the right path for LSPs.
PCE显然与包含网络中TE链路信息的TED一起工作。这些链接可能已经建立，或者可能是虚拟TE链接。在一个简单的TED中，TE链接的类型没有区别；然而，选择基于真实数据链路的TE链路可能比选择基于较低层中的动态lsp的TE链路更有利，因为数据链路可能更稳定。相反，基于动态lsp的TE链路可以动态地修复，从而提供更好的弹性。类似地，PCE可能更喜欢选择数据链路或现有LSP支持的TE链路，而不是使用虚拟TE链路，因为后者可能需要设置（需要时间），并且设置可能会失败。因此，PCE可能希望采用额外的度量或指标来帮助其查看TED并为LSP选择正确的路径。
If a PCE uses a virtual TE link, then some action will be needed to establish the LSP that supports that link. Some models (such as that in [RFC5212]) trigger the setup of the lower-layer LSPs on-demand during the signaling of the upper-layer LSP (i.e., when the upper layer comes to use the virtual TE link, the upper-layer signaling is paused and the lower-layer LSP is established). Another view, described in [RFC5623], is that when the PCE computes a path that will use a virtual TE link, it should trigger the setup of the lower-layer LSP to properly create the TE link so that the path it returns will be sure to be viable. This latter mode of operation can be extended to allow the PCE to spot the need for additional TE links and to trigger LSPs in lower layers in order to create those links.
如果PCE使用虚拟TE链路，则需要采取一些措施来建立支持该链路的LSP。一些模型（例如[RFC5212]中的模型）在上层LSP的信令期间触发下层LSP按需设置（即，当上层开始使用虚拟TE链路时，上层信令暂停，并且建立下层LSP）。[RFC5623]中描述的另一种观点是，当PCE计算将使用虚拟TE链路的路径时，它应触发下层LSP的设置，以正确创建TE链路，从而确保其返回的路径是可行的。后一种操作模式可以扩展，以允许PCE发现额外TE链路的需要，并触发较低层中的lsp以创建这些链路。
Of course, such "interference" in a lower-layer network by a PCE responsible for a higher-layer network depends heavily on policy. In order to make a clean architectural separation and to facilitate proper policy control, [RFC5623] introduces the Virtual Network Topology Manager (VNTM) as a functional element that manages and controls the VNT. [RFC5623] notes that the PCE and VNT Manager are distinct functional elements that may or may not be collocated. indeed, it should be noted that there will be a PCE for the upper layer, and a PCE for each lower layer, and a VNTM responsible for coordinating between the PCEs and for triggering LSP setup in the lower layers. Therefore, the combination of all of the PCEs and the VNTM produces functionally similar to an Active, multi-layer PCE.
当然，负责高层网络的PCE在低层网络中的这种“干扰”在很大程度上取决于策略。为了实现清晰的体系结构分离并促进适当的策略控制，[RFC5623]引入了虚拟网络拓扑管理器（VNTM），作为管理和控制VNT的功能元素。[RFC5623]注意，PCE和VNT管理器是不同的功能元件，可以并置，也可以不并置。实际上，应该注意的是，将有一个用于上层的PCE和一个用于每个下层的PCE，以及一个负责协调PCE和触发下层中的LSP设置的VNTM。因此，所有PCE和VNTM的组合产生的功能类似于有源多层PCE。
See [TE-INFO] for additional discussion of the construction of networks using virtual and potential links.
有关使用虚拟链路和潜在链路构建网络的更多讨论，请参见[TE-INFO]。
The VNTM described in Section 21 and [RFC5623] has several interfaces (see also [NET-OPS]).
第21节和[RFC5623]中描述的VNTM有几个接口（另请参见[NET-OPS]）。
- In order to make decisions on whether to create new TE links, the VNTM needs to learn from the upper-layer PCE about resource shortages and the need for additional TE links. It can then make policy-based decisions to determine whether to create new TE links and how to support them through existing or new LSPs.
- 为了决定是否创建新的TE链路，VNTM需要从上层PCE了解资源短缺和额外TE链路的需要。然后，它可以做出基于策略的决策，以确定是否创建新的TE链路，以及如何通过现有或新的LSP支持它们。
- The VNTM will need to coordinate with the PCEs in the lower layers, but this is simply a normal use of PCEP.
- VNTM需要与下层的PCE协调，但这只是PCEP的正常使用。
- The VNTM will need to issue provisioning requests/commands (via the Provisioning Manager described in [NET-OPS]) to the lower-layer networks to cause LSPs to be set up to act as TE links in the higher layer network. A number of potential protocols exist for this function as described in [NET-OPS], but it should be noted that it makes a lot of sense for this interface to be the same as that used by an Active PCE when providing paths to the network.
- VNTM需要（通过[NET-OPS]中所述的供应管理器）向下层网络发出供应请求/命令，以使LSP被设置为作为上层网络中的TE链路。如[NET-OPS]中所述，该功能存在许多潜在协议，但应注意，当提供网络路径时，该接口与活动PCE使用的接口相同是非常有意义的。
LSP scheduling or calendaring is a process where LSPs are planned ahead of time, and they are only set up when needed. The challenge here is to ensure that the resources needed by an LSP and that were available when the LSP's path was computed are still available when the LSP needs to be set up. This needs to be achieved using a mechanism that allows those resources to be used in the meantime.
LSP计划或日历是提前计划LSP的过程，并且仅在需要时设置LSP。这里的挑战是确保LSP所需的资源以及计算LSP路径时可用的资源在需要设置LSP时仍然可用。这需要使用一种允许同时使用这些资源的机制来实现。
Previous discussion of this topic has suggested that LSPs should be pre-signaled so that each LSR along the path could make a "temporal reservation" of resources. But this approach can become very complicated requiring each network node to store multi-dimensional state.
先前对该主题的讨论建议，应预先通知LSP，以便路径上的每个LSR可以对资源进行“暂时保留”。但这种方法可能变得非常复杂，需要每个网络节点存储多维状态。
Conversely, a centralized database of resources and LSPs (such as the database maintained by a Stateful PCE) can be enhanced with a time-based booking system. If the PCE is also Active, then when the time comes for the LSP to be set up (or later, when it is to be torn down), the PCE can issue recommendations to the network.
相反，资源和LSP的集中数据库（如有状态PCE维护的数据库）可以通过基于时间的预订系统进行增强。如果PCE也处于活动状态，则当设置LSP（或稍后拆除LSP）时，PCE可以向网络发出建议。
In a busy network (and why would one bother with a scheduling service in a network that is not busy?), it should be noted that the computation algorithm can be quite complex. It may also be necessary to reposition existing or planned LSPs as new bookings arrive.
在繁忙的网络中（为什么要在不繁忙的网络中处理调度服务呢？），应该注意的是，计算算法可能非常复杂。随着新预订的到来，可能还需要重新定位现有或计划的LSP。
Furthermore, the booking database that contains both the scheduled LSPs and their impact on the network resources can become quite large. A very important factor in the size of the active database (depending on implementation) may be the timeslices that are available in the calendering process.
此外，包含计划LSP及其对网络资源的影响的预订数据库可能变得相当大。活动数据库大小的一个非常重要的因素（取决于实现）可能是压延过程中可用的时间片。
Policy is critical to the operation of a network. In a PCE context, it provides control and management of how a PCE selects network resources for use by different PCEs.
策略对于网络的运行至关重要。在PCE环境中，它提供了PCE如何选择网络资源供不同PCE使用的控制和管理。
[RFC5394] introduced the concept of PCE-based policy-enabled path computation. It is based on the Policy Core Information Model (PCIM) [RFC3060] as extended by [RFC3460], and provides a framework for supporting path computation policy.
[RFC5394]介绍了基于PCE的策略启用路径计算的概念。它基于[RFC3460]扩展的策略核心信息模型（PCIM）[RFC3060]，并提供了支持路径计算策略的框架。
Policy enters into all aspects of the use of a PCE starting from the very decision to use a PCE to off-load computation function from the LSRs.
从决定使用PCE从LSR卸载计算功能开始，策略就进入了PCE使用的所有方面。
- Each PCC must select which computations will be delegated to a PCE.
- 每个PCC必须选择哪些计算将委托给PCE。
- Each PCC must select which PCEs it will use.
- 每个PCC必须选择要使用的PCE。
- Each PCE must determine which PCCs are allowed to use its services and for what computations.
- 每个PCE必须确定允许哪些PCC使用其服务以及用于哪些计算。
- The PCE must determine how to collect the information in its TED, who to trust for that information, and how to refresh/update the information.
- PCE必须确定如何在其TED中收集信息，该信息的信任人，以及如何刷新/更新信息。
- Each PCE must determine which objective functions and which algorithms to apply.
- 每个PCE必须确定要应用的目标函数和算法。
- Inter-domain (and particularly H-PCE) computations will need to be sensitive to commercial and reliability information about domains and their interactions.
- 域间（尤其是H-PCE）计算需要对域及其交互的商业和可靠性信息敏感。
- Stateful PCEs must determine what state to hold, when to refresh it, and which network elements to trust for the supply of the state information.
- 有状态的PCE必须确定要保持的状态、何时刷新状态，以及在提供状态信息时信任哪些网络元素。
- An Active PCE must have a policy relationship with its LSRs to determine which LSPs can be modified or triggered, and what LSP delegation is supported.
- 活动PCE必须与其LSR具有策略关系，以确定可以修改或触发哪些LSP，以及支持哪些LSP委派。
- Multi-layer interactions (especially those using virtual or dynamic TE links) must provide policy control to stop server layer LSPs (which are fat and expensive by definition) from being set up on a whim to address micro-flows or speculative computations in higher layers.
- 多层交互（特别是那些使用虚拟或动态TE链接的交互）必须提供策略控制，以阻止服务器层LSP（定义上是胖的和昂贵的）一时兴起而建立，以解决更高层的微流或推测性计算。
- A PCE may supply, along with a computed path, policy information that should be signaled during LSP setup for use by the LSRs along the path.
- PCE可以与计算路径一起提供在LSP设置期间应当用信号通知的策略信息，以供lsr沿路径使用。
It may be seen, therefore, that a PCE is substantially a policy engine that computes paths. It should also be noted that the work of the PCE can be substantially controlled by configured policy in a way that will reduce the options available to the PCC, but also significantly reduce the need for the use of optional parameters in the PCEP messages.
因此，可以看出，PCE实质上是计算路径的策略引擎。还应注意，PCE的工作可以通过配置的策略以一种将减少PCC可用的选项的方式进行实质性控制，但也显著减少对PCEP消息中使用可选参数的需要。
Software-Defined Networking (SDN) is the latest shiny thing in networking. It refers to a separation between the control elements and the forwarding components so that software running in a centralized system called a controller, can act to program the devices in the network to behave in specific ways.
软件定义网络（SDN）是网络中最新的亮点。它是指控制元件和转发组件之间的分离，以便在称为控制器的集中式系统中运行的软件可以对网络中的设备进行编程，使其以特定方式运行。
A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place flows within the network given knowledge of the availability of network resources, how other forwarding devices are programmed, and the way that other flows are routed. This, it may be concluded, is the same function that a PCE might offer in a network operated using a dynamic control plane. Thus, a PCE could form part of the infrastructure for an SDN.
SDN体系结构中的一个必需元素是规划如何使用网络资源以及如何对设备进行编程的组件。在已知网络资源的可用性、其他转发设备的编程方式以及其他流的路由方式的情况下，可以将此组件视为执行特定计算以在网络内放置流。可以得出结论，这与PCE在使用动态控制平面操作的网络中可能提供的功能相同。因此，PCE可以构成SDN基础设施的一部分。
A view of how PCE integrates into a wider network control system including SDN is presented in [NET-OPS].
[NET-OPS]中介绍了PCE如何集成到更广泛的网络控制系统（包括SDN）中的观点。
The use of a PCE-based architecture and subsequent impact on network security must, itself, be considered in the context of existing routing and signaling protocols and techniques. The nature of multi-domain network scenarios and establishment of relationships between PCCs and PCEs may increase the vulnerability of the network to security attacks. However, this informational document does not define any new protocol elements or mechanism. As such, it does not introduce any new security issues and security is deemed to be a
必须在现有路由和信令协议及技术的背景下，考虑使用基于PCE的体系结构及其对网络安全的后续影响。多域网络场景的性质以及PCC和PCE之间关系的建立可能会增加网络对安全攻击的脆弱性。但是，本信息性文档未定义任何新的协议元素或机制。因此，它不会带来任何新的安全问题，安全被视为
"previously answered question" even if the answers previously supplied are not perfect. Previous PCE RFCs have given some attention to security concerns in the use of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088, and RFC 5089), and PCEP (RFC 4657 and RFC 5440).
“先前回答的问题”即使先前提供的答案并不完美。以前的PCE RFC对PCE（RFC 4655）、PCE发现（RFC 4674、RFC 5088和RFC 5089）和PCEP（RFC 4657和RFC 5440）的使用中的安全问题给予了一些关注。
It is worth noting that PCEP operates over TCP. An analysis of the security issues for routing protocols that use TCP (including PCEP) is provided in [RFC6952], while [PCE-PCEPS] discusses an experimental approach to provide secure transport for PCEP.
值得注意的是，PCEP通过TCP进行操作。[RFC6952]对使用TCP（包括PCEP）的路由协议的安全问题进行了分析，而[PCE-PCEP]讨论了为PCEP提供安全传输的实验方法。
A number of the questions raised and answered in this document should be given consideration in the light of security requirements. Some of these are called out explicitly (Sections 8 and 10), but attention should also be paid to security in all aspects of the use of PCE. For example:
应根据安全要求考虑本文件中提出和回答的一些问题。其中一些是明确规定的（第8节和第10节），但也应注意PCE使用各方面的安全性。例如：
- Topology and other information about the network needs to be kept private and protected from modification or forgery. That means that access to the TED, LSP-DB, etc., needs to be secured and that mechanisms used to gather topology and other information (Sections 2, 11, 14, and 15) need to include security.
- 有关网络的拓扑和其他信息需要保密，并防止修改或伪造。这意味着需要保护对TED、LSP-DB等的访问，并且用于收集拓扑和其他信息的机制（第2、11、14和15节）需要包括安全性。
- PCE discovery (Sections 4, 5, 9, and 10) needs to protect against impersonation or misconfiguration so that PCCs know that they are getting correct paths and so that PCEs know that they are only serving legitimate computation requests.
- PCE发现（第4、5、9和10节）需要防止模拟或错误配置，以便PCC知道他们获得了正确的路径，并且PCE知道他们只服务于合法的计算请求。
- Synchronization of information and state between PCEs (Sections 6 and 16) is subject to the same security requirements in that the information exchanged is sensitive and needs to be protected against interception and modification.
- PCE之间的信息和状态同步（第6节和第16节）受相同安全要求的约束，因为交换的信息是敏感的，需要受到保护，以防被拦截和修改。
- PCE computes paths for components that may provision the network. Those component are responsible for the security of the provisioning mechanisms, however, if PCE operates as a provisioning protocol (Sections 17, 18, 19, and 25).
- PCE计算可能提供网络的组件的路径。但是，如果PCE作为供应协议运行（第17、18、19和25节），则这些组件负责供应机制的安全性。
- A PCE may also need to interface with other network components (Sections 19, 21, 22, and 25). Those communications, if external to an implementation, also need to be secure.
- PCE可能还需要与其他网络组件接口（第19、21、22和25节）。这些通信，如果在实现外部，也需要安全。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 56232009年9月<http://www.rfc-editor.org/info/rfc5623>.
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]King，D.，Ed.，和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，RFC 6805，2012年11月<http://www.rfc-editor.org/info/rfc6805>.
[ALTO-SERVER-DISC] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", Work in Progress, draft-ietf-alto-server-discovery-10, September 2013.
[ALTO-SERVER-DISC]Kiesel，S.，Stiemerling，M.，Schwan，N.，Scharf，M.，和H.Song，“ALTO服务器发现”，正在进行的工作，草稿-ietf-ALTO-SERVER-Discovery-102013年9月。
[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, draft-ietf-idr-ls-distribution-06, September 2014.
[LS-DISTRIB]Gredler，H.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和TE信息的北向分布”，正在进行的工作，草稿-ietf-idr-LS-Distribution-062014年9月。
[NET-OPS] King, D., and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", Work in Progress, draft-farrkingel-pce-abno-architecture-13, October 2014.
[NET-OPS]King，D.和A.Farrel，“基于PCE的应用程序网络运营架构”，正在进行的工作，draft-farrkingel-PCE-abno-Architecture-13，2014年10月。
[PCE-PCEPS] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-02, October 2014.
[PCE-PCEP]Lopez，D.，Gonzalez de Dios，O.，Wu，Q.，和D.Dhody，“PCEP的安全运输”，正在进行的工作，草案-ietf-PCE-PCEPS-022014年10月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001, <http://www.rfc-editor.org/info/rfc3060>.
[RFC3060]Moore，B.，Ellesson，E.，Strassner，J.，和A.Westerinen，“政策核心信息模型——版本1规范”，RFC 3060，2001年2月<http://www.rfc-editor.org/info/rfc3060>.
[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, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003 <http://www.rfc-editor.org/info/rfc3460>.
[RFC3460]Moore，B.，Ed.，“政策核心信息模型（PCIM）扩展”，RFC3460，2003年1月<http://www.rfc-editor.org/info/rfc3460>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004, <http://www.rfc-editor.org/info/rfc3812>.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月<http://www.rfc-editor.org/info/rfc3812>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月<http://www.rfc-editor.org/info/rfc4203>.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006, <http://www.rfc-editor.org/info/rfc4397>.
[RFC4397]Bryskin，I.和A.Farrel，“在ITU-T自动交换光网络（ASON）体系结构背景下解释通用多协议标签交换（GMPLS）术语的词典”，RFC 4397，2006年2月<http://www.rfc-editor.org/info/rfc4397>.
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006, <http://www.rfc-editor.org/info/rfc4657>.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月<http://www.rfc-editor.org/info/rfc4657>.
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006, <http://www.rfc-editor.org/info/rfc4674>.
[RFC4674]Le Roux，J.，Ed.“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月<http://www.rfc-editor.org/info/rfc4674>.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月<http://www.rfc-editor.org/info/rfc4726>.
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>.
[RFC4802]Nadeau，T.，Ed.，和A.Farrel，Ed.，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 48022007年2月<http://www.rfc-editor.org/info/rfc4802>.
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007, <http://www.rfc-editor.org/info/rfc4848>.
[RFC4848]Daigle，L.，“使用URI和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 48482007年4月<http://www.rfc-editor.org/info/rfc4848>.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007, <http://www.rfc-editor.org/info/rfc4974>.
[RFC4974]Papadimitriou，D.和A.Farrel，“支持呼叫的通用MPLS（GMPLS）RSVP-TE信令扩展”，RFC 4974，2007年8月<http://www.rfc-editor.org/info/rfc4974>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008, <http://www.rfc-editor.org/info/rfc5088>.
[RFC5088]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月<http://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5089]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月<http://www.rfc-editor.org/info/rfc5089>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月<http://www.rfc-editor.org/info/rfc5152>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008, <http://www.rfc-editor.org/info/rfc5212>.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 52122008年7月<http://www.rfc-editor.org/info/rfc5212>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 53052008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月<http://www.rfc-editor.org/info/rfc5307>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008, <http://www.rfc-editor.org/info/rfc5394>.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月<http://www.rfc-editor.org/info/rfc5394>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）程序”，RFC 54412009年4月<http://www.rfc-editor.org/info/rfc5441>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5557]Lee，Y.，Le Roux，JL.，King，D.，和E.Oki，“支持全局并行优化的路径计算元素通信协议（PCEP）要求和协议扩展”，RFC 5557，2009年7月<http://www.rfc-editor.org/info/rfc5557>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 59862010年9月<http://www.rfc-editor.org/info/rfc5986>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010, <http://www.rfc-editor.org/info/rfc6006>.
[RFC6006]Zhao，Q.，Ed.，King，D.，Ed.，Verhaeghe，F.，Takeda，T.，Ali，Z.，和J.Meuria，“点对多点流量工程标签交换路径的路径计算元素通信协议（PCEP）扩展”，RFC 60062010年9月<http://www.rfc-editor.org/info/rfc6006>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.“网络配置协议（NETCONF）”，RFC 62412011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月<http://www.rfc-editor.org/info/rfc6952>.
[STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
[STATEFUL-PCE]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-STATEFUL-PCE-10，2014年10月。
[TE-INFO] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D, and X. Zhang, "Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks", Work in Progress, draft-farrel-interconnected-te-info-exchange-07, September 2014.
[TE-INFO]Farrel，A.，Ed.，Drake，J.，Bitar，N.，Swallow，G.，Ceccarelli，D和X.Zhang，“互联交通工程网络之间信息交换的问题陈述和体系结构”，正在进行的工作，草稿-Farrel-Interconnected-TE-INFO-Exchange-07，2014年9月。
Acknowledgements
致谢
Thanks for constructive comments go to Fatai Zhang, Oscar Gonzalez de Dios, Xian Zhang, Cyril Margaria, Denis Ovsienko, Ina Minei, Dhruv Dhody, and Qin Wu.
感谢张法泰、奥斯卡·冈萨雷斯·德迪奥斯、张贤、西里尔·玛格丽亚、丹尼斯·奥文科、伊娜·米尼、杜鲁夫·杜迪和秦武的建设性评论。
This work was supported in part by the FP-7 IDEALIST project under grant agreement number 317999.
这项工作部分得到了FP-7理想主义项目的支持，该项目的赠款协议编号为317999。
This work received funding from the European Union's Seventh Framework Programme for research, technological development and demonstration through the PACE project under grant agreement no. 619712.
这项工作得到了欧洲联盟第七个研究、技术开发和示范框架方案的资助，该方案通过第619712号赠款协议下的PACE项目进行。
Authors' Addresses
作者地址
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk
Adrian Farrel Juniper Networks电子邮件：adrian@olddog.co.uk
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk
Daniel King老狗咨询电子邮件：daniel@olddog.co.uk