ONAP, Still Early Days or Substantial Progress?

On June 12, 2018, the Open Network Automation Platform (ONAP) community announced its second major release, ONAP Beijing. The recent release is intended to accelerate its progression toward a production-ready platform amid increased industry engagement. The enhancements implemented in ONAP Beijing mark progress in terms of nonbehavioral system qualities. The new release also advances functional behavior to achieve alignment with other standard bodies’ specifications (e.g., from TM Forum and MEF) on Virtualized Network Function (VNF) onboarding and northbound integration with Operations Support Systems (OSS)/Business Support Systems (BSS). There is growing momentum at the industry level to achieve technology harmonization and realize alignment of standards. Despite this impetus, work remains to be done particularly on BSS/OSS integration, and automation of network service provisioning when supported by a hybrid resource pool (VNFs/Physical Network Functions [PNFs]).

ONAP Beijing enjoys increased development support currently coming from 452 authors, up 58% from 286 authors recorded in the Amsterdam release dating back to November 2017. There is an upward shift of 54% in the number of commits, currently standing at 14,800 as opposed to 9,600 in the Amsterdam release. The contributor distribution in terms of code is dominated by AT&T at 40%, followed by Huawei and Amdocs accounting for 17% and 11%, respectively. [1] This is an indication that these three entities in the market, with 68% of overall code contribution, are largely driving the development of ONAP. Other big vendors like Nokia, Intel, and VMware appear to have similar contributions at approximately 2% or 3%, as does the Linux Foundation with a similar amount.

The focus of ONAP is limited to the NFV Orchestration (NFVO) and VNF Manager (VNFM) modules of ETSI NFV MANO specification but includes several more features and application areas, including analytics, policy-based management, and network monitoring. ONAP interacts with multiple Virtualized Infrastructure Managers (VIMs), typically based on OpenStack, and it aims to implement automation and service lifecycle management of VNFs, which run on top of standard industry hardware and open source (Kernel-Based Virtual Machine [KVM]) or proprietary (VMWare ESXi) hypervisors. The utility of ONAP extends beyond achieving operational automation at the NFVO and VNFM level to include automation of Operations, Administration and Management (OAM) and service assurance by means of real-time policy driven by closed-loop automation. The choice of VIM for ONAP lies between OpenStack and Kubernetes for a cloud-native containerized implementation. A cloud-native ONAP, however, introduces a degree of complexity attributable to two elements: one, a multiplicity of microservices, each of which needs to be instantiated, raises new orchestration requirements; two, a lack of maturity to run containers on bare metal means that most container deployments are in Virtual Machines (VMs). From an assurance perspective, an extra layer of abstraction is introduced that gives rise to a three-dimension environment (infrastructure, container, application), potentially raising complexity that ONAP, and vendor solutions that plug into it, ought to address.

The ONAP Beijing release introduces Stability, Security, Scalability, and Performance (SP3) enhancements that can be used to judge ONAP’s operation but that are not directly impacting its behavior. A notable area of progress regarding the technical functionality of the system is change management, a functionality that allows for seamless update/upgrade of a VNF in an already deployed network service. A second architectural change, and one that will be welcomed by the industry, was the introduction of ONAP Operations Manager, a module that facilitates VNF migration to microservices-based deployments. One noteworthy project among the 31 approved in the Beijing release is the solution “MUSIC” (this is not an acronym). MUSIC is an undertaking that aims to achieve 5x9s service availability with Commercial Off-the-Shelf (COTS) infrastructure geared toward lower availability requirements. ONAP’s focus on achieving a high degree of availability on standardized hardware is worthy of plaudits, but further platform maturity may be required to achieve protection against interference for a specialised telco infrastructure not fully harmonized with general-purpose equipment.

A significant development is the alignment with northbound Application Programming Interfaces (APIs) from MEF and TM Forum to achieve standardization and support interoperability with northbound service orchestration. Equally important is the coexistence of ONAP and other open source developments in the industry, namely ETSI OSM. On this front, ABI Research learned from a person familiar with the matter that key code contributors have agreed to institute alignment with ETSI OSM on the Or-Vnfm interface that is used for exchanges between NFVO and VNFM. This is certainly a first step toward promoting interoperability between the two MANO platforms, but it remains to be seen whether a richer and structured form of alignment will materialize. This marks good progress, however, toward an all-encompassing ONAP platform that warrants further maturity, particularly in managing hybrid VNF/PNF environments. Equally important is a broad integration with OSS/BSS layers, without which any orchestration solution would be considered peripheral.

The emergence of ONAP, ETSI OSM, and other open source platforms can potentially put telcos in uncharted waters from a commercial perspective. The openness and disintegration that is emerging disrupts the old business model predicated on specialized technology, control, and a tight integration of the infrastructure. Further maturation notwithstanding, telcos should ponder over how to leverage these open APIs to capture new growth opportunities over the short and long term. The notion of openness increases vendor competition because, from an engineering perspective, plugging into open platforms can be restrictive in terms of pursuing feature differentiation. Vendors that once offered differing products may face direct competition in offering many of the same products and services. Thus, it follows that wide adoption of ONAP gives rise to a diluted degree of differentiation that vendors ought to consider. Vendors must think of ways that bolster the utility derived from their products: providing an all-encompassing digitally native offering is one option; pursuing capabilities around “new” technologies of Artificial Intelligence (AI), cyber security, and analytics is another.

System Integrators (SIs) are another group of industry players bound to benefit from ONAP making its way into telco networks (IN-4462). SIs have an abundance of expertise related to integration services that will stand them in good stead for implementations that will require customizations, special integrations for specific customer use cases, and subsequent servicing.

SIs can cultivate this expertise to get a leg up on the professional services ladder, but getting involved with the development of ONAP as it matures into a production-ready platform is key. Of all SIs that could potentially benefit from an upswing in integration activities, only Tech Mahindra is contributing code to ONAP, albeit marginally.

ONAP is encroaching steadily, but with 68% of its development attributed to merely three stakeholders, involvement may need to be more dispersed before it is fully entrenched in the emerging digital environments.