Skip navigation

As a supplier of critical infrastructure software for Network Functions Virtualization (NFV), our team at Wind River spends a lot of time talking with service providers, Telecom Equipment Manufacturers (TEMs) and our ecosystem partners. As with any discussion about a technical topic that is both complex and relatively new, there’s always the need to “level set” the conversation by making sure that everyone around the table or around the conference phone is aligned on the terminology.

Thanks to all the work done by the ETSI NFV Industry Specification Group (ISG), it seems that everyone working in this space has a precise, shared understanding of most of the terms that describe the high-level system architecture. We don’t see much uncertainty or ambiguity about “Virtual Network Function (VNF)”, “NFV Infrastructure (NFVI)” or “Virtualized Infrastructure Manager (VIM)”, even though the NFV-related usage of these terms has really only developed over the past 18 months or so. And everyone who’s been around telecom networks for a while seems familiar with the concepts of an “OSS” and “BSS”, even if only a small minority is brave enough to dive into the deep complexity of those two functions.

At the recent ETSI ISG meeting in Okinawa, there was a lot of discussion about the “VNF Manager” (VNFM) function. This element of the architecture appears to need further exploration and clarification. As an example, the concept of a VNF Manager provided by the supplier of the VNF itself will be a topic for additional analysis by the Management and Orchestration (MANO) working group.

As we talk to our NFV software partners, one stumbling block tends to be uncertainty around the finer details of “VNF Orchestration” compared to “VNF Management”. We talk to industry-leading companies who provide orchestration solutions and inevitably get into a discussion of whether their VNF orchestration overlaps with our VNF management. Equally inevitably, the answer is either “no” or “minimally”, but it always takes a while to reach that conclusion.

I’ll briefly summarize our thoughts on the distinction between these functions. We’d be very interested in feedback from all you experts out there about whether our understanding is correct. After all, that’s why this is a blog post inviting comments and not a magazine article (remember those?) that you just tear up if you don’t agree with the contents.




Let’s start with the NFV Orchestrator. This element within the NFV architecture is the controlling logic for the lifecycle management of NFV services. In ETSI terms, it’s one of three MANO functions, with the others being the VNFM(s) and the VIM(s). Companies like Nakina, Overture and Tail-f, among others, provide solutions that are NFV Orchestrators.

When service provider introduces a new service request, the NFV Orchestrator receives as input from the OSS/BSS the service data model that describes the new service to be instantiated, typically expressing it as a set of linked VNFs. The grouping of VNFs can be described in terms of either function graphs or service graphs. Through abstraction, the overall functionality of the service is decomposed into components with relationships described by connections and functionality.


The NFV orchestrator references the system’s VNF descriptor that describes hosting requirements for the VNFs that are available for instantiation, which are defined abstractly and mapped as needed. The NFV orchestrator determines the availability and features of the physical platform resources and generates an optimized map of resource locations. It specifies both where VNFs should be instantiated and also the required connections between VNFs that are necessary to achieve the overall customer-facing service that has been ordered. Lastly, it records the results of VNF deployments to permit management views of the actual resource assignments.

The VNFs themselves are instantiated through a series of actions performed by the VNF Manager and the VIM. These functions are performed within integrated platforms such as our Carrier Grade Communications Server (CGCS) which also implements (in ETSI terms) the NVFI function.


Typically the VIM is implemented using OpenStack as a baseline. (OpenStack needs to be significantly hardened in order to meet Carrier Grade reliability requirements, but that’s a topic for other posts.) It deploys the VNFs that were specified by the NFV Orchestrator, implements all the required connections between them and makes them functional. For disaster recovery purposes, the VIM must also support inter-regional resource allocation and must control integrated backup and recovery systems.

VNF lifecycle maintenance is a key operational function. The VNF Manager must automatically detect all VNF failures and ensure that they are restarted so that there are no “silent failures”. VNFs must be automatically migrated through live migration, in order to optimize resource utilization. This live migration must of course include all the established network connections between VNFs. Finally, as services are no longer required, the VNF Manager implements automated VNF teardown through a graceful shutdown process.

We converged on this distinction between a NFV orchestration and VNF management after some intense whiteboard discussions with colleagues from several partner companies. And we’d be very interested in your opinion: are these definitions correct (at least at a high level), or have we missed something in our understanding of how NFV is supposed to work?

Filter Blog

By date: By tag: