Michael Howard of Infonetics has written a great paper, entitled “The Evolution of SDN and NFV Orchestration,” in which he lays out a realistic vision of a hierarchy of controllers and orchestrators to solve the overall network control challenge. This blog discusses key takeways of this paper.
My main takeaways from this paper are two.
- Complex control systems that attempt to solve multidomain (and multivendor) networks must be modular and hierarchical in nature.
- There are two distinct types of orchestrators: service orchestrators and infrastructure orchestrators.
I already wrote about the need for a modular and hierarchical control system in an earlier post. This is a much more realistic approach than having a monolithic controller that controls multiple domains and vendors, or a federation of peer controllers that somehow control the network without a hierarchy.
In this post I’d like to focus on the second observation about the different types of orchestrators. It is important since I see some confusion as different vendors and their marketing machines are coming out with their variant of the “first ever multilayer and multivendor orchestrator.”
Paraphrasing Howard’s observation, there are two types of orchestrators (or more accurately, orchestration applications; the orchestrator itself is a piece of infrastructure that does not do much without the applications driving it).
- Service orchestrators are in charge of setting up and managing individual services in the network.
- Infrastructure orchestrators are in charge of configuring physical (and virtual) devices that make up the infrastructure.
This classification can be made a bit crisper by generalizing the second category as domain orchestrators that are in charge of managing one or more network domains as a whole in a way that is not specific to a single service. It also includes configuring devices, in addition to configuring the control plane of one or more network domains.
A service orchestrator is a system that receives a request for a new service, such as L3 VPN, an Ethernet connection, or an optical connection, and figures out how to set it up in the network in the most resource-effective manner, while meeting the needs of the customer (sometimes called “intent”). To this end the orchestrator figures out:
- Which domains the service should go through?
- How to route it to achieve the required constraints (e.g., max latency)?
- Whether to protect the service to achieve the required resilience
- Which functions should be chained together to implement the service (this is especially valid with NFV)
Once the service orchestrator determines how to set up the service in each domain, it talks to each of the domain controllers and actually sets up the service. Typically, the orchestrator is also expected to manage the services it has helped set up and to eventually take them down.
A multilayer service orchestrator allows to set up and manage services at multiple layers in the network; a VPN service will be set up in the routers, an Ethernet service in the Ethernet network, and an optical service in the optical network. There is no need for strong collaboration between these different layers, just a way of managing them through a single system (a.k.a. “single pane of glass”).
The value of a service orchestrator is mainly operational; it automates and simplifies complex processes and enables substantially faster service delivery.
There are many examples for service orchestrators from Tail-f (now Cisco), which focused on a service orchestration framework for L3/L2 networks, to Cyan (now Ciena), whose forte is Ethernet and optical service management, with special focus on a very intuitive user interface, to ALU’s Network Services Platform (NSP), which also seems to focus on service activation.
Domain orchestration is about increasing the effectiveness of the network by changing its overall behavior in a way that is not specific to a single service. For example, properly tweaking the link weights in an IP/MPLS network will cause the traffic to be more balanced and reduce congestion without having to configure each service individually.
In the context of multilayer networking, there are many examples of domain orchestration functions, such as the following.
- Informing the IP/MPLS layer of links that share optical resources so that it can setup truly diverse L3 services
- Rerouting optical paths so that the impact of a fiber cut on the IP/MPLS layer is minimized
- Modifying the IP/MPLS layer topology so that it better fits the current traffic (this is often called “router bypass”); see our ONS demo.
- Setting up optical restoration for IP links in a way that is suitable for the IP/MPLS layer (multilayer restoration)
All these functions improve the efficiency of the overall network by causing the layers to work better together. This saves hardware (and therefore CapEx, power, and footprint), improves availability, or simplifies operations, and often, all of the above.
Since these functions affect the network as a whole, they are valid not only for high-touch business services, but also for connectionless internet traffic, and therefore for the bulk of the traffic that is consumer based and cannot be handled by a service orchestrator.
Some partial examples of multilayer domain orchestration are Juniper’s Northstar controller and Cisco’s Evolved Programmable Network (EPN), however the only example of a full multilayer and multivendor domain orchestration solution that I’m aware of is Sedona’s own NetFusion platform.
A summary of the characteristics of these two orchestrator types in the context of multilayer networks is shown in the following table.
|Multilayer Service Orchestration||Multilayer Domain orchestration|
|Mission||Service activation inside each layer in a multilayer network||Improve efficiency by increasing the collaboration between layers|
|Examples||Cyan Blue Planet, Tail-f NCS||Sedona’s multilayer NetFusion platform|
|Value Proposition||Increase service velocity, operational ease of use||Reduce network cost, improve availability, operational ease of use|
|Functionality||Connection management, fault management, performance management||Optimization, restoration, multilayer mapping|
|Main Customers||High-end business services||Internet (consumer and over-the-top business traffic), high-end services|
Perhaps the most intuitive explanation of the difference is visual. Look at the diagram below and think of service orchestration as focusing on horizontal coordination between different nodes at the specific layer in which the service is provided. Whereas multilayer domain orchestrators focus on vertical coordination using information from one layer to affect the behavior of other layers with reduced focus on coordination inside each layer.
This diagram indicates that these two orchestration types are quite complementary and can coexist, as shown in the following figure.