• Home
  • Events Calendar
  • Blueprint Guidelines
  • Privacy Policy
  • Subscribe to Daily Newsletter
  • NextGenInfra.io
No Result
View All Result
Converge Digest
Wednesday, April 15, 2026
  • Home
  • Events Calendar
  • Blueprint Guidelines
  • Privacy Policy
  • Subscribe to Daily Newsletter
  • NextGenInfra.io
No Result
View All Result
Converge Digest
No Result
View All Result

Home » MEF aims to define the future of Lifecycle Service Orchestration – Part 2

MEF aims to define the future of Lifecycle Service Orchestration – Part 2

July 26, 2017
in All
A A

link to part 1 of this article

by Bartosz Michalik of Amartus

OpenCS Packet WAN project advances development of LSO

Together with Donald Hunter from Cisco, I have the privilege of co-leading the OpenCS Packet WAN project, which is one of the seven initiatives started in OpenCS ecosystem. The aim of the project is to deliver a reference implementation of an SDN controller that manages multi-vendor networks. The northbound API was released as a part of Presto SDK, which, in its current version, focuses on Presto network resources provisioning (NRP) models. Packet WAN is an open source module of the OpenDaylight controller called Unimgr. But, before I delve into the project details, let me take you on a journey through how we got to this stage of the development.

LSO hackathons throwback

The LSO development effort started in Dallas, in November 2015, during the first LSO Hackathon that was co-located with MEF’s GEN15 conference. At the time, I joined one of the Hackathon teams as a regular participant, and together with 40+ other colleagues from various vendor and provider companies, we were experimenting with the first ideas around Presto API. This experience had a great influence upon me, and it turned out to be extremely productive in terms of the LSO development. As I already mentioned at the beginning of this article, soon after the Hackathon I summarized the work of our team and presented it in this guest blog post at SDxCentral.

Since that first Hackathon, MEF organised three successful meetings in Rome, Baltimore and Frankfurt that saw developers, engineers and networking experts from MEF member and non-member companies invest their exceptional skills in LSO evolution. For a recap of the last Frankfurt Euro17 Hackathon, please go to this blog post by Charles Eckel, an Open Source Developer Evangelist at Cisco. At the consecutive Hackathons, we were crowded in a confined space and turning coffee, sweets and brainpower into Presto, Legato and Sonata LSO building blocks code. In parallel, on the official level, OpenCS and OpenLSO were launched, and the Hackathon teams could start remote collaboration on a daily basis.

To facilitate continuous development, MEF has built MEFnet, a compute-storage-networking platform, which delivers technical facilities for the Third Network reference implementations, OpenLSO and OpenCS projects, and gives interested parties an ability to evaluate APIs using reference implementations deployed to the MEFnet cloud.

Recently, we have implemented agile methodologies with the aim to iteratively deliver APIs, their reference implementations, and other artifacts that, when they are combined, will become LSO IRP SDK. And only a few months ago MEF initiated yet another program to welcome contributions from academia – namely MEF Software Developer Community. The idea is to give researchers and students an opportunity to participate in the development of Lifecycle Service Orchestration. The next edition of the LSO Hackathon is coming this fall to Orlando, co-located with MEF17. Check out this MEF17 link for more details and information on participation. All hands on deck!

What Is OpenDaylight Unimgr plug-in?

So, to return to ‘my’ Hackathon project. OpenCS Packet WAN is a project that delivers orchestration of MEF CE 2.0 services with SDN OpenDaylight controllers in combination with CE 2.0 networking devices. It has been developed as an OpenDaylight Unimgr module. For the current implementation, we use the ODL controller similarly as we did at the first Hackathon when we were experimenting with some ad-hoc Presto NRP ideas: https://wiki.opendaylight.org/view/Unimgr:Main.

However, the model itself has evolved a great deal – from the prototype, via the ONF Core model-based data model to ONF Transport API (T-API). We have also been working on improving the architecture of the solution and adjusting it to the model changes.

Unimgr is a platform that focuses on the Presto NRP-compliant network resource activation API and is a good starting point to making a network LSO-compliant. The most important concept in our Presto implementation is a driver that encapsulates protocol- and vendor-specific logic to make a sub-segment activation possible. What it means is that networks built using Cisco and/or Juniper devices, can be using two different drivers to manage these types of devices. In addition, a driver is required to contribute an abstract representation of managed devices to the Unimgr topology. Why? Because an NBI client (e.g. Service Orchestration Functionality – SOF) needs to know the current state of the network to be able to trigger resource activation requests.

To support other network vendors, there are three drivers being maintain – Cisco XR driver for MPLS, OVSDB driver for SDN-like networks, and a dummy driver, which can act as a template and requires a minimal amount of code to meet a Unimgr driver contract. Once the driver is installed, then Unimgr middleware will begin handling the RPC requests, decomposing them and triggering requests to the registered drivers if needed.

The Unimgr development plan is aligned with MEF SDK effort and OpenCS planning. In fact, the second iteration of OpenCS is about to be delivered as a part of the ODL Nitrogen release. Some of the new features include:

•   The implementation of the latest Presto NRP.

•   Support for P2P connection over multiple drivers.

•   Support for dynamic bandwidth changes in the drivers that we host in the project.

In addition, a simple implementation of MEF LSO Legato will also be delivered for the scenarios in which a fully-featured SOF (e.g. for a lab/experimental network) is not needed.

The future for the LSO ecosystem

The LSO ecosystem is dynamic and fast growing which means the future of LSO is very bright. However, it is important to continually grow this ecosystems, which means encouraging engineers and coders from more companies to join the upcoming meetings and hackathons. The next big LSO hackathon is in Orlando, FL, 13-16th November during the MEF17 show.

About the Author

Bartosz Michalik is a Software Architect at Amartus, a Certified MEF Engineer, and a holder of the MEF Recognition Award for LSO Hackathon blogging and facilitation. He leads the LSO Presto Hackathon project, and co-leads the OpenCS Packet WAN project together with Donald Hunter from Cisco. He is also a contributor to the Open Daylight UniMgr project. E-mail me at a Bartosz.Michalik@amartus.com with any questions or queries.

(More information about MEF’s Third Network Vision and Lifecycle Service Orchestration is available here: https://www.mef.net/third-network/lifecycle-service-orchestration)

Tags: AmartusBlueprint columnsmPlify
ShareTweetShare
Previous Post

SD-WAN Interaction and the Importance of Interoperability

Next Post

Hammer Fiber teams with Go Long Wireless

Staff

Staff

Related Posts

Mplify: NaaS the Foundation of the Agentic AI Era
AI Infrastructure

Mplify: NaaS the Foundation of the Agentic AI Era

November 11, 2025
Mplify: AI Connectivity, Automation, and Sovereign Infrastructure
AI Infrastructure

Mplify: AI Connectivity, Automation, and Sovereign Infrastructure

November 11, 2025
GNE Keynote: Lumen Envisions Programmable Backbone of the AI Economy
AI Infrastructure

GNE Keynote: Lumen Envisions Programmable Backbone of the AI Economy

November 11, 2025
MEF Rebrands as Mplify — What’s Next for AI-Driven, Automated Network Services
Clouds and Carriers

Mplify Launches LSO API Certification to Drive Global NaaS 

August 27, 2025
Mplify Sets AI‑Driven Agenda for Global NaaS Event in Dallas
All

Mplify Sets AI‑Driven Agenda for Global NaaS Event in Dallas

August 21, 2025
MEF Rebrands as Mplify — What’s Next for AI-Driven, Automated Network Services
All

MEF Rebrands as Mplify — What’s Next for AI-Driven, Automated Network Services

June 24, 2025
Next Post
Hammer Fiber teams with Go Long Wireless

Hammer Fiber teams with Go Long Wireless

Please login to join discussion

Categories

  • 5G / 6G / Wi-Fi
  • AI Infrastructure
  • All
  • Automotive Networking
  • Blueprints
  • Clouds and Carriers
  • Data Centers
  • Enterprise
  • Explainer
  • Feature
  • Financials
  • Last Mile / Middle Mile
  • Legal / Regulatory
  • Optical
  • Quantum
  • Research
  • Security
  • Semiconductors
  • Space
  • Start-ups
  • Subsea
  • Sustainability
  • Video
  • Webinars

Archives

Tags

5G All AT&T Australia AWS Blueprint columns BroadbandWireless Broadcom China Ciena Cisco Data Centers Dell'Oro Ericsson FCC Financial Financials Huawei Infinera Intel Japan Juniper Last Mile Last Mille LTE Mergers and Acquisitions Mobile NFV Nokia Optical Packet Systems PacketVoice People Regulatory Satellite SDN Service Providers Silicon Silicon Valley StandardsWatch Storage TTP UK Verizon Wi-Fi
Converge Digest

A private dossier for networking and telecoms

Follow Us

  • Home
  • Events Calendar
  • Blueprint Guidelines
  • Privacy Policy
  • Subscribe to Daily Newsletter
  • NextGenInfra.io

© 2025 Converge Digest - A private dossier for networking and telecoms.

No Result
View All Result
  • Home
  • Events Calendar
  • Blueprint Guidelines
  • Privacy Policy
  • Subscribe to Daily Newsletter
  • NextGenInfra.io

© 2025 Converge Digest - A private dossier for networking and telecoms.

This website uses cookies. By continuing to use this website you are giving consent to cookies being used. Visit our Privacy and Cookie Policy.
Go to mobile version