Orchestration in network functions virtualization (NFV) is so critical that ETSI's NFV specification group has coined the term "MANO" for management and orchestration, and now the phrase has entered the networking lexicon.
Yet for all the work to develop "MANO," there's a surprising lack of consistency in how "orchestration" is defined by vendors. What's more, there's a major disconnect between the formal notion of orchestration for NFV and what operators actually need to meet their virtualization goals. That disconnect must be addressed or it will threaten NFV deployment.
What network operators need from NFV orchestration
The term orchestration in IT networking describes the process of automating the deployment and connection of multiple IT/network elements or software components. In that context, orchestration creates a kind of recipe for a service or application that, when followed, creates and sustains the expected experience for users. That can quicken the pace of deployment and reduce operating costs, both of which increase return on infrastructure and profits.
Now orchestration must match the same goals for NFV in operator networks. While capital expense management was initially the driving force behind NFV, operators have now evolved to focusing on improvements in service agility and velocity, as well as control of opex.
The problem this poses for NFV is that the ETSI Industry Specification Groups (ISG) work is focused on the hosting of virtual functions, which in most cases makes up only a small part of service insertion. A business VPN with a thousand sites might consume a few instances of a virtual firewall, for example, but will have much larger needs when it comes to enabling automated service insertion.
It is this shift in goals that has created a disconnect between what standards groups say about NFV orchestration and what operators need. Resolving this can come only from somehow taking orchestration and management to a higher level.
Are NFV managers the answer?
NFV includes the concept of "infrastructure" or "virtual function" managers who link the orchestration and management functions to hardware of many types. These managers or handlers may also be responsible for orchestrating a combination of NFV and non-NFV service elements.
All that's needed is a manager that takes into consideration every infrastructure element that must be controlled, and a model that represents the role of each of these elements in a service. In this situation, the NFV orchestration must either be able to control every element in the network, or it must be capable of subordinating to a higher-level orchestration strategy for end-to-end service control.
Why we need open-standards NFV orchestration
If not properly directed, this kind of orchestration expansion could generate multiple and incompatible proprietary solutions as vendors struggle to protect sales and differentiate their own approaches.
The risk of "walled-garden NFV" and orchestration has led many operators to seek open standards and even open-source software. As all of this takes shape, a more standardized approach to expanding NFV orchestration is needed. That appears to require two things --an open approach to service modeling and an open mechanism for managing services built from legacy or NFV-supported features.
Taken alone, NFV orchestration could be handled using something like the OpenStack Nova/Neutron APIs. The challenge is in modeling complex services that aren't fully based on cloud-hosted components, and for that there are no specific standards evolving. The most promising approach is the Topology and Orchestration Specification for Cloud Services (TOSCA), which is under development in the open standards development organization OASIS. As the name suggests, this is also intended as a cloud specification, but TOSCA models appear to be flexible enough to describe the kind of complex services that would contain NFV elements.
NFV orchestration must be paired with service management
To make the most of automated orchestration, this should be linked with service and element management in some way. Complex services, particularly those like NFV that host elements on virtual resources, require the virtual device the user sees be a construct of orchestration. Those virtual devices must be represented by a parallel construct of a management view. A virtual branch access device might be a firewall, NAT, DNS and DHCP component, each hosted on a virtual machine and connected via SDN. While the user shouldn't be able to distinguish between the elements, the network operations center has to be able to decompose the virtual device into its real components to solve problems.
One logical way to do this is to apply some of the principles of the IETF's Infrastructure to Application Exposure (i2aex) specification, which collects and centralizes all “real” management data into a repository and delivers derived management views.
Applications can then either directly query the repository (using SQL, for example) or use an SNMP or management "proxy" that will expose repository variables through an appropriate management interface standard. This approach also limits the risk of many virtual functions overwhelming shared devices with management requests, or having those functions make changes to shared resources that would impact other users. NFV orchestration must include secure multi-tenant management.
Ultimately, management and orchestration of NFV must be more than managing and arranging the new hosted-function model that NFV has created. The model has to be able to handle the entire service, end to end, or provider goals for improving service velocity/agility and operational efficiency cannot be met.
Do NFV orchestration tools exist?
To date, operators say that only a small number of vendors have even indicated such an approach is on their roadmap. Alcatel-Lucent, Cisco and HP claim they have a full solution, but none are yet offered in full form, according to research surveys that I've conducted.
Without a management/orchestration model that meets their goals, NFV buyers may realize that NFV deployments are likely to under-realize their full potential. This may leave operators scrambling to address their service agility and operations issues in some other way.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecom strategy issues.
Why should we care about OpenStack networking?
Why ADCs are still relevant in SDN
Where SDN and NFV meet
Why operators won’t invest in SDN and NFV
Layer 4-7 service insertion
Dig deeper on SDN management applications
Tom Nolle asks:
Do we need a separate set of NFV-specific orchestration tools?
0 ResponsesJoin the Discussion