ETSI and the Linux Foundation have announced they will be trying to align their working groups more closely.
The MoU is an effort to speed up the standards processes and make them more flexible, whilst adding some definition and interoperability to the open source landscape. In essence it’s about using standards processes to put some shape and interoperability into the open source projects and it’s about using open source methods to put some speed and agility into the standards process.
As a very rough background, we got here because ETSI and 3GPP standards and specifications for NFV and MEC (seen as a subset of NFV) didn’t actually define, or in some cases attempt to define, in clear enough fashion all the functions that could help operators get an operational system going. As an example, there were overlaps and grey areas in terms of the automated management of VNFs, in virtualised infrastructure management, as well as in overall orchestration and service orchestration.
Some therefore looked to other methods to deliver the code they needed to manage, operate and orchestrate the virtual network entities and services running over them. Enter open source. The best known of these in the management and orchestration area is ONAP, but there are a host of open source based networking projects, many of them running under the auspices of the Linux Foundation. These include edge stack focused projects like Akraino (also out of AT&T originally), and of course wider efforts such as the SDN-focussed ODL and OPNFV.
At the same time, ETSI had its own open source based MANO project running – OS-MANO – principally backed by Telefonica. There’s also been a long-standing effort to define operation of edge based virtual functions within its MEC ISG.
The issue for the industry as open source methods became more widespread was accepting a trade off of speed and flexibility versus fragmentation and potential loss of interoperability. The diversification of open source efforts has been a stated telco concern. De facto standardisation would only arrive if a critical mass of operators all fell in behind one effort or another, but another route would be to use the open source projects to speed up definitions of specifications within ETSI. Or to use standards to ensure interoperability between methods. That, of course, would involve working across the SDO and the open source project, defining APIs and management interfaces.
And that’s what we’re seeing. Despite stereotypes, it’s not really the case that we have a crusty old telecoms types taking two years to write static specs over here, and go-ahead coders over here, hacking away at challenges and contributing to a common code base upstream. For one thing, as Luis Jorge Romero, Director-General, ETSI, says, “Open Source has been part of our working methods and our technical groups, Open Source MANO being an example, for several years now. Further collaboration provides the standards community with a quick feedback loop on how our specifications are being implemented.” For another, given that telcos themselves are giving up resources into all these projects, and that they have limited resources, we’re often talking about the same people working on both “sides”.
For their part, as well as Linux Foundation groups having the involvement of major corporate entities, those entities also recognise the danger that fragmentation can act as its own brake on progress. For instance getting ONAP to a commercially consumable, modular product beyond its overall framework has been a key challenge. Telcos would like software they can use to automate and manage cloud network ops and services without paying large Systems Integrator or vendor integration fees to make sense of it all. Whisper it, but that requires an element of standardisation.
So now we have an agreement for ETSI and LF to work more closely, and this table maps how that might happen, and where there is still a fair bit to do.
How, for instance, might the OS-MANO and ONAP deliverables be aligned? The table proposes to “Explore opportunities for interoperability over NFV APIs and OSM IM.” That’s early stage stuff, although TMN is aware of work by Amdocs, for instance, to enable VNFs that can work without further development in both environments.
There’s also a proposal to contribute ETSI’s MEC APIs into the open source edge-focussed Akraino base, and to explore how OS-MANO and Akraino-managed infrastructure might be interoperable.
There isn’t much information yet about how these systems will work to give industry the consumable product that it wants, but let’s see how that shakes out.
