The long-term vision for NFV is to have a ubiquitous, virtualized infrastructure and orchestration stack capable of supporting any virtual network function (VNF) dropped onto it.

Such a platform will happily provide multiple different VNFs with appropriate execution environments, automatically placing them in the NFV infrastructure (NFVI) according to business and technical policies that govern, for example, the cost of running the VNF in a particular location, regulatory compliance, colocation -- or not -- with other instances of the same VNF or its performance requirements. The platform will monitor and manage all its VNFs throughout their lifecycle, so that they support customer-facing services effectively.

But building this platform is a huge task. Anyone who follows the NFV interoperability and performance tests that operators and vendor ecosystems are carrying out will know that a large number of components need to be assembled and integrated to populate an NFV architecture. On the NFVI side, these include hypervisors and virtual switches, carrier-grade operating systems and NFV-enabled chipsets, the capabilities of which need to be recognized and orchestrated by the NFV virtual infrastructure manager (VIM) and factored into its VNF placement algorithm.

Then there's the management and orchestration of a VNF itself -- its configuration, scaling, upgrading and healing -- which must be taken into account. Understanding the implications of a complex set of infrastructure components on the performance and management of a single VNF is hard enough. Reconciling the competing infrastructure requirements and dealing with the management idiosyncrasies of differently packaged (at this stage of the market) VNFs from multiple vendors is an enormous undertaking.

Over time, as the industry understands more about the interactions between NFV architecture components and there is greater consensus over the metrics used to benchmark them, it will become easier to realize the full NFV vision. Today, operators urgently need a way of introducing NFV to their networks that doesn't involve eating the whole pie at once. For a start, vendors are beginning to make noises about stopping support for their ATCA platforms. Meanwhile, financial institutions are starting to take notice of which operators have NFV transformation plans and may penalize those that don't. Then there's market competition, which will heat up as early adopters are able to offer more service innovation cost effectively and quickly as a result of NFV. So what does a digestible migration path look like?

The consensus among leading operators seems to be: Start with one VNF and the subset of NFV architecture components needed to support that one function. This will, of course, be a function where there is a strong business case for virtualization, whether that's based on cost reduction, end of life of existing equipment or support for a new customer-facing service. Heavy Reading research shows that operators vary widely in their choice of NFV starting points.

Run the VNF on an NFVI -- which will in effect be dedicated to a single VNF for the time being -- to gain experience of the way in which a VNF interacts with the various NFVI components. There will be multiple dimensions to this interaction but it's especially important for operators to gain hands-on experience of VNF/NFVI management and orchestration, since this represents major change for their organizations. One operator starting out with a single VNF as a test case for NFV is creating a new joint operations team to support it, handpicking IT and network operations staff who will pilot new NFV management processes and demonstrate to the rest of the company what post-transformation operations might look like in the future.

While many operators are increasingly comfortable with the idea of automated VNF deployment and configuration, they are often suspicious of orchestrated scaling and placement and their NFV orchestration strategy -- and its co-existence with traditional network management -- may be a work in progress. Again, advanced operators are starting with a minimal set of NFV management and orchestration (MANO) functions and adding to these over time.

A number of operators describe such first NFV migration steps as showcases for the organization, evangelizing NFV concepts and creating excitement and acceptance alongside internal knowledge of how NFV will work. The trick is to take an architectural approach, not simply to buy a turnkey VNF solution with no opportunity to understand how all the components and layers work together. A "black box" solution might get NFV up and running faster but there is limited opportunity for operators to add further VNFs over time as their experience and confidence grow.

— Caroline Chappell, Principal Analyst, Cloud & NFV, Heavy Reading

This blog is sponsored by Alcatel-Lucent.