Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8637 Huawei Technologies
Category: Informational Y. Lee
ISSN: 2070-1721 Futurewei Technologies
D. Ceccarelli
Ericsson
July 2019
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8637 Huawei Technologies
Category: Informational Y. Lee
ISSN: 2070-1721 Futurewei Technologies
D. Ceccarelli
Ericsson
July 2019
Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)
路径计算元素（PCE）在TE网络（ACTN）抽象和控制中的适用性
Abstract
摘要
Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
TE网络的抽象和控制（ACTN）是指协调、控制和管理大规模多域TE网络所需的一组虚拟网络（VN）操作，以促进网络的可编程性、自动化、高效资源共享，以及端到端虚拟服务感知连接和网络功能虚拟化服务。
The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).
路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的组件、应用程序或网络节点。PCE为来自路径计算客户端（PCC）的请求提供服务，这些客户端通过本地API或使用路径计算元素通信协议（PCEP）与其通信。
This document examines the applicability of PCE to the ACTN framework.
本文件检查了PCE对ACTN框架的适用性。
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 candidates 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/rfc8637.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8637.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background Information . . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation Element (PCE) . . . . . . . . . . . . . 3
2.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 4
2.1.2. PCE in Multidomain and Multilayer Deployments . . . . 4
2.1.3. Relationship to PCE-Based Central Control . . . . . . 5
2.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
3. Architectural Considerations . . . . . . . . . . . . . . . . 7
3.1. Multidomain Coordination via Hierarchy . . . . . . . . . 7
3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background Information . . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation Element (PCE) . . . . . . . . . . . . . 3
2.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 4
2.1.2. PCE in Multidomain and Multilayer Deployments . . . . 4
2.1.3. Relationship to PCE-Based Central Control . . . . . . 5
2.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
3. Architectural Considerations . . . . . . . . . . . . . . . . 7
3.1. Multidomain Coordination via Hierarchy . . . . . . . . . 7
3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Abstraction and Control of TE Networks (ACTN) [RFC8453] refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
TE网络的抽象和控制（ACTN）[RFC8453]是指协调、控制和管理大规模多域TE网络所需的一组虚拟网络（VN）操作，以促进网络的可编程性、自动化、高效资源共享，以及端到端虚拟服务感知连接和网络功能虚拟化服务。
The Path Computation Element (PCE) [RFC4655] is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).
路径计算元件（PCE）[RFC4655]是能够基于网络图计算网络路径或路由并应用计算约束的组件、应用程序或网络节点。PCE为来自路径计算客户端（PCC）的请求提供服务，这些客户端通过本地API或使用路径计算元素通信协议（PCEP）与其通信。
This document examines the PCE and ACTN architecture and describes how PCE architecture is applicable to ACTN. It also lists the PCEP extensions that are needed to use PCEP as an ACTN interface. This document also identifies any gaps in PCEP that exist at the time of publication of this document.
本文档检查了PCE和ACTN体系结构，并描述了PCE体系结构如何适用于ACTN。它还列出了将PCEP用作ACTN接口所需的PCEP扩展。本文件还确定了本文件出版时PCEP中存在的任何漏洞。
Further, ACTN, stateful Hierarchical PCE (H-PCE) [PCE-HPCE], and PCE as a central controller (PCECC) [RFC8283] are based on the same basic hierarchy framework and are thus compatible with each other.
此外，ACTN、有状态层次PCE（H-PCE）[PCE-HPCE]和PCE作为中央控制器（PCECC）[RFC8283]基于相同的基本层次结构框架，因此彼此兼容。
The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Clients (PCCs) to request a Path Computation Element (PCE) [RFC4655] to perform path computations.
路径计算元件通信协议（PCEP）[RFC5440]为路径计算客户端（PCC）提供请求路径计算元件（PCE）[RFC4655]执行路径计算的机制。
The ability to compute shortest constrained TE LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development.
在跨多个域的多协议标签交换（MPLS）和广义MPLS（GMPLS）网络中计算最短约束TE LSP的能力已被确定为PCE发展的关键动力。
A stateful PCE [RFC8231] is capable of considering, for the purposes of path computation, not only the network state in terms of links and nodes (referred to as the Traffic Engineering Database or TED), but also the status of active services (previously computed paths), and currently reserved resources, stored in the Label Switched Paths Database (LSP-DB).
出于路径计算的目的，有状态PCE[RFC8231]不仅能够考虑链路和节点（称为流量工程数据库或TED）的网络状态，还能够考虑存储在标签交换路径数据库中的活动服务（先前计算的路径）和当前保留资源的状态（LSP-DB）。
[RFC8051] describes general considerations for a stateful PCE deployment and examines its applicability and benefits as well as its challenges and limitations through a number of use cases.
[RFC8051]描述了有状态PCE部署的一般注意事项，并通过大量用例检查了其适用性和优点以及挑战和限制。
[RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute
[RFC8231]描述了PCEP的一组扩展，以提供有状态控制。有状态PCE不仅可以访问由网络内部网关协议（IGP）承载的信息，还可以访问活动路径集及其用于计算的保留资源。附加状态允许PCE进行计算
constrained paths while considering individual LSPs and their interactions. [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model.
考虑单个LSP及其交互时的约束路径。[RFC8281]描述了在有状态PCE模型下PCE启动的LSP的设置、维护和拆卸。
[RFC8231] also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP or make changes to the attributes of an existing LSP, or a PCC to delegate control of specific LSPs to a new PCE.
[RFC8231]还描述了活动的有状态PCE。活动PCE功能允许PCE重新路由现有LSP或更改现有LSP的属性，或允许PCC将特定LSP的控制权委托给新PCE。
Software-Defined Networking (SDN) [RFC7149] 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 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. It is concluded in [RFC7399] that this is the same function that a PCE might offer in a network operated using a dynamic control plane. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system including SDN is presented in Application-Based Network Operation (ABNO) [RFC7491].
软件定义网络（SDN）[RFC7149]是指控制元件和转发组件之间的分离，以便在称为控制器的集中式系统中运行的软件可以对网络中的设备进行编程，使其以特定方式运行。SDN体系结构中的一个必需元素是规划如何使用网络资源以及如何对设备进行编程的组件。在已知网络资源的可用性、其他转发设备的编程方式以及其他流的路由方式的情况下，可以将此组件视为执行特定计算以在网络内放置流。[RFC7399]中得出结论，这与PCE在使用动态控制平面运行的网络中可能提供的功能相同。这是PCE的功能和目的，基于应用的网络操作（ABNO）[RFC7491]中介绍了PCE集成到更广泛的网络控制系统（包括SDN）中的方式。
Computing paths across large multidomain environments requires special computational components and cooperation between entities in different domains capable of complex path computation. The PCE provides an architecture and a set of functional components to address this problem space. A PCE may be used to compute end-to-end paths across multidomain environments using a per-domain path computation technique [RFC5152]. The Backward-Recursive PCE-based path computation (BRPC) mechanism [RFC5441] defines a PCE-based path computation procedure to compute interdomain-constrained MPLS and GMPLS TE networks. However, per-domain technique assumes that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means. BRPC can work best with a known domain sequence, and it will also work nicely with a small set of interconnected domains. However, it doesn't work well for a large set of interconnected domains.
跨大型多域环境的计算路径需要特殊的计算组件以及能够进行复杂路径计算的不同域中实体之间的协作。PCE提供了一个体系结构和一组功能组件来解决这个问题空间。PCE可用于使用每域路径计算技术计算跨多域环境的端到端路径[RFC5152]。基于PCE的反向递归路径计算（BRPC）机制[RFC5441]定义了基于PCE的路径计算过程，用于计算域间约束MPLS和GMPLS TE网络。然而，每域技术假定从源到目的地的域序列是已知的，或者由网络运营商确定，或者通过其他方式获得。BRPC可以在已知的域序列中工作得最好，也可以在一小部分相互连接的域中工作得很好。然而，对于一大组相互连接的域来说，它并不能很好地工作。
[RFC6805] describes a Hierarchical PCE (H-PCE) architecture that can be used for computing end-to-end paths for interdomain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the domain sequence is not known. Within the Hierarchical PCE (H-PCE) architecture, the Parent PCE (P-PCE) is used to compute a multidomain path based on the domain connectivity information. A Child PCE (C-PCE) may be responsible for a single domain or multiple domains; it is used to compute the intradomain path based on its domain topology information.
[RFC6805]描述了一种分层PCE（H-PCE）体系结构，当域序列未知时，该体系结构可用于计算域间MPLS流量工程（TE）和GMPLS标签交换路径（LSP）的端到端路径。在分层PCE（H-PCE）体系结构中，父PCE（P-PCE）用于基于域连接性信息计算多域路径。子PCE（C-PCE）可能负责单个域或多个域；它用于根据域拓扑信息计算域内路径。
[PCE-HPCE] states the considerations for stateful PCEs in Hierarchical PCE architecture. In particular, the behavior changes and adds to the existing stateful PCE mechanisms (including PCE-initiated LSP setup and active PCE usage) in the context of networks using the H-PCE architecture.
[PCE-HPCE]说明分层PCE体系结构中有状态PCE的注意事项。特别是，在使用H-PCE体系结构的网络环境中，该行为改变并添加到现有的有状态PCE机制（包括PCE启动的LSP设置和活动PCE使用）。
[RFC5623] describes a framework for applying the PCE-based architecture to interlayer (G)MPLS TE. It provides suggestions for the deployment of PCE in support of multilayer networks. It also describes the relationship between PCE and a functional component in charge of the control and management of the Virtual Network Topology (VNT) [RFC5212] called the VNT Manager (VNTM).
[RFC5623]描述了将基于PCE的体系结构应用于夹层（G）MPLS TE的框架。它为支持多层网络的PCE部署提供了建议。它还描述了PCE和负责控制和管理虚拟网络拓扑（VNT）[RFC5212]的功能组件（称为VNT管理器（VNTM））之间的关系。
[RFC8283] introduces the architecture for PCE as a central controller (PCECC); it further examines the motivations and applicability for PCEP as a southbound interface (SBI) and introduces the implications for the protocol. Section 2.1.3 of [RFC8283] describes a hierarchy of PCE-based controllers as per the PCE Hierarchy Framework defined in [RFC6805].
[RFC8283]介绍了PCE作为中央控制器（PCECC）的体系结构；它进一步探讨了PCEP作为南向接口（SBI）的动机和适用性，并介绍了协议的含义。[RFC8283]第2.1.3节根据[RFC6805]中定义的PCE层次结构框架，描述了基于PCE的控制器的层次结构。
[RFC8453] describes the high-level ACTN requirements and the architecture model for ACTN, including the entities Customer Network Controller (CNC), Multidomain Service Coordinator (MDSC), and Provisioning Network Controller (PNC) and their interfaces.
[RFC8453]描述了高级ACTN需求和ACTN的体系结构模型，包括实体客户网络控制器（CNC）、多域服务协调器（MDSC）和供应网络控制器（PNC）及其接口。
The ACTN reference architecture is shown in Figure 1, which is reproduced here from [RFC8453] for convenience. [RFC8453] remains the definitive reference for the ACTN architecture. As depicted in Figure 1, the ACTN architecture identifies a three-tier hierarchy.
ACTN参考体系结构如图1所示，为方便起见，此处从[RFC8453]复制。[RFC8453]仍然是ACTN体系结构的最终参考。如图1所示，ACTN体系结构确定了一个三层层次结构。
+---------+ +---------+ +---------+
| CNC | | CNC | | CNC |
+---------+ +---------+ +---------+
\ | /
\ | /
Boundary =============\==============|==============/============
Between \ | /
Customer & ------- | CMI -------
Network Operator \ | /
+---------------+
| MDSC |
+---------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| SBI / | / \
| / | SBI / \
--------- ----- | / \
( ) ( ) | / \
- Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net )
- - ( ) ( ) -----
( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net )
----- -----
+---------+ +---------+ +---------+
| CNC | | CNC | | CNC |
+---------+ +---------+ +---------+
\ | /
\ | /
Boundary =============\==============|==============/============
Between \ | /
Customer & ------- | CMI -------
Network Operator \ | /
+---------------+
| MDSC |
+---------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| SBI / | / \
| / | SBI / \
--------- ----- | / \
( ) ( ) | / \
- Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net )
- - ( ) ( ) -----
( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net )
----- -----
CMI - (CNC-MDSC Interface) MPI - (MDSC-PNC Interface) SBI - (Southbound Interface)
CMI-（CNC-MDSC接口）MPI-（MDSC-PNC接口）SBI-（南行接口）
Figure 1: ACTN Hierarchy
图1:ACTN层次结构
There are two interfaces with respect to the MDSC: one north of the MDSC (the CNC-MDSC Interface (CMI)), and one south (the MDSC-PNC Interface (MPI)). A hierarchy of MDSCs is possible with a recursive MPI interface.
MDSC有两个接口：一个位于MDSC北部（CNC-MDSC接口（CMI）），另一个位于南部（MDSC-PNC接口（MPI））。MDSC的层次结构可以通过递归MPI接口实现。
[RFC8454] provides an information model for ACTN interfaces.
[RFC8454]为ACTN接口提供了一个信息模型。
The ACTN architecture [RFC8453] is based on the hierarchy and recursiveness of controllers. It defines three types of controllers (depending on the functionalities they implement). The main functionalities are:
ACTN体系结构[RFC8453]基于控制器的层次结构和递归性。它定义了三种类型的控制器（取决于它们实现的功能）。主要功能包括：
o Multidomain coordination
o 多域协调
o Abstraction
o 抽象
o Customer mapping/translation
o 客户映射/翻译
o Virtual service coordination
o 虚拟服务协调
Section 3 of [RFC8453] describes these functions.
[RFC8453]的第3节描述了这些功能。
It should be noted that this document lists all possible ways in which PCE could be used for each of the above functions, but all functions are not required to be implemented via PCE. Similarly, this document presents the ways in which PCEP could be used as the communications medium between functional components. Operators may choose to use the PCEP for multidomain coordination via stateful H-PCE but alternatively use Network Configuration Protocol (NETCONF) [RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752] to get access to the topology and support abstraction function.
应注意的是，本文件列出了PCE可用于上述各项功能的所有可能方式，但并不要求所有功能都通过PCE实现。同样，本文件介绍了PCEP用作功能部件之间通信媒介的方法。运营商可以选择通过有状态H-PCE使用PCEP进行多域协调，但也可以使用网络配置协议（NETCONF）[RFC6241]、RESTCONF[RFC8040]或BGP-链路状态（BGP-LS）[RFC7752]访问拓扑并支持抽象功能。
With the definition of domain being everything that is under the control of the single logical controller, as per [RFC8453], it is needed both to have a control entity that oversees the specific aspects of the different domains and to build a single abstracted end-to-end network topology in order to coordinate end-to-end path computation and path/service provisioning.
根据[RFC8453]，域的定义是在单个逻辑控制器控制下的所有内容，需要有一个控制实体来监督不同域的特定方面，并构建一个抽象的端到端网络拓扑，以便协调端到端路径计算和路径/服务供应。
The MDSC in ACTN framework realizes this function by coordinating the per-domain PNCs in a hierarchy of controllers. It also needs to detach from the underlying network technology and express customer concerns by business needs.
ACTN框架中的MDSC通过协调控制器层次结构中的每个域PNC来实现此功能。它还需要与底层网络技术分离，并通过业务需求表达客户的关注。
[RFC6805] and [PCE-HPCE] describe a hierarchy of PCEs with the Parent PCE coordinating multidomain path computation function between Child PCEs. It is easy to see how these principles align, and thus how the stateful H-PCE architecture can be used to realize ACTN.
[RFC6805]和[PCE-HPCE]描述了PCE的层次结构，其中父PCE协调子PCE之间的多域路径计算功能。很容易看出这些原则是如何协调一致的，因此可以使用有状态的H-PCE体系结构来实现ACTN。
The per-domain stitched LSP in the Hierarchical stateful PCE architecture, described in Section 3.3.1 of [PCE-HPCE], is well suited for multidomain coordination function. This includes domain sequence selection, End-to-End (E2E) path computation, and controller-initiated (PCE-initiated) path setup and reporting. This is also applicable to multilayer coordination in case of IP+optical networks.
[PCE-HPCE]第3.3.1节中描述的分层有状态PCE体系结构中的每域缝合LSP非常适合于多域协调功能。这包括域序列选择、端到端（E2E）路径计算以及控制器启动（PCE启动）路径设置和报告。这也适用于IP+光网络中的多层协调。
[PCE-STATE-SYNC] describes the procedures to allow a stateful communication between PCEs for various use cases. The procedures and extensions are also applicable to Child and Parent PCE communication and are thus useful for ACTN as well.
[PCE-STATE-SYNC]描述了允许PCE之间针对各种用例进行有状态通信的过程。这些程序和扩展也适用于儿童和家长PCE沟通，因此也适用于ACTN。
To realize ACTN, an abstracted view of the underlying network resources needs to be built. This includes global network-wide abstracted topology based on the underlying network resources of each domain. This also includes abstract topology created as per the customer service connectivity requests and represented as a VN slice allocated to each customer.
要实现ACTN，需要构建底层网络资源的抽象视图。这包括基于每个域的底层网络资源的全局网络范围的抽象拓扑。这还包括根据客户服务连接请求创建的抽象拓扑，并表示为分配给每个客户的VN片。
In order to compute and provide optimal paths, PCEs require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link-state (LS) routing protocol supporting traffic engineering extensions. PCE may construct its TED by participating in the IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An alternative is offered by BGP-LS [RFC7752].
为了计算和提供最佳路径，PCE需要准确及时的交通工程数据库（TED）。传统上，这种TED是从支持流量工程扩展的链路状态（LS）路由协议获得的。PCE可以通过参与IGP来构建其TED（对于MPLS-TE，[RFC3630]和[RFC5305]；对于GMPLS，[RFC4203]和[RFC5307]）。BGP-LS[RFC7752]提供了一种替代方案。
In case of H-PCE [RFC6805], the Parent PCE needs to build the domain topology map of the child domains and their interconnectivity. [RFC6805] and [PCE-INTER-AREA] suggest that BGP-LS could be used as a "northbound" TE advertisement from the Child PCE to the Parent PCE.
对于H-PCE[RFC6805]，父PCE需要构建子域及其互连的域拓扑图。[RFC6805]和[PCE-INTER-AREA]表明BGP-LS可以用作从子PCE到父PCE的“北向”TE广告。
[PCEP-LS] proposes another approach for learning and maintaining the Link-State and TE information as an alternative to IGPs and BGP flooding, using PCEP itself. The Child PCE can use this mechanism to transport Link-State and TE information from Child PCE to a Parent PCE using PCEP.
[PCEP-LS]提出了另一种使用PCEP自身学习和维护链路状态和TE信息的方法，作为IGPs和BGP洪泛的替代方法。子PCE可以使用此机制使用PCEP将链路状态和TE信息从子PCE传输到父PCE。
In ACTN, there is a need to control the level of abstraction based on the deployment scenario and business relationship between the controllers. The mechanism used to disseminate information from the PNC (Child PCE) to the MDSC (Parent PCE) should support abstraction. [RFC8453] describes a few alternative approaches of abstraction. The resulting abstracted topology can be encoded using the PCEP-LS mechanisms [PCEP-LS] and its optical network extension
在ACTN中，需要根据部署场景和控制器之间的业务关系来控制抽象级别。用于将信息从PNC（子PCE）传播到MDSC（父PCE）的机制应支持抽象。[RFC8453]描述了几种可选的抽象方法。由此产生的抽象拓扑可以使用PCEP-LS机制[PCEP-LS]及其光网络扩展进行编码
[PCEP-OPTICAL]. PCEP-LS is an attractive option when the operator would wish to have a single control-plane protocol (PCEP) to achieve ACTN functions.
[PCEP-光学]。当操作员希望使用单一控制平面协议（PCEP）来实现ACTN功能时，PCEP-LS是一个有吸引力的选项。
[RFC8453] discusses two ways to build abstract topology from an MDSC standpoint with interaction with PNCs. The primary method is called automatic generation of abstract topology by configuration. With this method, automatic generation is based on the abstraction/ summarization of the whole domain by the PNC and its advertisement on the MPI. The secondary method is called on-demand generation of supplementary topology via Path Compute Request/Reply. This method may be needed to obtain further complementary information such as potential connectivity from Child PCEs in order to facilitate an end-to-end path provisioning. PCEP is well suited to support both methods.
[RFC8453]讨论了从MDSC的角度通过与PNC交互来构建抽象拓扑的两种方法。主要方法称为通过配置自动生成抽象拓扑。通过这种方法，自动生成是基于PNC对整个领域的抽象/摘要及其在MPI上的广告。第二种方法称为通过路径计算请求/应答按需生成补充拓扑。为了促进端到端路径供应，可能需要该方法来获得进一步的补充信息，例如来自子pce的潜在连接性。PCEP非常适合支持这两种方法。
In ACTN, there is a need to map customer virtual network (VN) requirements into a network provisioning request to the PNC. That is, the customer requests/commands are mapped by the MDSC into network provisioning requests that can be sent to the PNC. Specifically, the MDSC provides mapping and translation of a customer's service request into a set of parameters that are specific to a network type and technology such that the network configuration process is made possible.
在ACTN中，需要将客户虚拟网络（VN）需求映射到PNC的网络供应请求中。也就是说，MDSC将客户请求/命令映射为可以发送到PNC的网络配置请求。具体而言，MDSC将客户的服务请求映射和转换为特定于网络类型和技术的一组参数，从而使网络配置过程成为可能。
[RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. To instantiate or delete an LSP, the PCE sends the Path Computation LSP Initiate Request (PCInitiate) message to the PCC. As described in [PCE-HPCE], for interdomain LSP in Hierarchical PCE architecture, the initiation operations can be carried out at the Parent PCE. In this case, after Parent PCE finishes the E2E path computation, it can send the PCInitiate message to the Child PCE; the Child PCE further propagates the initiate request to the Label Switching Router (LSR). The customer request is received by the MDSC (Parent PCE), and, based on the business logic, global abstracted topology, network conditions, and local policy, the MDSC (Parent PCE) translates this into a per-domain LSP initiation request that a PNC (Child PCE) can understand and act on. This can be done via the PCInitiate message.
[RFC8281]描述了在有状态PCE模型下PCE启动的LSP的设置、维护和拆卸，无需在PCC上进行本地配置，从而允许集中控制和部署动态网络。要实例化或删除LSP，PCE向PCC发送路径计算LSP启动请求（PCInitiate）消息。如[PCE-HPCE]中所述，对于分层PCE架构中的域间LSP，可以在父PCE处执行启动操作。在这种情况下，在父PCE完成E2E路径计算后，可以向子PCE发送PCInitiate消息；子PCE进一步将发起请求传播到标签交换路由器（LSR）。客户请求由MDSC（父PCE）接收，并且，基于业务逻辑、全局抽象拓扑、网络条件和本地策略，MDSC（父PCE）将其转换为PNC（子PCE）可以理解和执行的每域LSP启动请求。这可以通过PCInitiate消息完成。
PCEP extensions for associating opaque policy between PCEP peer [ASSOC-POLICY] can be used.
可以使用PCEP扩展来关联PCEP对等方之间的不透明策略[ASSOC-policy]。
Virtual service coordination function in ACTN incorporates customer service-related information into the virtual network service operations in order to seamlessly operate virtual networks while meeting customers' service requirements.
ACTN中的虚拟服务协调功能将客户服务相关信息整合到虚拟网络服务操作中，以便在满足客户服务需求的同时无缝操作虚拟网络。
[PCEP-VN] describes the need for associating a set of LSPs with a VN "construct" to facilitate VN operations in PCE architecture. This association allows the PCEs to identify which LSPs belong to a certain VN.
[PCEP-VN]描述了将一组LSP与VN“构造”相关联以促进PCE体系结构中的VN操作的需要。这种关联允许PCE识别属于某个VN的LSP。
This association based on VN is useful for various optimizations at the VN level, which can be applied to all the LSPs that are part of the VN slice. During path computation, the impact of a path for an LSP is compared against the paths of other LSPs in the VN. This is to ensure optimization and SLA attainment for the VN rather than for a single LSP. Similarly, during reoptimization, advanced path computation algorithms and optimization techniques can be considered for all the LSPs belonging to a VN/customer and optimize them all together.
这种基于VN的关联对于VN级别的各种优化非常有用，可以应用于作为VN切片一部分的所有LSP。在路径计算期间，将LSP的路径影响与VN中其他LSP的路径进行比较。这是为了确保VN而不是单个LSP的优化和SLA实现。类似地，在重新优化期间，可以针对属于VN/客户的所有lsp考虑高级路径计算算法和优化技术，并一起优化它们。
As per [RFC8453], to allow virtualization and multidomain coordination, the network has to provide open, programmable interfaces in which customer applications can create, replace, and modify virtual network resources and services in an interactive, flexible, and dynamic fashion while having no impact on other customers. The two ACTN interfaces are as follows:
根据[RFC8453]，为了实现虚拟化和多域协调，网络必须提供开放、可编程的接口，客户应用程序可以在不影响其他客户的情况下，以交互、灵活和动态的方式创建、替换和修改虚拟网络资源和服务。两个ACTN接口如下所示：
o The CNC-MDSC Interface (CMI) is an interface between a Customer Network Controller and a Multidomain Service Coordinator. It requests the creation of the network resources, topology, or services for the applications. The MDSC may also report potential network topology availability if queried for current capability from the Customer Network Controller.
o CNC-MDSC接口（CMI）是客户网络控制器和多域服务协调员之间的接口。它请求为应用程序创建网络资源、拓扑或服务。如果从客户网络控制器查询当前能力，MDSC还可以报告潜在的网络拓扑可用性。
o The MDSC-PNC Interface (MPI) is an interface between a Multidomain Service Coordinator and a Provisioning Network Controller. It communicates the creation request, if required, of new connectivity of bandwidth changes in the physical network via the PNC. In multidomain environments, the MDSC needs to establish multiple MPIs, one for each PNC, as there are multiple PNCs responsible for its domain control.
o MDSC-PNC接口（MPI）是多域服务协调器和供应网络控制器之间的接口。如果需要，它通过PNC在物理网络中传输带宽变化的新连接的创建请求。在多域环境中，MDSC需要建立多个MPI，每个PNC一个，因为有多个PNC负责其域控制。
In the case of a hierarchy of MDSCs, the MPI is applied recursively. From an abstraction point of view, the top-level MDSC, which interfaces the CNC, operates on a higher level of abstraction (i.e., less granular level) than the lower-level MDSCs.
对于MDSC的层次结构，MPI是递归应用的。从抽象的角度来看，与CNC接口的顶层MDSC比底层MDSC在更高的抽象级别（即更小的粒度级别）上运行。
PCEP is especially suitable on the MPI as it meets the requirement and the functions as set out in the ACTN framework [RFC8453]. Its recursive nature is well suited via the multilevel hierarchy of PCE. PCEP can also be applied to the CMI as the CNC can be a path computation client while the MDSC can be a path computation server. Section 5 describes how PCE and PCEP could help realize ACTN on the MPI.
PCEP特别适用于MPI，因为它满足ACTN框架[RFC8453]中规定的要求和功能。它的递归性质非常适合PCE的多级层次结构。PCEP也可以应用于CMI，因为CNC可以是路径计算客户端，而MDSC可以是路径计算服务器。第5节描述了PCE和PCEP如何帮助在MPI上实现ACTN。
As per the example in Figure 2, there are 4 domains, each with their own PNC and MDSC on top. The PNC and MDSC need PCE as an important function. The PNC (or Child PCE) already uses PCEP to communicate to the network device. It can utilize the PCEP as the MPI to communicate between controllers too.
如图2所示，有4个域，每个域的顶部都有自己的PNC和MDSC。PNC和MDSC需要PCE作为一项重要功能。PNC（或子PCE）已使用PCEP与网络设备通信。它还可以利用PCEP作为MPI在控制器之间进行通信。
******
..........*MDSC*..............................
. ****** .. MPI .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
\ / .
\ ****** / .
\ *PNC3*<............/.....................
\ ****** /
\+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
******
..........*MDSC*..............................
. ****** .. MPI .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
\ / .
\ ****** / .
\ *PNC3*<............/.....................
\ ****** /
\+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
Figure 2: ACTN with PCE
图2:ACTN与PCE
o Building Domain Topology at MDSC: PNC (or Child PCE) needs to have the TED to compute the path in its domain. As described in Section 3.2, it can learn the topology via IGP or BGP-LS. PCEP-LS is also a proposed mechanism to carry link state and traffic engineering information within PCEP. A mechanism to carry abstracted topology while hiding technology-specific information between PNC and MDSC is described in [PCEP-LS]. At the end of this step, the MDSC (or Parent PCE) has the abstracted topology from each of its PNCs (or Child PCE). This could be as simple as a domain topology map as described in [RFC6805], or it can have full topology information of all domains. The latter is not scalable, and thus, an abstracted topology of each domain interconnected by interdomain links is the most common case.
o 在MDSC上构建域拓扑：PNC（或子PCE）需要有TED来计算其域中的路径。如第3.2节所述，它可以通过IGP或BGP-LS学习拓扑。PCEP-LS也是一种在PCEP中承载链路状态和流量工程信息的机制。[PCEP-LS]中描述了一种在PNC和MDSC之间隐藏技术特定信息的同时携带抽象拓扑的机制。在这一步结束时，MDSC（或父PCE）具有来自其每个PNC（或子PCE）的抽象拓扑。这可以像[RFC6805]中描述的域拓扑图一样简单，也可以包含所有域的完整拓扑信息。后者是不可伸缩的，因此，通过域间链路互连的每个域的抽象拓扑是最常见的情况。
* Topology Change: When the PNC learns of any topology change, the PNC needs to decide if the change needs to be notified to the MDSC. This is dependent on the level of abstraction between the MDSC and the PNC.
* 拓扑更改：当PNC获悉任何拓扑更改时，PNC需要决定是否需要将更改通知MDSC。这取决于MDSC和PNC之间的抽象级别。
o VN Instantiate: When an MDSC is requested to instantiate a VN, the minimal information that is required would be a VN identifier and a set of end points. Various path computation, setup constraints, and objective functions may also be provided. In PCE terms, a VN Instantiate can be considered as a set of paths belonging to the same VN. As described in Section 3.4 and [PCEP-VN], the VN association can help in identifying the set of paths that belong to a VN. The rest of the information, like the endpoints, constraints, and objective function (OF), is already defined in PCEP in terms of a single path.
o VN实例化：当请求MDSC实例化VN时，所需的最小信息是VN标识符和一组端点。还可以提供各种路径计算、设置约束和目标函数。在PCE术语中，可以将VN实例化视为属于同一VN的一组路径。如第3.4节和[PCEP-VN]所述，VN关联有助于识别属于VN的路径集。其余的信息，如端点、约束和目标函数（of），已在PCEP中根据单个路径定义。
* Path Computation: As per the example in Figure 2, the VN instantiate requires two end-to-end paths between (A in Domain 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The MDSC (or Parent PCE) triggers the end-to-end path computation for these two paths. MDSC can do path computation based on the abstracted domain topology that it already has, or it may use the H-PCE procedures (Section 3.1) using the PCReq and PCRep messages to get the end-to-end path with the help of the Child PCEs (PNC). Either way, the resultant E2E paths may be broken into per-domain paths.
* 路径计算：如图2中的示例所示，VN实例化需要两条端到端路径（域1中的A到域3中的B）和（域4中的域1到C中的A）。MDSC（或父PCE）触发这两条路径的端到端路径计算。MDSC可以基于其已有的抽象域拓扑进行路径计算，也可以使用H-PCE过程（第3.1节），使用PCReq和PCRep消息，在子PCE（PNC）的帮助下获得端到端路径。无论哪种方式，生成的E2E路径都可能被分解为每个域路径。
* A-B: (A-B13,B13-B31,B31-B)
* A-B：（A-B13，B13-B31，B31-B）
* A-C: (A-B13,B13-B31,B31-B34,B34-B43,B43-C)
* A-C：（A-B13，B13-B31，B31-B34，B34-B43，B43-C）
* Per-Domain Path Instantiation: Based on the above path computation, MDSC can issue the path instantiation request to each PNC via PCInitiate message (see [PCE-HPCE] and [PCEP-VN]). A suitable stitching mechanism would be used to stitch these per-domain LSPs. One such mechanism is described in [PCE-INTERDOMAIN], where PCEP is extended to support stitching in stateful H-PCE context.
* 每个域路径实例化：基于上述路径计算，MDSC可以通过PCInitiate消息（参见[PCE-HPCE]和[PCEP-VN]）向每个PNC发出路径实例化请求。将使用合适的缝合机制来缝合这些每域LSP。[PCE-INTERDOMAIN]中描述了一种这样的机制，其中PCEP被扩展以支持有状态H-PCE上下文中的缝合。
* Per-Domain Path Report: Each PNC should report the status of the per-domain LSP to the MDSC via PCRpt message, as per the hierarchy of stateful PCEs ([PCE-HPCE]). The status of the end-to-end LSP (A-B and A-C) is made up when all the per-domain LSPs are reported up by the PNCs.
* 每域路径报告：每个PNC应根据有状态PCE（[PCE-HPCE]）的层次结构，通过PCRpt消息向MDSC报告每域LSP的状态。当PNC报告所有的每域LSP时，端到端LSP（A-B和A-C）的状态就形成了。
* Delegation: It is suggested that the per-domain LSPs are delegated to respective PNCs so that they can control the path and attributes based on the conditions of each domain network.
* 委派：建议将每个域LSP委派给各自的PNC，以便它们可以根据每个域网络的条件控制路径和属性。
* State Synchronization: The state needs to be synchronized between the Parent PCE and Child PCE. The mechanism described in [PCE-STATE-SYNC] can be used.
* 状态同步：需要在父PCE和子PCE之间同步状态。可以使用[PCE-STATE-SYNC]中描述的机制。
o VN Modify: MDSC is requested to modify a VN, for example, the bandwidth for VN is increased. This may trigger path computation at MDSC as described in the previous step and can trigger an update to an existing per-intradomain path (via PCUpd message) or the creation (or deletion) of a per-domain path (via PCInitiate message). As described in [PCE-HPCE], this should be done in make-before-break fashion.
o VN修改：请求MDSC修改VN，例如，VN的带宽增加。这可能会触发MDSC上的路径计算，如前一步所述，并可能触发对现有每域内路径的更新（通过PCUpd消息）或每域路径的创建（或删除）（通过PCInitiate消息）。如[PCE-HPCE]所述，这应以先通后断的方式进行。
o VN Delete: MDSC is requested to delete a VN, in this case, based on the E2E paths, and the resulting per-domain paths need to be removed (via PCInitiate message).
o VN Delete：在这种情况下，请求MDSC根据E2E路径删除VN，并且需要删除生成的每个域路径（通过PCInitiate消息）。
o VN Update (based on network changes): Any change in the per-domain LSP is reported to the MDSC (via PCRpt message) as per [PCE-HPCE]. This may result in changes in the E2E path or VN status. This may also trigger a reoptimization leading to a new per-domain path, an update to an existing path, or the deletion of the path.
o VN更新（基于网络更改）：根据[PCE-HPCE]，每域LSP中的任何更改都会报告给MDSC（通过PCRpt消息）。这可能导致E2E路径或VN状态发生变化。这还可能触发重新优化，导致新的每域路径、更新现有路径或删除路径。
o VN Protection: The VN protection/restoration requirements need to be applied to each E2E path as well as each per-domain path. The MDSC needs to play a crucial role in coordinating the right protection/restoration policy across each PNC. The existing protection/restoration mechanism of PCEP can be applied on each path.
o VN保护：VN保护/恢复要求需要应用于每个E2E路径以及每个域路径。MDSC需要在协调每个PNC的权利保护/恢复政策方面发挥关键作用。现有的PCEP保护/恢复机制可应用于每条路径。
o In case a PNC generates an abstract topology towards the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a path with abstract nodes and links. A PNC would need to take that as an input for path computation to get a path with physical nodes and links. Similarly, a PNC would convert the path received from the device (with physical nodes and links) into an abstract path (based on the abstract topology generated before with abstract nodes and links) and report it to the MDSC.
o 如果PNC生成指向MDSC的抽象拓扑，则从MDSC到PNC的PCInitiate/PCUpd消息将包含一条带有抽象节点和链接的路径。PNC需要将其作为路径计算的输入，以获得具有物理节点和链接的路径。类似地，PNC将从设备（具有物理节点和链路）接收的路径转换为抽象路径（基于之前生成的具有抽象节点和链路的抽象拓扑），并将其报告给MDSC。
This document has no IANA actions.
本文档没有IANA操作。
Various security considerations for PCEP are described in [RFC5440] and [RFC8253]. Security considerations as stated in Sections 10.1, 10.6, and 10.7 of [RFC5440] continue to apply on PCEP when used as an ACTN interface. Further, this document lists various extensions of PCEP that are applicable; each of them specify various security considerations that continue to apply here.
[RFC5440]和[RFC8253]中描述了PCEP的各种安全注意事项。[RFC5440]第10.1、10.6和10.7节所述的安全注意事项在用作ACTN接口时继续适用于PCEP。此外，本文件列出了适用的PCEP的各种扩展；它们中的每一个都指定了在这里继续应用的各种安全注意事项。
The ACTN framework described in [RFC8453] defines key components and interfaces for managed traffic-engineered networks. It also lists various security considerations such as request and control of resources, confidentially of the information, and availability of function, which should be taken into consideration.
[RFC8453]中描述的ACTN框架定义了受管流量工程网络的关键组件和接口。它还列出了各种安全注意事项，如资源的请求和控制、信息的机密性和功能的可用性，这些都应予以考虑。
As per [RFC8453], securing the request and control of resources, confidentiality of the information, and availability of function should all be critical security considerations when deploying and operating ACTN platforms. From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components (with PCE being one of them). Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts and eavesdropping of communication between different ACTN components. [RFC8453] further states that all protocols used to realize the ACTN framework should have rich security features, and customer, application, and network data should be stored in encrypted data stores. When PCEP is used as an ACTN interface, the security of PCEP provided by Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is used.
根据[RFC8453]，在部署和操作ACTN平台时，确保资源的请求和控制、信息的机密性以及功能的可用性都是关键的安全考虑因素。从安全性和可靠性的角度来看，ACTN可能会遇到许多风险，例如恶意攻击和试图连接到各种ACTN组件的流氓元素（PCE就是其中之一）。此外，一些ACTN组件代表单点故障和威胁向量，还必须管理不同ACTN组件之间的策略冲突和通信窃听。[RFC8453]进一步指出，用于实现ACTN框架的所有协议应具有丰富的安全功能，客户、应用程序和网络数据应存储在加密数据存储中。当PCEP用作ACTN接口时，使用传输层安全性（TLS）[RFC8253]根据[RFC7525]中的建议和最佳现行实践提供的PCEP安全性（除非[RFC8253]中明确规定）。
As per [RFC8453], regarding the MPI, a PKI-based mechanism is suggested, such as building a TLS or HTTPS connection between the MDSC and PNCs, to ensure trust between the physical network layer control components and the MDSC. Which MDSC the PNC exports topology information to, and the level of detail (full or abstracted), should also be authenticated, and specific access restrictions and topology views should be configurable and/or policy based. When PCEP is used in MPI, the security functions, as per [RFC8253], are used to fulfill these requirements.
根据[RFC8453]，关于MPI，建议使用基于PKI的机制，例如在MDSC和PNC之间建立TLS或HTTPS连接，以确保物理网络层控制组件和MDSC之间的信任。PNC将拓扑信息导出到哪个MDSC以及详细程度（完整或抽象）也应经过身份验证，并且特定的访问限制和拓扑视图应可配置和/或基于策略。当MPI中使用PCEP时，根据[RFC8253]，安全功能用于满足这些要求。
As per [RFC8453], regarding the CMI, suitable authentication and authorization of each CNC connecting to the MDSC will be required. If PCEP is used in CMI, the security functions, as per [RFC8253], can be used to support peer authentication, message encryption, and integrity checks.
根据[RFC8453]，关于CMI，需要对连接到MDSC的每个CNC进行适当的认证和授权。如果在CMI中使用PCEP，根据[RFC8253]，安全功能可用于支持对等身份验证、消息加密和完整性检查。
[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>.
[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>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453]Ceccarelli，D.，Ed.和Y.Lee，Ed.，“TE网络的抽象和控制框架（ACTN）”，RFC 8453，DOI 10.17487/RFC8453，2018年8月<https://www.rfc-editor.org/info/rfc8453>.
[ASSOC-POLICY] Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., and M. Negi, "Path Computation Element communication Protocol extension for associating Policies and LSPs", Work in Progress, draft-ietf-pce-association-policy-05, February 2019.
[ASSOC-POLICY]Litkowski，S.，Sivabalan，S.，Tantsura，J.，Hardwick，J.，和M.Negi，“用于关联策略和LSP的路径计算元素通信协议扩展”，正在进行的工作，草案-ietf-pce-association-POLICY-052019年2月。
[EXP] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng, H., and Y. Lee, "Experimental Validation of the ACTN architecture for flexi-grid optical networks using Active Stateful Hierarchical PCEs", 19th International Conference on Transparent Optical Networks (ICTON), DOI 10.5281/zenodo.832904, July 2017, <https://zenodo.org/record/832904>.
[EXP]Casellas，R.，Villata，R.，Martinez，R.，Munoz，R.，Zheng，H.，和Y.Lee，“使用有源状态分层PCE的灵活网格光网络ACTN架构的实验验证”，第19届透明光网络国际会议（ICTON），DOI 10.5281/zenodo.832904，2017年7月<https://zenodo.org/record/832904>.
[PCE-HPCE] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE).", Work in Progress, draft-ietf-pce-stateful-hpce-10, June 2019.
[PCE-HPCE]Dhody，D.，Lee，Y.，Ceccarelli，D.，Shin，J.，和D.King，“分层状态路径计算元素（PCE）”，正在进行的工作，草案-ietf-PCE-Stateful-HPCE-1022019年6月。
[PCE-INTER-AREA] King, D. and H. Zheng, "Applicability of the Path Computation Element to Interarea and Inter-AS MPLS and GMPLS Traffic Engineering", Work in Progress, draft-ietf-pce-inter-area-as-applicability-07, December 2018.
[PCE-INTER-AREA]King，D.和H.Zheng，“路径计算元素对区域间和区域间MPLS和GMPLS流量工程的适用性”，正在进行的工作，草稿-ietf-PCE-INTER-AREA-AS-Applicability-07，2018年12月。
[PCE-INTERDOMAIN] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Extension for Stateful Interdomain Tunnels", Work in Progress, draft-dugeon-pce-stateful-interdomain-02, March 2019.
[PCE-INTERDOMAIN]Dugeon，O.，Meuria，J.，Lee，Y.，和D.Ceccarelli，“有状态域间隧道的PCEP扩展”，正在进行的工作，草案-Dugeon-PCE-Stateful-INTERDOMAIN-022019年3月。
[PCE-STATE-SYNC] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Work in Progress, draft-litkowski-pce-state-sync-05, March 2019.
[PCE-STATE-SYNC]Litkowski，S.，Sivabalan，S.，Li，C.，和H.Zheng，“状态间路径计算元素（PCE）通信程序”，正在进行的工作，草稿-Litkowski-PCE-STATE-SYNC-052019年3月。
[PCEP-LS] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", Work in Progress, draft-dhodylee-pce-pcep-ls-13, February 2019.
[PCEP-LS]Dhody，D.，Lee，Y.，和D.Ceccarelli，“链路状态和TE信息分发的PCEP扩展”，正在进行的工作，草稿-dhodylee-pce-PCEP-LS-132019年2月。
[PCEP-OPTICAL] Lee, Y., Zheng, H., Ceccarelli, D., Wang, W., Park, P., and B. Yoon, "PCEP Extension for Distribution of Link-State and TE information for Optical Networks", Work in Progress, draft-lee-pce-pcep-ls-optical-07, March 2019.
[PCEP-OPTICAL]Lee，Y.，Zheng，H.，Ceccarelli，D.，Wang，W.，Park，P.，和B.Yoon，“光纤网络链路状态和TE信息分发的PCEP扩展”，正在进行的工作，草稿-Lee-pce-PCEP-ls-OPTICAL-07，2019年3月。
[PCEP-VN] Lee, Y., Zhang, X., and D. Ceccarelli, "Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks", Work in Progress, draft-leedhody-pce-vn-association-08, June 2019.
[PCEP-VN]Lee，Y.，Zhang，X.，和D.Ceccarelli，“建立LSP集和虚拟网络之间关系的路径计算元素通信协议（PCEP）扩展”，正在进行的工作，草稿-leedhody-pce-VN-association-082019年6月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<https://www.rfc-editor.org/info/rfc4203>.
[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, DOI 10.17487/RFC5152, February 2008, <https://www.rfc-editor.org/info/rfc5152>.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，DOI 10.17487/RFC5152，2008年2月<https://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, DOI 10.17487/RFC5212, July 2008, <https://www.rfc-editor.org/info/rfc5212>.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 5212，DOI 10.17487/RFC5212，2008年7月<https://www.rfc-editor.org/info/rfc5212>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<https://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, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.
[RFC5307]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，DOI 10.17487/RFC5307，2008年10月<https://www.rfc-editor.org/info/rfc5307>.
[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, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）程序”，RFC 5441，DOI 10.17487/RFC5441，2009年4月<https://www.rfc-editor.org/info/rfc5441>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5623]Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 5623，DOI 10.17487/RFC5623，2009年9月<https://www.rfc-editor.org/info/rfc5623>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149]Boucadair，M.和C.Jacquenet，“软件定义的网络：服务提供商环境中的视角”，RFC 7149，DOI 10.17487/RFC7149，2014年3月<https://www.rfc-editor.org/info/rfc7149>.
[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>.
[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>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[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>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]Zhang，X.，Ed.和I.Minei，Ed.“有状态路径计算元素（PCE）的适用性”，RFC 8051，DOI 10.17487/RFC8051，2017年1月<https://www.rfc-editor.org/info/rfc8051>.
[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>.
[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>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.
[RFC8283]Farrel，A.，Ed.，Zhao，Q.，Ed.，Li，Z.，和C.Zhou，“在具有中央控制的网络中使用PCE和PCE通信协议（PCEP）的体系结构”，RFC 8283，DOI 10.17487/RFC8283，2017年12月<https://www.rfc-editor.org/info/rfc8283>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8454]Lee，Y.，Belotti，S.，Dhody，D.，Ceccarelli，D.，和B.Yoon，“TE网络抽象和控制的信息模型（ACTN）”，RFC 8454，DOI 10.17487/RFC8454，2018年9月<https://www.rfc-editor.org/info/rfc8454>.
In the paper [EXP], the application of the ACTN architecture is presented to demonstrate the control of a multidomain flexi-grid optical network by proposing, adopting, and extending:
在[EXP]一文中，通过提出、采用和扩展以下内容，介绍了ACTN体系结构的应用，以演示对多域柔性网格光网络的控制：
o the Hierarchical active stateful PCE architectures and protocols
o 层次式主动有状态PCE体系结构与协议
o the PCEP protocol to support efficient and incremental link-state topological reporting, known as PCEP-LS
o 支持高效和增量链路状态拓扑报告的PCEP协议，称为PCEP-LS
o the per-link partitioning of the optical spectrum based on variable-sized allocated frequency slots enabling network sharing and virtualization
o 基于可变大小分配的频率槽的每链路频谱划分，实现网络共享和虚拟化
o the use of a model-based interface to dynamically request the instantiation of virtual networks for specific clients/tenants.
o 使用基于模型的接口为特定客户机/租户动态请求虚拟网络的实例化。
The design and implementation of the test bed are reported in order to validate the approach.
为了验证该方法，报告了试验台的设计和实现。
Acknowledgments
致谢
The authors would like to thank Jonathan Hardwick for the inspiration behind this document. Further thanks to Avantika for her comments with suggested text.
作者要感谢乔纳森·哈德威克（Jonathan Hardwick）为本文件提供的灵感。进一步感谢Avantika对建议文本的评论。
Thanks to Adrian Farrel and Daniel King for their substantial reviews.
感谢阿德里安·法雷尔和丹尼尔·金的大量评论。
Thanks to Yingzhen Qu for RTGDIR review.
感谢瞿英珍对RTGDIR的审核。
Thanks to Rifaat Shekh-Yusef for SECDIR review.
感谢Rifaat Shekh Yusef的SECDIR审查。
Thanks to Meral Shirazipour for GENART review.
感谢Meral Shirazipour的GENART评论。
Thanks to Roman Danyliw and Barry Leiba for IESG review comments.
感谢Roman Danyliw和Barry Leiba对IESG评论的评论。
Thanks to Deborah Brungard for being the responsible AD.
感谢Deborah Brungard作为负责任的广告。
Authors' Addresses
作者地址
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
印度卡纳塔克邦班加罗尔Whitefield Bangalore Dhruv Dhody华为技术分部，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Young Lee Futurewei Technologies 5340 Legacy Drive, Suite 173 Plano, TX 75024 United States of America
Young Lee Futurewei Technologies美国德克萨斯州普莱诺市5340 Legacy Drive 173室75024
Email: younglee.tx@gmail.com
Email: younglee.tx@gmail.com
Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm Sweden
Daniele Ceccarelli Ericsson Torshamnsgatan，瑞典斯德哥尔摩48号
Email: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com