RFC 8283
An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
📡 RFC 8283: An Architecture for Use of PCE and PCEP in a Network with Central Control 💖
okay bestie, this is RFC 8283, published in December 2017 as an Informational doc from the IETF (ISSN 2070-1721). It was written by A. Farrel, Ed. of Juniper Networks, Q. Zhao, Ed. and R. Li of Huawei Technologies, and C. Zhou of Cisco Systems. The header doesn't list anything it obsoletes or updates. 🎀 The title says it all: it's about using the PCE and PCEP as a central controller, so let's get into it 🦋
Abstract ✨
okay so the Path Computation Element (PCE) is a core piece of Software-Defined Networking (SDN) systems 💅 It can work out the best paths for traffic across a network, and it can update those paths when the network or the traffic demands change 🌈
the PCE was originally built to figure out paths for MPLS Label Switched Paths (LSPs), and those paths get handed to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP) 🧚
BUT SDN is way bigger than just signaled MPLS traffic-engineered (TE) networks 😭 the PCE can help find paths for lots of other stuff too: static LSPs, segment routing, Service Function Chaining (SFC), and most kinds of routed or switched network 🔥 so it totally makes sense to think of PCEP as a control protocol for these environments, letting the PCE be fully enabled as a central controller 👑
this doc gives a quick intro to the PCE-as-central-controller architecture, looks at why and where PCEP would be used as a control protocol in that setup, and talks about what it means for the protocol 🌸 a PCE-based central controller can make processing a distributed control plane way simpler by mixing it with SDN elements, and it doesn't have to totally replace the distributed stuff either 🫶
last bit: this doc doesn't go deep into use cases, and it doesn't define any protocol extensions. that work is for other documents, bestie 💜
Status of This Memo ✨
this one is not an Internet Standards Track spec. it's just published for info 🎀
it's a product of the IETF, and it reflects the IETF community's consensus. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full story 🙈
for the current status, any errata, or to send feedback, head to https://www.rfc-editor.org/info/rfc8283 🦋
Copyright Notice ✨
© 2017 IETF Trust and the people listed as document authors. all rights reserved 💅
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as they stood on the publication date. please actually read those, bestie, because they spell out your rights and restrictions for this doc 📜
if you pull any Code Components out of this doc, they have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, same as that license says 💜
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 . . . . . . . . . . . . . . . . . . . . . . . 251. Introduction ✨
okay so the Path Computation Element (PCE) [RFC4655] was built to take path computation off routers in an MPLS traffic-engineered network 💖 since then, the PCE's job has grown to cover other stuff too, like GMPLS [RFC7025], and it now allows delegated control [RFC8231] and PCE-initiated use of network resources [RFC8281] 🦋
according to [RFC7399], Software-Defined Networking (SDN) is a split between the control elements and the forwarding components, so software running in a centralized system (called a controller) can program the devices in the network to behave in specific ways 🧚 a must-have piece of any SDN architecture is the component that plans how network resources get used and how devices get programmed 🎀 you can think of it as doing specific computations to place traffic flows in the network, using what it knows about available resources, how other forwarding devices are programmed, and how other flows are routed 🌈 that's the whole purpose of a PCE, and [RFC7491] explains how a PCE fits into a bigger network control system, SDN included 👑
in the early PCE days, the PCE derived paths for MPLS Label Switched Paths (LSPs). the paths were requested by network elements (called Path Computation Clients (PCCs)), and the results were handed back to those elements using the Path Computation Element Communication Protocol (PCEP) [RFC5440] 💅 later on, the protocol got extended so a PCE could send unsolicited requests to the network for LSP establishment [RFC8281] 🫶
SDN is WAY broader than just signaled MPLS or GMPLS traffic-engineered networks 😭 the PCE piece of an SDN system can figure out paths for a wide range of use cases: static LSPs, segment routing [SR-ARCH], SFC [RFC7665], and honestly any form of routed or switched network 🔥 so it's reasonable to see PCEP as a general southbound control protocol (a control protocol for talking from the central controller to network elements) for these environments, letting the PCE be fully enabled as a central controller 👑
this doc introduces the PCE-as-central-controller architecture as an extension of the one in [RFC4655], and it assumes PCEP stays as the protocol between PCE and PCC 🌸 it also looks at why and where PCEP would work as a Southbound Interface (SBI), and what that means for the protocol when used that way 💜 a PCE-based central controller can simplify processing in a distributed control plane by blending it with SDN elements, without necessarily replacing that plane completely 🦋
and yes, again, this doc doesn't go into use cases in detail and doesn't define protocol extensions. that work is left for other docs, bestie 🎀
2. Architecture ✨
okay so the whole architecture for using a PCE in centralized control is built on one big idea: a PCE can figure out how connections should be placed and how resources should get used across the network, and then it can make those connections actually happen 💅. Figure 1 shows how that control relationship plays out in a network with an active control plane. if you've read [RFC4655] and [RFC8281], this is giving total déjà vu 🫶.
In this mode, an orchestrator, a service manager, an Operations Support System (OSS), a Network Management Station (NMS), or some other app asks the central controller to create connectivity 🎀. The PCE-based controller computes paths while being aware of the network topology, the available resources, and the other services running in the network. All that info lives in the Traffic Engineering Database (TED) and other databases the PCE can reach. Then the PCE sends a request over PCEP to one of the Network Elements (NEs), and that NE uses a control plane to set up 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 PlaneAlthough the architecture in Figure 1 counts as 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 big 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 ControllerThe approach in Figure 2 delivers the SDN functionality, but it's overly complicated and insufficiently flexible 😭.
- the complication: two controllers stacked in a hierarchy, which means two protocols going southbound 💀
- the lack of flexibility: it comes from the assumed or required lack of a control plane 🙃
This document describes an architecture that cuts down the number of components and is flexible across a bunch 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, meaning it can communicate with each node along the path using PCEP 🫶. That means the controller can talk to a conventional control-plane-enabled NE using PCEP, and it can also use the same protocol to program individual NEs. So 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, using 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 basically 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 Control2.1. Resilience and Scaling
okay, real talk: systems with central controllers are vulnerable to two problems, failure of the controller or overload of the controller 😬. These concerns aren't unique to 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. They're 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 applies in each case 🌸.
2.1.1. Partitioned Network
the first and simplest way to handle controller overload or scalability is to use multiple controllers, each responsible for part of the network. We can call the resulting 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 doesn't remove the concern about a single point of failure, even if it does reduce the impact on the network of a single controller failing 💅.
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 Network2.1.2. Multiple Parallel Controllers 🦋
okay so bestie, this is the "more the merrier" setup 💅 Multiple controllers can be deployed where EACH controller is capable of controlling all of the network elements. So if one controller goes down, the network is still manageable, and in normal circumstances the load can be spread across the controllers ✨
Multiple parallel controllers may be deployed as shown in Figure 5. Again, each controller is capable of controlling all of the network elements, so 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. Wait, I should be careful with that, the original doesn't use a capitalised key word here, so it's just "must" in plain lowercase, which means the orchestrator has to pick one. Ok, that's the vibe 🫶
--------------------------------------------
| 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 💜
An alternate approach is to present the controllers as a "cluster" that represents itself externally as a single controller, like in Figure 3, but that is actually made up 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 keep providing full function if a controller fails, the controllers must synchronise with each other 🔥 This is nominally a simple task if there are just two controllers, but it can actually get quite complex if state changes in the network are not to be lost 💀 And if there are more than two controllers, synchronisation between them can become a hard problem 😭
Synchronisation issues are often offloaded as "database synchronisation" problems, because distributed database packages have already had to deal with 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) with normal routing protocols such as OSPF, IS-IS, and BGP 🛰️ It should be noted that addressing synchronisation 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 🌀
--------------------------------------------
| 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 including 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 applicability, 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 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 that it controls, and it may take 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
Okay so multicast LSPs can be set up with a control plane or as static LSPs, bestie 🦋 Nothing extra is needed beyond what we covered in Sections 3.1.1 and 3.1.2, except the PCE also has to include the instructions for where the LSP branches, aka where packets must be copied 🌿✨
3.1.4. Transport SDN
Transport SDN (T-SDN) is when you bring SDN techniques to transport networks 🚆💖 In this context, a transport network is any network built from a technology below the IP layer that's designed to carry traffic transparently in a connection-oriented way 🎀 So an MPLS traffic-engineered network counts as a transport network! Though it's more common to think of things like Time Division Multiplexing (TDM) and Optical Transport Networks (OTNs) as transport networks 💅
Transport networks can run with or without a control plane, and they can have point-to-point or point-to-multipoint connections 🌈 So everything in Sections 3.1.1, 3.1.2, and 3.1.3 applies, meaning the normal PCEP message lets a PCE-based central controller provision a transport network 🫶 Usually you also need extra technology-specific parameters to configure the NEs or LSPs in transport networks, like optical characteristics ✨ Those parameters have to be carried in PCEP messages, and 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 works by placing a series of forwarding instructions in the header of a packet 🦋 At each hop, 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, which gives you 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 the forwarding actions on the routers, and telling the edge routers which instructions to attach to packets as they enter the network 👑 The last two jobs can be done using PCEP, and the PCE-based controller takes responsibility for managing the space of labels or path identifiers used to decide how packets get forwarded 💅✨
3.1.6. Service Function Chaining
SFC is described in [RFC7665] 🎀 It's the process of directing traffic so it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular functions on the traffic 🌷 The set of functions, and the order they run in, is called a service function chain 💖 Add the locations where the service functions are performed and you get a Service Function Path (SFP) 🦋 Each packet gets marked as belonging to a specific SFP, and that marking tells each service function node which functions to perform and which node to send the packet to 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 🌈 It may also be necessary to set up 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 jobs can be done by a PCE-based controller, which can use PCEP to program the network and install the service function chains and any required tunnels 👑✨
3.2. High-Level Applicability
This section gives a list of the high-level functions a PCE-based controller can deliver 🌸
3.2.1. Traffic Engineering
According to [RFC2702], TE is concerned with performance optimization of operational networks 🔥 In general, it covers applying technology and scientific principles to measuring, modeling, and characterizing Internet traffic, controlling it, and applying that knowledge and those techniques to hit specific performance objectives 💜
In practice, this means understanding the topology of the network, the characteristics of its nodes and links, and the traffic demands and flows across it 🦋 It also means being able to make sure 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 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 a big deal in traffic engineering 🌈 It's the process of looking at a packet to determine how it should be treated as it's forwarded through the network 💅 It shows up in lots of scenarios: MPLS traffic engineering (where it decides which traffic goes onto which LSPs), segment routing (where it selects which set of forwarding instructions to add to a packet), and SFC (where it indicates which service function path a packet should follow) 🧚 Together with traffic engineering, traffic classification is a key enabler for load balancing 🫶
Traffic classification is tightly linked to the computational parts of planning the network functions we just listed, because it determines how traffic load gets balanced and distributed through the network 👑 So picking what traffic classification a router should perform is a big part of the work a PCE-based controller does 🔥
Instructions can be passed from the controller to the routers using PCEP 🌸 They 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]); and Pseudowires [RFC3985] 🎀
Delivering services over a network in an optimal way needs coordination in how network resources are allocated to support those services 😭 A PCE-based central controller can look at the whole network and every component of a service at once when planning how to deliver it ✨ It can then use PCEP to manage the network resources and install the necessary associations between them 💅🌈
- Protocol Implications / Guidance for Solution Developers
PCEP is a push-pull protocol designed to move requests and responses between a server (the PCE) and clients (the PCCs, i.e., the network elements) 🧚 In particular, there's a message (the LSP Initiate Request (PCInitiate); see [RFC8281]) that the PCE can send to install state or trigger actions at the PCC, plus a response message (Path Computation State Report (PCRpt)) that's used to confirm the request 🦋
So there's an expectation that only relatively minor changes to PCEP are needed to support the concept of a PCE-based controller 💜 The only work expected is extending existing PCEP messages to carry additional or specific information elements for individual use cases, in a way that maintains backward compatibility and doesn't 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, and consistent with the general principles of how protocols are extended, any additions should be made in a generic way so they're open to use across a range of applications 👑✨
It's anticipated that new documents (such as [PCEP-CONTROLLER]) will be produced for each use case, depending on support and demand 🎀 Those documents will explain the use case and define the necessary protocol extensions 💖
Protocol extensions could impact existing PCEP deployments and interoperability between different implementations 😭 It's anticipated that changes to the PCEP protocol or additions of information elements could require extra testing to make sure different PCEP implementations still interoperate 🔥
It's reasonable to expect that implementations are able to select a subset or profile of the protocol extensions and PCEP features that are relevant to the application scenario they'll be deployed in 🌈 Identifying these profiles should form part of the protocol itself, so interoperability can be easily determined and testing can be limited to the specific profiles 💅
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 🧚 [RFC8231] discusses mechanisms for achieving PCE state synchronization 🦋
- Security Considerations
Security considerations for a PCE-based controller are little different from those for any other PCE system 🔐💜 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's 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 that's 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 interactions with a PCE-based controller aren't substantially different from those in any other SDN architecture, the security implications of SDN haven't 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 produced for a specific use case will also include considerations of the security impacts of using a PCE-based central controller on the network type and services being managed 🎀🌈
6. Manageability Considerations ✨
okay so this section is about the boring-but-important stuff, aka how you actually run this thing 💅 The architecture here is a management architecture, bestie. The PCE-based controller is a management component, and it controls the network through a southbound control protocol called PCEP 🎀
A PCE-based controller needs info about the network state, its nodes, and its links. Some of that is the TED, which is totally normal for a PCE and can be collected with the mechanisms that already exist, like listening to the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-encoded data [YANG-TE] from the network elements to the controller 🦋 More info can be collected in the LSP database for stateful PCEs, as described in [RFC7399] and [RFC8231]. If other specific use cases need extra info, that will have to be collected and passed to the controller too. That might need protocol extensions for the mechanisms in this paragraph, so keep that in mind 🧚
Different PCEP options and protocol extensions can affect interoperability, and that's a management issue, obviously 🙈 As noted in Section 4, protocol extensions should be done in a way that makes it possible to identify profiles of PCEP. Those profiles help with interoperability, and they make deployment and manageability way easier. Iconic behaviour, honestly 👑
[RFC5440] has a substantive Manageability Considerations section that looks at how a PCE-based system and a PCE-enabled system can be managed, so go read that too 🌸 Also, a MIB module for PCEP was published as [RFC7420], and a YANG module for PCEP has been proposed too [YANG-PCEP]. Very cute, very organised ✨
7. IANA Considerations 🌈
This document does not require any IANA actions. Zero registry drama, bestie 💖
8. References 📚
8.1. Normative References
The must-read ones, the foundations everything else stands on 🫶 Here's the full list, exactly as it's written in the document:
[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>.8.2. Informative References
These are the extra-credit reads, the context and the deep dives 🦋 Also copied exactly:
[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>.
[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>.
[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 fully acknowledge that prior work and thank everyone involved for opening the discussion. The individuals concerned are King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, and Zhenbin Li. Iconic shoutouts ✨
This document benefited from discussions within a small ad hoc design team. The members of that team 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 🎀 And Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful comments during IESG review, so they get flowers too 🌷
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.comAuthors' Addresses 🦋
The authors, in their own (verbatim) words:
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.comThat's the whole RFC, bestie! 🌈👑 We did it, we ate it, we left no crumbs 💅💖
📦 where this page comes from
- ietf: rfc8283 2017-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms