Nobody would argue that Network Functions Virtualization (NFV) has made significant progress in the past two and one half years. There are dozens of proof of concepts being run by operators in conjunction with vendors working together in communities and consortiums. Some service providers and vendors have announced that they have functional NFV architectures in their production networks.
But, everyone needs to take a step back and look at some of the realities associated with the NFV architectural model as it stands today. There are success stories, but there are still significant challenges and hurdles to the smooth implantation of a NFV-based solution. Here are four key challenges to the success of NFV as an architectural standard today.
Challenge 1 is the fact that there are no standards today for communications between the NFV components. We have interfaces such as the Ve-Vnfm, Nf-Vi, or Vn-Nf, but these interfaces have no definition beyond their name and which components are communicating with each other. Standards bodies and various communities are working on creating communications models for the named interfaces, but it will take time for consensus standards to be created. There are competing bodies and competing standards. In the meantime, we need to get NFV working.
Challenge 2 is that NFV is a multivendor landscape by the nature of the architecture. Different components from the NFVI, different VNFs, and MANO will need to be delivered by multiple vendors and the interconnectivity needs to be open and standardized. As mentioned, these standards are still being developed. In the meantime, we need open standards today. This does not necessarily open source, but open where everyone in this multivendor architecture can view, program to, and interact with the different components as necessary.
Challenge 3 is using a single orchestration system to bridge the existing hardware solutions with the virtualized solutions. For legacy, performance, and functionality reasons, the foreseeable future is a hybrid network with both proprietary hardware and virtualized services. Management and orchestration systems should have the ability to support and interact with physical, proprietary solutions as much as the logical and virtualized technologies. If the function is identical, then there is no reason for a management and orchestration system to treat the two systems differently except for their physical footprint.
Challenge 4 is the fact that true orchestration that delivers desired automation for agility and elasticity requires analytics and heuristics combining different technologies and vendors. These systems are being developed but they do not fully exist today. It will take time for vendors, service providers and organizations to work together to fully develop these systems. It is essential for the system to be ‘carrier class’ and support the needs of a typical service provider while having the capability to manage multiple vendors, multiple disparate technologies, customer specific policies, and do this all with a holistic view of the entire core network as an ecosystem.
These are challenges that need to be viewed and addressed. There are expected benefits of the NFV architecture based on cost, operational efficiencies, business agility. The service provider industry will find ways to resolve these challenges and make NFV successful. Let us just hope that this happens sooner, rather than later.
