The top business drivers for the adoption of SDN technologies are reducing the TCO and enhancing elasticity and agility. In the context of the IP/MPLS WAN, the cost reduction can be achieved by the optimal usage of the network. It is a challenge for the service providers using IP/ MPLS networks to maximize the usage of the network at the same time ensure resiliency and meet the service level targets for various services. Without proper capacity planning and tools, some of them rely on overprovisioning which leads to idle bandwidth and thus high capex. Others try to utilize the MPLS traffic engineering as a strategic and tactical tool to optimize the network usage. But the challenge for them is the complex tasks of data gathering, LSP calculation and provisioning. Offline TE solutions may help to some extent, but they also lack mechanisms to dynamically adjust the LSPs according to the changes in the network and demands.

Following are some of the approached to traffic engineering path computation

Distributed online path computation

In the distributed online path computation, the path calculation is distributed to the routers in the network. Each router runs CSPF on the IGP TED and calculates the best path that satisfies the resource constraints. The result of the CSPF calculation is an ERO which is passed to RSVP for path setup. It is considered online as the routers can dynamically react to the changes in the network and demands.


This approach has certain disadvantages

Limited view of the network – The LSP is calculated from the viewpoint of the each router. It does not have the global view of the network, resources and demands from other routers.

Limited to single IGP area – Inter-Area and Inter-AS LSP calculations are not possible with CSPF as the information available in the TED is limited to single area.

Order of LSP setup is critical – Since the LSP calculation and setup is distributed, each router calculates and setup LSPs independent of each other which may result in some suboptimal LSP placement. The first routers to reserve the resources will successfully signal the LSP and the LSPs signaled later may not find sufficient resources. Even though setup and hold priorities can be used to ensure resources to high priority LSPs, it requires complex manual calculations.

Centralized offline path computation

In this approach the routers in the network do not calculate the LSPs. Instead it is done by a centralized offline TE tool. The data from the network is collected by the tool or exported to the tool through some means and the LSP path computation is performed offline. This approach offers several advantages compared to the distributed approach for TE LSP computation like global view of the network, creation of inter-area and inter-AS LSPs and support for complex algorithms and modeling. Some of the leading companies offering the solution are WANDL (Acquired by Juniper), Cariden (Acquired by Cisco), Opnet (Acquired by Riverbed) and Packet Design.


The major drawback of the offline path is that it is not dynamic. Any changes to the network topology, resources or demands will require updating the database and repeating the offline path computation which is time consuming

SDN and centralized online path computation

Most of the IP/MPLS WAN SDN controllers in the market utilizes centralized online computation based on Path Computation Element (PCE) architecture combined with IGP/BGP-LS for topology acquisition and PCEP/NETCONF for provisioning.

Topology acquisition

The near real-time topology acquisition is based on IGP or BGP-LS. Some of the SDN controllers run a virtualized version of their router inside the controller which can peer with the network using BGP-LS or IGP like ISIS or OSPF. The IGP peering can be direct or through a GRE tunnel. In the case of BGP-LS, the peering is with the BGP routers or route reflector in the existing MPLS TE network. The peering router extracts the TED and advertises them in BGP-LS updates. BGP-LS have several advantages over regular IGP peering including scalability and policy based control and also simplifies multi-area and multi-domain topology acquisition.

PCE Architecture

PCE – A Path Computation Element (PCE) is an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.

PCC – A Path Computation Client (PCC) is any client application requesting a path computation to be performed by a PCE

PCEP – The Path Computation Element Protocol (PCEP) enables communications between a PCC and a PCE, or between two PCEs


In an SDN environment, the controller acts as the PCE and the routers are the PCC. Active stateful PCE is used to maintain the LSP state synchronized with the PCC. The PCC can delegate LSPs to the PCE in which case the PCE has control over the LSP and its attributes. Certain features are limited based on the type of the LSPs

PCC controlled LSPs – These LSPs are configured and computed on the routers and PCE has no control over those LSPs

Delegated LSPs – These LSPs are configured and computed on the routers and later the control is delegated to PCE. PCE can modify the attributes of the LSP. PCCs have the option to revoke the delegation if needed.

PCE Initiated – These LSPs are computed by PCE and configured using the PCEP on the PCCs. PCEs have full control over these LSPs. While the PCC controlled and delegated LSPs maintains configuration on the routers, the PCE initiated configuration is transient and not shown in the router configurations

Use Cases

Dynamic topology acquisition, visualization and LSP reporting – SDN Controller graphically displays the network topology which it acquired through BGP-LS, IGP and PCEP. It also provides details of the LSP including attributes of nodes, links, SRLG groups etc.

Diverse LSP provisioning – SDN Controller is able to create diverse LSP between two pair of nodes as it has the global view of the network topology including link, node, SRLG and resource utilization.


Time based LSP scheduling – Using this feature, LSP can be scheduled in the future by using time based calendaring. This feature can be combined with constraints like bandwidth to create services like bandwidth calendaring which can be operator driven or even customer initiated from the customer portal and programmed through orchestrator and SDN controller

Maintenance Scheduling – If a node, link or SRLG needs to be taken out of the network for maintenance purpose, SDN controller can schedule a maintenance event by which it will reroute the affected LSPs just before the maintenance event is initiated. After the scheduled maintenance period is over, SDN controller will optimize the paths.

There are many other SDN use cases like multi-layer coordination and enhancements offered by segment routing which will be covered in later blogs