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 towards 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.”