The term “orchestration” is used frequently in discussions about Network Functions Virtualization (NFV). What does orchestration mean for the cloud data center? What additional requirements are imposed by NFV?
What additional requirements do we get when we add NFV to the mix?
The first difference is span of control. Traditional orchestration solutions are focused on resources within the data center. Carrier NFV will be used to build carrier services across the network, and orchestration must support those additional network elements and requirements.
Orchestration in the data center is simplified by the homogeneous nature of the physical and virtual element. Adding the hodgepodge of metro equipment to the mix makes the problem harder. I saw a great tweet on this point the other day from Gabriel Brown (@Gabeuk) that said “NFV is pretty much akin to rebuilding your house while you’re living in it.” I believe that the network is going to evolve, so we can’t scrap the old stuff and start over. We have to solve this problem.
Resources Have Variable Cost and Variable Value
In a data center, the resources are all equivalent. The available interconnect bandwidth is high, and the corresponding latency is low. There is usually a large pool of each type of resource, so the cost of any given resource is low and uniform. These facts simplify the selection and assignment of resources.
With NFV we may be adding resources in a central office, point of presence or even at the customer site. The resources in these sites will necessarily be limited, so their cost is high relative to those in the data center. However, their proximity to the customer means that their value may be relatively high for some applications. Why? Two reasons:
Orchestration for NFV must take into account the variable costs and values of resources and optimize the use of these elements versus the requirements for the given service.
There is some tie-in of data center orchestration into other systems, but these are often standalone scripts. In contrast, orchestration for NFV must tie into higher-level systems. As shown in the figure at the right, the orchestration may need to tie into the service provider’s OSS systems for operation, policies and/or billing. The orchestrator may instead need to tie into an intermediate level of network applications or higher-level service orchestration. In either case, the need for open APIs is clear.
One of the great benefits of cloud applications is that they are horizontally scalable or “elastic”. Services built using NFV must also be elastic, and this means the components must be built accordingly. They can’t be simple re-compilations of the software to run on a server instead of an appliance.
An appliance has a fixed size and capacity, and its software is designed and optimized for that capacity. In moving from an appliance to a virtual environment, the software needs to be decomposed, analyzed and recomposed to achieve elasticity.
Another reason for the success of cloud services is the on-demand, pay as you go model. Operators want this same benefit from services built using NFV. When moving from an appliance to a virtualized implementation the supplier also needs to revisit their licensing model in order for the overall service to meet its goals.
First, it is important to distinguish between multi-tenancy and virtualization. From Wikipedia: Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client-organizations (tenants).
Compare this with virtualization where components are abstracted enabling each customer application to appear to run on a separate physical machine.
While the isolation and encapsulation of virtualization is important for NFV, it may be a drawback for orchestration. For orchestration, multi-tenancy simplifies system design and integration into higher level systems, while providing and enforcing the needed separation between the various users (tenants) of the orchestrated services.
Comparison of Cloud Data Center and Carrier Class Orchestration
The table below shows a summary of the contrasts discussed in this blog.
About the Author
Prayson Pate is Chief Technologist and co-founder at Overture. Prayson is a technology evangelist with a proven track record leading teams and delivering products. Since 1983 he has been building Carrier Ethernet and telecom products for service providers and network operators around the world – both as an individual developer and as a leader of development teams. Prayson spends much of his time driving adoption of Overture’s new Ensemble Open Service Architecture, which includes aspects of automation, virtualization, SDN and NFV. He has a BSEE from Duke, an MSECE from NC State and is the holder of nine US patents.
Follow Prayson on twitter: @praysonpate
Contact Overture to learn how you can increase profitability by transforming service delivery.
Copyright © 2016 | All Rights Reserved | Overture Networks