Team of companies belonging to both groups will work on making sure LSO interfaces match ONAP needs at key north-south and east-west connections.

October 11, 2017

4 Min Read
ONAP & MEF Formally Team on LSO APIs, Framework

MEF and ONAP are formally teaming up, agreeing to work jointly on key aspects of MEF's Lifecycle Services Orchestration framework, including specific interfaces that will ultimately allow end-to-end services across multiple operators' ONAP deployments.

The formal memorandum of understanding means MEF becomes an associate member of Open Network Automation Platform (ONAP) while ONAP's host organization, the Linux Foundation, becomes an associate member of MEF. (See MEF, ONAP Collaborate on LSO, Automation.)

More practically speaking, a group of companies that belongs to both organizations will become part of a sub-project under the existing team addressing standards development organizations, says Arpit Joshipura, The Linux Foundation's general manager of Networking & Orchestration, in an interview. That sub-project team will work out the next level of detail in making sure the APIs being developed for MEF's LSO will work with ONAP's specifications. Their work will then be reviewed and approved by the ONAP technical steering committee and put into the open source code that ONAP releases, with that group also responsible for any upstream changes that follow, Joshipura says.

Specifically, the joint effort will focus on the LSO Legato API, a key northbound interface in the LSO Framework that defines the connection to operations and support and billing systems (OSSs/BSSs), says Daniel Bar-Lev, MEF's director of the office of the CTO. "If we can agree we'll both use LSO Legato APIs, that is a great step forward and that is one of our initial objectives," he tells Light Reading.

There is also a focus on using two other APIs -- LSO Sonata and LSO Interlude -- as a means for network operators to enable their ONAP implementations to interact, since each operator's use of ONAP will be adapted to its own existing network operations, Bar-Lev adds.

Figure 1:

"This is really where the collaboration is going, where the rubber meets the road," he commented. "If we can get this down, where we agree on using LSO Legato and how that should be done, that makes sense for physical network functions as well as virtual network functions to seamlessly work together. We can also provide that east-west connection, which ONAP isn't dealing with, through LSO Legato and LSO Interlude, and then we'll be able to take different ONAP implementations in different providers and actually start seeing and demonstrating end-to-end services using ONAP."

Bar-Lev says MEF members are going to make available the ONAP implementations in their networks and labs for interaction through the MEF-ONAP collaboration, as soon as late this year, following MEF17 in Orlando in mid-November.

Standards developing organizations (SDOs) and open source groups have been promising to work more closely together, to ease both network operator and vendor concerns that the proliferation of organizations tackling specs and standards has become confusing and overwhelming, but this is one of the first formal agreements of this type that specifies work between an SDO and an open source group.

Joshi says it won't be the last for ONAP, which is set to issue its first software release by year's end, adding that such collaborations will focus on groups engaged in work areas directly adjacent to ONAP's work. As for the scope of that work, ONAP is moving in the opposition direction of Open Source MANO, which this week dropped a software release that positions OSM as a component for NFV orchestration. (See OSM's New NFV MANO Release Sticks to a Focused Approach.)

"We believe that ONAP is now turning out to be the de facto automation platform for carriers," Joshi says. At the group's recent technical meeting, further progress was made on the ONAP architecture that will be foundational for its Amsterdam software release, shown below.

Figure 2:

"It is very comprehensive, and not only is it multivendor, it is multi-cloud. You have the VF-C drivers in there, SDN agents in there, controller drivers, etc.," he says, along with VNF onboarding requirements. "The team is working toward year-end delivery with about 30 projects approved in this release."

— Carol Wilson, Editor-at-Large, Light Reading

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like