Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 8283 Juniper Networks
Category: Informational Q. Zhao, Ed.
ISSN: 2070-1721 R. Li
Huawei Technologies
C. Zhou
Cisco Systems
December 2017
Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 8283 Juniper Networks
Category: Informational Q. Zhao, Ed.
ISSN: 2070-1721 R. Li
Huawei Technologies
C. Zhou
Cisco Systems
December 2017
An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
在具有中央控制的网络中使用PCE和PCE通信协议（PCEP）的体系结构
Abstract
摘要
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
路径计算元素（PCE）是软件定义网络（SDN）系统的核心组件。它可以计算网络中流量的最佳路径，还可以更新路径以反映网络或流量需求的变化。
PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).
PCE用于推导MPLS标签交换路径（LSP）的路径，这些路径使用路径计算元素通信协议（PCEP）提供给LSP的前端。
SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
SDN比信令MPLS流量工程（TE）网络具有更广泛的适用性，并且PCE可用于确定一系列用例中的路径，包括静态LSP、段路由、服务功能链（SFC）和大多数形式的路由或交换网络。因此，合理地考虑PCEP作为在这些环境中使用的控制协议，以允许PCE作为中央控制器完全启用。
This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
本文档简要介绍了PCE作为中央控制器的体系结构，探讨了PCEP作为控制协议在该环境中的动机和适用性，并介绍了该协议的含义。基于PCE的中央控制器可以通过将分布式控制平面与SDN元素混合，而不必完全替换它，从而简化分布式控制平面的处理。
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.
本文档没有详细描述用例，也没有定义协议扩展：这项工作留给其他文档完成。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8283.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8283.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 8
2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 9
2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 10
2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14
3.1.1. Applicability to Control-Plane Operated Networks . . 14
3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14
3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15
3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15
3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16
3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
4. Protocol Implications / Guidance for Solution Developers . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 8
2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 9
2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 10
2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14
3.1.1. Applicability to Control-Plane Operated Networks . . 14
3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14
3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15
3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15
3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16
3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
4. Protocol Implications / Guidance for Solution Developers . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
The Path Computation Element (PCE) [RFC4655] was developed to offload path computation function from routers in an MPLS traffic-engineered network. Since then, the role and function of the PCE has grown to cover a number of other uses (such as GMPLS [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated use of network resources [RFC8281].
路径计算元件（PCE）[RFC4655]是为了在MPLS流量工程网络中从路由器上卸载路径计算功能而开发的。从那时起，PCE的角色和功能已扩展到涵盖许多其他用途（如GMPLS[RFC7025]），并允许授权控制[RFC8231]和PCE发起的网络资源使用[RFC8281]。
According to [RFC7399], Software-Defined Networking (SDN) 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. 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 traffic flows
根据[RFC7399]，软件定义网络（SDN）指的是控制元件和转发组件之间的分离，以便在称为控制器的集中式系统中运行的软件可以对网络中的设备进行编程，使其以特定方式运行。SDN体系结构中的一个必需元素是规划如何使用网络资源以及如何对设备进行编程的组件。可以将此组件视为执行特定计算以放置交通流
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 is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system (including an SDN system) is presented in [RFC7491].
在网络中，已知网络资源的可用性、其他转发设备的编程方式以及其他流的路由方式。这是PCE的功能和用途，PCE集成到更广泛的网络控制系统（包括SDN系统）的方式见[RFC7491]。
In early PCE implementations, where the PCE was used to derive paths for MPLS Label Switched Paths (LSPs), paths were requested by network elements (known as Path Computation Clients (PCCs)), and the results of the path computations were supplied to network elements using the Path Computation Element Communication Protocol (PCEP) [RFC5440]. This protocol was later extended to allow a PCE to send unsolicited requests to the network for LSP establishment [RFC8281].
在早期的PCE实现中，PCE用于导出MPLS标签交换路径（LSP）的路径，网络元件（称为路径计算客户端（PCC））请求路径，并且使用路径计算元件通信协议（PCEP）[RFC5440]将路径计算的结果提供给网络元件。该协议后来被扩展以允许PCE向网络发送未经请求的请求以建立LSP[RFC8281]。
SDN has a far broader applicability than just signaled MPLS or GMPLS traffic-engineered networks. The PCE component in an SDN system may be used to determine paths in a wide range of use cases including static LSPs, segment routing [SR-ARCH], SFC [RFC7665], and indeed any form of routed or switched network. It is, therefore, reasonable to consider PCEP as a general southbound control protocol (i.e., a control protocol for communicating from the central controller to network elements) for use in these environments to allow the PCE to be fully enabled as a central controller.
SDN比信号MPLS或GMPLS流量工程网络具有更广泛的适用性。SDN系统中的PCE组件可用于确定各种用例中的路径，包括静态LSP、段路由[SR-ARCH]、SFC[RFC7665]，以及任何形式的路由或交换网络。因此，合理地考虑PCEP作为一般的南向控制协议（即，从中央控制器到网络单元的通信的控制协议）用于在这些环境中使用，以允许PCE作为中央控制器完全启用。
This document introduces the architecture for PCE as a central controller as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE and PCC. This document also examines the motivations and applicability for PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol used in this way. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
本文件介绍了PCE作为中央控制器的体系结构，作为[RFC4655]中所述体系结构的扩展，并假设PCE和PCC之间继续使用PCEP作为协议。本文件还探讨了PCEP作为南向接口（SBI）的动机和适用性，并介绍了以这种方式使用的协议的含义。基于PCE的中央控制器可以通过将分布式控制平面与SDN元素混合，而不必完全替换它，从而简化分布式控制平面的处理。
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.
本文档没有详细描述用例，也没有定义协议扩展：这项工作留给其他文档完成。
The architecture for the use of PCE within centralized control of a network is based on the understanding that a PCE can determine how connections should be placed and how resources should be used within the network, and that the PCE can then cause those connections to be established. Figure 1 shows how this control relationship works in a network with an active control plane. This is a familiar view for those who have read and understood [RFC4655] and [RFC8281].
用于在网络的集中控制内使用PCE的架构基于这样的理解，即PCE可以确定如何在网络内放置连接以及如何使用资源，并且PCE随后可以导致建立这些连接。图1显示了此控制关系如何在具有活动控制平面的网络中工作。对于阅读并理解[RFC4655]和[RFC8281]的人来说，这是一个熟悉的观点。
In this mode of operation, the central controller is asked to create connectivity by a network orchestrator, a service manager, an Operations Support System (OSS), a Network Management Station (NMS), or some other application. The PCE-based controller computes paths with awareness of the network topology, the available resources, and the other services supported in the network. This information is held in the Traffic Engineering Database (TED) and other databases available to the PCE. Then the PCE sends a request using PCEP to one of the Network Elements (NEs), and that NE uses a control plane to establish the requested connections and reserve the network resources.
在此操作模式下，要求中央控制器通过网络协调器、服务管理器、操作支持系统（OSS）、网络管理站（NMS）或某些其他应用程序创建连接。基于PCE的控制器通过感知网络拓扑、可用资源和网络中支持的其他服务来计算路径。该信息保存在交通工程数据库（TED）和PCE可用的其他数据库中。然后，PCE使用PCEP向其中一个网元（NE）发送请求，该网元使用控制平面来建立请求的连接并保留网络资源。
Note that other databases (such as an LSP Database (LSP-DB)) might also be used, but for simplicity of illustration, just the TED is shown.
注意，也可以使用其他数据库（例如LSP数据库（LSP-DB）），但为了简单说明，只显示了TED。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^
PCEP|
v
---- ---- ---- ----
| NE |<--------->| NE |<--->| NE |<--->| NE |
---- Signaling ---- ---- ----
Protocol
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^
PCEP|
v
---- ---- ---- ----
| NE |<--------->| NE |<--->| NE |<--->| NE |
---- Signaling ---- ---- ----
Protocol
Figure 1: Architecture for the Central Controller with a Control Plane
图1：带有控制平面的中央控制器的体系结构
Although the architecture shown in Figure 1 represents a form of SDN, one objective of SDN in some environments is to remove the dependency on a control plane. A transition architecture toward this goal is presented in [RFC7491] and is shown in Figure 2. In this case, services are still requested in the same way, and the PCE-based controller still requests use of the network using PCEP. The main difference is that the consumer of the PCEP messages is a network controller that provisions the resources and instructs the data plane using an SBI that provides an interface to each NE.
尽管图1所示的体系结构代表了SDN的一种形式，但在某些环境中，SDN的一个目标是消除对控制平面的依赖。[RFC7491]中介绍了实现这一目标的过渡架构，如图2所示。在这种情况下，仍然以相同的方式请求服务，并且基于PCE的控制器仍然使用PCEP请求使用网络。主要区别在于，PCEP消息的使用者是一个网络控制器，它提供资源并使用SBI指示数据平面，SBI为每个网元提供接口。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^
| PCEP
v
------------
| Network |
| Controller |
/------------\
SBI / ^ ^ \
/ | | \
/ v v \
----/ ---- ---- \----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^
| PCEP
v
------------
| Network |
| Controller |
/------------\
SBI / ^ ^ \
/ | | \
/ v v \
----/ ---- ---- \----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 2: Architecture Including a Network Controller
图2：包括网络控制器的体系结构
The approach in Figure 2 delivers the SDN functionality but is overly complicated and insufficiently flexible.
图2中的方法提供了SDN功能，但过于复杂且不够灵活。
o The complication is created by the use of two controllers in a hierarchical organization and the resultant use of two protocols in a southbound direction.
o 这种复杂性是由在一个分层组织中使用两个控制器以及在南行方向上使用两个协议造成的。
o The lack of flexibility arises from the assumed or required lack of a control plane.
o 缺乏灵活性是由于假设或要求缺少控制平面。
This document describes an architecture that reduces the number of components and is flexible to a number of deployment models and use cases. In this hybrid approach (shown in Figure 3), the network controller is PCE enabled and can also speak PCEP as the SBI (i.e., it can communicate with each node along the path using PCEP). That means that the controller can communicate with a conventional control-plane-enabled NE using PCEP and can also use the same protocol to program individual NEs. In this way, the PCE-based controller can control a wider range of networks and deliver many different functions as described in Section 3.
本文档描述了一种体系结构，该体系结构减少了组件的数量，并对许多部署模型和用例具有灵活性。在这种混合方法中（如图3所示），网络控制器启用PCE，也可以将PCEP作为SBI（即，它可以使用PCEP与路径上的每个节点通信）。这意味着控制器可以使用PCEP与启用了传统控制平面的网元进行通信，并且还可以使用相同的协议对各个网元进行编程。这样，基于PCE的控制器可以控制范围更广的网络，并提供第3节所述的许多不同功能。
There will be a trade-off in different application scenarios. In some cases, the use of a control plane will simplify deployment (for example, by distributing recovery actions), and in other cases, a control plane may add operational complexity.
在不同的应用场景中会有一个权衡。在某些情况下，使用控制平面将简化部署（例如，通过分发恢复操作），而在其他情况下，控制平面可能会增加操作复杂性。
PCEP is essentially already capable of acting as an SBI and only small, use-case-specific modifications to the protocol are needed to support this architecture. The implications for the protocol are discussed further in Section 4.
PCEP基本上已经能够充当SBI，并且只需要对协议进行小的、特定于用例的修改就可以支持该架构。第4节将进一步讨论该协议的含义。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
/------------\
PCEP / ^ ^ \
/ | | \
/ v v \
/ ---- ---- \
/ | NE | | NE | \
----/ ---- ---- \----
| NE | | NE |
---- ----
^ ---- ---- ^
:......>| NE |...| NE |<....:
Signaling Protocol ---- ----
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
/------------\
PCEP / ^ ^ \
/ | | \
/ v v \
/ ---- ---- \
/ | NE | | NE | \
----/ ---- ---- \----
| NE | | NE |
---- ----
^ ---- ---- ^
:......>| NE |...| NE |<....:
Signaling Protocol ---- ----
Figure 3: Architecture for Node-by-Node Central Control
图3：逐节点中央控制的体系结构
Systems with central controllers are vulnerable to two problems: failure of the controller or overload of the controller. These concerns are not unique to the use of a PCE-based controller, but they need to be addressed in this document before the PCE-based controller architecture can be considered for use in all but the smallest networks.
带有中央控制器的系统容易出现两个问题：控制器故障或控制器过载。这些问题并非基于PCE的控制器的唯一用途，但在考虑将基于PCE的控制器体系结构用于除最小网络以外的所有网络之前，需要在本文档中解决这些问题。
There are three architectural mechanisms that can be applied to address these issues. The mechanisms are described separately for clarity, but a deployment may use any combination of the approaches.
有三种体系结构机制可用于解决这些问题。为了清楚起见，将单独描述这些机制，但是部署可以使用这些方法的任意组合。
For simplicity of illustration, these three approaches are shown in the sections that follow without a control plane. However, the general, hybrid approach of Figure 3 is applicable in each case.
为便于说明，以下章节中显示了这三种方法，没有控制平面。然而，图3中的一般混合方法适用于每种情况。
The first and simplest approach to handling controller overload or scalability is to use multiple controllers, each responsible for a part of the network. We can call the resultant areas of control "domains" [RFC4655].
处理控制器过载或可伸缩性的第一个也是最简单的方法是使用多个控制器，每个控制器负责网络的一部分。我们可以将生成的控制区域称为“域”[RFC4655]。
This approach is shown in Figure 4. It can clearly address some of the scaling and overload concerns since each controller now only has responsibility for a subset of the network elements. But this comes at a cost because end-to-end connections require coordination between the controllers. Furthermore, this technique does not remove the concern about a single point-of-failure even if it does reduce the impact on the network of the failure of a single controller.
这种方法如图4所示。它可以清楚地解决一些扩展和过载问题，因为每个控制器现在只负责网络元素的一个子集。但这是有代价的，因为端到端连接需要控制器之间的协调。此外，该技术不会消除对单点故障的担忧，即使它确实减少了单个控制器故障对网络的影响。
Note that PCEP is designed to work as a PCE-to-PCE protocol as well as a PCE-to-PCC protocol, so it should be possible to use it to coordinate between PCE-based controllers in this model.
请注意，PCEP设计为作为PCE-to-PCE协议以及PCE-to-PCC协议工作，因此在该模型中，应该可以使用它在基于PCE的控制器之间进行协调。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| |
v v
------------ Coordi- ------------
----- | | nation | | -----
| TED |--->| PCE-Based |<-------->| PCE-Based |<---| TED |
----- | Controller | | Controller | -----
| | :: | |
/------------ :: ------------\
/ ^ ^ :: ^ ^ \
/ | | :: | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| |
v v
------------ Coordi- ------------
----- | | nation | | -----
| TED |--->| PCE-Based |<-------->| PCE-Based |<---| TED |
----- | Controller | | Controller | -----
| | :: | |
/------------ :: ------------\
/ ^ ^ :: ^ ^ \
/ | | :: | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
Figure 4: Multiple Controllers on a Partitioned Network
图4：分区网络上的多个控制器
Multiple controllers may be deployed where each controller is capable of controlling all of the network elements. Thus, the failure of any one controller will not leave the network unmanageable and, in normal circumstances, the load can be distributed across the controllers.
可以部署多个控制器，其中每个控制器能够控制所有网络元件。因此，任何一个控制器的故障都不会使网络无法管理，在正常情况下，负载可以分布在控制器上。
Multiple parallel controllers may be deployed as shown in Figure 5. Each controller is capable of controlling all of the network elements; thus, the failure of any one controller will not leave the network unmanageable, and in normal circumstances, the load can be distributed across the controllers. In this model, the orchestrator (or any requester) must select a controller to consume its request.
如图5所示，可以部署多个并行控制器。每个控制器能够控制所有网络元件；因此，任何一个控制器的故障都不会使网络无法管理，在正常情况下，负载可以分布在控制器上。在此模型中，编排器（或任何请求者）必须选择一个控制器来使用其请求。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| ___________________ |
| | Synchronization | |
v v v v
------------ ------------
| | ----- | |
| PCE-Based |<---| TED |--->| PCE-Based |
| Controller | ----- | Controller |
| |__ ...........| |
------------\ \_:__ :------------
^ ^ \___: \ .....: ^ ^
| | .....:\ \_:___ ..: :
| |__:___ \___:_ \_:___ :
| ....: | .....: | ..: | :
| : | : | : | :
v v v v v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| ___________________ |
| | Synchronization | |
v v v v
------------ ------------
| | ----- | |
| PCE-Based |<---| TED |--->| PCE-Based |
| Controller | ----- | Controller |
| |__ ...........| |
------------\ \_:__ :------------
^ ^ \___: \ .....: ^ ^
| | .....:\ \_:___ ..: :
| |__:___ \___:_ \_:___ :
| ....: | .....: | ..: | :
| : | : | : | :
v v v v v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 5: Multiple Redundant Controllers
图5：多个冗余控制器
An alternate approach is to present the controllers as a "cluster" that represents itself externally as a single controller as in Figure 3 but that is actually comprised of multiple controllers. The size of the cluster may be varied according to the load in the manner of Network Functions Virtualization (NFV), and the cluster is responsible for sharing load among the members of the cluster. This approach is shown in Figure 6.
另一种方法是将控制器表示为一个“集群”，它在外部表示为一个控制器，如图3所示，但实际上由多个控制器组成。集群的大小可以根据负载以网络功能虚拟化（NFV）的方式变化，并且集群负责在集群的成员之间共享负载。此方法如图6所示。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
--------------------------+-------------------------
| Controller ______________|_____________ |
| Cluster | | |
| | ___________________ | |
| | | Synchronization | | |
| v v v v |
| ------------ ----- ------------ |
| | PCE-Based |<---| TED |--->| PCE-Based | |
| | Controller | ----- | Controller | |
| | Instance | | Instance | |
| ------------ ------------ |
| ^ ^ |
| |____________________________| |
| | |
--------------------------+-------------------------
_____________|_____________
| | | |
v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
--------------------------+-------------------------
| Controller ______________|_____________ |
| Cluster | | |
| | ___________________ | |
| | | Synchronization | | |
| v v v v |
| ------------ ----- ------------ |
| | PCE-Based |<---| TED |--->| PCE-Based | |
| | Controller | ----- | Controller | |
| | Instance | | Instance | |
| ------------ ------------ |
| ^ ^ |
| |____________________________| |
| | |
--------------------------+-------------------------
_____________|_____________
| | | |
v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 6: Multiple Controllers Presented as a Cluster
图6：多个控制器显示为一个集群
To achieve full redundancy and to be able to continue to provide full function in the event of a controller failure, the controllers must synchronize with each other. This is nominally a simple task if there are just two controllers but can actually be quite complex if state changes in the network are not to be lost. Furthermore, if there are more than two controllers, the synchronization between controllers can become a hard problem.
为了实现完全冗余并在控制器发生故障时能够继续提供完整功能，控制器必须彼此同步。如果只有两个控制器，这名义上是一项简单的任务，但如果不丢失网络中的状态变化，这实际上可能相当复杂。此外，如果有两个以上的控制器，控制器之间的同步可能会成为一个难题。
Synchronization issues are often off-loaded as "database synchronization" problems, because distributed database packages have already had to address these challenges, or by using a shared database. In networking, the problem may also be addressed by collecting the state from the network (effectively using the network as a database) using normal routing protocols such as OSPF, IS-IS, and BGP. It should be noted that addressing the synchronization problem through a shared database may be hiding the issues of congestion and of a single point of failure: while the controllers may have been made resilient by allowing redundancy, the shared database is still a problem, so the whole system is still vulnerable.
同步问题通常作为“数据库同步”问题卸载，因为分布式数据库包已经必须解决这些问题，或者使用共享数据库。在网络中，也可以通过使用诸如OSPF、IS-IS和BGP等常规路由协议从网络收集状态（有效地将网络用作数据库）来解决该问题。应该注意的是，通过共享数据库解决同步问题可能隐藏了拥塞和单点故障的问题：虽然控制器可能通过允许冗余而具有弹性，但共享数据库仍然是一个问题，因此整个系统仍然易受攻击。
Figure 7 shows an approach with hierarchical controllers. This approach was developed for PCEs in [RFC6805] and appears in various SDN architectures where a "parent PCE", an "orchestrator", or a "super controller" takes responsibility for a high-level view of the network before distributing tasks to lower-level PCEs or controllers.
图7显示了使用分层控制器的方法。这种方法是在[RFC6805]中为PCE开发的，并出现在各种SDN体系结构中，其中“父PCE”、“编排器”或“超级控制器”负责网络的高级视图，然后再将任务分发给较低级别的PCE或控制器。
On its own, this approach does little to protect against the failure of a controller, but it can make significant improvements in loading and scaling of the individual controllers. It also offers a good way to support end-to-end connectivity across multiple administrative or technology-specific domains.
就其本身而言，这种方法对防止控制器故障几乎没有什么作用，但它可以显著改进单个控制器的加载和扩展。它还提供了一种支持跨多个管理或技术特定域的端到端连接的好方法。
Note that this model can be arbitrarily recursive with a PCE-based controller being the child of one parent PCE-based controller while acting as the parent of another set of PCE-based controllers.
请注意，此模型可以是任意递归的，基于PCE的控制器是一个基于PCE的父控制器的子控制器，同时充当另一组基于PCE的控制器的父控制器。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| Parent | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^ ^
| |
v :: v
------------ :: ------------
----- | | :: | | -----
| TED |--->| PCE-Based | :: | PCE-Based |<---| TED |
----- | Controller | :: | Controller | -----
/| | :: | |\
/ ------------ :: ------------ \
/ ^ ^ :: ^ ^ \
/ | | :: | | \
/ | | :: | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| Parent | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^ ^
| |
v :: v
------------ :: ------------
----- | | :: | | -----
| TED |--->| PCE-Based | :: | PCE-Based |<---| TED |
----- | Controller | :: | Controller | -----
/| | :: | |\
/ ------------ :: ------------ \
/ ^ ^ :: ^ ^ \
/ | | :: | | \
/ | | :: | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
Figure 7: Hierarchical Controllers
图7：分层控制器
This section gives a very high-level introduction to the applicability of a PCE-based centralized controller. There is no attempt to explain each use case in detail, and the inclusion of a use case is not intended to suggest that deploying a PCE-based controller is a mandatory or recommended approach. The sections below are provided as a stimulus to the discussion of the applicability of a PCE-based controller, and it is expected that separate documents will be written to develop the use cases in which there is interest for implementation and deployment. As described in
本节对基于PCE的集中式控制器的适用性进行了高度介绍。没有试图详细解释每个用例，包含用例并不意味着部署基于PCE的控制器是一种强制性或推荐的方法。以下各节旨在促进对基于PCE的控制器适用性的讨论，预计将编写单独的文件，以开发对实施和部署感兴趣的用例。如中所述
Section 4, specific enhancements to PCEP may be needed for some of these use cases, and it is expected that the documents that develop each use case will also address any extensions to PCEP.
第4节，对于其中一些用例，可能需要对PCEP进行特定的增强，预计开发每个用例的文档也将涉及对PCEP的任何扩展。
The rest of this section is divided into two sub-sections. The first approaches the question of applicability from a consideration of the network technology. The second looks at the high-level functions that can be delivered by using a PCE-based controller.
本节其余部分分为两个小节。第一种是从网络技术的角度来探讨适用性问题。第二部分介绍了使用基于PCE的控制器可以实现的高级功能。
As previously mentioned, this section is intended to just make suggestions. Thus, the material supplied is very brief. The omission of a use case is in no way meant to imply some limit on the applicability of PCE-based control.
如前所述，本节旨在提出建议。因此，提供的材料非常简短。省略用例绝不意味着对基于PCE的控制的适用性有某种限制。
This section provides a list of use cases based on network technology.
本节提供了基于网络技术的用例列表。
This mode of operation is the common approach for an active, stateful PCE to control a traffic-engineered MPLS or GMPLS network [RFC8231]. Note that the PCE-based controller determines what LSPs are needed and where to place them. PCEP is used to instruct the head end of each LSP, and the head end signals in the control plane to set up the LSP.
这种操作模式是主动、有状态PCE控制流量工程MPLS或GMPLS网络的常用方法[RFC8231]。请注意，基于PCE的控制器确定需要哪些LSP以及将其放置在何处。PCEP用于指示每个LSP的前端，控制平面中的前端信号用于设置LSP。
In this mode of operation, the PCE may construct its TED in a number of ways as described in [RFC4655], including (but not limited to) participating in the IGP or receiving information from a network element via BGP-LS [RFC7752].
在该操作模式中，PCE可以按照[RFC4655]中描述的多种方式构造其TED，包括（但不限于）参与IGP或经由BGP-LS[RFC7752]从网元接收信息。
Static LSPs are provisioned without the use of a control plane. This means that they are established using a management plane or "manual" configuration.
在不使用控制平面的情况下提供静态LSP。这意味着它们是使用管理平面或“手动”配置建立的。
Static LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path LSP. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCE-based controller keeps a view of the network and determines the paths of the end-to-end LSPs just as it does for the use case described in Section 3.1.1, but the controller uses PCEP to communicate with each router along the path of the end-to-end LSP. In this case, the PCE-based controller will take responsibility for managing some part of the MPLS label space for each of the routers
静态LSP可以在端到端路径LSP上的每个跃点处设置为显式标签指令。路径上的每个路由器必须被告知向程序转发指令的标签以及要保留的资源。基于PCE的控制器保持网络视图并确定端到端LSP的路径，就像它在第3.1.1节中描述的用例中所做的一样，但控制器使用PCEP沿端到端LSP的路径与每个路由器通信。在这种情况下，基于PCE的控制器将负责管理每个路由器的MPLS标签空间的某些部分
that it controls, and it may taker wider responsibility for partitioning the label space for each router and allocating different parts for different uses, communicating the ranges to the router using PCEP.
它控制，并可能承担更广泛的责任，为每个路由器划分标签空间，为不同的用途分配不同的部分，使用PCEP将范围传送给路由器。
Multicast LSPs may be provisioned with a control plane or as static LSPs. No extra considerations apply above those described in Sections 3.1.1 and 3.1.2 except, of course, to note that the PCE must also include the instructions about where the LSP branches, i.e., where packets must be copied.
多播lsp可以用控制平面或作为静态lsp提供。除第3.1.1节和第3.1.2节中所述的注意事项外，没有其他注意事项适用于上述第3.1.1节和第3.1.2节中所述的注意事项，当然，PCE还必须包括关于LSP分支位置的说明，即必须复制数据包的位置。
Transport SDN (T-SDN) is the application of SDN techniques to transport networks. In this respect, a transport network is a network built from any technology below the IP layer and designed to carry traffic transparently in a connection-oriented way. Thus, an MPLS traffic-engineered network is a transport network, although it is more common to consider technologies such as Time Division Multiplexing (TDM) and Optical Transport Networks (OTNs) to be transport networks.
传输SDN（T-SDN）是SDN技术在传输网络中的应用。在这方面，传输网络是由IP层以下的任何技术构建的网络，其设计目的是以面向连接的方式透明地传输流量。因此，MPLS流量工程网络是一种传输网络，虽然更常见的是将诸如时分复用（TDM）和光传输网络（OTN）之类的技术视为传输网络。
Transport networks may be operated with or without a control plane and may have point-to-point or point-to-multipoint connections. Thus, all of the considerations in Sections 3.1.1, 3.1.2, and 3.1.3 apply so that the normal PCEP message allows a PCE-based central controller to provision a transport network. It is usually the case that additional technology-specific parameters are needed to configure the NEs or LSPs in transport networks, such as optical characteristic. Such parameters will need to be carried in the PCEP messages: new protocol extensions may be needed, as described, for example, in [PCEP-WSON-RWA].
传输网络可以使用或不使用控制平面运行，并且可以具有点对点或点对多点连接。因此，第3.1.1节、第3.1.2节和第3.1.3节中的所有注意事项均适用，以便正常PCEP消息允许基于PCE的中央控制器提供传输网络。通常情况下，需要额外的技术特定参数来配置传输网络中的网元或LSP，例如光学特性。此类参数需要在PCEP消息中携带：可能需要新的协议扩展，如[PCEP-WSON-RWA]中所述。
Segment routing is described in [SR-ARCH]. It relies on a series of forwarding instructions being placed in the header of a packet. At each hop in the network, a router looks at the first instruction and may: continue to forward the packet unchanged; strip the top instruction and forward the packet; or strip the top instruction, insert some additional instructions, and forward the packet.
[SR-ARCH]中描述了段布线。它依赖于在数据包的报头中放置的一系列转发指令。在网络中的每一个跃点，路由器都会查看第一条指令，并可能：继续转发数据包，保持不变；剥离top指令并转发数据包；或者剥离顶部指令，插入一些附加指令，然后转发数据包。
The segment routing architecture supports operations that can be used to steer packet flows in a network, thus providing a form of traffic engineering. A PCE-based controller can be responsible for computing the paths for packet flows in a segment routing network, configuring
段路由体系结构支持可用于控制网络中的分组流的操作，从而提供了一种流量工程形式。基于PCE的控制器可以负责计算段路由网络中分组流的路径，配置
the forwarding actions on the routers, and telling the edge routers what instructions to attach to packets as they enter the network. These last two operations can be achieved using PCEP, and the PCE-based controller will assume responsibility for managing the space of labels or path identifiers used to determine how packets are forwarded.
路由器上的转发操作，并告诉边缘路由器在数据包进入网络时附加哪些指令。最后两个操作可以使用PCEP实现，基于PCE的控制器将负责管理用于确定如何转发数据包的标签或路径标识符的空间。
SFC is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking lets each successive service function node know which functions to perform and to which service function node to send the packet next.
[RFC7665]中描述了SFC。它是在网络中引导流量的过程，使其通过特定的硬件设备或虚拟机（称为服务功能节点），这些设备或虚拟机可以对流量执行特定的期望功能。要执行的一组功能及其执行顺序称为服务功能链。该链通过执行服务功能的位置得到增强，以导出服务功能路径（SFP）。每个分组被标记为属于特定SFP，并且该标记使每个后续服务功能节点知道执行哪些功能以及下一个将分组发送到哪个服务功能节点。
To operate an SFC network, the service function nodes must be configured to understand the packet markings, and the edge nodes must be told how to mark packets entering the network. Additionally, it may be necessary to establish tunnels between service function nodes to carry the traffic.
要操作SFC网络，必须将服务功能节点配置为了解数据包标记，并且必须告知边缘节点如何标记进入网络的数据包。此外，可能需要在服务功能节点之间建立隧道以承载业务。
Planning an SFC network requires load balancing between service function nodes and traffic engineering across the network that connects them. These are operations that can be performed by a PCE-based controller, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.
规划SFC网络需要在服务功能节点之间进行负载平衡，并通过连接它们的网络进行流量工程。这些操作可由基于PCE的控制器执行，该控制器可使用PCEP对网络进行编程，并安装服务功能链和任何所需的隧道。
This section provides a list of the high-level functions that can be delivered by using a PCE-based controller.
本节提供了使用基于PCE的控制器可以实现的高级功能列表。
According to [RFC2702], TE is concerned with performance optimization of operational networks. In general, it encompasses the application of technology and scientific principles to the measurement, modeling, characterization, control of Internet traffic, and application of such knowledge and techniques to achieve specific performance objectives.
根据[RFC2702]，TE关注运营网络的性能优化。一般来说，它包括将技术和科学原理应用于互联网流量的测量、建模、表征、控制，以及应用这些知识和技术来实现特定的性能目标。
From a practical point of view, this involves having an understanding of the topology of the network, the characteristics of the nodes and links in the network, and the traffic demands and flows across the network. It also requires that actions can be taken to ensure that traffic follows specific paths through the network.
从实践的角度来看，这包括了解网络的拓扑结构、网络中节点和链路的特性以及网络上的流量需求和流量。它还要求可以采取措施确保流量遵循网络中的特定路径。
PCE was specifically developed to address TE in an MPLS network, so a PCE-based controller is well suited to analyze TE problems and supply answers that can be installed in the network using PCEP. PCEP can be responsible for initiating paths across the network through a control plane or for installing state in the network node by node such as in a segment-routed network (see Section 3.1.5) or by configuring IGP metrics.
PCE是专门为解决MPLS网络中的TE而开发的，因此基于PCE的控制器非常适合分析TE问题并提供可使用PCEP安装在网络中的答案。PCEP可负责通过控制平面启动网络路径，或负责逐节点在网络中安装状态，如分段路由网络（见第3.1.5节），或通过配置IGP度量。
Traffic classification is an important part of traffic engineering. It is the process of looking at a packet to determine how it should be treated as it is forwarded through the network. It applies in many scenarios including MPLS traffic engineering (where it determines what traffic is forwarded onto which LSPs); segment routing (where it is used to select which set of forwarding instructions to add to a packet); and SFC (where it indicates along which service function path a packet should be forwarded). In conjunction with traffic engineering, traffic classification is an important enabler for load balancing.
交通分类是交通工程的重要组成部分。它是查看数据包以确定在通过网络转发时应如何处理的过程。它适用于许多场景，包括MPLS流量工程（其中确定哪些流量转发到哪个LSP）；段路由（用于选择要添加到数据包的转发指令集）；和SFC（其中指示数据包应沿着哪个服务功能路径转发）。与流量工程相结合，流量分类是实现负载平衡的一个重要因素。
Traffic classification is closely linked to the computational elements of planning for the network functions just listed because it determines how traffic load is balanced and distributed through the network. Therefore, selecting what traffic classification should be performed by a router is an important part of the work done by a PCE-based controller.
流量分类与刚刚列出的网络功能规划的计算元素密切相关，因为它决定了流量负载如何通过网络平衡和分布。因此，选择路由器应该执行的流量分类是基于PCE的控制器所做工作的重要部分。
Instructions can be passed from the controller to the routers using PCEP. These instructions tell the routers how to map traffic to paths or connections.
可以使用PCEP将指令从控制器传递到路由器。这些说明告诉路由器如何将流量映射到路径或连接。
Various network services may be offered over a network. These include protection services (including end-to-end protection [RFC4427], restoration after failure, and fast reroute [RFC4090]); Virtual Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985].
可以通过网络提供各种网络服务。其中包括保护服务（包括端到端保护[RFC4427]、故障后恢复和快速重路由[RFC4090]）；虚拟专用网络（VPN）服务（如第3层VPN[RFC4364]或以太网VPN[RFC7432]）；或伪导线[RFC3985]。
Delivering services over a network in an optimal way requires coordination in the way that network resources are allocated to support the services. A PCE-based central controller can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources.
以最佳方式通过网络交付服务需要在分配网络资源以支持服务的方式上进行协调。基于PCE的中央控制器可以考虑整个网络和服务的所有组件在规划如何交付服务时一次。然后，它可以使用PCEP来管理网络资源，并在这些资源之间安装必要的关联。
PCEP is a push-pull protocol that is designed to move requests and responses between a server (the PCE) and clients (the PCCs, i.e., the network elements). In particular, it has a message (the LSP Initiate Request (PCInitiate); see [RFC8281]) that can be sent by the PCE to install state or cause actions at the PCC and a response message (Path Computation State Report (PCRpt)) that is used to confirm the request.
PCEP是一种推拉协议，设计用于在服务器（PCE）和客户端（PCC，即网元）之间移动请求和响应。特别是，它有一条消息（LSP Initiate请求（PCInitiate）；请参阅[RFC8281]），可由PCE发送以在PCC处安装状态或引起操作，以及一条用于确认请求的响应消息（路径计算状态报告（PCRpt））。
As such, there is an expectation that only relatively minor changes to PCEP are required to support the concept of a PCE-based controller. The only work expected to be needed is extensions to existing PCEP messages to carry additional or specific information elements for the individual use cases, which maintain backward compatibility and do not impact existing PCEP deployments. [RFC5440] already describes how legacy implementations handle unknown protocol extensions and how to use the PCEP Open message to indicate support for PCEP features. Where possible, consistent with the general principles of how protocols are extended, any additions to the protocol should be made in a generic way such that they are open to use in a range of applications.
因此，人们期望仅需对PCEP进行相对较小的更改即可支持基于PCE的控制器的概念。预期需要做的唯一工作是对现有PCEP消息进行扩展，以携带单个用例的附加或特定信息元素，这些信息元素保持向后兼容性，并且不会影响现有PCEP部署。[RFC5440]已经描述了旧式实现如何处理未知协议扩展，以及如何使用PCEP Open消息来指示对PCEP功能的支持。在可能的情况下，根据协议扩展的一般原则，对协议的任何添加都应以通用方式进行，以便在一系列应用中开放使用。
It is anticipated that new documents (such as [PCEP-CONTROLLER]) will be produced for each use case dependent on support and demand. Such documents will explain the use case and define the necessary protocol extensions.
预计将根据支持和需求为每个用例生成新文档（如[PCEP-CONTROLLER]）。这些文档将解释用例并定义必要的协议扩展。
Protocol extensions could have impact on existing PCEP deployments and the interoperability between different implementations. It is anticipated that changes of the PCEP protocol or addition of information elements could require additional testing to ensure interoperability between different PCEP implementations.
协议扩展可能会对现有PCEP部署以及不同实现之间的互操作性产生影响。预计PCEP协议的更改或信息元素的添加可能需要额外的测试，以确保不同PCEP实施之间的互操作性。
It is reasonable to expect that implementations are able to select a subset or profile of the protocol extensions and PCEP features that are relevant for the application scenario in which they will be deployed. Identification of these profiles should form part of the protocol itself so that interoperability can be easily determined and testing can be limited to the specific profiles.
有理由期望实现能够选择协议扩展和PCEP特性的子集或概要文件，这些特性与部署它们的应用场景相关。这些概要文件的标识应构成协议本身的一部分，以便可以轻松确定互操作性，并且测试可以限制在特定概要文件中。
Note that protocol mechanisms to handle synchronization of state in parallel PCE-based controllers will also be required if parallel controllers are used as described in Section 2.1.2. In [RFC8231], there is a discussion of mechanisms to achieve PCE state synchronization.
请注意，如果按照第2.1.2节所述使用并行控制器，则还需要协议机制来处理基于并行PCE的控制器中的状态同步。在[RFC8231]中，讨论了实现PCE状态同步的机制。
Security considerations for a PCE-based controller are little different from those for any other PCE system. That is, the operation relies heavily on the use and security of PCEP, so consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253].
基于PCE的控制器的安全注意事项与任何其他PCE系统的安全注意事项几乎没有什么不同。也就是说，操作在很大程度上依赖于PCEP的使用和安全性，因此应考虑[RFC5440]中讨论的安全特性和[RFC8253]中描述的其他机制。
It should be observed that the trust model of a network that operates without a control plane is different from one with a control plane. The conventional "chain of trust" used with a control plane is replaced by individual trust relationships between the controller and each individual NE. This model may be considerably easier to manage, so it is more likely to be operated with a high level of security.
应该注意的是，没有控制平面的网络的信任模型不同于有控制平面的网络。与控制平面一起使用的传统“信任链”被控制器和每个单独网元之间的单独信任关系所取代。此模型可能更易于管理，因此更有可能在高安全级别下运行。
However, an architecture with a central controller has a central point of failure, and this is also a security weakness since the network can be vulnerable to denial-of-service attacks on the controller. Similarly, the central controller provides a focus for interception and modification of messages sent to individual NEs. In short, while the interactions with a PCE-based controller are not substantially different to those in any other SDN architecture, the security implications of SDN have not been fully discussed or described. Therefore, protocol and applicability work-around solutions for this architecture must take proper account of these concerns.
但是，具有中央控制器的体系结构有一个中心故障点，这也是一个安全弱点，因为网络容易受到控制器上的拒绝服务攻击。类似地，中央控制器为截取和修改发送到各个网元的消息提供了焦点。简言之，虽然与基于PCE的控制器的交互与任何其他SDN架构中的交互没有本质上的不同，但是尚未充分讨论或描述SDN的安全含义。因此，该体系结构的协议和适用性解决方案必须适当考虑这些问题。
It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCE-based central controller on the network type and services being managed.
预计为特定用例生成的每个新文档还将考虑使用基于PCE的中央控制器对所管理的网络类型和服务的安全影响。
The architecture described in this document is a management architecture: the PCE-based controller is a management component that controls the network through a southbound control protocol (PCEP).
本文档中描述的体系结构是一种管理体系结构：基于PCE的控制器是一种管理组件，通过南向控制协议（PCEP）控制网络。
An implementation of a PCE-based controller will require access to information about the state of the network, its nodes, and its links. Some of this will be the TED as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to
基于PCE的控制器的实现需要访问有关网络状态、节点及其链路的信息。其中一些将是TED，这对于PCE来说是正常的，并且可以使用已经存在的机制收集（例如倾听）
the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-encoded data [YANG-TE] from the network elements to the controller). More information may be collected in the LSP database for stateful PCEs as described in [RFC7399] and [RFC8231]. Additional information may be needed for other specific use cases and will need to be collected and passed to the controller. This may require protocol extensions for the mechanisms listed in this paragraph.
IGPs，使用BGP-LS[RFC7752]，或从网络元件向控制器北行导出YANG编码数据[YANG-TE]）。如[RFC7399]和[RFC8231]所述，可在LSP数据库中收集有状态PCE的更多信息。其他特定用例可能需要额外的信息，需要收集并传递给控制器。这可能需要对本段中列出的机制进行协议扩展。
The use of different PCEP options and protocol extensions may have an impact on interoperability, which is a management issue. As noted in Section 4, protocol extensions should be done in a way that makes it possible to identify profiles of PCEP to aid interoperability, and this will aid deployment and manageability.
使用不同的PCEP选项和协议扩展可能会影响互操作性，这是一个管理问题。如第4节所述，协议扩展应以能够识别PCEP配置文件以帮助互操作性的方式进行，这将有助于部署和可管理性。
[RFC5440] contains a substantive Manageability Considerations section that examines how a PCE-based system and a PCE-enabled system may be managed. A MIB module for PCEP was published as [RFC7420], and a YANG module for PCEP has also been proposed [YANG-PCEP].
[RFC5440]包含一个实质性的可管理性注意事项部分，该部分检查如何管理基于PCE的系统和启用PCE的系统。PCEP的MIB模块发布为[RFC7420]，PCEP的YANG模块也被提出[YANG-PCEP]。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8281]Crabbe，E.，Minei，I.，Sivabalan，S.，和R.Varga，“有状态PCE模型中PCE启动LSP设置的路径计算元素通信协议（PCEP）扩展”，RFC 8281，DOI 10.17487/RFC8281，2017年12月<https://www.rfc-editor.org/info/rfc8281>.
[PCECC] Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, C., Communications, T., Rachitskiy, A., and A. Gulida, "The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs", Work in Progress, draft-zhao-teas-pcecc-use-cases-02, October 2016.
[PCECC]Zhao，Q.，Li，Z.，Khasanov，B.，Ke，Z.，Fang，L.，Zhou，C.，Communications，T.，Rachitskiy，A.，和A.Gulida，“将PCE用作LSP中央控制器（PCECC）的用例”，正在进行的工作，草稿-Zhao-teas-PCECC-Use-Cases-022016年10月。
[PCEP-CONTROLLER] Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Work in Progress, draft-zhao-pce-pcep-extension-for-pce-controller-06, October 2017.
[PCEP-CONTROLLER]Zhao，Q.，Li，Z.，Dhody，D.，Karunaniti，S.，Farrel，A.，和C.Zhou，“将PCE用作LSP中央控制器（PCECC）的PCEP程序和协议扩展”，正在进行的工作，草稿-Zhao-PCE-PCEP-extension-for-PCE-CONTROLLER-06，2017年10月。
[PCEP-WSON-RWA] Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing and Wavelength Assignment", Work in Progress, draft-ietf-pce-wson-rwa-ext-07, November 2017.
[PCEP-WSON-RWA]Lee，Y.和R.Casellas，“WSON路由和波长分配的PCEP扩展”，正在进行的工作，草稿-ietf-pce-WSON-RWA-ext-072017年11月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，DOI 10.17487/RFC2702，1999年9月<https://www.rfc-editor.org/info/rfc2702>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，DOI 10.17487/RFC3985，2005年3月<https://www.rfc-editor.org/info/rfc3985>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 4090，DOI 10.17487/RFC4090，2005年5月<https://www.rfc-editor.org/info/rfc4090>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<https://www.rfc-editor.org/info/rfc4364>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，DOI 10.17487/RFC4427，2006年3月<https://www.rfc-editor.org/info/rfc4427>.
[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, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC6805]King，D.，Ed.和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，RFC 6805，DOI 10.17487/RFC6805，2012年11月<https://www.rfc-editor.org/info/rfc6805>.
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, DOI 10.17487/RFC7025, September 2013, <https://www.rfc-editor.org/info/rfc7025>.
[RFC7025]Otani，T.，Ogaki，K.，Caviglia，D.，Zhang，F.，和C.Margaria，“PCE的GMPLS应用要求”，RFC 7025，DOI 10.17487/RFC70252013年9月<https://www.rfc-editor.org/info/rfc7025>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7399]Farrel，A.和D.King，“路径计算元素架构中未回答的问题”，RFC 7399，DOI 10.17487/RFC7399，2014年10月<https://www.rfc-editor.org/info/rfc7399>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素通信协议（PCEP）管理信息库（MIB）模块”，RFC 7420，DOI 10.17487/RFC7420，2014年12月<https://www.rfc-editor.org/info/rfc7420>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432]Sajassi，A.，Ed.，Aggarwal，R.，Bitar，N.，Isaac，A.，Uttaro，J.，Drake，J.，和W.Henderickx，“基于BGP MPLS的以太网VPN”，RFC 7432，DOI 10.17487/RFC7432，2015年2月<https://www.rfc-editor.org/info/rfc7432>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.
[RFC7491]King，D.和A.Farrel，“基于PCE的应用程序网络运营架构”，RFC 7491，DOI 10.17487/RFC7491，2015年3月<https://www.rfc-editor.org/info/rfc7491>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665]Halpern，J.，Ed.和C.Pignataro，Ed.，“服务功能链（SFC）架构”，RFC 7665，DOI 10.17487/RFC7665，2015年10月<https://www.rfc-editor.org/info/rfc7665>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752]Gredler，H.，Ed.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，RFC 7752，DOI 10.17487/RFC7752，2016年3月<https://www.rfc-editor.org/info/rfc7752>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的路径计算元素通信协议（PCEP）扩展”，RFC 8231，DOI 10.17487/RFC82312017年9月<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253]Lopez，D.，Gonzalez de Dios，O.，Wu，Q.，和D.Dhody，“PCEP：使用TLS为路径计算元素通信协议（PCEP）提供安全传输”，RFC 8253，DOI 10.17487/RFC8253，2017年10月<https://www.rfc-editor.org/info/rfc8253>.
[SR-ARCH] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-13, October 2017.
[SR-ARCH]Filsfils，C.，Previdi，S.，Ginsberg，L.，Decarene，B.，Litkowski，S.，和R.Shakir，“分段布线架构”，正在进行的工作，草案-ietf-spring-Segment-Routing-132017年10月。
[YANG-PCEP] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
[YANG-PCEP]杜迪，D.，哈德威克，J.，比拉姆，V.，和J。jefftant@gmail.com，“路径计算元件通信协议（PCEP）的YANG数据模型”，正在进行的工作，草稿-ietf-pce-PCEP-YANG-052017年6月。
[YANG-TE] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", Work in Progress, draft-ietf-teas-yang-te-topo-13, October 2017.
[YANG-TE]Liu，X.，Bryskin，I.，Beeram，V.，Saad，T.，Shah，H.，和O.Dios，“交通工程（TE）拓扑的YANG数据模型”，正在进行的工作，草案-ietf-teas-YANG-TE-topo-13，2017年10月。
Acknowledgments
致谢
The ideas in this document owe a lot to the work started by the authors of [PCECC] and [PCEP-CONTROLLER]. The authors of this document fully acknowledge the prior work and thank those involved for opening the discussion. The individuals concerned are: King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, and Zhenbin Li.
本文件中的想法在很大程度上归功于[PCECC]和[PCEP-CONTROLLER]的作者所开展的工作。本文件的作者充分肯定了之前的工作，并感谢参与讨论的人员。有关人士包括:柯王,方绿园,周潮,张伯里斯,李振斌。
This document has benefited from the discussions within a small ad hoc design team; the members of which are listed as document contributors.
本文件得益于小型特设设计团队的讨论；其成员被列为文档贡献者。
Thanks to Michael Scharf and Andy Malis for a lively discussion of this document.
感谢Michael Scharf和Andy Malis对本文件的热烈讨论。
Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call comments on this document.
感谢Phil Bedard、Aijun Wang和Elwyn Davies对本文档的最后点评。
Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful comments during IESG review.
斯宾塞·道金斯、亚当·罗奇和本·坎贝尔在IESG审查期间提供了有益的意见。
Contributors
贡献者
The following people contributed to discussions that led to the development of this document:
以下人员参与了导致本文件编制的讨论：
Cyril Margaria Email: cmargaria@juniper.net
Cyril Margaria电子邮件：cmargaria@juniper.net
Sudhir Cheruathur Email: scheruathur@juniper.net
Sudhir Cheruathur电子邮件：scheruathur@juniper.net
Dhruv Dhody Email: dhruv.dhody@huawei.com
Dhruv Dhody电子邮件：Dhruv。dhody@huawei.com
Daniel King Email: daniel@olddog.co.uk
Daniel King电子邮件：daniel@olddog.co.uk
Iftekhar Hussain Email: IHussain@infinera.com
Iftekhar Hussain电子邮件：IHussain@infinera.com
Anurag Sharma Email: AnSharma@infinera.com
Anurag Sharma电子邮件：AnSharma@infinera.com
Eric Wu Email: eric.wu@huawei.com
Eric Wu电子邮件：Eric。wu@huawei.com
Authors' Addresses
作者地址
Adrian Farrel (editor) Juniper Networks
Adrian Farrel（编辑）Juniper Networks
Email: afarrel@juniper.net
Email: afarrel@juniper.net
Quintin Zhao (editor) Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States of America
赵昆廷（编辑）华为技术125美国马萨诸塞州纳戈尔技术园阿克顿01719
Email: quintin.zhao@huawei.com
Email: quintin.zhao@huawei.com
Robin Li Huawei Technologies Huawei Bld., No.156 Beiqing Road Beijing 100095 China
中国北京市北青路156号华为大厦Robin Li华为技术有限公司100095
Email: lizhenbin@huawei.com
Email: lizhenbin@huawei.com
Chao Zhou Cisco Systems
潮州思科系统有限公司
Email: chao.zhou@cisco.com
Email: chao.zhou@cisco.com