Path Computation

A fundamental aspect of GMPLS routing is the path computation process. To this purpose, the IETF PCE WG defines architectures and protocols for path computation. Path computation manages aspects related to finding a physical route between two network nodes, commonly referred to as endpoints. Path computation is a functional component of a control plane, invoked for (dynamic) provisioning, re-routing, restoration, as well as advanced use cases such as overall optimisation, adaptive network planning or, in the case of DWDM flexi-grid networks, spectrum de-fragmentation. The Path Computation Element (PCE) framework in [23] outlines two main components: the Path Computation Client (PCC) and a Path Computation Element (PCE). Consider the PCC is the initiator of a path computation request, while the PCE is responsible for computing the end-to-end network paths, using a set of constraints and objective functions that may be minimised, maximised, include or exclude.

The PCE will operate looking at topology and Traffic Engineering (TE) information, via a Traffic Engineering Database (TED), for network domain it is responsible for. Extensions to the PCE exist for end-to-end inter-domain path computations, which are then performed through the cooperation of multiple PCEs.

The Internet Engineering Task Force (IETF) PCE WG specifies different models for inter-PCE cooperation in multi-domain scenarios. Firstly, the “crankback”-based Backward-Recursive PCE-based Computation (BRPC) procedure follows a peer-to-peer approach [40]. Alternatively, a hierarchical model specified in [41] called Hierarchical PCE (H-PCE) introduces the concepts of a “Parent” and a

37

“Child” PCEs: the parent PCE oversees the coordination of an end-to-end path computation operation. This would be based on abstracted views of the transit inter-domain topologies, provided by the cooperating with child PCEs (i.e., the management entities responsible for the internal transit domain path computation.

The PCE communication Protocol (PCEP) is the protocol regulating the interaction between PCC and PCE, or between different PCEs. It is initially defined in [24] and extended in several RFCs and IETF Drafts in support of advanced features, including point-to-multipoint services (such as video) [42], and Global Concurrent Optimization [43] to defragment resources, and network path computation in MLN- MRN environments [44].

The two main PCE models for computing end-to-end transport paths have been defined and standardised for multi-domain computation: BRPC and hierarchical PCE. The next two subsections provide a brief overview of both types of path computation.

2.5.1.1 Backwards Recursive Path Computation

The multiple PCE computation models, where different PCEs cooperate to compute the end-to-end path in multi-domain scenarios, allows limiting the flooding scope within each domain. Following this approach, each PCE has visibility only on the topology of its domain, and inter-domain flooding or neighbour domain knowledge is not required or generally available. For network scalability, a single PCE does nor have visibility of other domains, and therefore unable to compute a path that crosses any transit domain. It must communicate with other PCEs in order to obtain intra-domain path segments that can be combined to provide an end-to-end path, or an engineer must manually stitch together a path, which often takes days to design.

The current Backward Recursive PCE-based Computation (BRPC) mechanism is typically used to automate inter-domain transport paths across a predetermined sequence of transport domains, that must be identified by the operator.

2.5.1.2 Hierarchical PCE

The hierarchical PCE model is a more recent method for the multi-domain path computation problem that the BRPC mechanism described above solves. One of the earliest heuristics and procedures for inter-PCE cooperation, facilitating calculation of an optimum end-to-end path without operator engineers having to define which transit domains should be used, i.e., requiring a-priori known domain path. This model is defined in and is characterised by a hierarchical relationship between domains, each of them controlled by an H-PCE (or “Parent”, also known as the broker PCE, with domain topology knowledge and policy rules for domain transport.

2.5.1.3 Impact of PCE within Software Defined Networks

SDN Is emerging as an extensible and programmable open way of operating networks. Its main concept is the decoupling of forwarding and control functions, centralising network intelligence and state information while providing to the upper layers an abstracted and vendor independent view of network state and available resources through well-defined or documented open Application Programming Interfaces (APIs). Compared to prior technologies, SDN allows network providers to build more scalable, agile and easily manageable networks. This resource abstraction, via a software layer, of the physical network facilitates “network programmable” resources.

If we agree SDN supports programmability of the network path by decoupling the data plane and allowing the removal of a distributed control plane (previously required on all forwarding nodes), which are currently integrated vertically in most network equipment’s. Separation of control plane and data plane functions, then SDN becomes the underlying principle of heterogeneous technologies

38 for a variety of transport types (e.g. optical layer, carrier Ethernet, and other traffic engineered technologies) and administrative regions.

SDN can abstract the heterogeneous transport technologies employed in the data plane and represent them in a unified way, under the umbrella of a centralised control plane. Well documented open standards, vendor and technology agnostic protocols and procedures will be needed for the SDN controller to communicate with a wide range of devices (“open” or proprietary hardware), in the data plane. These requirements established OpenFlow [8] as the de facto protocol for early SDN deployments.

In this context, the PCE architectures natively offer a solution to decouple the path computation from the forwarding plane, also providing an open standard protocol instead of using OpenFlow. This opens wide opportunities for integration of PCE in an SDN controller pre-imbued with a diverse set of control plane path computation and traffic engineering capabilities even beyond its original MPLS/GMPLS scope, with SDN. On the one hand, PCE can offload path computations to dedicated engines/elements with the aim of assisting SDN controllers for their base services, while natively providing mechanisms and procedures for cooperation among diverse PCEs in multi-domain transport scenarios [46]. The integration of PCE within SDN allows operators to utilise well-defined and well-documented routing and traffic engineering algorithms developed in the scope of PCE for SDN purposes, thus not wasting solid expertise and knowledge (e.g. from network operators) in the PCE area. These PCE models are discussed in “A Survey on the Contributions of Software-Defined Networking to Traffic Engineering”

[47].

Numerous PCE and SDN integration models exist, and depending on the specific needs and PCE capabilities available: path setup for point-to-point services, multipoint or point-to-multipoint. While a stateless, stateful, or active stateful PCE may be an external application of the SDN controller, it would utilise LSP information exchanged through a dedicated set of controller northbound APIs. A stateful PCE with LSP initiation (based on application demands or in response to changing network conditions) this capability itself becomes itself a kind of controller application. Moreover, a PCE might be used to manage SDN resources for network virtualisation.

In summary, the PCE is an extremely powerful functional component with three key architectures, a wide variety of applications and use cases. It also has an extensive set of well-standardised extensions developed by the IETF. Therefore, it is likely to play a key role in the development of transport network control platforms for future networks.