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 a 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 using the traditional per-hop approach, which may cause performance issues.

It’s in this context that we need to look at the PCE. To define a 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, a PCE can be an external server application or even a network component such as the headend router.

Why PCE?

In IP/MPLS networks, 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 TE Database (TED), which holds the topology and resource information of its domain.

A PCE allows for faster updating of path computation policies, reduces costs, and provides the ability to move away from path computation algorithms that are hardcoded into router vendor hardware. Perhaps more importantly, the 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 IGP areas or another Autonomous System. 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 the Path Computation Element Protocol (PCEP).

PCE architecture components

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.

TED: A collection of information about the topology of the network, its nodes, links, and relationships, and the details of resources and their attributes.

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 path within its IGP area without collaborating with other PCEs, or multiple PCEs can collaborate to compute a single path.

In addition, a PCE can be stateful or stateless. A stateful PCE is aware of the Label Switched Paths (LSPs) 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. On the other hand, a stateless PCE does not remember any computer paths. It processes each path request as a new and independent request.

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 the PCE has helped you understand what it is and its role in TE. Blue Planet Route Optimization and Analytics (ROA) comes with a built-in PCE and PCEP support to automate path calculation and provisioning, ultimately helping service providers increase service agility, decrease churn, and reduce costs.