The Path Computation Element (PCE)

Introduction

Multi-Protocol Label Switching with Traffic Engineering extensions (MPLS-TE, Awduche et al, 1999) and Generalized MPLS (GMPLS, Mannie, 2004) provide the Traffic Engineering (TE) capability to forward traffic flows along explicit routes, namely Label Switched Paths (LSPs). The TE capability allows to perform path computation subject to additional QoS constraints typical of such networks, e.g., guaranteed bandwidth in MPLS networks, spectrum continuity constraint in optical networks. TE relies on resource availability and topology information collected through routing protocols, such as Open Shortest Path First with TE extensions (OSPF-TE, Katz, Kompella, & Yeung, 2003) or Intermediate System to Intermediate System with TE extensions (ISIS-TE, Li T. & Smith H. (2008). In LSPs provisioning, the path computation process represents one of the crucial steps to achieve TE objectives, including optimizing network resource utilization.

Within a given domain, the path computation is usually determined by the routing information collected at the head-end node, while resources are reserved during the signaling phase, exploited through distributed protocols, such as the Resource reSerVation Protocol with TE extensions (RSVP-TE, Awduche et al, 2011). The separation between the routing and signaling operations may lead to sub-optimal TE solutions generally inducing a waste of network resources. In optical networks, the impairment-aware spectrum assignment process, may introduce additional potential TE inefficiencies (e.g., worst case impairment assumptions). Moreover, distributed path computation may require heavy processing at each source (control plane) node, especially when based on multiple constraints. Moving from single-domain single-layer scenarios to multi-layer/technology, multi-vendor and inter-domain, additional issues arise, such as restricted topology visibility due to scalability reasons and/or administrative constraints among others. For example, when the source and destination of a traffic request belong to different administrative domains, the need to preserve operator- and policy-specific information confidentiality and integrity across domains prevents the open advertisement of detailed intra-domain network resources. Such limitations considerably complicate path computation and affect the inter-layer/inter-domain TE performance in terms of the overall network resource utilization.

The aforementioned path computation restrictions for provisioning end-to-end connections are at the basis of a significant research and engineering activity carried on in the last years and still active nowadays in the context of core network control plane developments.

The Internet Engineering Task Force (IETF) has proposed a set of techniques defined under the umbrella of the Path Computation Element (PCE) architecture (Farrel, Vasseur, & Ash, 2006). Such techniques rely on path computation, performed by dedicated network entities (i.e., the PCEs).

The PCE collects link-state information from network nodes and performs path computation on behalf of network nodes. In addition, it may resort to other information sources, such as the network management system (NMS), to retrieve detailed information about resource utilization or physical network parameters (e.g., link/span length and impairments in optical networks). The PCE provides the additional advantage that network nodes can avoid highly CPU-intensive multi-constraint path computations and effective TE solutions are achievable also in case of legacy network nodes. For example, NMS can be used as Path Computation Client (PCC) to communicate with PCE to get path information and then supply head-end node with full explicit path (e.g. using the management interface, like the TE management information base (MIB) module (Srinivasan, Viswanathan & Nadeau, 2004).