    Internet Engineering Task Force (IETF)                    A. Farrel, Ed.
    Request for Comments: 8283                              Juniper Networks
    Category: Informational                                     Q. Zhao, Ed.
    ISSN: 2070-1721                                                    R. Li
                                                         Huawei Technologies
                                                                     C. Zhou
                                                               Cisco Systems
                                                               December 2017

    An Architecture for Use of PCE and the PCE Communication Protocol (PCEP)
                       in a Network with Central Control

    Abstract

       The Path Computation Element (PCE) is a core component of Software-
       Defined Networking (SDN) systems.  It can compute optimal paths for
       traffic across a network and can also update the paths to reflect
       changes in the network or traffic demands.

       PCE was developed to derive paths for MPLS Label Switched Paths
       (LSPs), which are supplied to the head end of the LSP using the Path
       Computation Element Communication Protocol (PCEP).

       SDN has a broader applicability than signaled MPLS traffic-engineered
       (TE) networks, and the PCE may be used to determine paths in a range
       of use cases including static LSPs, segment routing, Service Function
       Chaining (SFC), and most forms of a routed or switched network.  It
       is, therefore, reasonable to consider PCEP as a control protocol for
       use in these environments to allow the PCE to be fully enabled as a
       central controller.

       This document briefly introduces the architecture for PCE as a
       central controller, examines the motivations and applicability for
       PCEP as a control protocol in this environment, and introduces the
       implications for the protocol.  A PCE-based central controller can
       simplify the processing of a distributed control plane by blending it
       with elements of SDN and without necessarily completely replacing it.

       This document does not describe use cases in detail and does not
       define protocol extensions: that work is left for other documents.

    Farrel, et al.                Informational                     [Page 1]

    RFC 8283                   PCE-CC Architecture             December 2017

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Not all documents
       approved by the IESG are a candidate for any level of Internet
       Standard; see Section 2 of RFC 7841.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       https://www.rfc-editor.org/info/rfc8283.

    Copyright Notice

       Copyright (c) 2017 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.

    Farrel, et al.                Informational                     [Page 2]

    RFC 8283                   PCE-CC Architecture             December 2017

    Table of Contents

       1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
         2.1.  Resilience and Scaling  . . . . . . . . . . . . . . . . .   8
           2.1.1.  Partitioned Network . . . . . . . . . . . . . . . . .   9
           2.1.2.  Multiple Parallel Controllers . . . . . . . . . . . .  10
           2.1.3.  Hierarchical Controllers  . . . . . . . . . . . . . .  12
       3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .  13
         3.1.  Technology-Oriented Applicability . . . . . . . . . . . .  14
           3.1.1.  Applicability to Control-Plane Operated Networks  . .  14
           3.1.2.  Static LSPs in MPLS . . . . . . . . . . . . . . . . .  14
           3.1.3.  MPLS Multicast  . . . . . . . . . . . . . . . . . . .  15
           3.1.4.  Transport SDN . . . . . . . . . . . . . . . . . . . .  15
           3.1.5.  Segment Routing . . . . . . . . . . . . . . . . . . .  15
           3.1.6.  Service Function Chaining . . . . . . . . . . . . . .  16
         3.2.  High-Level Applicability  . . . . . . . . . . . . . . . .  16
           3.2.1.  Traffic Engineering . . . . . . . . . . . . . . . . .  16
           3.2.2.  Traffic Classification  . . . . . . . . . . . . . . .  17
           3.2.3.  Service Delivery  . . . . . . . . . . . . . . . . . .  17
       4.  Protocol Implications / Guidance for Solution Developers  . .  18
       5.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
       6.  Manageability Considerations  . . . . . . . . . . . . . . . .  19
       7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
       8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
         8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
         8.2.  Informative References  . . . . . . . . . . . . . . . . .  21
       Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  23
       Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

    1.  Introduction

       The Path Computation Element (PCE) [RFC4655] was developed to offload
       path computation function from routers in an MPLS traffic-engineered
       network.  Since then, the role and function of the PCE has grown to
       cover a number of other uses (such as GMPLS [RFC7025]) and to allow
       delegated control [RFC8231] and PCE-initiated use of network
       resources [RFC8281].

       According to [RFC7399], Software-Defined Networking (SDN) refers to a
       separation between the control elements and the forwarding components
       so that software running in a centralized system, called a
       controller, can act to program the devices in the network to behave
       in specific ways.  A required element in an SDN architecture is a
       component that plans how the network resources will be used and how
       the devices will be programmed.  It is possible to view this
       component as performing specific computations to place traffic flows

    Farrel, et al.                Informational                     [Page 3]

    RFC 8283                   PCE-CC Architecture             December 2017

       within the network given knowledge of the availability of network
       resources, how other forwarding devices are programmed, and the way
       that other flows are routed.  This is the function and purpose of a
       PCE, and the way that a PCE integrates into a wider network control
       system (including an SDN system) is presented in [RFC7491].

       In early PCE implementations, where the PCE was used to derive paths
       for MPLS Label Switched Paths (LSPs), paths were requested by network
       elements (known as Path Computation Clients (PCCs)), and the results
       of the path computations were supplied to network elements using the
       Path Computation Element Communication Protocol (PCEP) [RFC5440].
       This protocol was later extended to allow a PCE to send unsolicited
       requests to the network for LSP establishment [RFC8281].

       SDN has a far broader applicability than just signaled MPLS or GMPLS
       traffic-engineered networks.  The PCE component in an SDN system may
       be used to determine paths in a wide range of use cases including
       static LSPs, segment routing [SR-ARCH], SFC [RFC7665], and indeed any
       form of routed or switched network.  It is, therefore, reasonable to
       consider PCEP as a general southbound control protocol (i.e., a
       control protocol for communicating from the central controller to
       network elements) for use in these environments to allow the PCE to
       be fully enabled as a central controller.

       This document introduces the architecture for PCE as a central
       controller as an extension of the architecture described in [RFC4655]
       and assumes the continued use of PCEP as the protocol used between
       PCE and PCC.  This document also examines the motivations and
       applicability for PCEP as a Southbound Interface (SBI) and introduces
       the implications for the protocol used in this way.  A PCE-based
       central controller can simplify the processing of a distributed
       control plane by blending it with elements of SDN and without
       necessarily completely replacing it.

       This document does not describe use cases in detail and does not
       define protocol extensions: that work is left for other documents.

    Farrel, et al.                Informational                     [Page 4]

    RFC 8283                   PCE-CC Architecture             December 2017

    2.  Architecture

       The architecture for the use of PCE within centralized control of a
       network is based on the understanding that a PCE can determine how
       connections should be placed and how resources should be used within
       the network, and that the PCE can then cause those connections to be
       established.  Figure 1 shows how this control relationship works in a
       network with an active control plane.  This is a familiar view for
       those who have read and understood [RFC4655] and [RFC8281].

       In this mode of operation, the central controller is asked to create
       connectivity by a network orchestrator, a service manager, an
       Operations Support System (OSS), a Network Management Station (NMS),
       or some other application.  The PCE-based controller computes paths
       with awareness of the network topology, the available resources, and
       the other services supported in the network.  This information is
       held in the Traffic Engineering Database (TED) and other databases
       available to the PCE.  Then the PCE sends a request using PCEP to one
       of the Network Elements (NEs), and that NE uses a control plane to
       establish the requested connections and reserve the network
       resources.

       Note that other databases (such as an LSP Database (LSP-DB)) might
       also be used, but for simplicity of illustration, just the TED is
       shown.

                  --------------------------------------------
                 | Orchestrator / Service Manager / OSS / NMS |
                  --------------------------------------------
                          ^
                          |
                          v
                      ------------
                     |            |     -----
                     | PCE-Based  |<---| TED |
                     | Controller |     -----
                     |            |
                      ------------
                        ^
                    PCEP|
                        v
                       ----             ----       ----       ----
                      | NE |<--------->| NE |<--->| NE |<--->| NE |
                       ----  Signaling  ----       ----       ----
                             Protocol

              Figure 1: Architecture for the Central Controller with
                                  a Control Plane

    Farrel, et al.                Informational                     [Page 5]

    RFC 8283                   PCE-CC Architecture             December 2017

       Although the architecture shown in Figure 1 represents a form of SDN,
       one objective of SDN in some environments is to remove the dependency
       on a control plane.  A transition architecture toward this goal is
       presented in [RFC7491] and is shown in Figure 2.  In this case,
       services are still requested in the same way, and the PCE-based
       controller still requests use of the network using PCEP.  The main
       difference is that the consumer of the PCEP messages is a network
       controller that provisions the resources and instructs the data plane
       using an SBI that provides an interface to each NE.

                    --------------------------------------------
                   | Orchestrator / Service Manager / OSS / NMS |
                    --------------------------------------------
                                       ^
                                       |
                                       v
                                  ------------
                                 |            |     -----
                                 | PCE-Based  |<---| TED |
                                 | Controller |     -----
                                 |            |
                                  ------------
                                       ^
                                       | PCEP
                                       v
                                  ------------
                                 |  Network   |
                                 | Controller |
                                 /------------\
                            SBI /   ^       ^  \
                               /    |       |   \
                              /     v       v    \
                         ----/    ----     ----   \----
                        | NE |   | NE |   | NE |  | NE |
                         ----     ----     ----    ----

               Figure 2: Architecture Including a Network Controller

       The approach in Figure 2 delivers the SDN functionality but is overly
       complicated and insufficiently flexible.

       o  The complication is created by the use of two controllers in a
          hierarchical organization and the resultant use of two protocols
          in a southbound direction.

       o  The lack of flexibility arises from the assumed or required lack
          of a control plane.

    Farrel, et al.                Informational                     [Page 6]

    RFC 8283                   PCE-CC Architecture             December 2017

       This document describes an architecture that reduces the number of
       components and is flexible to a number of deployment models and use
       cases.  In this hybrid approach (shown in Figure 3), the network
       controller is PCE enabled and can also speak PCEP as the SBI (i.e.,
       it can communicate with each node along the path using PCEP).  That
       means that the controller can communicate with a conventional
       control-plane-enabled NE using PCEP and can also use the same
       protocol to program individual NEs.  In this way, the PCE-based
       controller can control a wider range of networks and deliver many
       different functions as described in Section 3.

       There will be a trade-off in different application scenarios.  In
       some cases, the use of a control plane will simplify deployment (for
       example, by distributing recovery actions), and in other cases, a
       control plane may add operational complexity.

       PCEP is essentially already capable of acting as an SBI and only
       small, use-case-specific modifications to the protocol are needed to
       support this architecture.  The implications for the protocol are
       discussed further in Section 4.

                      --------------------------------------------
                     | Orchestrator / Service Manager / OSS / NMS |
                      --------------------------------------------
                                          ^
                                          |
                                          v
                                    ------------
                                   |            |     -----
                                   | PCE-Based  |<---| TED |
                                   | Controller |     -----
                                   |            |
                                   /------------\
                             PCEP /   ^       ^  \
                                 /    |       |   \
                                /     v       v    \
                               /    ----     ----   \
                              /    | NE |   | NE |   \
                         ----/      ----     ----     \----
                        | NE |                        | NE |
                         ----                          ----
                           ^        ----     ----      ^
                           :......>| NE |...| NE |<....:
                 Signaling Protocol ----     ----

              Figure 3: Architecture for Node-by-Node Central Control

    Farrel, et al.                Informational                     [Page 7]

    RFC 8283                   PCE-CC Architecture             December 2017

    2.1.  Resilience and Scaling

       Systems with central controllers are vulnerable to two problems:
       failure of the controller or overload of the controller.  These
       concerns are not unique to the use of a PCE-based controller, but
       they need to be addressed in this document before the PCE-based
       controller architecture can be considered for use in all but the
       smallest networks.

       There are three architectural mechanisms that can be applied to
       address these issues.  The mechanisms are described separately for
       clarity, but a deployment may use any combination of the approaches.

       For simplicity of illustration, these three approaches are shown in
       the sections that follow without a control plane.  However, the
       general, hybrid approach of Figure 3 is applicable in each case.

    Farrel, et al.                Informational                     [Page 8]

    RFC 8283                   PCE-CC Architecture             December 2017

    2.1.1.  Partitioned Network

       The first and simplest approach to handling controller overload or
       scalability is to use multiple controllers, each responsible for a
       part of the network.  We can call the resultant areas of control
       "domains" [RFC4655].

       This approach is shown in Figure 4.  It can clearly address some of
       the scaling and overload concerns since each controller now only has
       responsibility for a subset of the network elements.  But this comes
       at a cost because end-to-end connections require coordination between
       the controllers.  Furthermore, this technique does not remove the
       concern about a single point-of-failure even if it does reduce the
       impact on the network of the failure of a single controller.

       Note that PCEP is designed to work as a PCE-to-PCE protocol as well
       as a PCE-to-PCC protocol, so it should be possible to use it to
       coordinate between PCE-based controllers in this model.

                        --------------------------------------------
                       | Orchestrator / Service Manager / OSS / NMS |
                        --------------------------------------------
                                    ^                 ^
                                    |                 |
                                    v                 v
                            ------------  Coordi-   ------------
                 -----     |            |  nation  |            |     -----
                | TED |--->| PCE-Based  |<-------->| PCE-Based  |<---| TED |
                 -----     | Controller |          | Controller |     -----
                           |            |    ::    |            |
                           /------------     ::     ------------\
                          /    ^       ^     ::    ^        ^    \
                         /     |       |     ::    |        |     \
                        |      |       |     ::    |        |      |
                        v      v       v     ::    v        v      v
                      ----    ----    ----   ::   ----    ----    ----
                     | NE |  | NE |  | NE |  ::  | NE |  | NE |  | NE |
                      ----    ----    ----   ::   ----    ----    ----
                                             ::
                                    Domain 1 :: Domain 2
                                             ::

              Figure 4: Multiple Controllers on a Partitioned Network

    Farrel, et al.                Informational                     [Page 9]

    RFC 8283                   PCE-CC Architecture             December 2017

    2.1.2.  Multiple Parallel Controllers

       Multiple controllers may be deployed where each controller is capable
       of controlling all of the network elements.  Thus, the failure of any
       one controller will not leave the network unmanageable and, in normal
       circumstances, the load can be distributed across the controllers.

       Multiple parallel controllers may be deployed as shown in Figure 5.
       Each controller is capable of controlling all of the network
       elements; thus, the failure of any one controller will not leave the
       network unmanageable, and in normal circumstances, the load can be
       distributed across the controllers.  In this model, the orchestrator
       (or any requester) must select a controller to consume its request.

                             --------------------------------------------
                            | Orchestrator / Service Manager / OSS / NMS |
                             --------------------------------------------
                                    ^                            ^
                                    |    ___________________     |
                                    |   |  Synchronization  |    |
                                    v   v                   v    v
                              ------------                 ------------
                             |            |     -----     |            |
                             | PCE-Based  |<---| TED |--->| PCE-Based  |
                             | Controller |     -----     | Controller |
                             |            |__  ...........|            |
                              ------------\  \_:__        :------------
                                    ^  ^   \___:  \  .....:  ^   ^
                                    |  |  .....:\  \_:___  ..:   :
                                    |  |__:___   \___:_  \_:___  :
                                    | ....:   | .....: | ..:   | :
                                    | :       | :      | :     | :
                                    v v       v v      v v     v v
                                   ----      ----     ----     ----
                                  | NE |    | NE |   | NE |   | NE |
                                   ----      ----     ----     ----

                     Figure 5: Multiple Redundant Controllers

    Farrel, et al.                Informational                    [Page 10]

    RFC 8283                   PCE-CC Architecture             December 2017

       An alternate approach is to present the controllers as a "cluster"
       that represents itself externally as a single controller as in
       Figure 3 but that is actually comprised of multiple controllers.  The
       size of the cluster may be varied according to the load in the manner
       of Network Functions Virtualization (NFV), and the cluster is
       responsible for sharing load among the members of the cluster.  This
       approach is shown in Figure 6.

                           --------------------------------------------
                          | Orchestrator / Service Manager / OSS / NMS |
                           --------------------------------------------
                                                 ^
                                                 |
                       --------------------------+-------------------------
                      | Controller ______________|_____________            |
                      | Cluster   |                            |           |
                      |           |    ___________________     |           |
                      |           |   |  Synchronization  |    |           |
                      |           v   v                   v    v           |
                      |     ------------      -----      ------------      |
                      |    | PCE-Based  |<---| TED |--->| PCE-Based  |     |
                      |    | Controller |     -----     | Controller |     |
                      |    | Instance   |               | Instance   |     |
                      |     ------------                 ------------      |
                      |           ^                            ^           |
                      |           |____________________________|           |
                      |                          |                         |
                       --------------------------+-------------------------
                                    _____________|_____________
                                   |         |        |        |
                                   v         v        v        v
                                 ----      ----     ----     ----
                                | NE |    | NE |   | NE |   | NE |
                                 ----      ----     ----     ----

               Figure 6: Multiple Controllers Presented as a Cluster

       To achieve full redundancy and to be able to continue to provide full
       function in the event of a controller failure, the controllers must
       synchronize with each other.  This is nominally a simple task if
       there are just two controllers but can actually be quite complex if
       state changes in the network are not to be lost.  Furthermore, if
       there are more than two controllers, the synchronization between
       controllers can become a hard problem.

    Farrel, et al.                Informational                    [Page 11]

    RFC 8283                   PCE-CC Architecture             December 2017

       Synchronization issues are often off-loaded as "database
       synchronization" problems, because distributed database packages have
       already had to address these challenges, or by using a shared
       database.  In networking, the problem may also be addressed by
       collecting the state from the network (effectively using the network
       as a database) using normal routing protocols such as OSPF, IS-IS,
       and BGP.  It should be noted that addressing the synchronization
       problem through a shared database may be hiding the issues of
       congestion and of a single point of failure: while the controllers
       may have been made resilient by allowing redundancy, the shared
       database is still a problem, so the whole system is still vulnerable.

    2.1.3.  Hierarchical Controllers

       Figure 7 shows an approach with hierarchical controllers.  This
       approach was developed for PCEs in [RFC6805] and appears in various
       SDN architectures where a "parent PCE", an "orchestrator", or a
       "super controller" takes responsibility for a high-level view of the
       network before distributing tasks to lower-level PCEs or controllers.

       On its own, this approach does little to protect against the failure
       of a controller, but it can make significant improvements in loading
       and scaling of the individual controllers.  It also offers a good way
       to support end-to-end connectivity across multiple administrative or
       technology-specific domains.

       Note that this model can be arbitrarily recursive with a PCE-based
       controller being the child of one parent PCE-based controller while
       acting as the parent of another set of PCE-based controllers.

    Farrel, et al.                Informational                    [Page 12]

    RFC 8283                   PCE-CC Architecture             December 2017

                          --------------------------------------------
                         | Orchestrator / Service Manager / OSS / NMS |
                          --------------------------------------------
                                               ^
                                               |
                                               v
                                          ------------
                                         |   Parent   |     -----
                                         | PCE-Based  |<---| TED |
                                         | Controller |     -----
                                         |            |
                                          ------------
                                           ^        ^
                                           |        |
                                           v   ::   v
                                 ------------  ::  ------------
                      -----     |            | :: |            |     -----
                     | TED |--->| PCE-Based  | :: | PCE-Based  |<---| TED |
                      -----     | Controller | :: | Controller |     -----
                               /|            | :: |            |\
                              /  ------------  ::  ------------  \
                             /   ^       ^     ::    ^        ^   \
                            /    |       |     ::    |        |    \
                           /     |       |     ::    |        |     \
                          |      |       |     ::    |        |      |
                          v      v       v     ::    v        v      v
                        ----    ----    ----   ::   ----    ----    ----
                       | NE |  | NE |  | NE |  ::  | NE |  | NE |  | NE |
                        ----    ----    ----   ::   ----    ----    ----
                                               ::
                                      Domain 1 :: Domain 2
                                               ::

                        Figure 7: Hierarchical Controllers

    3.  Applicability

       This section gives a very high-level introduction to the
       applicability of a PCE-based centralized controller.  There is no
       attempt to explain each use case in detail, and the inclusion of a
       use case is not intended to suggest that deploying a PCE-based
       controller is a mandatory or recommended approach.  The sections
       below are provided as a stimulus to the discussion of the
       applicability of a PCE-based controller, and it is expected that
       separate documents will be written to develop the use cases in which
       there is interest for implementation and deployment.  As described in

    Farrel, et al.                Informational                    [Page 13]

    RFC 8283                   PCE-CC Architecture             December 2017

       Section 4, specific enhancements to PCEP may be needed for some of
       these use cases, and it is expected that the documents that develop
       each use case will also address any extensions to PCEP.

       The rest of this section is divided into two sub-sections.  The first
       approaches the question of applicability from a consideration of the
       network technology.  The second looks at the high-level functions
       that can be delivered by using a PCE-based controller.

       As previously mentioned, this section is intended to just make
       suggestions.  Thus, the material supplied is very brief.  The
       omission of a use case is in no way meant to imply some limit on the
       applicability of PCE-based control.

    3.1.  Technology-Oriented Applicability

       This section provides a list of use cases based on network
       technology.

    3.1.1.  Applicability to Control-Plane Operated Networks

       This mode of operation is the common approach for an active, stateful
       PCE to control a traffic-engineered MPLS or GMPLS network [RFC8231].
       Note that the PCE-based controller determines what LSPs are needed
       and where to place them.  PCEP is used to instruct the head end of
       each LSP, and the head end signals in the control plane to set up the
       LSP.

       In this mode of operation, the PCE may construct its TED in a number
       of ways as described in [RFC4655], including (but not limited to)
       participating in the IGP or receiving information from a network
       element via BGP-LS [RFC7752].

    3.1.2.  Static LSPs in MPLS

       Static LSPs are provisioned without the use of a control plane.  This
       means that they are established using a management plane or "manual"
       configuration.

       Static LSPs can be provisioned as explicit label instructions at each
       hop on the end-to-end path LSP.  Each router along the path must be
       told what label-forwarding instructions to program and what resources
       to reserve.  The PCE-based controller keeps a view of the network and
       determines the paths of the end-to-end LSPs just as it does for the
       use case described in Section 3.1.1, but the controller uses PCEP to
       communicate with each router along the path of the end-to-end LSP.
       In this case, the PCE-based controller will take responsibility for
       managing some part of the MPLS label space for each of the routers

    Farrel, et al.                Informational                    [Page 14]

    RFC 8283                   PCE-CC Architecture             December 2017

       that it controls, and it may taker wider responsibility for
       partitioning the label space for each router and allocating different
       parts for different uses, communicating the ranges to the router
       using PCEP.

    3.1.3.  MPLS Multicast

       Multicast LSPs may be provisioned with a control plane or as static
       LSPs.  No extra considerations apply above those described in
       Sections 3.1.1 and 3.1.2 except, of course, to note that the PCE must
       also include the instructions about where the LSP branches, i.e.,
       where packets must be copied.

    3.1.4.  Transport SDN

       Transport SDN (T-SDN) is the application of SDN techniques to
       transport networks.  In this respect, a transport network is a
       network built from any technology below the IP layer and designed to
       carry traffic transparently in a connection-oriented way.  Thus, an
       MPLS traffic-engineered network is a transport network, although it
       is more common to consider technologies such as Time Division
       Multiplexing (TDM) and Optical Transport Networks (OTNs) to be
       transport networks.

       Transport networks may be operated with or without a control plane
       and may have point-to-point or point-to-multipoint connections.
       Thus, all of the considerations in Sections 3.1.1, 3.1.2, and 3.1.3
       apply so that the normal PCEP message allows a PCE-based central
       controller to provision a transport network.  It is usually the case
       that additional technology-specific parameters are needed to
       configure the NEs or LSPs in transport networks, such as optical
       characteristic.  Such parameters will need to be carried in the PCEP
       messages: new protocol extensions may be needed, as described, for
       example, in [PCEP-WSON-RWA].

    3.1.5.  Segment Routing

       Segment routing is described in [SR-ARCH].  It relies on a series of
       forwarding instructions being placed in the header of a packet.  At
       each hop in the network, a router looks at the first instruction and
       may: continue to forward the packet unchanged; strip the top
       instruction and forward the packet; or strip the top instruction,
       insert some additional instructions, and forward the packet.

       The segment routing architecture supports operations that can be used
       to steer packet flows in a network, thus providing a form of traffic
       engineering.  A PCE-based controller can be responsible for computing
       the paths for packet flows in a segment routing network, configuring

    Farrel, et al.                Informational                    [Page 15]

    RFC 8283                   PCE-CC Architecture             December 2017

       the forwarding actions on the routers, and telling the edge routers
       what instructions to attach to packets as they enter the network.
       These last two operations can be achieved using PCEP, and the
       PCE-based controller will assume responsibility for managing the
       space of labels or path identifiers used to determine how packets are
       forwarded.

    3.1.6.  Service Function Chaining

       SFC is described in [RFC7665].  It is the process of directing
       traffic in a network such that it passes through specific hardware
       devices or virtual machines (known as service function nodes) that
       can perform particular desired functions on the traffic.  The set of
       functions to be performed and the order in which they are to be
       performed is known as a service function chain.  The chain is
       enhanced with the locations at which the service functions are to be
       performed to derive a Service Function Path (SFP).  Each packet is
       marked as belonging to a specific SFP, and that marking lets each
       successive service function node know which functions to perform and
       to which service function node to send the packet next.

       To operate an SFC network, the service function nodes must be
       configured to understand the packet markings, and the edge nodes must
       be told how to mark packets entering the network.  Additionally, it
       may be necessary to establish tunnels between service function nodes
       to carry the traffic.

       Planning an SFC network requires load balancing between service
       function nodes and traffic engineering across the network that
       connects them.  These are operations that can be performed by a
       PCE-based controller, and that controller can use PCEP to program the
       network and install the service function chains and any required
       tunnels.

    3.2.  High-Level Applicability

       This section provides a list of the high-level functions that can be
       delivered by using a PCE-based controller.

    3.2.1.  Traffic Engineering

       According to [RFC2702], TE is concerned with performance optimization
       of operational networks.  In general, it encompasses the application
       of technology and scientific principles to the measurement, modeling,
       characterization, control of Internet traffic, and application of
       such knowledge and techniques to achieve specific performance
       objectives.

    Farrel, et al.                Informational                    [Page 16]

    RFC 8283                   PCE-CC Architecture             December 2017

       From a practical point of view, this involves having an understanding
       of the topology of the network, the characteristics of the nodes and
       links in the network, and the traffic demands and flows across the
       network.  It also requires that actions can be taken to ensure that
       traffic follows specific paths through the network.

       PCE was specifically developed to address TE in an MPLS network, so a
       PCE-based controller is well suited to analyze TE problems and supply
       answers that can be installed in the network using PCEP.  PCEP can be
       responsible for initiating paths across the network through a control
       plane or for installing state in the network node by node such as in
       a segment-routed network (see Section 3.1.5) or by configuring IGP
       metrics.

    3.2.2.  Traffic Classification

       Traffic classification is an important part of traffic engineering.
       It is the process of looking at a packet to determine how it should
       be treated as it is forwarded through the network.  It applies in
       many scenarios including MPLS traffic engineering (where it
       determines what traffic is forwarded onto which LSPs); segment
       routing (where it is used to select which set of forwarding
       instructions to add to a packet); and SFC (where it indicates along
       which service function path a packet should be forwarded).  In
       conjunction with traffic engineering, traffic classification is an
       important enabler for load balancing.

       Traffic classification is closely linked to the computational
       elements of planning for the network functions just listed because it
       determines how traffic load is balanced and distributed through the
       network.  Therefore, selecting what traffic classification should be
       performed by a router is an important part of the work done by a
       PCE-based controller.

       Instructions can be passed from the controller to the routers using
       PCEP.  These instructions tell the routers how to map traffic to
       paths or connections.

    3.2.3.  Service Delivery

       Various network services may be offered over a network.  These
       include protection services (including end-to-end protection
       [RFC4427], restoration after failure, and fast reroute [RFC4090]);
       Virtual Private Network (VPN) services (such as Layer 3 VPNs
       [RFC4364] or Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985].

    Farrel, et al.                Informational                    [Page 17]

    RFC 8283                   PCE-CC Architecture             December 2017

       Delivering services over a network in an optimal way requires
       coordination in the way that network resources are allocated to
       support the services.  A PCE-based central controller can consider
       the whole network and all components of a service at once when
       planning how to deliver the service.  It can then use PCEP to manage
       the network resources and to install the necessary associations
       between those resources.

    4.  Protocol Implications / Guidance for Solution Developers

       PCEP is a push-pull protocol that is designed to move requests and
       responses between a server (the PCE) and clients (the PCCs, i.e., the
       network elements).  In particular, it has a message (the LSP Initiate
       Request (PCInitiate); see [RFC8281]) that can be sent by the PCE to
       install state or cause actions at the PCC and a response message
       (Path Computation State Report (PCRpt)) that is used to confirm the
       request.

       As such, there is an expectation that only relatively minor changes
       to PCEP are required to support the concept of a PCE-based
       controller.  The only work expected to be needed is extensions to
       existing PCEP messages to carry additional or specific information
       elements for the individual use cases, which maintain backward
       compatibility and do not impact existing PCEP deployments.  [RFC5440]
       already describes how legacy implementations handle unknown protocol
       extensions and how to use the PCEP Open message to indicate support
       for PCEP features.  Where possible, consistent with the general
       principles of how protocols are extended, any additions to the
       protocol should be made in a generic way such that they are open to
       use in a range of applications.

       It is anticipated that new documents (such as [PCEP-CONTROLLER]) will
       be produced for each use case dependent on support and demand.  Such
       documents will explain the use case and define the necessary protocol
       extensions.

       Protocol extensions could have impact on existing PCEP deployments
       and the interoperability between different implementations.  It is
       anticipated that changes of the PCEP protocol or addition of
       information elements could require additional testing to ensure
       interoperability between different PCEP implementations.

       It is reasonable to expect that implementations are able to select a
       subset or profile of the protocol extensions and PCEP features that
       are relevant for the application scenario in which they will be
       deployed.  Identification of these profiles should form part of the
       protocol itself so that interoperability can be easily determined and
       testing can be limited to the specific profiles.

    Farrel, et al.                Informational                    [Page 18]

    RFC 8283                   PCE-CC Architecture             December 2017

       Note that protocol mechanisms to handle synchronization of state in
       parallel PCE-based controllers will also be required if parallel
       controllers are used as described in Section 2.1.2.  In [RFC8231],
       there is a discussion of mechanisms to achieve PCE state
       synchronization.

    5.  Security Considerations

       Security considerations for a PCE-based controller are little
       different from those for any other PCE system.  That is, the
       operation relies heavily on the use and security of PCEP, so
       consideration should be given to the security features discussed in
       [RFC5440] and the additional mechanisms described in [RFC8253].

       It should be observed that the trust model of a network that operates
       without a control plane is different from one with a control plane.
       The conventional "chain of trust" used with a control plane is
       replaced by individual trust relationships between the controller and
       each individual NE.  This model may be considerably easier to manage,
       so it is more likely to be operated with a high level of security.

       However, an architecture with a central controller has a central
       point of failure, and this is also a security weakness since the
       network can be vulnerable to denial-of-service attacks on the
       controller.  Similarly, the central controller provides a focus for
       interception and modification of messages sent to individual NEs.  In
       short, while the interactions with a PCE-based controller are not
       substantially different to those in any other SDN architecture, the
       security implications of SDN have not been fully discussed or
       described.  Therefore, protocol and applicability work-around
       solutions for this architecture must take proper account of these
       concerns.

       It is expected that each new document that is produced for a specific
       use case will also include considerations of the security impacts of
       the use of a PCE-based central controller on the network type and
       services being managed.

    6.  Manageability Considerations

       The architecture described in this document is a management
       architecture: the PCE-based controller is a management component that
       controls the network through a southbound control protocol (PCEP).

       An implementation of a PCE-based controller will require access to
       information about the state of the network, its nodes, and its links.
       Some of this will be the TED as is normal for a PCE and can be
       collected using the mechanisms already in place (such as listening to

    Farrel, et al.                Informational                    [Page 19]

    RFC 8283                   PCE-CC Architecture             December 2017

       the IGPs, using BGP-LS [RFC7752], or northbound export of
       YANG-encoded data [YANG-TE] from the network elements to the
       controller).  More information may be collected in the LSP database
       for stateful PCEs as described in [RFC7399] and [RFC8231].
       Additional information may be needed for other specific use cases and
       will need to be collected and passed to the controller.  This may
       require protocol extensions for the mechanisms listed in this
       paragraph.

       The use of different PCEP options and protocol extensions may have an
       impact on interoperability, which is a management issue.  As noted in
       Section 4, protocol extensions should be done in a way that makes it
       possible to identify profiles of PCEP to aid interoperability, and
       this will aid deployment and manageability.

       [RFC5440] contains a substantive Manageability Considerations section
       that examines how a PCE-based system and a PCE-enabled system may be
       managed.  A MIB module for PCEP was published as [RFC7420], and a
       YANG module for PCEP has also been proposed [YANG-PCEP].

    7.  IANA Considerations

       This document does not require any IANA actions.

    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>.

       [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>.

    Farrel, et al.                Informational                    [Page 20]

    RFC 8283                   PCE-CC Architecture             December 2017

    8.2.  Informative References

       [PCECC]    Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou,
                  C., Communications, T., Rachitskiy, A., and A. Gulida,
                  "The Use Cases for Using PCE as the Central
                  Controller(PCECC) of LSPs", Work in Progress,
                  draft-zhao-teas-pcecc-use-cases-02, October 2016.

       [PCEP-CONTROLLER]
                  Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
                  and C. Zhou, "PCEP Procedures and Protocol Extensions for
                  Using PCE as a Central Controller (PCECC) of LSPs", Work
                  in Progress, draft-zhao-pce-pcep-extension-for-pce-
                  controller-06, October 2017.

       [PCEP-WSON-RWA]
                  Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
                  and Wavelength Assignment", Work in Progress,
                  draft-ietf-pce-wson-rwa-ext-07, November 2017.

       [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
                  McManus, "Requirements for Traffic Engineering Over MPLS",
                  RFC 2702, DOI 10.17487/RFC2702, September 1999,
                  <https://www.rfc-editor.org/info/rfc2702>.

       [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
                  Edge-to-Edge (PWE3) Architecture", RFC 3985,
                  DOI 10.17487/RFC3985, March 2005,
                  <https://www.rfc-editor.org/info/rfc3985>.

       [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
                  Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
                  DOI 10.17487/RFC4090, May 2005,
                  <https://www.rfc-editor.org/info/rfc4090>.

       [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
                  Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
                  2006, <https://www.rfc-editor.org/info/rfc4364>.

       [RFC4427]  Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
                  (Protection and Restoration) Terminology for Generalized
                  Multi-Protocol Label Switching (GMPLS)", RFC 4427,
                  DOI 10.17487/RFC4427, March 2006,
                  <https://www.rfc-editor.org/info/rfc4427>.

    Farrel, et al.                Informational                    [Page 21]

    RFC 8283                   PCE-CC Architecture             December 2017

       [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>.

       [RFC7025]  Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
                  Margaria, "Requirements for GMPLS Applications of PCE",
                  RFC 7025, DOI 10.17487/RFC7025, September 2013,
                  <https://www.rfc-editor.org/info/rfc7025>.

       [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>.

       [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
                  Hardwick, "Path Computation Element Communication Protocol
                  (PCEP) Management Information Base (MIB) Module",
                  RFC 7420, DOI 10.17487/RFC7420, December 2014,
                  <https://www.rfc-editor.org/info/rfc7420>.

       [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
                  Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
                  Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
                  2015, <https://www.rfc-editor.org/info/rfc7432>.

       [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>.

       [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
                  Chaining (SFC) Architecture", RFC 7665,
                  DOI 10.17487/RFC7665, October 2015,
                  <https://www.rfc-editor.org/info/rfc7665>.

       [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>.

       [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>.

    Farrel, et al.                Informational                    [Page 22]

    RFC 8283                   PCE-CC Architecture             December 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,
                  <https://www.rfc-editor.org/info/rfc8253>.

       [SR-ARCH]  Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
                  Litkowski, S., and R. Shakir, "Segment Routing
                  Architecture", Work in Progress, draft-ietf-spring-
                  segment-routing-13, October 2017.

       [YANG-PCEP]
                  Dhody, D., Hardwick, J., Beeram, V., and j.
                  jefftant@gmail.com, "A YANG Data Model for Path
                  Computation Element Communications Protocol (PCEP)", Work
                  in Progress, draft-ietf-pce-pcep-yang-05, June 2017.

       [YANG-TE]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
                  O. Dios, "YANG Data Model for Traffic Engineering (TE)
                  Topologies", Work in Progress, draft-ietf-teas-yang-te-
                  topo-13, October 2017.

    Acknowledgments

       The ideas in this document owe a lot to the work started by the
       authors of [PCECC] and [PCEP-CONTROLLER].  The authors of this
       document fully acknowledge the prior work and thank those involved
       for opening the discussion.  The individuals concerned are: King Ke,
       Luyuan Fang, Chao Zhou, Boris Zhang, and Zhenbin Li.

       This document has benefited from the discussions within a small ad
       hoc design team; the members of which are listed as document
       contributors.

       Thanks to Michael Scharf and Andy Malis for a lively discussion of
       this document.

       Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call
       comments on this document.

       Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful
       comments during IESG review.

    Farrel, et al.                Informational                    [Page 23]

    RFC 8283                   PCE-CC Architecture             December 2017

    Contributors

       The following people contributed to discussions that led to the
       development of this document:

          Cyril Margaria
          Email: cmargaria@juniper.net

          Sudhir Cheruathur
          Email: scheruathur@juniper.net

          Dhruv Dhody
          Email: dhruv.dhody@huawei.com

          Daniel King
          Email: daniel@olddog.co.uk

          Iftekhar Hussain
          Email: IHussain@infinera.com

          Anurag Sharma
          Email: AnSharma@infinera.com

          Eric Wu
          Email: eric.wu@huawei.com

    Farrel, et al.                Informational                    [Page 24]

    RFC 8283                   PCE-CC Architecture             December 2017

    Authors' Addresses

       Adrian Farrel (editor)
       Juniper Networks

       Email: afarrel@juniper.net

       Quintin Zhao (editor)
       Huawei Technologies
       125 Nagog Technology Park
       Acton, MA  01719
       United States of America

       Email: quintin.zhao@huawei.com

       Robin Li
       Huawei Technologies
       Huawei Bld., No.156 Beiqing Road
       Beijing  100095
       China

       Email: lizhenbin@huawei.com

       Chao Zhou
       Cisco Systems

       Email: chao.zhou@cisco.com

    Farrel, et al.                Informational                    [Page 25]