Network functions virtualization (NFV) depends on a range of virtual network functions (VNFs) to be orchestrated...
into services. While the dependence is obvious, the source of VNFs and their relationship to NFV platforms and tools isn't always as clear.
Perhaps the biggest unresolved question is whether a specific virtual network function or group of VNFs will conform to some standard architecture -- in other words, whether major vendors will collect VNF providers into ecosystems that offer a wide choice of functions or whether some major VNFs will be so tied to NFV platforms (such as management and orchestration or NFV infrastructure) that they create silos. How this issue is resolved may set the pace at which NFV can be adopted.
In a nutshell, a VNF is a software component that does something beneficial -- often something that traditionally would be performed using a custom network device or appliance. There are two primary sources of VNFs: the vendors that have developed these custom devices or open-source software where free versions of many network features can be found. If we were to assume, for example, that VNFs were simply cloud software components, we could also assume that as long as a VNF machine image could be hosted in a given cloud data center, the VNF would run there. We'd have an open community with no barriers to incorporating new VNFs and no proprietary lock-ins.
NFV, however, requires a little more than just a place to host things. NFV deployment requires a descriptor that instructs the NFV platform how to deploy VNFs and how they should be connected.
Additional services can change VNF code itself
Some features of VNF-based services -- such as horizontal scaling or increasing and decreasing the number of virtual network function copies being run to accommodate load changes -- may also require adding components like load balancers or even making some changes in the VNF code itself. All of these could take a generalized piece of cloud software and specialize it to a particular NFV platform/vendor.
The European Telecommunications Standards Institute (ETSI), meanwhile, also calls for a VNF manager (VNFM) to oversee the VNFs. This VNFM is combined in some way with the original VNF, and effectively becomes an extension of the NFV platform and the management and orchestration (MANO) function. While a generalized VNFM might be possible, customizing the VNFM for each VNF or group of VNFs is also accepted by the ETSI specifications. This all means that VNFs may not be as portable as cloud components. And that's where issues could arise.
Every operator that has run an NFV trial has encountered one issue: onboarding. If VNFs are in fact specialized components, then there will be some special steps needed to get one to run on a given NFV platform. In effect, the NFV platform should include a platform as a service (PaaS) specification -- in the form of data models, APIs and other elements -- to describe how VNFs are expected to be linked with management and deployment. At this point in time, this structure is still hazy, which means that moving a VNF from one place to another may be difficult. It's hard to say how quickly this VNF-PaaS specification will mature, or even whether it will fully describe the way a VNF is connected.
NFV platform providers working hard to gather virtual functions
In the meantime, major providers of NFV platform components (MANO and NFV infrastructure) are working to gather virtual functions by establishing a partner program or ecosystem. For VNF providers, allying with a major NFV platform vendor makes sense because it assures their functions can be deployed and managed properly. For the platform vendors, it also makes sense because a rich inventory of VNFs may be critical in aligning their products with early market opportunities. Operators like ecosystems because they reduce onboarding efforts by harmonizing VNFs on a single platform.
In a VNF ecosystem everything is said to be equal, but as always, some things are more "equal" than others. A VNF-like firewall may have a dozen commercial implementations and another dozen open-source free ones, so no single firewall vendor has control over ecosystem partners or network operators. With VNFs that are expensive and highly proprietary, such as implementations of IP multimedia subsystems, evolved packet core and content delivery networks, the VNF provider can gain an advantage by creating a proprietary link between their critical VNFs and their NFV platform. This could induce operators that need the VNF to adopt the platform, and the platform might then restrict their options for other VNFs they'll need. As a result, operators worry this could create VNF silos that could end up forcing them to install more than one VNF platform -- thus increasing both initial and ongoing operations costs.
Operators know that a completely open VNF architecture would be the best outcome here. One possibility is that the newly formed Open Platform for NFV (OPNFV) initiative within the Linux Foundation will create an open-source reference architecture and commercial options will then converge on it. The biggest differences among VNF approaches, however, lie in the management, including integration with current network management systems and operations centers, and with operations and business support systems. It's not yet clear when, or whether, OPNFV will address those issues.
It is very possible that a unified virtual network function architecture will emerge from one or more of the vendor-sponsored VNF ecosystems. As these deploy and attract operator commitment, they'd become more attractive for VNF providers to join. A leading candidate could then run away from the market by collecting the largest inventory of useful functions. It's even possible that another standards group like the Object Management Group or the TM Forum will frame a universal management model that could minimize differences in how VNFs are deployed and managed and create that sought-after universal approach.
NFV is entering into its most critical period, the time when proof-of-concept trials targeting technical feature verification give way to field trials to validate the NFV business case. The VNFs selected for field trials have to present commercial utility and not just demonstrate features. Because operators' opportunities for VNF-based services vary, a rich set of VNF choices is critical if NFV is to meet its goals.
Learn more about building a VNF framework and the role of NFV orchestration.
Read more about what makes software become front and center in NFV.