NFV – a path to fixing the interoperability obstacle

Telecoms.com periodically invites expert third parties to share their views on the industry’s most pressing issues. In this piece Doug Tait, Director, Director of Product Marketing at Oracle Communications, explains why a standard protocol, or at least standard goals and thinking, is essential if NFV is to live up to its promise.

It sounds too good to be true: a network where the software functions are separate from the hardware; yet that is exactly what network function virtualization (NFV) offers. It is a proposition that is music to the ears of communications service providers (CSPs) everywhere, promising to slash the costs stemming from updating, maintaining and enhancing network functions. Indeed, by decoupling network software from hardware, NFV delivers CSPs with options to run the very best software components on the very best hardware components.

Now this all sounds very good, but nothing in the world of communications technology is ever that simple. As we shall see, NFV really does offer CSPs a new and highly beneficial way of running a network, but there are significant challenges which must first be overcome.

A Virtual Network for a Virtual Age

For CSPs, the bifurcated network created by NFV makes perfect sense. We all know the software lifecycle is completely different to that of network hardware. NFV provides the blueprint to virtualise software and deploy agile services when needed, or when upgrades are required, all without time-consuming and expensive network redeployments.

NFV is doing for network technology what cloud computing has done for enterprise IT infrastructures: abstracting and virtualising applications to make for a more agile and cost-effective platform. Again following the cloud computing example: now the deployment model has been transformed, the next step is to free software functions. Specifically, NFV has matured to the point where CSPs can deploy on any suitable hardware – now it’s time that CSPs have more choices to deploy best-of-breed software on that hardware to build the best network possible.

However, this is the point at which the NFV story hits its significant snag: while hardware components are interoperable, network software components are not.

Interoperability Rears Its Ugly Head

For NFV, interoperability is required on two levels: 1) between virtual network functions (VNFs) and 2) between management and network orchestrators (MANOs) and the VNFs. Issues arise from taking existing network functions that do not interoperate and virtualising them into VNFs, as you are still left with network functions that do not interoperate. In fact, NFV exacerbates the problem, because there aren’t agreed-upon standards between the MANO and VNF. As a result, suppliers are only creating the best interface for the NFV products they actually own.

Of course, the problem of NFV interoperability is not new, and there have already been several attempts to create hard standards for network functions to fix it, such as TINA-C, JAIN, PARLAY and OneAPI. Unfortunately, none of these approaches managed to fully achieve software interoperability in the communications network. However, those invested in NFV are taking a new tack in the quest for interoperability by taking an open source approach. The aim is to create an open source reference implementation model for NFV which network equipment providers will follow; how successful it will be remains to be seen.

The original NFV whitepaper makes it clear that many of largest and most influential CSPs want to allow VNFs to proliferate in an open market where network providers may mix, match, buy, and deploy best-of-breed VNFs that would automatically connect and run their networks. But in order to make this objective a reality, full interoperability between VNFs and MANOs is required. So what is the best way for the industry to move forward from this stalemate?

Overcoming the Obstacles of Interoperability

When it comes to solving the great interoperability dilemma, it seems clear that rather than focus on one solution, the industry should consider an integrated and multi-step path capable of jumpstarting the VNF market.

Here are a few things that the industry should consider:

If CSPs are to embrace fully the network nirvana that is NFV, the significant hurdle of interoperability must be cleared—and soon. Whether it comes by way of standards, protocols, interface frameworks, or a mix, the industry needs to promote this new kind of culture of openness and innovation if it wants to achieve interoperability.

As Director of Product Marketing for Oracle Communications, Doug is responsible for driving the strategy and tactics for Service Delivery Platforms, Policy, Service Brokering, and IP integration. Prior to Oracle, Doug was the director for Global Telecom Markets at BEA and founded the JAIN initiative defining Java technology for communications at Sun.