ETSI and ONAP vye to address MANO for hybrid networks and slicing

The two main bodies developing open source platforms for management and orchestration (MANO) tend to announce their rival specifications at the same time. Once again, ONAP (Open Network Automation Protocol), the AT&T-initiated, Linux Foundation-hosted group, unveiled its latest release within days of new technology from ETSI’s Open Source MANO (OSM) project.

ONAP’s new release is called Casablanca and claims to make its software more modular, and easier to deploy for the efficient, flexible management of virtualized networks. For the first time, it will support physical network functions (PNFs) alongside their virtual equivalents (VNFs), a critical step forward for many telcos, which expect their physical and virtual worlds to coexist for many years.

Casablanca’s 5G blueprint aims to extend zero-touch orchestration and automation to the RAN, with PNF integration in hybrid radio and network optimization. ONAP has targeted next year for a multi-release blueprint, providing a template process to fully automate 5G networks.

Casablanca also features Hardware Platform Awareness (HPA), which supports uniform management of VNFs under a new module, the controller design studio. This is used to define the parameters of VNFs from one to seven, support PNFs, and scale out to migrate the traffic from one VNF to another.

Arpit Joshipura, general manager for networking at the Linux Foundation, said the new release took ONAP a step further in terms of enabling fully automated networks on a global scale.

“Casablanca addresses the three most important things that people are interested in,” Joshipura told LightReading.

These are:

  • Increased diversity in membership, contributors and standards development organizations, which means ONAP is less reliant on its original backers, such as AT&T, Amdocs and Huawei, and with access to a broader set of innovations. Just over 500 organizations contributed to Casablanca, compared to 473 for its predecessor, Beijing, and 324 for the release before that, Amsterdam.
  • Global deployment focus, which involves a large number of new features to meet diverse requirements and large scale. There are “some new blueprints, and significant new factors on deployability,” Joshipura said, which are focused particularly on two key concerns for operators, 5G readiness and the transition to containerized and cloud-native environments.
  • Focus on the end user and the commercial ecosystem, which has driven the “cross-release” – a platform that spans different carriers, VNFs, across controllers, vendors and projects.

In 2019, ONAP will offer a certification, compliance and verification program, with documentation on deployments and requirements. The group is responding to criticism of major gaps in its documentation process.

A rising number of operators are publicly backing ONAP, including Orange, which has made the protocol compulsory for its 5G deployment, Reliance Jio in India, Vodafone and China Mobile (which contributed some of the founding code). Vodafone and China Mobile developed a proof of concept for inter-carrier orchestration of cross-carrier VPNs, using ONAP, this fall, and this work has been upstreamed into Casablanca as a new blueprint, called the Cross Domain Cross Layer VPN Blueprint. This provides a high speed optical transport network on and end-to-end basis using ONAP instances deployed on the different sides.

ONAP founder AT&T has announced an ‘ONAP-first’ policy that requires its inhouse developments on the platform to be upstreamed first to the open source community, to accelerate uptake and avoid duplication of effort.

“With wide-scale service provider and equipment supplier participation, ONAP is becoming the de facto automation platform for carrier grade service provider networks,” said Chris Rice, SVP of network cloud and infrastructure at AT&T and board chair of the Linux Foundation’s networking umbrella project.

He added: “AT&T remains committed to actively contributing new code; leading technical areas; partnering on new 5G initiatives; orchestrating services across VNFs, PNFs, and soon CNFs (container network functions), as well as developing leading edge, model driven platform enhancements like the Controller Design Studio.”

The next major release in the twice-yearly cycle will be called Dublin, and some key areas of focus have already been identified, though no detailed scope. In particular, it will look at evolution of the DevOps CI/CD approach, security by design, and further improvements to documentation.

The ONAP group is also working more closely with another open initiative in this field, Open Platform for NFV (OPNFV), whose Gambia release came out earlier this month. The two organizations are doing joint verification and compliance, bringing ONAP under the OPNFV Verification Program (OVP) to enable easier testing for a full range of virtualization elements from VNFs to the NFV infrastructure (NFVi).

Gambia, which also exists within the LFN umbrella, focuses on continuous delivery, cloud native network functions (CNFs), testing, carrier-grade NFVi features and upstream project integration. Having pioneered continuous integration (CI) processes within the NFV developer community, OPNFV says it is now taking a first step towards DevOps and continuous delivery (CD).

Meanwhile, ETSI announced Release Five of its Open Source MANO, claiming “a huge step towards 5G network deployments and their end-to-end orchestration by telecom operators”.

Like Casablanca, the Release is preoccupied with working across physical as well as virtual functions, and the new software extends OSM orchestration capabilities beyond virtual domains, to embrace physical and hybrid network elements, as well as extending into transport networks.

This is done in a technology-agnostic way, said ETSI, extending the existing plug-in framework to transport, and using the same network functions modelling across all domains.

“With six releases in its two years and a half, OSM has proven to be an extremely agile vehicle for evolving an information model and the associated stack to provide network-as-a-service (NWaaS) in a completely automated fashion. With Release Five, OSM has become an essential engine to orchestrate 5G services end-to-end,” said Juan Carlos García, SVP of technology and architecture at Telefónica, which was the key code contributor to the early releases of OSM. He added: “We see it as key component for Telefónica’s virtualization program, Unica.”

Another way in which OSM is seeking to stay in the zeitgeist along with ONAP is its adoption of a microservices architecture, to make it easier to incorporate new features in a flexible manner, including distributed and edge functions, and NWaaS approaches. The latter will be important to 5G deployments, allowing them to support multiple use cases with separate, optimized connectivity, and to support wholesale customers, MVNOs and enterprises with their own network slices.

Indeed, the OSM group claims its new release offers full support for 5G slicing, as well as:

  • dynamic creation of inter-data center connections across heterogeneous WAN
  • extended support for service function chaining (SFC)
  • policy-based closed loop control
  • extended monitoring capabilities, including VNF metrics collection
  • support for physical and hybrid network functions

Other new features include a GUI-based Composer for network functions and services; an improved dashboard for logs, metrics and alarms; and faster start-up and response.

“OSM Release FIVE delivers new features which are vital to realize the 5G vision. Enhanced features such as information model extensions to support network slicing, powerful inter-data center connections and extensive improvements to monitoring and policy modules, will further enable service assurance and closed loop automation,” said Pål Grønsund, OSM’s vice chair, in a statement.

The ETSI OSM group includes 110 members, with Saudi Telecom the most recent telco to join up.

Earlier this year, there were hopes that the ONAP and ETSI OSM might be drawing closer together, and even talk that Telefónica might join ONAP, building a powerful bridge between the two groups. However, in September, the Spanish telco was at loggerheads with Orange of France, both calling for the industry to unite around a single MANO platform – but backing different horses.

The SVP of Orange Labs Networks, Emmanuel Delpon, told a conference that ONAP was the right orchestrator for the future, and that the industry needed to get behind it, to avoid destructive fragmentation. “If we fail to deliver one standard, we will have an industry disaster,” he warned. “We will not have the full benefit of 5G if we don’t have the right orchestration layer. We firmly believe ONAP is the right orchestrator for the future and we urge the operator community to join forces to have ONAP as the unique orchestration.”

He also wants the industry to get behind Open Platform for NFV (OPNFV) to achieve a common approach to NFV infrastructure (NFVi).

In the same week, at a different conference, Telefónica’s head of network virtualization strategy and technology, Antonio Elizondo, called for operators to unify around OSM. He told the attendees that OSM was distinguished from other efforts by its focus on a common information model, and that it had the most advanced such model in the industry, focused on service orchestration.

He pointed to the “nightmare” that resulted when the TOSCA information model project, run by OASIS and ETSI, resulted in multiple, incompatible versions. To make matters worse, vendors started to support the models at different stages, so did not even have interoperability within the same version of TOSCA, even if they were claiming compliance.

“It is a nightmare for us for service providers because there is no interoperability, no compliance and it is unclear how to progress the information model,” he said.

He wants telcos to avoid the same problem again by getting behind OSM’s model and Release Five, on the basis that will provide a single entry point to drive full automation of network services or slices. “OSM has a clear path to become an end-to-end service orchestrator” of physical and virtual elements,” he insisted.

Telefónica is working with Telenor on a common proof-of-concept to demonstrate how OSM can orchestrate 5G network slices.

However, convergence of the two efforts would certainly be a benefit, despite its complexities, not just to avoid fragmentation, but because the two projects have different scopes. ONAP is far broader while OSM has a tight focus on service orchestration. ONAP currently has several information models, but OSM could help it understand what is most required for service orchestration, said Elizondo. Many companies are part of both efforts and are sharing information, he noted.