ONAP Amsterdam release furthers automated virtualization trend

ONAP has taken another step forward as a key enabler for service providers virtualizing their networks with its first platform release, ONAP Amsterdam, focusing on a unified​ ​architecture​ ​for​ ​closed-loop​ ​network​ ​automation.

Offering new service delivery lifecycle for traditional telco, cable and cloud providers, ONAP is uniting​ ​the majority​ ​of​ ​operators​ ​(end​ ​users)​ ​with​ ​the​ ​majority​ ​of​ ​vendors​ ​(integrators)​ ​in building​ ​a​ ​real​ ​service​ ​automation​ ​and​ ​orchestration​ ​platform.

RELATED: Linux Foundation’s Joshipura says ONAP is now the de facto open networking platform

​Arpit​ ​Joshipura,​ ​general​ ​manager,​ ​networking​ ​and orchestration for ​The​ ​Linux​ ​Foundation, told FierceTelecom that Amsterdam is based​ ​on​ ​open​ ​source​ ​and​ ​open​ ​standards ​is the​ ​first​ ​step​ ​toward​s a ​​globally​ ​shared​ ​architecture​ ​and​ ​implementation​ ​for​ ​network automation.

“Amsterdam is the first vendor-agnostic model-driven platform with closed loop,” Joshipura said.

The platform is based on two parts: technology and the ecosystem. From a technology point of view, Amsterdam is a platform with tested blueprints. And from an ecosystem perspective, ONAP is aligning the service providers with suppliers.

When ONAP launched Amsterdam earlier this year, it began with 10 requirements—five technologies and five ecosystems. On the technology side, ONAP merged ECOMP which came from AT&T and the OpenO. Likewise, ONAP developed an ecosystem path that now includes 58 members.

“In less than eight months, we have been able to pull together a community of 538 contributors,” Joshipura said.                 

Merging, simplifying coding

The​ ​Amsterdam​ ​release​ ​provides​ ​a​ ​unified​ ​architecture, ​ ​which​ ​includes​ ​code from​ ​OpenECOMP​ ​and​ ​Open-O, ​ ​to​ ​provide​ ​design-time​ ​and​ ​run-time​ ​environments​ ​within​ ​a single, ​policy-driven​ ​service​ ​orchestration​ ​platform.

In creating Amsterdam, ONAP took the two code bases and decoupled and modularized it. Specifically, ONAP decoupled the base from the upstream components, which includes OpenDaylight and others. On top of that ONAP added in the new code from OpenO and CLAMP modeling.

“We removed and refactored a lot of code,” Joshipura said. “In a lot of these 30 projects, we can create this modular design which is now called Amsterdam.”

Amsterdam’s architecture has three main components: design-time, run-time and the managed environment. In the design-time, ONAP includes the VNF SDK (software development kit), catalog policy and Closed Loop Automation Management Platform (CLAMP). CLAMP is a platform for designing and managing control loops. It is used to design a closed loop, configure it with specific parameters for a network service, then deploying and undeploying it.

“With CLAMP, any feedback that comes from the run-time environment can be given back into the models and then actions can be taken automatically,” Joshipura said.

In run-time, there are external APIs that can work with the MEF’s new Sonata and Legato specifications for automating Ethernet service delivery. ONAP also aligned a set virtual function controllers are aligned with ESTI’s MANO specifications as well as a whole set of additional OpenDaylight controllers, but service providers have the options to use a third-party controller.

Enhancing service delivery

ONAP’s key focus with Amsterdam is driving virtual network function (VNF) automation, an element that will enable service providers to shorten service delivery timeframes.

By offering common ​vendor-agnostic​ ​models, service providers and enterprises ​can quickly​ ​design​ ​and​ ​implement​ ​new​ ​services​ ​using​ ​best-of-breed​ ​components, even within​ ​existing​ ​brownfield​ environments. 

Amsterdam provides a common and​ ​open platform​ ​that can ​reduce​ ​development​ ​costs​ ​and​ ​time​ ​for​ ​VNF​ ​vendors,​ ​while​ ​allowing​ ​network operators​ ​to​ ​optimize​ ​their​ ​selection​ ​of​ ​best-of-breed​ ​commercial​ ​VNF​ ​offerings​ ​for​ ​each​ ​of​ ​their services.​

“The most important part of the Amsterdam platform is VNF automation,” Joshipura said. “At the end of the day, services are what make the end-user money and today VNFs gets on boarded differently.”

To resolve the VNF puzzle, ONAP’s Amsterdam produces three main concepts: the VNF requirement, SDKs, and validation.

Amsterdam also provides support for network testing and support for various environments. The release features real-time​ ​inventory​ ​and​ ​analytics​ ​support​ ​monitoring, end-to-end​ ​troubleshooting,​ ​and​ ​closed-loop​ ​feedback​ ​to​ ​ensure​ ​SLAs​ ​as​ ​well​ ​as​ ​rapid optimization​ ​of​ ​service​ ​design​ ​and​ ​implementations.​ ​ONAP​ ​​is​ also ​able​ ​to​ ​manage​ ​and orchestrate​ ​both​ ​virtualized​ ​and​ ​physical​ ​network​ ​functions.

“There’s an exhaustive list of requirements with an SDK and auto scripts to test things are working,” Joshipura said. “This means every VNF vendor can integrate and do the lifecycle management of the VNF in a simple way.”

Service providers step up

As ONAP moves forward with Amsterdam, a growing number of service providers are continuing to engage in proof of concept (PoC) exercises for ONAP.

Member​ ​companies, ​​which​ ​represent​ ​every​ ​aspect​ ​of​ ​the​ ​ecosystem—vendors, telecommunication​ ​providers, cable​ ​and​ ​cloud​ ​operators,​ ​NFV​ ​vendors,​ ​solution​ ​providers—are already​ ​leveraging​ ​ONAP​ ​for​ ​commercial​ ​products​ ​and​ ​services.​ ​Amsterdam​ ​code​ ​is​ ​also integrated​ ​into​ ​PoC. 

AT&T, which already uses ONAP for Network on Demand today with over 100 VNFs tested, is conducting PoC trials for its wireless network: self-organizing LTE networks and the RAN use case. The service provider is also pulling ONAP from the OoenSource into their internal network environment to do a CI/CD DevOps model.

“With the CI/CD model, AT&T can keep ONAP and ECOMP in synch,” Joshipura said. “As new features and app come up, the carrier can push it out to the network.”

Meanwhile, Orange has been working with AT&T to conduct tests related to Ethernet lifecycle orchestration (LSO). Other participants include China Mobile, Bell and Vodafone.

The​ ​entire​ ​Amsterdam platform​ ​has​ ​been built​ ​to​ ​address​ ​current​ ​real-world​ ​challenges​ to operate large network environments.

Amsterdam​ ​provides​ ​verified​ ​blueprints​ ​for​ ​two​ ​initial​ ​use​ ​cases, with​ ​more​ ​to​ ​be​ ​developed​ ​and​ ​tested​ ​in​ ​future​ ​releases, including​ ​VoLTE​ ​(Voice​ ​Over LTE),​ ​which​ ​allows​​ ​voice​ ​to​ ​be​ ​unified​ ​onto​ ​IP​ ​networks.​ ​By​ ​virtualizing​ ​the​ ​the​ ​core​ ​network, ONAP​ ​is​ ​used​ ​to​ ​design,​ ​deploy,​ ​monitor​ ​and​ ​manage​ ​the​ ​lifecycle​ ​of​ ​an​ ​end-to-end VoLTE​ ​service.​ ​

​Residential​ ​vCPE is the second use case for Amsterdam.​ ​With​ ​ONAP,​ ​all​ ​services​ ​are provided​ ​in-network,​ ​which​ ​means​ ​service providers​ ​can​ ​​add​ ​​new​ ​services​ ​rapidly​ ​and​ ​on-demand​ ​to​ ​their residential​ ​customers​ ​to​ ​create​ ​new​ ​revenue​ ​streams​ ​and​ ​counter​ ​competitors.

“The concept here is to make sure we do an end-to-end model test of ONAP,” Joshipura said. “If members want to deploy the blueprint they can do it.”