ALL ABOUT MULTILAYER

Sedona's Blog

   

Share to Facebook Share to linkedin Share to Twitter Share to Google Plus

I will be discussing the requirements that multilayer control imposes on the northbound interface (NBI) of the Optical layer controller and the IP/MPLS layer controller. This unique perspective calls for some non-obvious requirements that have not been discussed so far in standard bodies (such as IETF and ONF) and open-source forums (such as ODL and ONOS) since these bodies have typically focused mostly on one layer or the other, but not on making both layers work together.

The detailed requirements from each layer controller can be found at Multilayer Requirements for NBI of Optical Domain Controllers and Multilayer Requirements for NBI of IP/MPLS Domain Controllers. So far we have shared this information with select equipment vendors, but I think it’s time to open this up for other entities building single layer controllers, be it system vendors or independent controller providers, and standardization bodies.

As discussed in my post about the different type of orchestrators, people refer to “multilayer control” in two senses. Here we focus on infrastructure orchestrators that deal with improved collaboration across the layers; the requirements for service orchestrators are being defined in the context of intent frameworks. Click here for a good explanation of intent frameworks.

So what are some of the non-obvious needs for a usable multilayer solution?

  • A detailed Optical layer topology: The various attempts to standardize an abstract view that looks at the whole network as a single switch or as a set of virtual connections do not give the multilayer optimization engine enough detail to make the right tradeoffs. Perhaps more importantly, they don’t give the operator enough visibility to trust the decisions made by the tool, and this is critical for real-world deployment.
  • IP/MPLS traffic measurements: Many multilayer control functions are about changing the IP topology, whether it’s about taking down links as part of coordinated maintenance or adding new links as part of network optimization. To assess the impact of such an operation, the behavior of the IP network needs to be simulated. This requires knowledge of end-to-end traffic.
  • IP/MPLS layer simulation: As previously mentioned, IP/MPLS layer simulation is necessary. It is best performed by a tool that is trusted by the service provider, and therefore we require an API to such a tool. This tool can be part of the IP/MPLS layer controller or separate from it. Either way, this is part of the IP/MPLS control system.
  • Optical layer feasibility calculation: This is the responsibility of the optical controller. There is no standard way of doing this, and all past attempts to force a common way to calculate feasibility have failed. Therefore, the optical controller must provide a way to trigger such a calculation over the NBI.
  • Physical IP ports: Some experts argue that since the IP/MPLS controller is an extension of the IP/MPLS layer control plane, it should only focus on IP/TE links and not on physical ports. But this concept breaks down when it comes to multilayer control. The router entity that ties the two layers together is the IP port.

Requirements for a Single-Layer Controller

Below I’ve summarized what functions we need from Optical layer controller and from an IP/MPLS layer controller. This is just a high level list; the details can be found at Multilayer Requirements for NBI of Optical Domain Controllers and Multilayer Requirements for NBI of IP/MPLS Domain Controllers.

Let’s start with requirements that are needed forany single-layer controller in order to maintain an up-to-date view of the topology.

  • Get the network topology, namely, the nodes and the links between them
  • Get the relevant physical ports – especially those connecting between the layers
  • Get the existing connections (lightpaths, LSPs, etc.) and their paths in the networks
  • Asynchronous events reflecting changes and failures in the network

In addition, some specific requirements from the Optical layer controller are needed for managing optical connections and understanding their feasibility.

  • Compute feasible optical paths without setting them up
  • Set up new connections with path constraints, taking into account optical feasibility
  • Define optical restoration properties for connections

From the IP/MPLS layer controller, we need to understand IP/MPLS traffic conditions, manage IP links over optical connections, or more specifically, to do the following.

  • Get the reserved and actual bandwidth for an LSP
  • Get the end-to-end IP traffic matrix
  • Add an IP link and configure its properties
  • Cost out an IP link
  • Simulate IP/MPLS layer behavior under link add/remove operations

This relatively limited set of functions allows us to provide a plethora of multilayer applications: from a multilayer visualization tools, to multilayer optimization and restoration, to various operational tools designed to achieve better coordination between the teams operating the different layers.