Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
A Multi-Layer PCE using a Controller-to-Controller Interface
Aug 31, 2015

Introduction and Goals

 

This Multi-Layer solution provides a packet-layer Path Computation Element(PCE)[1] (e.g. the NorthStar Controller) with an abstracted view of an underlying transport network to facilitate better or more optimal input for its [packet-layer PCE] applications, such as a path diversity applications. The abstracted view of the transport network will provide enough relevant information about an under-lying transport network to improve and expand the NorthStar Controller’s packet centric applications. The solution is not aimed at providing so much information as to allow the NorthStar Controller to compute paths for the transport domain. Computing paths within the transport domain requires layer specific topology and resource information; this information may not be available or may not be usable, even if available, because of various reasons for example; technology considerations such as proprietary information, scaling considerations, and security considerations. The relevant topology information comes in the form of a YANG based data-model[2] exchanged between layer specific applications/controllers via a RESTCONF[3] or REST[4] interface. The YANG data-model describes the transport network in the form of an abstract Traffic-Engineering(TE) topology. This exchange of topological information can, ultimately, provide support for the following high-level packet-layer use-cases: 

 

  • Multilayer network visualization: Visualization of the path a packet-layer link takes across the transport layer.

 

  • Dynamic and real-time exchange of Shared Risk Link Groups (SRLGs): The shared fate of packet-layer links are learned from the transport-layer allowing a PCE to leverage this information for its routing of LSPs.

 

  • Multilayer coordinated maintenance: Planned events in the transport-layer can be scheduled within the packet-layer allowing the PCE to proactively reroute LSPs.

 

  • Fault correlation: The PCE can react to specific types of failures, e.g. the failure of the access-links, differently and based on global policy.

Most importantly, the solution gives the packet-layer an awareness of events within the transport domain and enables the building of specialized applications to leverage that awareness. The figure below shows a high-level picture of the solution.

 

 MLO-PCE.png

Figure 1: Multi-Layer PCE Solution Overview

 

Operation

 

The Yang data model, mentioned above, is used for representing, retrieving and manipulating "Traffic-Engineering (TE) Topologies". Some of the salient aspects of this data model include the following:

 

  • A technology agnostic method of describing TE-links and TE-nodes and their attributes

 

  • Overlay and Underlay relationships of the TE-nodes and TE-links providing a useful representation of hierarchical TE Topologies

 

  • Customized TE Topologies: The notion of "TE Topology as a service" e.g. A transport provider can present its network in abstract TE terms on a per client basis

The packet-layer PCE obtains the transport topology from the transport-layer controller by sending a GET request. This will result in the retrieval of the complete abstract TE topology. The NorthStar Controller will consume the topology and connectivity matrix to produce circuit information, and update its topology database to form an abstract-layer network model. Subsequent updates to the topology, via incremental updates, leverage a PUSH model through a notification subscription model. Individual TE-links and TE-nodes may be updated but also may be created and or deleted with in the framework. Figures 2 and 3 below show example workflows for full topology learning and incremental updates between the packet-layer and transport-layer controllers.

 

 MLO-pict.png

               Figure 2: Initial topology                         Figure 3: Incremental topology

                      Synchronization                                              updates

 

Comparative solutions

 

This solution provides value over other possible alternatives, such as leveraging GMPLS extensions for Inter-layer control[5], in that it supports and maintains the relatively different architectural and philosophical differences between transport networks and IP/MPLS networks. Allowing service providers to maintain the “boundaries” between domains while at the same time addressing the challenges associated with multi-layer coordination and end-to-end services.

 

There is no transport-node to packet-node protocol interoperability needed and no requirement for mass software upgrades within either the transport or IP/MPLS-layer networks. The separate domains can continue to evolve according to the domain specific technology curves they are accustomed to. Further, packet-optical architectures such as moving specific optical components into the router can easily be supported without disruption to the over-all solution.

 

References

 

[1] http://datatracker.ietf.org/doc/rfc4655/

[2] https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-01

[3] https://tools.ietf.org/html/draft-ietf-netconf-restconf-06

[4] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

[5] http://datatracker.ietf.org/doc/rfc5623/