What do we need from NFV Orchestration?

NFV 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.

Brian Naughton

Brian Naughton

Sunday 10 April, 2016