Telcos want to move fast but they also need to move together, which slows them down. Vendors want to move fast and compete with each other, but to ensure they all get the largest possible addressable market they also need to move together.
Collaboration is an anchor on innovation, but sprinting ahead of the pack means you might hit the wall later in the race.
Ideally, these conflicting forces were resolved through standards. Competing visions and interests were bashed out and resolved to a workable compromise and that became a specification that was then formalised into a standard. Then the vendors went and added bits on top, and vendors and telcos implemented those standards in different ways, and often ended up with a custom install of a standard solution that “locked” them to their vendors.
To recognise a problem is not necessarily to solve it. When NFV was outlined, seven years ago now, the aim was to disaggregate hardware from software, to achieve vendor interoperability and a flexible application environment. Into the standards organisations it went – namely ETSI NFV. But standards, as we knew and as we know, weren’t enough. As ETSI defined the architectural model for NFV, some bits were left out. Some bits overlapped. There was room for interpretation and for individual code fixes and specific integration and the whole big vision dimmed.
This week at Open Network Summit Europe, an event organised by open source networks facilitator and umbrella group the Linux Networking Foundation, the industry was still wrestling with the key issues.
As a top line example, Vodafone’s Director, Technology Strategy & Architecture, Matt Beal said he had three main issues. First, VNF implementations on NFV infrastructure were inconsistent (despite ETSI NFV standards). Second, some VNFs can only talk to some orchestrators, and some orchestrators can only talk to some VNFs. Cloud Native Functions have also been slow to arrive because now there are lots of different ways to implement the cloud.
The linkage between VNFs and orchestration had “come much later in the game than I envisaged”. VNF and NFVi deployment is still an “artisan” rather than an “industrial” process.
Beal did have solutions. NFVi behaviour can be solved by adopting CNTT “patterns” – VNF vendors will not get their own scale benefits (and therefore produce products) if telcos are all giving them different targets. “We have to get consistent in terms of what standards we require of VNFs and orchestrators”.
VNF-orchestrator interworking can be addressed by taking on board TMF APIs and by mandating ONAP support. The bottom layer was more cloudy – but it relies on a common cloud infrastructure with an abstraction layer to the CNFs, not a selection of vertically integrated clouds.
Taking Beal’s two slides as a jumping off point, let’s look at each of those.
CNTT – Cloud Native Takes Time
In fact CNTT stands for Common NFVi Telco Taskforce. This is what Beal thinks can solve the infrastructure-related issues. AT&T’s Amy Wheelus, VP Network Cloud, also called for the industry to stop trying to compete on the infrastructure layer – and that too makes sense in terms of CNTT.
CNTT has been formed as an initiative hosted by GSMA and LF Networking, and it aims to trim all the different NFVi Profiles that have sprouted up into a set of consolidated options. That has been described to TMN as a line by line process that trims away what is not needed to produce a set of reference profiles for particular deployment models. It will also develop testing and verification requirements and will sit as part of the LNF’s overall certification and validation programme known as OVP (OPNFV Verification Programme).
CNTT is only three meetings old and until now it has been led by operators, but of course vendor involvement is crucial. Verizon’s Beth Cohen, also on stage during ON Summit, said that she had been frustrated so far by “a whole lot of vendors who have not been participating in these tests.” Off stage she slightly tempered these comments, saying that vendors are aligned – she just wants to see more of them getting involved.
Arpit Joshipura, GM Networking, Edge and IoT at the Linux Foundation, said that vendors have been holding back from CNTT due to a niggle over the open source license – Apache 2.0 – that had originally been agreed upon for the programme. That has now been sorted out with a tweak to licence terms and we will see a whole lot more vendors join the Taskforce, he said.
He added that the wider point of CNTT is that its standardised profiles will be just a part of the LF Networking’s OVP – which will outline how to do testing and deployment of VNFs within ONAP for orchestration, VIM with OpenStack and so on. This will mean that a vendor can download test scripts for a chosen implementation, automate the test based on the chosen stack using OVP tooling, and then go to an operator with OVP compliance that includes the NFVi profile plus orchestration and VNF management.
The clear inference to be drawn from the creation of this taskforce is that what has been done to date on NFVi and VNF management has not worked. It hasn’t worked well enough for operators and it hasn’t worked well enough for vendors. But speed is now of the utmost importance.
It is, of course, early days for CNTT, and although the group is mushrooming, telcos are waiting now for tools that can get them to their automated, orchestrated, cloud-native vision.
So… ONAP
A year ago there was a lot of talk about the need for ONAP to be more “consumable” by telcos, to be more modular in its architecture and to be more of a hardened commercial offering.
All of that, said Joshipura, is now sorted – “it is behind us” he told TMN. To precis his words: the code has matured, and vendors can see that there is now real operator money behind it. The latest release – Dublin (ONAP Releases are named after the cities in which the working groups meet to agree final release) – sorts a lot of that out. There are 16 operators now with live ONAP deployments. So… all sorted.
Not that ONAP is really viewed that way, even by its own proponents, on the ground. It is necessarily a work in progress. A session from Orange’s Eric Debeau, Head of Network Automation, outlined the desires he still has for the platform. He granted there had been big progress since the Amsterdam release, which was very hard to deploy. But there is still scope to reduce the code required in the design stage on ONAP and get to a more model-driven approach. He is also missing tools to verify what he has built. And he wants a more streamlined method of configuring VNFs. “It’s not currently user friendly. Today to deploy a VNF we have many choices/pathways – which could be seen as a positive but we don’t know which path to use. Also we need to test all these combinations. It’s better to have one path that has all the features we need.”
ONAP is also too big – it’s 100 gigabytes of memory in its full implementation. He would still like to see a more flexible and reduced footprint to make it easier for telcos to grapple with.
China Mobile’s Lingli Den had a different target in mind. She wants ONAP to define interfaces that would enable the carrier to disaggregate and decouple software elements so that it can create and manage network slices more easily. That would mean that it can support functions from different software vendors within its network – which it says would give it much more flexibility across its large network. The issue is that nobody is defining those internal interfaces.
“3GPP SA5 defined the functional architecture and model for slice management, but is not planning to specify any related interfaces which are key to decoupling management functions – which we see are essential,” she said.
So the operator wants to see the next ONAP release, Frankfurt, pick up on this and define the interfaces between the management functions. If ONAP doesn’t then China Mobile might get on and do it for itself.
But niggles aside, and scope for improvement is hardly surprising, there’s little doubt that an increasing number of large operators will mandate ONAP support for the automated orchestration element of their NFV deployments. There is, you would feel, still going to be a sizeable distribution or integration opportunity in amongst the T2/3 players.
