NFV was introduced to replace purpose-built hardware limited to performing a set of tasks with a multi-purpose platform that is flexible, yet standardized. The capex and opex reductions gained from NFV are so attractive that it has rapidly gained traction across the entire ecosystem of telecoms - R&D, manufacturers and operators - thus making it an industry wide initiative. Going hardware-agnostic would only makes sense if that is followed by adoption of open-source projects at a massive scale.

Since NFV’s inception, OpenStack is being targeted to provide the orchestration layer for NFV infrastructure. OpenStack is an open-source set of software aimed at building and managing cloud networks. We can think of OpenStack as a suite of tools and the mission is to produce, as noted on the OpenStack FAQ, "the ubiquitous open source cloud computing platform that will meet the needs of public and private cloud providers regardless of size." But the challenge is that OpenStack alone is not enough for a carrier-grade NFV orchestration as telecom applications span over multiple virtual machines, especially when it comes to a carrier-grade NFV deployment. Thus a higher layer of abstraction is needed that orchestrates virtual network functions (VNF) instead of virtual machines (VMs).

OpenStack implementations of today lean towards being more computation-centric whereas NFV follows a more connection-centric approach. For instance, a public OpenStack offering would enable tenants to share resources in a cost effective and scalable manner while the CSP NFV implementations will require to scale network functions, aimed at serving subscribers ranging from tens to even hundreds of thousands across multiple operators. As such, the requirements of a virtual network function (VNF) regarding resource provisioning, resource pooling, scalability, VNF related dependency policies, chaining and availability (five 9s), would all be very different compared to the enterprise applications enabled on the cloud networks of today.  As an example, consider a single telecom application instance that is likely to be spread over multiple VMs across multiple data centers due to resilience and redundancy requirements. While before we had a single or at most a handful of VMs (loosely linked at best), here we would have to enable multiple, tightly coupled VMs with heavy inter-VM traffic and high-availability constraints.

However, a higher abstraction layer which orchestrates VNFs (applications) instead of just VMs will offer us the solution we are looking for; the challenges of which are bound to be an interesting area for future cloud centric research. With this higher abstraction layer, called the NFV orchestrator, we can bridge the gap between the compute-centric OpenStack solution and application-centric NFV requirements resulting tremendous scalability advantages for both ends of the cloud spectrum.

Having said that, there will remain certain entities of a CSP network which have to, and most likely will continue to, be part of the physical separate domain requiring definitive segments and service boundaries with smooth handovers. Since "network functions" is a term used broadly to encompass all nodes residing in a communication network, virtualizing certain network functions would be straightforward depending on the processor, storage and networking requirements coupled with VMs. Other implementations, however, might not be such, and in fact could be curtailed owing to stringent real-time and reliability requirements. Virtualizing such functions would require strict collaboration between inter-cloud as well as intra-cloud platform tasks under the control of the network functions themselves.

Some recommendations to look into are:

1. Consolidated Monitoring. With the multivendor CSP environment of today, it's a blame game if there is something going on with the network. Just imagine throwing a lot more vendors and solutions into the mix. Unlike what we have today, an NFV proposed solution can have the VNF from one vendor and hardware from another. On top of that, there will be multiple options for the OpenStack distribution and hypervisors. All this is to replace a solution where at least one vendor provided the software, the hardware and the management for any network function.

A consolidated way of monitoring is of critical importance for NFV. A simple solution is to have a rich set of monitoring APIs that the VNF vendors will use that can help analyze application behavior through data observations. These APIs can get integrated with the NFV-O and can feed in wealth of data that can help analyze the health and performance of the networks, the subscriber behavior, and the application behavior. Like SNMP or Netconf, if these APIs can be standardized it will help with adoption and a smoother transition into the promised world of NFV.

2. Containerization. Docker provides multiple containers within a VM. While this is a very good way to optimize things for applications that can run within one VM, a containerization technique is required for NFV that can have multiple VMs inside it. That “service container” can be made highly available, scaled in or out, or moved from one data center to another as a single entity, without worrying about the underlying VMs. This service container will be allocated as an inseparable resource unit.

So in short, NFV needs an app-centric architecture in the cloud. It needs a VNF-centric networking platform with abstraction layer for VNFs for provisioning and management. NFV requires an end-to-end platform that handles all aspects of application lifecycle management from creation to teardown that will include installing, upgrading, monitoring, scaling and self-healing with mechanisms in place to ensure their high availability and reliability.

Focus will shift from reliability and availability per network element to end-to-end service availability. This will require new systems for monitoring, analyzing and managing the end-to-end infrastructure.