ONAP Alignment to Open APIs: Netcracker’s View and Contributions

Any orchestration environment, whether open source such as ONAP or commercial, requires standards-based interoperability with other applications in the SDN/NFV ecosystem. Anything less will lead to significant operational and development overhead, requiring adaptation on a case-by-case basis.

Interoperability is achieved through common APIs and a reference architecture that is aligned with industry standards. This blog will focus on API alignment.

In ONAP, or any orchestration environment, there are two critical areas where API alignment with industry standards is required: internal component-level APIs and external APIs.

The alignment of internal component-level APIs is critical for the move towards a modular ONAP design (read our blog on ONAP modularity). Given that service providers want the flexibility to use only the particular ONAP modules they need, these modules will need to support standard APIs to interwork with commercial vendor solutions that are already deployed.

The second critical alignment relates to using external APIs to integrate ONAP with external systems.

• Northbound APIs: For integration with existing BSS and OSS systems and end-to-end service orchestration.
• Southbound APIs: For integration with the network and cloud environments and external generic or specific VNF managers.
• East-West APIs: For integration with other service providers.

Since most of these internal and external APIs are already well defined in standards development organizations (SDOs) such as ETSI, MEF and TM Forum, the alignment and adoption by the Linux Foundation Networking/ONAP is the most logical path.

Where Does Each Standard Organization Fit?

ETSI is the organization that started it all in the NFV orchestration domain. ETSI MANO is the reference architecture for managing virtualized services and resources within a service provider’s environment. Alignment with ETSI APIs is relevant for ONAP’s internal APIs, interworking entities such as service orchestration, application controllers, virtual function controllers and multi-VIM/cloud infrastructure adaptation layers.

However, the ONAP architecture includes many functions that are outside of the ETSI MANO scope, requiring alignment with both MEF and TM Forum APIs.

MEF is widely known for lifecycle service orchestration (LSO), the framework for orchestrating the entire lifecycle of hybrid services across multiple network domains, from onboarding through scaling and healing. TM Forum has its roots in pulling together BSS/OSS best practices and business processes in usable frameworks for service providers. MEF is also defining the integration reference points which will accommodate multiple TM Forum open APIs. Alignment with both MEF and TM Forum APIs will be needed for ONAP’s external APIs for integration with BSS/OSS, network and cloud environment and inter-operator communications.

Netcracker’s Contributions

Netcracker has identified two focus areas that must be addressed in the ONAP community for further collaborative development.

1. Aligning with SDOs’ open APIs

For external APIs, ONAP needs to support standard interfaces for both north-south and east-west interactions. Both interfaces working seamlessly together is essential for end-to-end automation. The current ONAP work is more focused on the north-south interface based on MEF’s LSO reference point, Legato. Our study brings into focus the east-west interactions with MEF’s LSO reference point, Interlude. It’s an important contribution, as service providers are raising concerns that standards organizations are fragmented. A consensus and consolidated view on inter-operator communications are required.

For internal APIs, Netcracker’s focus is to identify gaps between the existing ONAP component APIs and ETSI MANO and suggest improvements. ONAP’s future Dublin release has initiated activities to align with ETSI MANO APIs such as SOL005 and SOL003. However, given the wide set of operational and interoperability cases required in ONAP, we anticipate either more internal ONAP APIs will need to be aligned or additional ETSI APIs may need to be considered.

Given the lag today between standard API development and service provider needs, we expect to speed up this process by working with SDOs to close the gaps or developing the missing APIs in ONAP and contributing back to the SDOs.

2. Consolidating and unifying ONAP API management functionality

The way ONAP APIs are managed today will be a major hurdle when adopting open APIs. API management is mostly the responsibility of individual components and is often duplicated and inconsistent. Netcracker’s objective is to propose a common way to manage APIs so that alignment with standards is well coordinated across different components.

These architectural contributions will significantly reduce the maintenance overhead by adapting ONAP to different deployment and integration scenarios and aligning more closely with service providers’ operational requirements. They will be mutually beneficial for ONAP as well as the SDOs.