Open Source MANO: Addressing Interoperability Challenge in NFV

September 2018 

By Sagar Nangare, Principle Executive – Digital Marketing, Calsoft Inc.

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 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 extra ordinarily deliver performance and improvements. MANO framework should provide service agility and continuous optimization and requires 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 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 need to provide incorporation of MANO elements like NFVO, generic VNFM and specific VNFM modules from different vendors. OSM fits in altogether in this case.

 

Fig.1 - Interoperability of OSM

 

In its latest Release FOUR, OSM enhanced features to provide better functionality, user experience and maturity. It included improvements in monitoring, assurance, closed loop capabilities, easy cloud native installation, much leaner footprints – 75% less RAM consumption, new 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.

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 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

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 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 variety of NFV implementations and add more value to interoperable OSM stack.