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 use virtualization technology to consolidate network equipment types onto industry-standard servers, switches and storage.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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 would require a shift in network management models 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 like traditional devices
The challenge for NFV is that a new operations model must provide efficiency across an entire service. This means management models need to reach beyond hosting virtual functions on servers as specific devices.
What the ETSI NFV Industry Specification Group (ISG) aims for is the creation of a network management model for NFV that "plugs into" current network management systems 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 may 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 two, 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 make use of multiple virtual function components, virtual machines or containers for hosting and a range of other devices. 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. However, if 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 while others would be 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.
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. Both the "inside" or "on top of NFV" situations are describing a two-level process of orchestration and management that contrasts with the single-level practices that are dominant 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's 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, making it 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 operational 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.