This content is part of the Essential Guide: NFV basics: A guide to NFV implementation, challenges and benefits
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Network Functions Virtualization demands new network management models

NFV aims for dynamic network provisioning and orchestration, requiring a new network management model that integrates legacy and virtual resources.

When a cadre of giant global network operators started the initiative known as Network Functions Virtualization (NFV) in late 2012, their stated goal was to leverage virtualization technology to consolidate network equipment types onto industry-standard servers, switches and storage.

Clearly this was aimed at reducing the capital cost of purpose-built network equipment. But only a year later, the focus widened. These same operators believed the benefit of NFV would lie in improving the efficiency of operations, even enabling service agility.

That was a profound shift that meant NFV's success would depend on its operational effectiveness and this would require a shift in network management model away from one that is device-driven and toward one that would take into account orchestration across both legacy network components and virtual resources.

Why virtual network functions can't be managed as traditional network devices

The challenge for NFV is that a new operations model must provide efficiency across an entire service. This means management models must reach beyond hosting virtual functions on servers as specific devices.

What the ETSI NFV Industry Specification Group (ISG) process appears to aim for is the creation of a network management model for NFV that "plugs into" current network management system and OSS/BSS systems by offering element management interfaces to NFV processes and elements.

In effect, this means that a virtual network function, or a complex of such functions that emulates the behavior of a physical appliance (like a firewall), would be a virtual form of that physical device and be managed in the same way.

While this approach would address the stated goal of exploiting virtualization, it also suggests that overall service deployment and management practices would change little as NFV is deployed. That makes it difficult to secure major changes in operating efficiency or service agility.

How to change the network management model for NFV

There are two ways this could change -- one by creating a smarter higher layer above NFV, and the other by making an NFV virtual device into something very different from the real device on which it was based.

The connections between virtual network functions inside an NFV virtual device could already involve legacy network components and certainly would involve multiple virtual function components, virtual machines or containers for hosting, etc. That means that every NFV virtual device is really a system of cooperating elements whose collective functionality has to be reflected through the management information base that represents the virtual device to any management system or OSS/BSS element.

If the scope of a virtual device is very small -- limited to emulating a single real appliance -- then current systems and practices would change little when NFV is deployed. If, however, the virtual device was expanded to include more legacy network components, it's possible to visualize an NFV "device" that represents a complete end-to-end service, including both virtual and legacy elements. In that case, how NFV services were deployed and managed inside the virtual device boundary would determine how agile and operationally efficient the service was.

The problem with this approach is that we already have NMS, OSS, and BSS systems for legacy networks and for the legacy components of future networks. If NFV defines an umbrella operations model, how does that model embrace service components that have no NFV components?

A network management model for integrated NFV

An alternate approach preserves these past practices by creating a new operations model that sits above the ETSI NFV processes. This model would define services as a collection of virtual elements some of which might be implemented through NFV processes and some through normal legacy-network provisioning and management. Efficiencies in service agility and operations efficiency would be created by this new operations model and could be applied even to services with no NFV components at all.

More on the network functions virtualization revolution

How NFV will transform architecture

Network functions virtualization primer

Overcoming NFV implementation challenges

CloudNFV creates NFV prototypes

The relationship between NFV and SDN

SDN + NDV = service orchestration in mobile networks

It should be clear that what's being considered here is less what needs to be done operationally than where the new operations model would reside. What's being described in either the "inside" or "on-top-of-NFV" situations is a two-level process of orchestration and management that contrasts with the single-level practices that dominate today. The NFV operations model consists of a functional layer where logical components of services are assembled into retail offerings regardless of how they are implemented, and a second structural layer where the logical components are actually deployed by committing network, software and server resources.

This model fits both the evolving NFV specifications and cloud computing's own notion of "DevOps" provisioning quite well, since both could fit in the structural layer. However, there are no functional-layer models currently accepted, and many would argue that none are under consideration. Two issues deter such a model: jurisdiction and management.

Who is responsible for building a management model beyond OSS/BSS?

Something that lies between OSS/BSS systems and networks could logically be called either an extension to OSS/BSS or an extension to the network. The TM Forum (TMF) is the accepted OSS/BSS standards group and so would be a logical candidate to pursue functional management models. The problem is that functional operations models look a lot like building service logic and the TMF is a management body.

On the network side, there's no shortage of possible sources for a model, ranging from the NFV ISG and cloud groups like OpenStack, to the IETF, the International Telecommunications Union, 3GPP and even the Open Networking Foundation. A network-side operations model might end up being five such models, which would then demand a higher-level model to accommodate them all.

The most likely paths to a resolution of NFV's operations challenges are the TMF at the OSS/BSS level or a union of the NFV ISG and the ONF on the network side. Those two bodies have already agreed on cooperating, but the focus of their cooperation is well below the functional level and it leaves management out of the picture completely.

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.

This was last published in April 2014

Dig Deeper on Network virtualization technology

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.