From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8637.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc8637.txt (limited to 'doc/rfc/rfc8637.txt') diff --git a/doc/rfc/rfc8637.txt b/doc/rfc/rfc8637.txt new file mode 100644 index 0000000..e17f505 --- /dev/null +++ b/doc/rfc/rfc8637.txt @@ -0,0 +1,1235 @@ + + + + + + +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) + +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. + + 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). + + This document examines the applicability of PCE to the ACTN + framework. + +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. + + 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. + + + + + +Dhody, et al. Informational [Page 1] + +RFC 8637 PCE-ACTN July 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + 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. + + + +Dhody, et al. Informational [Page 2] + +RFC 8637 PCE-ACTN July 2019 + + + 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). + + 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. + + 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. + +2. Background Information + +2.1. Path Computation Element (PCE) + + 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. + + 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. + + 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). + + [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. + + [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 + + + + +Dhody, et al. Informational [Page 3] + +RFC 8637 PCE-ACTN July 2019 + + + 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. + + [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. + +2.1.1. Role of PCE in SDN + + 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]. + +2.1.2. PCE in Multidomain and Multilayer Deployments + + 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. + + + + + + +Dhody, et al. Informational [Page 4] + +RFC 8637 PCE-ACTN July 2019 + + + [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. + + [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. + + [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). + +2.1.3. Relationship to PCE-Based Central Control + + [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]. + +2.2. Abstraction and Control of TE Networks (ACTN) + + [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. + + 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. + + + + + + + + +Dhody, et al. Informational [Page 5] + +RFC 8637 PCE-ACTN July 2019 + + + +---------+ +---------+ +---------+ + | 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) + + Figure 1: ACTN Hierarchy + + 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. + + [RFC8454] provides an information model for ACTN interfaces. + + + + + + + + +Dhody, et al. Informational [Page 6] + +RFC 8637 PCE-ACTN July 2019 + + +3. Architectural Considerations + + 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: + + o Multidomain coordination + + o Abstraction + + o Customer mapping/translation + + o Virtual service coordination + + Section 3 of [RFC8453] describes these functions. + + 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. + +3.1. Multidomain Coordination via Hierarchy + + 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. + + 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. + + [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. + + + + + + +Dhody, et al. Informational [Page 7] + +RFC 8637 PCE-ACTN July 2019 + + + 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-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. + +3.2. Abstraction + + 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. + + 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]. + + 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. + + [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. + + 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 + + + +Dhody, et al. Informational [Page 8] + +RFC 8637 PCE-ACTN July 2019 + + + [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. + + [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. + +3.3. Customer Mapping + + 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. + + [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. + + PCEP extensions for associating opaque policy between PCEP peer + [ASSOC-POLICY] can be used. + + + + + +Dhody, et al. Informational [Page 9] + +RFC 8637 PCE-ACTN July 2019 + + +3.4. Virtual Service Coordination + + 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. + + [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. + + 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. + +4. Interface Considerations + + 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: + + 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 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. + + + + + + +Dhody, et al. Informational [Page 10] + +RFC 8637 PCE-ACTN July 2019 + + + 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. + + 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. + +5. Realizing ACTN with PCE (and PCEP) + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dhody, et al. Informational [Page 11] + +RFC 8637 PCE-ACTN July 2019 + + + ****** + ..........*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 + + Figure 2: ACTN with 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. + + + +Dhody, et al. Informational [Page 12] + +RFC 8637 PCE-ACTN July 2019 + + + * 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. + + 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. + + * 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. + + * A-B: (A-B13,B13-B31,B31-B) + + * 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. + + * 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. + + * 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. + + + +Dhody, et al. Informational [Page 13] + +RFC 8637 PCE-ACTN July 2019 + + + * 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. + + 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 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 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 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 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. + +6. IANA Considerations + + This document has no IANA actions. + + + + + + + + + + +Dhody, et al. Informational [Page 14] + +RFC 8637 PCE-ACTN July 2019 + + +7. Security Considerations + + 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. + + 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. + + 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. + + 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. + + 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. + + + +Dhody, et al. Informational [Page 15] + +RFC 8637 PCE-ACTN July 2019 + + +8. References + +8.1. Normative References + + [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation + Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + . + + [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, + . + + [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, + . + +8.2. Informative References + + [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. + + [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, + . + + [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. + + + + +Dhody, et al. Informational [Page 16] + +RFC 8637 PCE-ACTN July 2019 + + + [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-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-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. + + [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-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-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. + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + DOI 10.17487/RFC3630, September 2003, + . + + [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, + . + + + + + + + +Dhody, et al. Informational [Page 17] + +RFC 8637 PCE-ACTN July 2019 + + + [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, + . + + [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, + . + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, . + + [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, + . + + [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, + . + + [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, . + + [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, + . + + [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, + . + + [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path + Computation Element Architecture", RFC 7399, + DOI 10.17487/RFC7399, October 2014, + . + + + + +Dhody, et al. Informational [Page 18] + +RFC 8637 PCE-ACTN July 2019 + + + [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for + Application-Based Network Operations", RFC 7491, + DOI 10.17487/RFC7491, March 2015, + . + + [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, . + + [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, + . + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + + [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a + Stateful Path Computation Element (PCE)", RFC 8051, + DOI 10.17487/RFC8051, January 2017, + . + + [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, + . + + [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, + . + + [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, + . + + + + + + + + +Dhody, et al. Informational [Page 19] + +RFC 8637 PCE-ACTN July 2019 + + + [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, + . + + [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, . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dhody, et al. Informational [Page 20] + +RFC 8637 PCE-ACTN July 2019 + + +Appendix A. Additional Information + + 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: + + o the Hierarchical active stateful PCE architectures and protocols + + o the PCEP protocol to support efficient and incremental link-state + topological reporting, known as PCEP-LS + + o the per-link partitioning of the optical spectrum based on + variable-sized allocated frequency slots enabling network sharing + and virtualization + + o the use of a model-based interface to dynamically request the + instantiation of virtual networks for specific clients/tenants. + + 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. + + Thanks to Adrian Farrel and Daniel King for their substantial + reviews. + + Thanks to Yingzhen Qu for RTGDIR review. + + Thanks to Rifaat Shekh-Yusef for SECDIR review. + + Thanks to Meral Shirazipour for GENART review. + + Thanks to Roman Danyliw and Barry Leiba for IESG review comments. + + Thanks to Deborah Brungard for being the responsible AD. + + + + + + + + + + + + +Dhody, et al. Informational [Page 21] + +RFC 8637 PCE-ACTN July 2019 + + +Authors' Addresses + + Dhruv Dhody + Huawei Technologies + Divyashree Techno Park, Whitefield + Bangalore, Karnataka 560066 + India + + Email: dhruv.ietf@gmail.com + + + Young Lee + Futurewei Technologies + 5340 Legacy Drive, Suite 173 + Plano, TX 75024 + United States of America + + Email: younglee.tx@gmail.com + + + Daniele Ceccarelli + Ericsson + Torshamnsgatan,48 + Stockholm + Sweden + + Email: daniele.ceccarelli@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + +Dhody, et al. Informational [Page 22] + -- cgit v1.2.3