ONAP vs OSM – Who will win?
A major topic of discussion in IT circles these days is about the best way to operate an efficient, scalable, and automated network infrastructure. One of the major challenges is being able to offer high availability services while remaining agile enough to swiftly deploy new services; ongoing operations need to keep running and costs must remain low. The answer to this challenge is a combination of of cloud computing, network functions virtualization (NFV), and the software-defined network (SDN). These approaches allow for the operation of different network functions over same off-the-shelf hardware in both on-premises or public clouds.
In order to realize the full potential of these technologies, operators need to introduce a new approach to managing their network architectures. NFV Management and Orchestration (NFV MANO) is considered to be crucial part of cloud infrastructure for unlocking the full potential of network functions virtualization: simplified infrastructure operation, scaling, and faster deployment of the services. That’s why it’s important to choose the right approach for management and orchestration, as well as the framework in which it will be developed. This blog will focus on the advantages of two major frameworks, ONAP and OSM.
The Open Network Automation Platform (ONAP) is an open-source software platform that enables the design, creation, and orchestration of services on an infrastructure layer on top of individual virtual network functions or SDN—or even a combination of the two. ONAP was formed as a combination of the Linux Foundation’s OPEN-Orchestrator Project (OPEN-O), and the AT&T ECOMP (Enhanced Control, Orchestration, Management and Policy) platform to form one unique code. On the one hand, the main purpose of the OPEN-O project is to develop an open-source software framework in theory for the orchestration of SDN and NFV. On the other, AT&T’s comprehensive virtual platform was developed with same goal in practice.
The main purpose of ONAP is to answer the rising needs of service providers to operate a common platform that will be able to provide efficient, end-to-end infrastructure management. The platform is also meant to speed up delivery of different on-demand services with the possibility of automating most of the 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.
Learn more about ONAP with ONAP Training
The execution-time environment framework is used to execute all policies and rules prepared in design-time environment. These policies and rules are responsible for resource inventory, data collection, and analytics. They handle tasks such as performance monitoring, service orchestration for end-to-end service automation, and security based on the strong foundation inherited from ECOMP. In addition, using the Closed Loop Automation Management Platform, ONAP enables service providers to manage virtual network function life cycles and to automate deployment processes.
Open Source MANO (OSM) is an ETSI-hosted initiative for the development of open-source NFV Management and Orchestration software stacks. The initiative is fully aligned with the ETSI-developed NFV reference architecture. OSM is one of the first projects of the ETSI entity called OSG (Open Source Group), allowing open-source projects to be developed under ETSI.
While ETSI has always focused on standards, the OSM initiative is based on open-source tools like GitHub. Hosted by ETSI, the initiative is also based on components that have been around for some time like Telefonica’s OpenMANO project, Canonical’s Juju generic VNF Manager, and RIFT.io’s orchestrator.
The idea behind OSM is to have all activities in development closely aligned with the evolution of the ETSI NFV standard. This enables vendors and operators to have an ecosystem that gives them the ability to deliver and deploy services in a cost-effective manner. In particular, OSM should allow network architects to take advantage of synergies between the ETSI NFV standard and the open-source approach. These synergies are important when developing Management and Orchestration infrastructure, an all-important part of the networks of future service providers. Like ONAP, the architecture of OSM consists of two major components: run-time scope and design-time scope.
The run-time scope component comprises different functions like automated service orchestration. The primary purpose of the component is to simplify service and lifecycle management. The component also performs provisioning for SDN controllers, including plugin models integrating multiple SDN controllers. The run-time scope also includes delivery of plugin models for integrating VIMs and multiple VIMs. Run-time scope’s Generic VNF Manager is an important function to control VNFs with support for specific VNF Managers based on demand. Run-time scope supports integration of a new Physical Network Function into an automated service deployment, and a plugin model for the integration of multiple monitoring tools.
Create Production-Grade NFV Deployments With Cloudify
Design-time scope includes support for a model-driven environment fully aligned with the ETSI NFV standard. It also has functions for the creation, update and deletion of service definitions. Finally, it supplies a Graphical User Interface (GUI) to accelerate service design time, VNF onboarding, and deployment.
ONAP vs OSM
There are several ways to size up the differences between ONAP and OSM. To begin, both frameworks are used by major global service providers and network vendors. As far as service providers are concerned, ONAP has the advantage because it has been adopted by a larger group of global service providers, such as AT&T and China Mobile. ONAP has very good coverage in North America and Asia. There is less support in Europe. Despite that, OSM’s standing there is still strong because it has been adopted by major European network operators like British Telecom and Telefonica.
On the other hand, when analyzing major network vendors, ONAP emerges in a much better position because it is supported by Ericsson, Nokia, Cisco, and Huawei, while OSM only has ZTE. ONAP might be considered the preferred approach based on project architecture, proof of production, and readiness to be deployed. That’s because a large part of it is the ECOMP architecture that is already used in AT&T, with different proven use cases already developed and approved (VoLTE, vCPE). A slight downside of the ONAP framework is that it is formed through a merger of two huge projects, requiring the composition of numerous lines of a code.
OSM has been imagined as a framework that will follow the ETSI standard, with the scope to cover 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. On the other hand, ONAP covers all of the above; it also includes a unified design framework (supporting TOSCA and YANG) helping with end-to-end service orchestration and automation. This is considered a very important function and a good reason to adopt software-based networks.
As already mentioned, Management and Orchestration is one of the most important functions when using network function virtualization technology and planning to introduce automation for a service deployment. With the IT industry’s fast evolving acceptance of different ideas and technologies to enable faster network development, service deployment, and cost reduction, it seems that ONAP and OSM have split IT professionals. Advocates on both sides would probably agree that there is a lot of work to be done. Still, it is good to know that both ONAP and OSM are following the ETSI NFV reference architecture for features, interfaces, and building blocks.