opinion


NFV – a path to fixing the interoperability obstacle

cloud virtualization nfv sdn - 1

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:

  • Establish an interoperability group to test, run and police software: One of the major roadblocks to reaching NFV’s potential is that there is very little standardised enforcement across the communications industry. A standards body or policing agency could help by validating and certifying that vendors’ products and solutions meet defined specifications.
  • Encourage open source community offerings: While open source communities do not have a charter to enforce interoperability, CSPs may use the reference implementation the communities produce as a model or means to test the VNFs.
  • Define a standard API for VNFs: Admittedly a standard API does not completely solve interoperability issues and does not enforce the standard between the VNFs into the MANO, but it would provide a universal programming interface for all VNFs. VNF providers may produce their products despite not having their own MANO product.
  • Define a standard protocol: The industry need a standard protocol that it could adopt as a universal standard. This would enable CSPs to compare vendors, supporting a fair and free market, as CSPs can buy the best product for their company without fear that the vendor is not violating standards.
  • Create an interface framework in the VNF manager: Another way to encourage adoption of NFV is through a VNF plugin framework. In the absence of hand protocol standards, an interface framework would allow suppliers to build and test executable plugins that interface with their products, yet run within the VNF manager. This would promote technical interoperability between the VNF manager and the VNF, while opening the market for suppliers to work together. The benefit of this approach is that when the industry finally produces a standard, the only update required would be the plugin; the VNF manager and the VNFs would require little change.

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.

 

Doug TaitAs 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.

  • OSS in the Era of SDN & NFV

  • NFV and Carrier SDN


Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Polls

How have open source groups influenced the development of virtualization in telecoms?

Loading ... Loading ...