Overcoming network functions virtualization implementation challenges

Carriers need network functions virtualization implementation prespecification, so they'll look to TM Forum and cloud management models for help.

Network functions virtualization (NFV) technology aims to host network functions on standardized servers rather...

than custom devices. While vendors and carrier network operators are eager to launch trials, the European Telecommunications Standards Institute (ETSI) specification process is scheduled to run until January 2015, so early NFV implementation will have to be based on broader principles that will have to be adopted as more details emerge.

To achieve NFV implementation in the shorter term, vendors will have to make four key decisions:  on implementing a cloud-hosted model, choosing network-optimized platforms, structuring services and resources based on TM Forum principles to facilitate operations integration, and adopting an agile and loosely coupled data/process architecture.

Finding common management framework for NFV: Go OpenStack?

In theory, NFV could be hosted on anything from dedicated physical servers to virtual servers in the cloud. But in practice, accommodating that wide a range of implementation choices is difficult without a consistent management framework that covers all the options.

In theory, NFV could be hosted on anything from dedicated physical servers to virtual servers in the cloud. But in practice, accommodating that wide a range of implementation choices is difficult without a consistent management framework that covers all the options.

The answer to that problem may be in placing virtual functions in the cloud and using OpenStack as the cloud software platform. OpenStack has wide industry support, and it has a network-as-a-service framework. Neutron (formerly called Quantum) has plug-ins that support most of the popular SDN technologies and even some proprietary network management systems (NMSs). However, Neutron is evolving to meet cloud computing needs rather than the broader needs of network operators, and it's likely that early implementations of NFV will have to extend Neutron for carrier networks to cover things like traditional point-to-point connections that don't exist in the cloud. In this case, Neutron would have to be augmented by developers -- or bypassed for the models it doesn't support.

Optimizing commercial servers for NFV implementation

The success of NFV and hosting virtual functions will hinge on whether these functions can be made available and perform as needed. The expressed goal of the ETSI NFV Industry Specification Group (ISG) is to do this on commercial servers, but these will have to be network-optimized through both hardware and software. This optimization is particularly necessary in the case of the data-path connection from network interfaces to virtual machines. After all, network devices vary depending on the traffic they're expected to handle and the reliability they're expected to deliver. The same scenario holds true for NFV hosts -- so the same optimization will be necessary.

Finding an NFV management model: Look to the TM Forum

The third issue in implementing NFV is the management process. This has to be based on a data model to describe services and resources. Even before NFV came along, the TM Forum (TMF) provided a suitable, perhaps even ideal, data model, (SID) GB922. While it's likely this model will have to be extended to support virtual functions and cloud resources, the extensions are minimal, and GB922 offers a rich model for describing both services that include virtual functions and the resources on which those functions are hosted.

The TMF model greatly facilitates the structuring and management of both resources and services, and NFV's own virtual-function management conception will likely be fit into the larger TMF model in any case.

In addition, the TMF model can be easily adapted to represent not only services newly composed from virtual functions, but also services provisioned traditionally, and even those a partner supplies. By having a common architecture to represent all kinds of services, the model allows operators to manage the transition to NFV when many traditional network devices will remain in use.

NFV implementation demands untraditional data models

Management integration and service modeling are only examples of the largest and final NFV implementation decision, the data model. NFV touches the existing network OSS/BSS, as well as NMSs, the cloud management systems and the management of virtual functions themselves. It will have to accommodate all of the devices used to host NFV and all the surrounding network equipment.

More on network functions virtualization

CloudNFV creates NFV prototypes

The relationship between NFV and SDN

SDN + NDV = service orchestration in mobile networks

Will NFV revolutionize network architecture?

NFV basics: A primer

Virtualization, machine images of virtual functions, virtual-network SDN connectivity and traffic patterns will all have to be considered in identifying the best places to host functions and the best ways of connecting them. The optimization task is significant, but the real challenge is simply expressing the policies to guide deployment and accumulating the management data needed. For that, NFV implementation demands thinking outside the box of traditional data models.

Modern data-driven process models separate data storage from data/information models, and they use a semantic layer to describe interpretation and relationships. These can easily accommodate collector interfaces to gather telemetry from devices and functions, as well as distribution interfaces to visualize the data in the form a management system needs. The IETF has already proposed using a data repository to accumulate resource information for distribution to virtual functions or management processes in its Infrastructure to Application Exposure (i2aex) architecture. This semantic modeling approach also makes it easy to adapt a prestandard implementation to interfaces yet to be specified by the NFV ISG.

In NFV implementation, do we need off-the-shelf cloud apps?

Beyond these basic implementation points, there's also the basic question of where virtual functions actually come from.

If virtual functions have to be custom-developed to run in an NFV implementation, there could be a potential delay in function availability. After all, developers have to commit to the new environment, which could result in multiple platforms with different requirement sets. The ability to host any cloud-ready application or network component in NFV would solve the function availability problem, but off-the-shelf cloud application or network feature components couldn't take advantage of any special management, availability or performance tools that might be built into the NFV specification. The right answer is likely to support both off-the-shelf apps and customized apps with NFV-optimized behavior. The market can then choose what's most important.

There will almost certainly be many NFV implementations before specifications emerge. In fact, the ISG's work isn't intended to describe or limit the implementation process and vendors, and NFV users will place different values on different features and capabilities. As the implementations roll out, we'll get our first concrete look at what NFV can do, and from that we'll be able to tell just how much of a revolution it will be.

This was last published in September 2013

Dig Deeper on Open source networking