Service Provider Transformation
Juniper Employee , Juniper Employee Juniper Employee
Service Provider Transformation
The Relationship between Multi-Layer Optimization & Multi-Layer PCEs
Jul 13, 2016

Introduction

In this Northstar related Blog installment we will discuss the need to directly exchange several pieces of critical information between an optical ‘controller’ and a packet ‘controller’ to deliver several use-cases that could be referred to as multi-layer optimization.

 

First let’s quickly review the behavior of an IP/MPLS network as it pertains to the use-cases that will be discussed.   IP/MPLS networks are very dynamic in their operation and behavior.  Not only do they autonomously detect and adapt to changing traffic patterns, in real-time, they also adapt to changes in the underlying transport system that is responsible for delivering the connectivity services from router interface to router interface over a Wide Area Network (WAN).  It is this dynamism and adaptation that has enabled IP networking to become the predominant transport technology for communication systems in the past decade.  

 

While SDN initiatives have introduced more centralized forms of control and management of IP/MPLS networks, these ‘controllers’ operate in such a way as to add predictability to the behavior of IP/MPLS networks while not interfering with the autonomous behavior and adaptability of such systems.  The role of the controller is to participate in the control-plane of the network to address challenges such as predictability while enabling new forms of path computation and control that would otherwise be challenging or near impossible in a fully distributed system.

 

Proposed Architecture

We suggest a direct communication channel between the Controller of the optical system and the Controller of the packet system as shown in figure 1 below.  This communication channel provides a means of exchanging relevant information so as to enable each domain specific controller to optimize the services for which it is responsible.  The data [information] exchanged should be in the form of a common language or data-model that can be used as a trusted source of relevant and real-time domain specific analytics.  The relevant data-model is described in [yang-abstract-te-topo].  The architecture associated with the propagation of this information must not impede technology deployment in either layer.

 

ciecn-f1.png

 

                                                   Figure 1: abstract-te-topo exchange between controllers

 

The IP/MPLS Network Controller

The primary goal of the IP/MPLS Controller, or Juniper Northstar TE Controller, is to compute optimal paths for LSPs given a set of per LSP constraints.  Constraints such as available bandwidth (BW), set-up and hold priorities, maximum path hop-count, link inclusion or exclusion, maximum path delay, secondary/standby protection and path diversity are just a few that must be considered.  As alluded to above, the routing of these LSPs takes place in real-time where the time scale is on the order of 100’s of milliseconds for 10’s of thousands of LSPs across a network.  It is therefore essential that any underlying changes within the transport network be propagated to the IP/MPLS controller as quickly as possible so as not to result in path computations that inadvertently violate a critical constraint.

 

If we consider the consumption of data directly from an optical controller, as depicted in figure 2 below, several new types of LSP routing methods are enabled thus resulting in multi-layer awareness for an IP/MPLS Controller.

 

ciena-f2.png

                                   Figure 2: Consumption of the abstract-te-topology by an IP/MPLS Controller

 

As optical networks become more dynamic and new technologies are introduced and deployed it is becoming more and more important for transport layer specific information to be propagated to the IP/MPLS client-layer(s) so that changes in the transport layer that could effect service level agreements (SLAs) and thus the constraints associated with the routing of LSPs can be accounted for expediently.  There are several immediate use-cases that are available:

 

  • Diverse routing of LSPs: Accurate diversity is accomplished by learning about common Shared Risk Link Groups (SRLGs) of client-layer links directly from the transport layer. This enables the computation of secondary/standby LSPs along with the wholly diverse routing of 1 or more pairs of LSPs possible without manual configuration of static SRLGs in the packet network.  Manual configuration leads to long delays in the propagation of information as well as introduces the risk of inaccuracies due to the changing dynamics of the transport network in the event optical protection or restoration are used.

 

  • Maximally protected routing of LSPs: A new link attribute is available that enables LSPs to be routed along a set of client-layer links that are protected within the server-layer. This benefits the IP/MPLS network by ensuring that LSPs that traverse optically protected links need not also be protected within the IP/MPLS network.  Enabling more efficient use of back-up resources.

 

  • Minimum delay routing of LSPs: Delay has historically been imbedded in the TE metrics, statically, of IP layer links thus enabling path computations to infer the delay of the transport layer. However, as mentioned above, as transport layers become more dynamic it is essential to be able to modify this dynamically thus ensuring that a delay specific SLA is met.

Note: What is described in the above section is supported in the Northstar 2.0 software release

 

The Optical Controller

An Optical controller also has many domain specific responsibilities and an ideal place to implement those functions is with in a software entity of the Optical controller including the routing of circuits across the transport domain.  Much like the best place for the computation of paths of LSPs reside within the IP/MPLS controller.  The domain specific optimizations may vary and will certainly evolve over time; it is therefore important to develop an architecture that enables that evolution with as few dependencies as possible.

 

The data-model described in [abstract-te-topo] allows a Packet Controller to share it’s domain specific attributes with the Optical controller as depicted in figure 3 below.  Attributes of client-layer links include such items as TE-metric, color, maximum reservable BW, current reserved BW, and protection to name just a few.  Let’s consider a use-case, protection within the transport layer that could be enabled keeping in mind several of the attributes of IP/MPLS networks mentioned above:

 

ciena-f3.png

 

                                     Figure 3: Consumption of the abstract-te-topology by an Optical Controller

 

As previously mentioned, an Optical Controller can convey that a link is protected to an IP/MPLS controller.  However, it might be more efficient if the IP/MPLS controller requested protection and the Optical Controller attempted to meet the request since protection SHOULD be a function of the services a link is carrying.  As noted above, the amount of data a client-layer link carries may vary quite dramatically on a relatively short time scale.  Therefore, a request for protection can and should change accordingly.  Also, since IP/MPLS links carry multiple services, it is important to have a clear picture of what LSPs actually need protection or may already have protection within the IP/MPLS network.

 

The following deployment scenarios could be considered:

 

  1. The IP/MPLS controller simply decides what links it should explicitly request protection for and possibly even what kind of protection.
  2. The IP/MPLS controller ‘sends’ all and/or class specific data to the Optical Controller and it is the responsibility of the Optical Controller to decide what to do with the information according to a policy.

Both of the above deployment scenarios refer to a ‘policy’ by which protection could be requested.  There are several kinds of policy under consideration:

 

  1. Protection based on client-link global utilization: Any link with greater than 50% utilization the IP/MPLS controller should request restoration or protection services for.
  2. Protection based on class specific client-layer utilization: The protection and restoration policy may be "Class of Service" specific and dependent on how much high priority traffic is traversing the link(s).
  3. Protection based on the number of transit LSPs a link may carry: A single IP/MPLS link may carry 10’s of thousands of LSPs while another may carry just a few. 
  4. Variations and combinations of the above policies.

Depending on the use case, the Optical domain may need more or less frequently updated usage information. There are many events that occur within an IP/MPLS network that would result in changes to the link utilization of the number of LSPs that traverse a link.  To satisfy this demand in a flexible manner the following policies should be considered.

 

  1. Initial IP/MPLS event delay: Delay after an IP/MPLS event that the Packet Controller waits to update the Optical Controller
  2. Link utilization change threshold: Threshold by which the link utilization changes that triggers than update.
  3. Consecutive event wait time: Wait timer between consecutive IP/MPLS layer events.

Once the optical controller has established efficient restoration and protection schemes, the new scheme should be acknowledged using the [abstract-te-topo] data-model.  Thus this simple real-time bi-directional information exchange enables domain specific optimization(s) that can satisfy inter-domain constraints efficiently.

 

The Role of an Orchestrator

It’s hard to go a day without seeing a picture of network clouds, controllers and an over arching orchestrator serving as a controller of controllers, as depicted in figure 4 below.  However, it’s rare to see a complete description of what said orchestrator should do.  While it is beyond the scope of this paper to describe the breath of services this orchestrator may or even should provide, we will present a few suggestions as they pertain to this multi-layer proposal.

 

ciena-f4.png

 

                                                     Figure 4: Orchestrator within a SDN Controlled Network

 

In the “The Optical Controller” section of this paper, we introduced several details associated with coordinating policies between Optical and Packet Controllers and while the ideas were presented briefly, they could result in complex policies that must be coordinated between controllers.  There also is the task of telling one controller to talk to another controller and vise a versa.  Both of these tasks could be greatly simplified if they were handled by some higher layer controller or orchestrator thus allowing an operator to define only policy, e.g. EF-class LSPs must be protected with a 50sec SLA while BE-class LSPs must be protected with a 10 minute SLA, and of course which controllers should publish to data to which other controllers to enforce such policy.  The orchestrator can or may also provide a high level “single pane of glass”.

 

This proposal attempts to define clear and simple roles for domain specific controllers that result in efficient and highly scalable work-flows for the emerging topic of Multi-Layer Optimization.  The proposed architecture results in a more flexible/modular solution than the classical hierarchical picture with no controller-to-controller communication.  Enabling each controller to function as a standalone entity or as a cooperative system. The controller-to-controller communication brings significant enhancements, but does not result in breaking everything if it is not present.

 

References

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

 

Related Blogs

http://forums.juniper.net/t5/SDN-and-NFV-Era/Northstar-Multi-Layer-PCE-Demonstration-and-Interoperab...

 

http://forums.juniper.net/t5/SDN-and-NFV-Era/A-Multi-Layer-PCE-using-a-Controller-to-Controller-Inte...