JNT Visual - Fotolia
Much of the buzz about NFV has been about exciting virtual network functions (VNFs) that could radically change...
the way services and applications are delivered. However, underneath those VNFs, there must be a supporting NFV Infrastructure (NFVI), and that technology is still difficult to define.
While many vendors claim they offer NFVI, their portfolios vary widely, making it difficult for network pros to make investment decisions. The good news is that the ETSI NFV Industry Specification Group has outlined a few basic elements that make an NFVI environment work.
An NFVI definition takes shape
At the high level, NFVI is the set of resources that is used to host and connect virtual functions. The easiest parallel to draw is that NFVI is a kind of cloud data center, containing servers, hypervisors, operating systems, virtual machines, virtual switches and network resources.
Some say that the term NFVI also includes the physical switches and routers that connect users to VNFs. But if you follow this line of reasoning, you're left with the idea that everything that's in or connected to a data center could be considered NFVI. In that case, Alcatel-Lucent, Cisco, Dell, IBM, Huawei and a host of other vendors already offer NFVI. But we have to tighten our requirements to determine a clearer picture.
There are two table stakes for NFVI -- an NFV orchestrator and Virtual Infrastructure Managers (VIMs). When NFV services are built, there should be an NFV orchestrator that calls on a series of VIMs that in turn call for the necessary resources from the underlying infrastructure. This is similar to how OpenStack works for hosting applications.
What to expect from an NFVI Virtual Infrastructure Manager
In ETSI's NFVI model, there must be VIMs that represent the infrastructure resources. Within that, there are questions about what VIMs must be able to do and how the infrastructure interacts with them.
According to ETSI, NFVI must be "secure," and "available," and have other attributes that support a service level agreement. That implies that a VIM would publish its capabilities and allow an orchestrator to specify just what's needed. If that VIM couldn't handle the orchestrator's request, it would presumably be able to direct it to another appropriate VIM. The details on how this might work aren't final yet, so it's possible that a vendor could claim to offer NFVI but not provide features and capabilities most services would demand.
Does NFV need its own orchestrator beyond OpenStack?
In NFVI, the orchestrator is what actually builds NFV services. A VIM can't do much without orchestration capability. Vendors that offer their own orchestrator can drive NFV engagement and validate their own NFVI offerings. The major point of confusion here is whether something like OpenStack or the DevOps tools associated with it qualify as orchestration.
Based on the ETSI NFV specifications, there are things that the orchestrator is expected to do that go beyond the features of cloud tools like OpenStack. As one example, orchestrators would access and use information about VNFs and services.
In fact, you could argue that OpenStack is a part of a VIM or even part of NFVI itself, while an NFVI orchestrator will really be a piece of software more dedicated to NFV specifically than to the cloud in general. Right now, fewer than half the vendors who claim to offer NFVI have an orchestrator of their own. Most vendors are dependent on the buyer finding and integrating the orchestrator.
How the OPNFV could play a role in developing NFVIs
It is with VIMs and orchestrators that the open-source project, Open Platform for NFV (OPNFV) may make its first and greatest contribution. To properly define the interfaces associated with a VIM, the OPNFV will have to define what NFVI is expected to publish and what the orchestrator can ask for in the way of resource commitments. We know the roles and requirements of VIMs and orchestrators in only general terms, and so participation in OPNFV may be the critical test for any vendor who purports to have NFVI capability.
NFVI and the rise of the infrastructure manager
Major NFVI questions still remain around the network itself. Some operators in the NFV Industry Specification Group have proposed that the notion of a VIM be extended to that of an infrastructure manager that embraces not only deploying and connecting VNFs, but also “parameterizing” legacy network devices. The question of how SDN in general, and OpenFlow or OpenDaylight in particular, relate to NFVI is also open. Most operators have been conducting proofs of concept for NFV aimed at proving the technical principles unique to NFV rather than the end-to-end service application of NFV and legacy network elements. How those elements are ultimately treated will determine whether the NFVI of the future looks like a cloud data center or a global infrastructure.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
A guide to NFV basics
What we need from NFV orchestration
Where SDN and NFV meet