ONAP vs OSM – The Battle for NFV Management and Orchestration Supremacy

ONAP Vs OSM – Who Will Win?

There’s a lot of open talk about the best way to operate an efficient, scalable, automated network infrastructure. One of the main challenges encountered comes to the ability to offer high availability services while in parallel having the agility to swiftly deploy new services. DevOps has a need to keep ongoing operations running, while keeping costs low. These things needn’t be contradictory.

There is an answer to this challenge, and it’s a combination of cloud computing, network functions virtualization (NFV), and the software-defined network (SDN). With these approaches, it is possible to operate different network functions over the same hardware, both in on-premises and public clouds.

For these technologies to reach their full potential, operators need a new approach to managing network architectures. NFV Management and Orchestration (NFV MANO) is a crucial aspect of cloud infrastructure when it comes to unlocking the full potential of virtualization of network functions: scaling, simplified infrastructure operation, and faster deployment of services. This makes it important to select the right approach for orchestration and management, as well as the development framework.

Read on to learn about the advantages of two primary frameworks: ONAP, and OSM.

About ONAP

The Open Network Automation Platform (ONAP) is an open-source software platform. It enables the design, creation, and orchestration of services on the infrastructure layer sitting on top of individual virtual network functions or SDN, or a combination of the two. ONAP was originally developed as a combination of OPEN-O (Linux Foundations OPEN-Orchestrator Project), and the AT&T ECOMP (Enhanced Control, Orchestration, Management, and Policy) platforms, forming its own unique code.

The primary objective of ONAP is to address the rising needs for a common platform with the capability of providing efficient, end-to-end infrastructure management. It also serves to speed up the delivery of different on-demand services, and enables automation of the majority of associated processes.

ONAP architecture consists of two major architectural frameworks — design-time environment and execution-time environment — with numerous separate subsystems operating within them. A design-time environment is used as a development environment with all the functions and libraries needed for the development of new capabilities; the environment can be used to upgrade of existing capabilities through portal, role-based interfaces, and CLI. With a design-time environment framework, the Service Design and Creation can be used as visual tool for designing and modeling assets used in all ONAP components, while the POLICY subsystem is used to make policies and conditional rules.

Two major architectural frameworks meet to comprise ONAP, with numerous separate subsystems operating within them:

• Design-time environment – the development environment with functions and libraries to support development of new capabilities. This environment may be used to upgrade existing capabilities through role-based interfaces portals, or CLI. With this environment framework, the Service Design and Creation can be leveraged as a visual tool for the design and modeling of assets used in ONAP components, with a POLICY subsystem being used to make policies and conditional rules.
• Execution-time environment – a framework used to execute the policies and rules that have been prepared in the design-time environment. The policies and rules are responsible for a variety of things, such as data collection, analytics, and resource inventory. They also handle various tasks including service orchestration for end-to-end service automation, performance monitoring, and security based on ECOMP. Using the Closed Loop Automation Management Platform, ONAP also enables the management of virtual network function life cycles, and for the automation of deployment processes.

Learn more about ONAP with ONAP Training

About OSM

Open Source MANO (OSM) is an ETSI-hosted initiative, aimed at the deployment of open-source NFV management and orchestration software stacks, and is fully aligned with the ETSI-developed NFV reference architecture. The ETSI entity labeled OSM as OSG (Open Source Group) – one of the first projects to be given this association – which allows open source projects to be developed under ETSI.

ETSI has historically focused on standards, and the OSM expands this focus to open-source tools such as GitHub. Hosted by ETSI, OSM is also based on existing components such as Telefonica’s OpenMANO project, RIFT.io’s orchestrator, and Canonical’s Juju generic VNF Manager.

Essentially, OSM aims to align activities in development with the evolution of the ETSI NFV standard, enabling operators and vendors to have an ecosystem supporting delivery and deployment of services in a cost-effective manner. It should allow network architects to leverage synergies between the open-source approach and the ETSI NFV standard, which are important when developing Management and Orchestration infrastructure. The two major components of OSM are run-time scope, and design-time scope.

The run-time scope’s primary purpose is the simplification of service and lifecycle management, and supports different functions such as automated service orchestration. It also performs cloud provisioning for SDN controllers, including plugin models integrating multiple controllers. It also includes delivery of plugin models for the integration of VIMs (even multiple VIMs). 

Run-time scope’s Generic VNF Manager is a crucial function for controlling VNFs with demand-based support for specific VNF Managers. It also supports the integration of a new Physical Network Function into an automated service deployment, and the integration of multiple monitoring tools through a plugin model. 

Create Production-Grade NFV Deployments With Cloudify

Design-time scope supports a model-driven environment fully aligned with the ETSI NFV standard. It includes functions for creation, update, and deletion of service definitions. It also provides a GUI to accelerate VNF onboarding, deployment, and service design time.

ONAP Vs OSM

Wondering how to evaluate the difference between OSM and ONAP? There are several ways to go about it.

Firstly, both are frameworks which are used by major network vendors and global service providers. For service providers, ONAP is the leading choice as it has been adopted by a larger group of global providers (AT&T and China Mobile, for example). ONAP has comprehensive coverage across North America and Asia, though in Europe there is less support, making OSM the stronger choice in the region.

That said, ONAP comes out on top when analyzing major network vendors. This is due to its support by Ericsson, Cisco, Huawei, and Nokia, whereas OSM has only ZTE on its side. ONAP is a preferred approach based on project architecture, proof of production, and deployment readiness. A large part of ONAP is the ECOMP architecture, which has already been adopted by AT&T, with other proven use cases already deployed and approved (such as VoLTE, vCPE). It does have a small downside, however, in that its framework has been formed through the merger of two large projects, which requires the composition of numerous lines of code.

OSM has been created as a framework in line with the ETSI standard, with a scope that covers NFV orchestration (including network service onboarding, lifecycle, and performance management), VNF management (including VNF onboarding, lifecycle, fault, and performance management), VIM/SDN controllers, and security. ONAP ticks all of these boxes, and includes a TOSCA- and YANG-supporting unified design framework, which helps with end-to-end service orchestration and automation.This function is highly important, and a strong reason to adopt software-based networks.

Conclusion

To recap: Management and Orchestration are amongst the most important functions to consider when using NFV technology, and when planning to leverage automation for a service deployment. 

ONAP and OSM have created a divide amongst IT professionals, driven by the industry’s rapidly evolving acceptance of various ideas and technologies aimed at enabling faster service deployment, network development, and cost reduction.

Advocates on either side would likely agree that there is a lot of work yet to be done. Regardless, it’s good to know that ONAP and OSM are in line with the ETSI NFV reference architecture for building blocks, features, and interfaces.