Originally published in the September/October edition of VanillaPlus
The difference between communications service providers (CSPs) and the IT industry is like the difference between First World War infantrymen and a modern coalition of crack special forces units. One set plods along in formation, getting picked off at will, while the others make rapid advances, capturing territory while constantly keeping tabs on the other teams and ready to regroup, writes Nick Booth
It’s small wonder that CSPs fail to keep pace with their agile ‘frenemies’ at Amazon, Facebook and Apple who are going over the top at speed and mopping up revenues.
While the telecoms industry loves to meet its obligation to create universal standards there is an argument that this is folly and that adherence should be modified if CSPs are to reap the benefits of software defined networking before it’s too late. Currently the standardisation approaches for network functions virtualisation (NFV) fall between two stools. The de jure standards created by industry bodies are pure but are avoided like the plague by vendors, as they do not play to their strengths. The de facto standards are only decided by the exclusive group of vendors acting in their own interest.
The European Telecommunications Standards Institute (ETSI) has pulled in enough vendors to make its NFV standards a strong de facto platform. The Open Networking Foundation (ONF) isn’t quite as strong, say analysts below. The Internet Engineering Task Force (IETF) and the Alliance for Telecoms Industry Standards (ATIS) are both struggling to drive de jure standards because of a lack of overall agreement and are several years behind where they need to be, according to Bernt Ostergaard, the service director at telecoms analyst firm Quocirca. “However, whatever these groups do come out with will be nominally embraced by the likes of ETSI and the ONF – because it is good form to do so,” he says.
This leaves one more group of NFV standard bearers, the open source camp. Again this is fractured with the two biggest groups, OpenDaylight (OD) and the OPNFV, each having backing from different vendors. “It’s most likely that the standards developed will find their way into the underpinning software layers, and so will be the base layer of the NFV stack,” says Ostergaard. On top of the OD or OPNFV standards will be extras – the elements that ETSI and ONF want to see, says Ostergaard. This makes it likely that the IETF and ATIS will be bogged down and so far behind that they have nothing to show for their work.
Two noteworthy initiatives are OSM and the Open Orchestrator Project.
OSM has emerged from the combined efforts of Telefónica, Telenor and BT around OpenMANO. “The Mano options could give you great savings, but most CSPs don’t think the technology is quite there yet,” says Jonathan Bell, the vice president of marketing at OpenCloud, which develops software for telecoms NFV. The Open Orchestrator Project (OPEN-O) has big-name support too with China Mobile, China Telecom, Ericsson and Huawei some of its more prominent supporters.
The end result of this diversity is confusion. “NFV is an orgy of hardware and software vendors. Standardisation means customers can more easily switch suppliers for best-of-breed environments, but keeping up is a much bigger challenge,” says Ostergaard.
Though software defined networking and NFV changes the game for the dominant hardware manufacturers – it doesn’t make them go away. They are still the major solution providers with the extensive integration-tested partner ecosystem to provide complete multi-brand NFV packages. Virtualisation has greatly reduced the hardware footprint in the data centre, but with a host of new providers customers face complex software update tasks and scalability challenges.
A lot of patience is needed among CSPs, says Giuseppe Monteleone, senior technical marketing engineer for Italian vendor Italtel. “Almost four years since the start of the ETSI group we share a common vision and a reference framework but we still miss the precise definition of important protocol interfaces,” says Monteleone, “on the other hand, we have de facto standards consolidated with the work of open source communities.”
Another issue to be confronted is licensing, says Greg Colllins, an analyst at Exact Ventures.
CSPs are justly resentful of paying for network capacity licences that are superfluous. With NFV and cloud network elements, having pay-as- you-go or post-pay licensing seems to make the most sense, says Collins. With NFV and cloud, network capacity is dynamic and elastic, yet traditional licensing requires CSPs to buy a static amount of capacity. If they could pay for just the capacity they used, CSPs could save on licensing costs and avoid the headaches associated with managing the various licensing models.
The CSPs need an open ecosystem and the current scenario is still too fragmented, says Monteleone. A more realistic approach would focus on basic interoperability between entities from different vendors, such as VNFs and MANO systems, in order to orchestrate a wide catalogue of tools. You don’t have to standardise everything right away. It might be better to regularly consolidate on a continuous process of innovation and experimentation.
“The initiatives taken around standardisation have helped significantly to advance the NFV architecture definition and identify NFV implementation and deployment challenges,” says Amol Phadke, global network virtualisation and transformation lead at Accenture.
Market activity so far has shown vendors and service providers how to develop and deploy NFV. They should trust the evidence of their own success, rather than the guidance of standards committees, according to Phadke.
“The pace of progress with some of these initiatives has been slow and has lagged real world deployments. The scope of some of these standardisation activities has also been limited in that they do not provide a complete NFV solution but rather only a piece of the puzzle,” says Phadke.
Ultimately, NFV could be more successfully brought to market if there was less obsessiveness about unifying every last aspect of it and advancing all parties together, says Bell at OpenCloud. A more lightweight and less encompassing approach, led by AT&T in the OpenStack camp, would enable individual projects to advance faster. These advanced parties, that progress on a variety of fronts, could all be cross-referenced and catch up with each other at intervals, as happens in the IT industry. As it is, the pace of progress in the CSP sector is relatively slow.
Get in touch