Open Source MANO (OSM): Addressing Interoperability Challenge in NFV

This article was originally published on ETSI OSM blog. I am re-publishing it here.

NFV introduced in 2012 along with stating its benefits, especially for telecom domain. But there were challenges associated with actual implementation.

Mainly, it was associated with the management and orchestration (MANO) layer. After a few years, solution vendors who decided to offer NFV realized that to achieve full exploitation of NFV for business benefits MANO framework should extraordinarily deliver performance and improvements. MANO framework should provide service agility and continuous optimization and requires a common approach from one carrier or ecosystem to another allowing interoperability.

In 2016, ETSI formed an open community named, Open Source MANO (OSM). This post is about how OSM is addressing challenges associated with orchestration, interoperability and performance optimization which ultimately focused towards making NFV as a mature technology for telecom domain.

Achieving Interoperability

OSM offers E2E service orchestration which simplifies NFV lifecycle. The core of OSM is that the framework based on ETSI NFV standards and Information Model provides interoperability among different service provider NFV infrastructures or OSS systems. Interoperability in the sense that MANO stack needs to provide incorporation of MANO elements like NFVO, generic VNFM and specific VNFM modules from different vendors. OSM fits in all together in this case.


Interoperability of OSM
Fig. 1 – Interoperability of OSM

In its latest Release FOUR, OSM enhanced features to provide better functionality, user experience a, d maturity. It included improvements in monitoring, assurance, closed-loop capabilities, easy cloud-native installation, much leaner footprints – 75% less RAM consumption, new north northbound interface which is aligned with ETSI NFV specifications to provide single pane control to OSM systems. Upcoming Release FIVE will be more focused towards giving telecom service providers 5G-related features, like Network Slicing and container-based VNFs.

Let’s have a look on how OSM operates with rich information model specified in ETSI’s NFV ISG.

Fig 2 – OSM Architecture: Rich Information Model
Fig 2 – OSM Architecture: Rich Information Model

Information model leveraged by OSM embeds all the operational procedures and requirements for orchestration of services and resource across other elements of MANO stack and NFVI. Basically, IM required to address lack of dependencies raised within management and orchestration functions. OSM emphasizes on the clarity with common information model along with its mapping with data model enrich OSM to be a more interoperable (like in fig 1). As you can see OSM architecture in fig 2, which instructions packaged in IM at upper layer completely take control on overall operations where MANO stack is deployed. The resulting OSM stack could be suitable for all VNFs, does not depend on any single VIM platform and SDN platform.

Enhancements in Release FOUR

Fig 3 – Release FOUR additions to architecture
Fig 3 – Release FOUR additions to architecture



A major and prominent enhancement with OSM Release FOUR is addition of unified message bus which is implemented with Apache Kafka. This bus allows asynchronous communication between OSM components and enables the introduction of new modules which can be easily pluggable. In above fig 3, Monitoring Module (MON) and Policy Module (PM) were added in release 4 which are used to provide policy management, fault and performance management for functions like auto-scaling, obtaining performance metrics, etc. Also, Lifecycle Management module (LCM) is added which replace the Service Orchestrator (SO) in previous architecture.

As stated in OSM Release FOUR whitepaper, OSM community has taken a huge leap forward but these additions made architectural changes to make OSM more mature to get adopted for use cases which are highly in demand by service providers. These enhancements made OSM stack more applicable to a variety of NFV implementations and add more value to interoperable OSM stack.

Leave a Reply

Your email address will not be published. Required fields are marked *

Show Buttons
Hide Buttons