First software release fully merges OpenECOMP and OPEN-O into modular architecture, pieces of which are already being put to use and in PoCs.

November 20, 2017

6 Min Read
Ambitious Amsterdam Makes ONAP's Case

ONAP today rolled out its much-anticipated first software release, dubbed Amsterdam, promising a unified architecture for network automation, modules of which can -- and are -- being used immediately by network operators beyond AT&T. (See ONAP Issues Amsterdam, First Software .)

In the eight months since AT&T's OpenECOMP combined with Open-Orchestration to form the Open Network Automation Platform (ONAP) under the Linux Foundation banner, the group has grown to 58 members. And with Amsterdam, ONAP releases a unified architecture that not only combines the contributed code of both groups, removing duplication in the process, but also adds significant new features including a new correlation engine called Holmes which has been added to the ECOMP Data Collection, Analytics and Events (DCAE) module and a new module called Control Loop Automation Management Platform (CLAMP). (See ONAP Makes Splashy ONS Debut.)

Amsterdam also provides two "verified blueprints," which show how its modules can be combined to deliver early use cases sought by its members: voice-over-LTE, including virtual IMS, and Residential vCPE.

ONAP officials are stressing the fact that Amsterdam is production code that is already being put to use by AT&T Inc. (NYSE: T), of course, but also China Mobile Ltd. (NYSE: CHL). It is planned for use soon by BCE Inc. (Bell Canada) (NYSE/Toronto: BCE), and is in multiple proofs of concept at Orange (NYSE: FTE) and others. Vodafone Group plc (NYSE: VOD), a recent addition to ONAP, is evaluating use of ONAP modules in its Ocean transformation program, including ONAP's common approach to virtual function onboarding control and service definition.

Figure 1:

"The modular approach makes sense, because nobody is going to rip and replace their existing systems to use ONAP," says James Crawshaw, senior analyst with Heavy Reading . "They want to use legacy as much as possible and implement new stuff as it were, where there is a clear opportunity to save costs or be more innovative and agile in coming up with new services." (See ONAP Takes Flak as Telcos Prep for Release 1 and ONAP Strikes Back, Saying Critics Are Misinformed.)

Sandra O'Boyle, also a Heavy Reading senior analyst, says the modular approach should help ONAP overcome criticisms from those who thought it was too big and ambitious to be practical. "One of the issues they had was the size of ONAP/AT&T ambition is too big for them to consume, or they are a bit uncomfortable with the scale and would rather 'wait and see'," she says. Mobile operators were also unwilling to take on features designed to serve enterprise customers but might be perfectly happy to consume modules for VoLTE, IMS and evolved packet core.

Next page: Diversity improving

Diversity improving
Crawshaw, who questioned the diversity of ONAP contributions in the past, notes that the project "now seems to be gaining critical mass," and that contributions beyond the initial group are becoming more diverse.

"Gradually we are starting to see contributions from new faces," he says. "AT&T is still the dominant contributor to the project with around 40% followed by Amdocs -- around 20% -- and then Huawei and ZTE -- both around 10%. We're also seeing code contributions from China Mobile, Bell Canada, Orange, Windstream and Verizon which is a healthy sign. Nokia and Ericsson are nowhere to be seen really or very small players in the project at this stage and if I was them I would wanting to be putting more resources into it."

Verizon Communications Inc. (NYSE: VZ)'s participation is particularly interesting since the company is not an ONAP member. (See Verizon Weighing Open MANO Options.)

At ONAP's outset, there were 11 projects within the open source group, eight coming out of AT&T's ECOMP and three coming from OPEN-O, notes Mazin Gilbert, vice president of Advanced Technology, AT&T Labs, and technical steering committee chair for ONAP. In completing Amsterdam, ONAP wound up with 30 projects in delivering end-to-end, closed-loop network automation that is vendor-agnostic and supports rapid service turn-up.

Figure 2: Source: Linux Foundation Source: Linux Foundation

Basically each "box" within its architectural design is a project, and there are application programming interfaces deployed in between to enable the modularity ONAP is promising, Gilbert says. ONAP used existing APIs wherever possible and developed its own where needed. That's an ongoing process, he added.

The architecture includes design time and run-time environments and has matured code in each area.

"We have beefed up design time; there is now a catalog for these network functions," Gilbert says in an interview. "There is an SDK [software development kit] to onboard these network functions, there's a validation of the network functions, once you onboard them and there are policy creations. There are designs to enable you to service-chain them and there is a CLAMP that we have added to help design and policy-enable closed loop and open loop use cases for Amsterdam."

Amsterdam expands the concept of run-time beyond service orchestration to include virtual and physical functions but also lifecycle management, he adds. This is where Holmes, the addition to the DCAE model, factors in as the correlation engine. In addition, Amsterdam includes an expanded policy framework and expansion of Active and Available Inventory (A&AI) to include external as well as internal resources.

The initial software release goes beyond supporting multiple software-defined networking controllers to having a controller framework for plug-and-play, Gilbert says. It includes an application controller and a virtual function controller, which is aligned with the ETSI model. That could facilitate further integration with Open Source MANO Community (OSM) , the ETSI-based open source group.

As promised, Amsterdam supports multiple Virtual Infrastructure Managers, multiple-clouds and multiple NFV infrastructures. Arpit Joshipura, general manager of networking and orchestration for The Linux Foundation, said ONAP uses northbound interfaces developed by the MEF and the TM Forum . (See ONAP & MEF Formally Team on LSO APIs, Framework.)

Next page: Operator engagement

Operator engagement
It's not a surprise that AT&T is already using ONAP to orchestrate its network-on-demand service, but it has now added proofs of concept involving a self-organizing network use case with LTE and both physical and virtual network functions. In addition, it is deploying ONAP internally with its staff and vendors.

China Mobile is using four ONAP modules in its NFV rollout, to combine orchestration of NFV with physical elements and OSSs, and is using different modules in constructing a new data center to data center infrastructure. Orange had three proofs of concept before Amsterdam and is adding four more this year and next, while BCE announced plans to begin implementation of five different ONAP modules later this year.

Two vendors -- Amdocs Ltd. (NYSE: DOX) and Fujitsu Ltd. (Tokyo: 6702; London: FUJ; OTC: FJTSY) -- have announced commercial versions of ONAP. (See Monetizing ONAP, the Amdocs Way and Amdocs Unveils ONAP-Based Intercarrier Service Orchestration Solution.)

All of that adds to the project's maturity and momentum, notes Joshipura. The second release, Beijing, is due out next summer and its focus will be on enhancing scale, stability, security and performance.

— Carol Wilson, Editor-at-Large, Light Reading

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like