In 2015, as operators push for the agility and cost reduction that network functions virtualization enables, they face a range of fundamental and complex decisions. In simple terms, this can be isolated to the question: On what platform should you base your implementation of NFV? But in more complex terms, the choice represents how the service is orchestrated, how it scales, and how it performs – whether you are setting up your own NFV infrastructure (NFVI) or using a systems integrator. Understanding these choices can enhance your business and operational options in the long term.

In the technology selection there are a couple of obvious initial considerations:

1. An open ecosystem allows for a greater number of vendors to integrate, providing a greater range of virtualized network functions (VNFs).
2. If the ultimate goal is to reduce costs, then this will partly be achieved by the adoption of commercial off-the-shelf (COTS) hardware, but it also has to be considered from a software licensing perspective – both the functions themselves and the new management structure required for the virtualized operation.

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 of thinking about NFV from a transport layer perspective. The cost savings of a virtualized transport layer using COTS hardware are obvious. And the simplicity that it could bring is attractive. But that leaves a lot on the table. NFV does not just have to be a cost-saver; it can also 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 and signaling-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.

Returning to the central question at hand, we should ask: On what platform should you base your implementation of NFV in order for it to be a long-term enabler of business transformation?

The starting point for NFV is a clear reference architecture. This has been addressed by ETSI and by groups like OpenStack and Open Platform NFV (OPNFV), which provide 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.

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.

The chart below summarizes the key features and how each major group addresses it.

To really understand the pros and cons, the trade-offs and compromises, of each system, we need to take each function in turn.

For now, we’ll focus on application data streams, orchestration, and VNF management. Value for mobile operators has moved firmly 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 the user and the content provider.

In implementation terms, orchestration and VNF management is a maturing area, with a number of vendors competing to be the reference implementation. A key consideration in an open environment is how the performance of the system can be measured from a service level as part of the service level agreement (SLA). In the case where there are multiple VNFs or VNF forwarding groups that define the service, the SLA will be federated among multiple vendors. The orchestration and management function must allow for the transient instantiation of VNF. This includes taking care of possible SLA breaches because of physical/resource network issues, the possibility of a VNF being “dead on arrival” and failing to start, or a fault occurring in a different VNF in the forwarding group and network service chain.

The move to NFV and dynamic orchestration is transformational. Moving from a fixed, dedicated appliance infrastructure will require new operational techniques (for example, managing scenarios where reserved resources are not available or a VNF fails to start or to receive traffic) and new ways of defining vendor SLAs (for example, where an SLA is shared among multiple VNFs).

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, resilience, performance, cost, and latency.

The technology choices made at this stage may be critical to longer-term success. In defining your own NFVI or using a system integrator, the key questions of resilience, fail-over, scale, and performance need to be defined for each virtualized service. Adopting open technology on COTS hardware provides the most flexibility – but this does come at a cost, as the timing of an open API definition (and the associated vendor adoption) can lag behind the service demands of the telco cloud.

In assessing the business and technical transformation to the telco cloud, the speed and agility demanded by the business must be tempered with new orchestration and service management techniques so that the transformation can successfully evolve.