Wanted: One Copy of ‘NFV Orchestration for Dummies’

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.

Among NFV software partners, one stumbling block tends to be uncertainty around the finer details of “VNF orchestration” compared to “VNF management”. Industry-leading companies who provide orchestration solutions  inevitably get into discussions of whether their VNF orchestration overlaps with someone else’s 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 my thoughts on the distinction between these functions, and I’d be very interested in feedback from all you experts out there about whether my 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 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.

This distinction between a NFV orchestration and VNF management emerged after some intense whiteboard discussions — but what’s your opinion? Are these definitions correct (at least at a high level), or are they missing something in their understanding of how NFV is supposed to work?

Post originally published on SDNCentral.

Charlie Ashton is an accomplished marketing and business development executive with extensive experience in the embedded systems industry. At Wind River, Charlie is responsible for business development initiatives for Networking and Telecommunications markets. He has held leadership roles in both engineering and marketing at software, semiconductor and systems companies including 6WIND, Green Hills Software, Timesys, Motorola (now Freescale Semiconductor), AMCC (now AppliedMicro), AMD and Dell.