Industry Blog

Which platform will you use for NFV?

Fergus Wills is Director of Product Management for Openwave Mobility

In 2015, as operators push for the agility and cost reduction that NFV enables, they face a fundamental, and complex decision.  Namely, on what platform should you base your implementation of NFV?

When selecting a platform, there are a couple of obvious initial considerations.

Firstly, openness.  An open ecosystem allows for a greater number of vendors to integrate, providing a greater range of Virtualized Network Functions (VNFs).

And secondly, cost.  If the ultimate goal is to reduce costs, then investing in expensive software licenses may negate any gain achieved by deploying virtual network functions versus traditional dedicated hardware solutions.

Business transformation

But there is a third, critical consideration that is sometimes overlooked.  That is the transformative potential of an NFV platform.

Certainly, there are the much discussed benefits to thinking about NFV from a transport layer perspective.  The cost savings of a virtualized transport layer using Commercial Off The Shelf (COTS) hardware are obvious.  And the simplicity that it could bring is attractive. But that leaves so much on the table.  NFV does not just have to be a cost-saver.  It can be a revenue-generator.  With NFV, there is the potential for a new wave of openness with content providers and enterprises, which can be leveraged to generate new income streams.  This is where NFV stops being a transport layer optimizer and becomes a business transformer.

One implication of this is that as well as involving the packet, transport and secure layers of the protocol stack, we must add Application, Policy, Profile and External Web Interfaces to our thinking.

So, coming back to the central question with new qualification…  On what platform should you base your implementation of NFV in order for it to be a long-term enabler of business transformation?

NFV reference architectures

The starting point for NFV is a clear reference architecture – this has been addressed by ETSI as well as groups like OpenStack and Open Platform NFV (OPNFV), providing reference NFV architectures that define key interfaces including compute, storage, network and orchestration.

OpenStack’s core services Nova (Compute), Cinder (Storage), Neutron (Network) and auxiliary service Heat (Orchestration) neatly overlay the ETSI architecture. This goes a long way to explaining the dominance and momentum of this open platform.

Commercial systems muscle in

However it’s important to remember that while OpenStack, like Linux, is open and free, that does not mean every deployment is open and free. A number of vendors including RedHat, HP, Mirantis and VMWare are already offering their own versions of OpenStack, with a specific set of supported services and components.  While OpenStack is open and supported by multiple large organizations such as RedHat, IBM and Cisco, it is still maturing.

To really understand the pros and cons, the trade-offs and compromises of each system, we need to take each function in turn.  For a full breakdown of each function and how each major group (VMWare, Openstack, and AWS) addresses it, please download our recent whitepaper, SDN.NFV.Cloud. Evolving Mobile Data Access.

For now, we’ll focus on application data streams (layer 4-7 in OSI), orchestration and VNF management. Value for mobile operators has moved away from voice and SMS into mobile data. It is critical in new service architectures to have the virtualized network tools to selectively engage user sessions, interact with their data streams and add value to both user and content provider.

The importance of open orchestration

In reference implementation terms, orchestration and VNF management is a maturing area, with a number of vendors competing to be the reference implementation. It is our view that regardless of how open the rest of the platform is, if the orchestrator is closed, then the number of vendors who are capable of easily integrating it is reduced. And this undermines the business options for the operator.

OpenStack is evolving its own orchestration service, Heat, which is maturing with each release. Heat can create and launch virtual resources, but the key is a VNF Manager (ETSI). This adds application logic and instructs Heat when to scale and when to do it. Each VNF will have its own rules around this. The Linux foundation, in collaboration with multiple vendors and operators are addressing the additional management aspects of OpenStack through Open Platform NFV. In the absence of standard interfaces for VNF managers, Openwave Mobility has developed its own software so that it can easily and openly integrate with 3rd party VNF Manager and Orchestration services.

Conclusion

The move to NFV and dynamic orchestration is transformational. Moving from a fixed, dedicated appliance infrastructure will require new operational techniques and new ways of defining vendor SLAs.  The challenge is complex, and in assessing a solution from a value perspective it must also be assessed from the core telecom services perspective of: scale, resiliency, performance, cost and latency.

The technology choices made at this stage may be critical to longer term success. Core questions have to be asked.  Does the technology lead to a vendor lock-in for software rather than hardware?  Is the technology sustainable, will it scale, is it reliable?  Will vendors cooperate and interoperate with the standards interfaces?  Will the processing of traffic and signalling streams be predictable and consistent in a software orientated environment?

Only when these questions are asked and answered will operators be able to start or continue their journey towards the transformation that NFV will enable, with confidence.

For more information, read our whitepaper SDN.NFV.Cloud. Evolving Mobile Data Access.

A related article was also published on SDX Central.