A Quick Start to Path Computation Element (PCE)

With more and more network operators looking at MPLS-TE for Traffic Engineered (TE) networks and with the increasing adoption of SDN, it is about time that Path Computation Element (PCE) is more widely adopted in carrier networks. Here’s a look at what Path Computation Element is, how it works, and its benefits.

IP/MPLS network operators depend on TE to optimize their networks and quickly provide new service offerings using existing network infrastructure. MPLS TE uses source routing, where an ingress headend router determines the source to destination path for a specific traffic flow based on an application’s demand (e.g., QoS) and the constraints of the network (e.g., bandwidth availability or minimal jitter and latency). This allows the application traffic to be sent through underused paths rather than use the traditional per-hop approach, which may cause performance issues.

It is in this context that we need to look at PCE. To define PCE in the simplest of words, it is an entity that is capable of computing a suitable network path for transmitting data between a source and destination by applying computational constraints. Here, PCE can be an external server application or even a network component such as the headend router.

Why PCE?

As we explained in our Traffic Engineering blog posts the headend router computes the path for traffic based on the demands of the network. But this also comes with its share of issues. There can be instances where the headend router or the network device computing the path does not have a powerful enough CPU to compute complex path requirements or enough memory to maintain a large Traffic Engineering Database (TED), which holds the topology and resource information of its domain.

Path Computation Element (PCE) allows for faster updating of path computation policies, reduces costs, and provides the ability to move away from path computation algorithms that are hard coded into router vendor hardware. Perhaps more importantly, PCE addresses TE limitations in large, multi-domain networks where path computation is complex due to TE’s limited visibility into neighboring domains, such as another Autonomous System or neighboring IGP areas. An external path computation server addresses these issues by using dedicated hardware for path computation, and a PCE can be designed to work with other PCEs for a global view of the domain and inter-domain routing requirements. See RFC 4655 for other reasons that led to the design of PCE.

PCE Architecture Components

Path Computation Element (PCE): The functional component that performs complex path computations based on traffic demand and network constraints.

Path Computation Client (PCC): A client application or component requesting a path computation to be performed by the PCE. The PCC can be a network node, such as the headend router along an MPLS-TE path.

Traffic Engineering Database (TED): This is a collection of information about the topology of the network, its nodes, links and relationships, and the details of resources and their attributes.

Path Computation Element Communication Protocol (PCEP): Defined in RFC 5440, this is a TCP-based communication protocol the PCC uses to communicate its path and resource requirements to the PCE. It is also used by the PCE to reply to the PCC and between PCEs when they need to communicate with each other.

Path Computation Models

Centralized Path Computation: All path computations for a domain are performed by a single, centralized PCE.

Distributed Path Computation: Multiple PCEs are deployed in a domain, and path computation is shared between these PCEs. This model can have a single PCE computing paths within its IGP area without collaborating with other PCEs, or multiple PCEs can collaborate to compute a single path.

In addition, PCE can be a stateful PCE or a stateless PCE. A stateful PCE is aware of the label switched paths (LSP) in the network when processing new requests from the PCC. It retains information about the paths it previously computed or gathers information from the network by using PCEP or BGP-LS with extensions. In this way, a stateful PCE can do more intelligent path computation. A stateless PCE on the other hand does not remember any computer paths. It processes each path request as a new and independent request.

How PCE Works

When a PCC needs a path to reach another network, it establishes a TCP connection with the PCE. A PCEP session is then established on top of the TCP connection, and session open messages are exchanged. After a session has been established, PCC uses a PCReq message to request a path to the PCE. The message includes the source and destination of the traffic and path constraints, such as bandwidth required, nodes to be excluded, and other requirements of the traffic and the path. The PCE then replies to the PCC with the computed paths or with a reject reply that conveys why the path could not be determined. The PCE can also collaborate with other PCEs if needed to compute an end-to-end path traversing multiple domains. At any point, a PCEP session can be closed by any of the participating peers (PCE or PCC) by sending a close message, upon which the PCE and PCC clears all pending requests and closes the session. With the path computed by the PCE, the headend router can now send traffic to its destination meeting TE requirements of the network.

Hopefully, this introduction to PCE has helped you understand what it is and its role in Traffic Engineering. The next blog in this PCE series looks at the role of PCE in SDN networks. Meanwhile, let us know about your experiences with PCE.