2014 was a year full of PoCs and limited trials for SDN and NFV. These activities were important steps for the industry as network operators try to understand the operational impact of moving toward network virtualization.
PoCs and trials teach all of us important lessons. Should VNF placement be centralized or distributed? What role does OpenStack play vs. the orchestrator? What is the commercialization model? Why is deterministic placement important for VNF performance? At the end of the day, those of us in the trenches are learning quite a bit from these engagements with operators and other vendors.
And through all of these activities, it has become to clear to our customers, and to us, that the multi-domain and multi-vendor orchestrator plays the key role in service deployment and revenue attainment. There are a number of different organizations and schools of thought on how to characterize and define orchestration. Cyan participates in all the major standards and industry initiatives and strive to provide an interoperable solution that will satisfy the needs of our customers.
The ETSI Model
One model for orchestration is defined by ETSI, which is a service provider, led initiative. Cyan is supportive of and compliant to the ETSI model, but has a flexible architecture that can respond to unique customer requirements and future standards if required. For the sake of this blog, we’ll use the ETSI model to describe functions:
- NFV Orchestrator (NFVO): Responsible for on-boarding of network services and Virtual Network Functions (VNF), service lifecycle management, global resource management and so on.
- VNF Manager: Responsible for overseeing lifecycle management of VNF instances; coordination and adaptation role for configuration and event reporting between NFVI and E/NMS.
- Virtualized Infrastructure Manager (VIM): Responsible for managing the NFV infrastructure resources such as compute, networking and storage.
Role of the Orchestrator
We often see that the role of the NFV orchestrator is commonly confused by many with cloud management systems such as OpenStack, which really provides the VIM functionality. This confusion may result in questioning why there is need for anything other than OpenStack. The simple fact is that OpenStack is a cloud management system and an infrastructure abstraction and management tool, but not an orchestration solution for the following reasons.
1. OpenStack is meant to be a broad, virtualized infrastructure manager that is not necessarily tailored to all the needs of a specific industry. OpenStack enables tenants to share resources in a cost effective and scalable manner all the while it abstracts out the complexities of the underlying infrastructure.
2. Most importantly, a service provider trying to operationalize NFV implementations and drive services revenue will need to dynamically and automatically scale network functions, optimally place them on servers based on available compute and desired performance, take care of complete life-cycle management (not just turn the service turn), provide geographic redundancy (spanning multiple locations) be mindful of VNF related dependencies and try to chain the virtual resources over a WAN so that end users can connect to such applications in a reliable and consistent manner. These are all provided by the NFV orchestrator, not the VIM.
From this, a clear definition for NFV Orchestration evolves to include:
- Awareness of and control over both virtual and physical resources
- Provide resiliency and redundancy for services provisioned
- Provide continuous monitoring, alarm correlation and OAM/FCAPS
- Connect data center virtual functions to users over a multi-vendor WAN
- Take corrective action against VM and thread failure
- Provide automated complete life-cycle management of services
- Connect distributed resources to provide a multi-domain service
An alternative option to using an NFV orchestrator is to glue a number of disparate scripts using DevOps tools such as Chef and Puppet. To make this work, a full-staff of coders would be required that not only excel at OpenStack but also understand service provider product offerings and infrastructure. This team would also need to provide around the clock support to ensure that failures are addressed and to assure there is minimal disruption in service. This is an inefficient and expensive model available to only the largest operators paying for large internal development teams or outsourced software integration services.
The best case for operationalizing NFV is to use a standards-based, programmable NFV orchestrator. It should be template based and data driven following industry standard modeling languages and interfaces that can address all of definitions outlined above. None of which fall into the capabilities of a VIM. Ultimately, the end goal of the orchestrator is to enabling service providers to efficiently deliver next-generation services that stich together the virtual resource with the physical infrastructure – from data center, across the WAN, to the end location.
Specifically, an orchestrator will provide service level orchestration by taking the service order, mapping it to a service model and decomposing the top-level request to lower level mini services that may span multiple domains such as multiple data centers, multiple virtualized infrastructure managers, a multi-vendor WAN structures, optical underlays a well as IP based overlays.
The multi-domain and complex nature of many operator networks mean that the orchestrator will need to organize and collaborate with multiple and federated controllers to deliver a seamless service to the end user. The orchestrator can map service models to lower level models and functions based on the infrastructure and controllers at its disposal. Once the top level service, such as “turn on a virtual firewall and router for customer X” is placed, the orchestrator will decompose it to smaller functions and push these functions as well as requirements down to the lower layers. Of course, to do so, the orchestrator should be able to gather information about the infrastructure such as topology, connectivity, capability and so on. In this particular case, the orchestrator may rely on OpenStack, VMWare or Docker, for example, to onboard the VNF, use an IP based overlay for management, and rely on a WAN based SDN controller to provision a MEF certified E-Line service. All of this would be automated and programmable.
NFV orchestration is more than just managing virtual resources on top of a VIM such as OpenStack. NFV orchestration about operationalizing VNFs by taking care of the complete life-cycle from on-boarding to terminating and everything in between by carefully addressing the entire chain of physical and virtual resources that sit between the end user and the bare metal server.
We have learned so much from 2014 in terms of what operators need and don’t need to make the most out of NFV. While network transformation is moving fast, 2014 provided us the time we needed to discover these facts and to ensure they were built into our implementations. We’re ready. The Future is Now. 2015 is the Year of the Orchestrator.