The O​pen Network Automation Platform (ONAP)​ project today issued its second software release — Beijing. It includes more support for containers and some functionality for service providers to deploy ONAP across geographically dispersed data centers.

The ONAP project gave clues that it was working with the container orchestrator Kubernetes in March when the two projects conducted a joint demonstration at the Open Networking Summit (ONS).

Now, the Beijing release evolves ONAP toward container-based implementations via the ONAP Operations Manager (OOM). The OOM enables ONAP modules to run on Kubernetes. And the operations manager also sets the stage for full implementation of a micro-services architecture expected with the third ONAP release — named Casablanca, which is slated for the fourth quarter of this year.

Arpit Joshipura, general manager of networking with the Linux Foundation, said OOM was already being worked on within ONAP during ONAP’s first code release, Amsterdam. And Bell Canada, which was the first organization to deploy ONAP in a production environment, used OOM. “Bell Canada used OOM to put ONAP in production,” said Joshipura. “But OOM was not formally integrated into Amsterdam. It was on the way, but not complete. We want to use the packaging and power of containers.”

AT&T has been a leading force in ONAP. The service provider contributed at least half of the initial code for ONAP. And AT&T recently announced Airship, a project to make its OpenStack cloud 100-percent based on containers.

Asked how Airship’s container focus fits with ONAP’s OOM container focus, Joshipura said, “The Airship project is aimed at solving the scaling problems of OpenStack when you have a large set of OpenStack deployments. Yes, it also uses Kubernetes for pulling things together. The underlying framework is all Kubernetes-based. But the problem domain is different. Airship solves large scale deployments of OpenStack versus OOM that solves the deployment of ONAP in a container manner.”

A new project within Beijing is the ​Multi-Site State Coordination Service (MUSIC). The​ project ​is an optional new solution for state management of ONAP components across geographically distributed sites. Joshipura said some of the bigger service provider members of ONAP have data centers located around the globe, and they need the functionality of MUSIC. He cited AT&T, China Mobile, Vodafone, and Orange as examples.

The Beijing release also ensures that ONAP’s External API can communicate with MEF and TM Forum frameworks.

Several of the TM Forum’s Catalyst projects included pre-release versions of ONAP’s Beijing release. “Acting as working prototypes for the industry, these Catalyst projects have helped the development of the TM Forum Open APIs included in the release (TM Forum Open APIs carrying MEF defined payloads provide the northbound interfaces in the ONAP Beijing release), and provided implementation feedback to the ONAP project,” said Andy Tiller, TM Forum’s EVP of collaboration and innovation.

Other key updates in Beijing include:

• The adoption of ​Core Infrastructure Initiative (CII)​ badging for security.
• The ONAP community worked closely with the ​OPNFV Verified Program​ (OVP) to coordinate integrations via the ONAP VNF SDK and ONAP ​VNF Validation Program (VVP) components.

The Linux Foundation Networking Fund (LFN), which includes ONAP, now enables more than 65 percent of the world’s mobile subscribers, as well as global enterprises and cloud providers. The most recent service providers to join LFN include Sprint, KT, KDDI, SK Telecom, Swisscom, and Telecom Italia.

While AT&T and China Mobile contributed the lion’s share of the initial code for ONAP, others are now stepping up to contribute more. A snapshot of contributors from the second quarter of 2018 shows that Huawei, Amdocs, and ZTE, along with many others, are contributing to ONAP.