summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8283.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8283.txt')
-rw-r--r--doc/rfc/rfc8283.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc8283.txt b/doc/rfc/rfc8283.txt
new file mode 100644
index 0000000..4ebe286
--- /dev/null
+++ b/doc/rfc/rfc8283.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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]
+