doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

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,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+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,
+              <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.
+
+
+
+
+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,
+              <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>.
+
+
+
+
+
+
+
+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,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+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,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+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,
+              <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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+