The original Path Computation Element Protocol (PCEP) work dates from the early 2000’s, with the first IETF RFC (4655) being made informational in 2006—which means PCEP predates the time when SDNs were “cool.” PCEP was originally, because of the increasingly complex nature of computing Traffic Engineering (TE) paths through (primarily), Service Provider (SP) networks. Three specific developments drove the design, standardization, and deployment of PCEP—

• The complexity of calculating TE paths across large, dispersed networks with a lot of different available paths
• The complexity of calculating TE paths across multiple organizations and internal network boundaries; for instance multiple flooding domains, multiple interior gateway protocols stitched together with BGP, or multiple BGP autonomous systems
• The complexity of computing TE paths through multiple levels of abstraction, such as computing an MPLS TE path on top of an optical path; this includes the difficulty of computing Shared Risk Link Groups (SRLGs) where a large set of virtual topologies cross a complex set of physical (primarily optical) links

The state necessary to compute TE paths in each of these situations is either very difficult, or actually impossible, to assemble in a single distributed control plane. All of these functions require some sort of overlay controller based network that has visibility into the entire network, including the physical through the application layers, and across administrative and failure domain boundaries.

If this set of requirements is starting to sound familiar, it should be; many of the SDN type overlays discussed in this series were created to solve some variant of this problem set. The figure below illustrates the components of PCEP.

There are four crucial components of PCEP shown in this diagram:

• The PCC is the Path Computation Client; this is the application or service that requests a new TE path be configured through the network
• The PCE is the Path Computation Element; this is the controller that has the overall view of the network, and computes the TE path through the network (normally using some form of Constrained SPF)
• The LER is the Label Edge Router; this is the head and tail end of the TE Label Switched Path (LSP) through the network
• The LSR is the Label Switch Router; these simply forward based on the labels as they are configured by the PCE using PCEP

In a single network (domain, or autonomous system), there may be multiple PCEs which may communicate in a number of different ways—for instance, PCEs may share topology information using a link state protocol, or BGP (particularly if BGP is carrying topology information through BGP-LS). There may also be one or more PCCs. PCEP is also designed to build paths across domains or autonomous systems; set of PCCs may communicate with one another to build a TE path across multiple provider networks, instructing local PCEs to set up the correct LSPs through each LSR along the path.

The way a TE path is normally designed in PCEP is each device is configured with a simple set of forwarding rules; any packet received with one label, say X, is forwarded out the indicated interface with a new label Y. This is exactly the same as any other MPLS technology that swaps the outer label at each hop.

PCEP, as a protocol, is highly tuned to the process of inserting the inbound label, outbound interface, and outbound label into the forwarding table at each LER and LSR. While PCEP does encode information into TLVs, there is no specific capability to insert filtering or traffic classification rules of any kind. It is assumed that the controller will be able to configure the LER to channel the correct traffic into the LSP head end in some way. It is possible, of course, to configure a label to be routed to the NULL0 interface, which effectively filters the packet stream, so it is possible to do some forms of packet filtering using PCEP.

There are drafts out there that extend PCEP to impose a label stack at the LER, rather than one (a single transport label) or two (an inner and outer label, with the outer label being used by LSRs to switch the packet through the network). This is primarily designed to allow PCEP to support Segment Routing; these extensions can be found in draft-ietf-pce-segment-routing.

Overall, PCEP is a narrowly focused southbound interface that predates the SDN craze. It is actually fairly widely deployed, particularly in large provider networks where there is a lot of overlap between network overlay TE paths and optical TE paths.

The next post in this series will begin the wrap up by examining the concept of a centralized control plane, which often goes hand in hand with Software Defined Networks—what does “centralized” really mean, anyway?