The recent Bejing release of ONAP has been much anticipated by network function suppliers like Openet. The addition of new features like multi-cloud support as well as S3P hardening (security, stability, scalability and performance) across the ONAP platform are welcome and position the system for production deployments. Should the focus of Openet’s 5G VNF development now switch to supporting this shiny, new platform?

Up to this point, you may consider the adoption of an NFV platform in the telecom industry as a three horse race. The VNF vendor has had to consider how to divide resources between developing support for:

• The ONAP platform

• Any one of a number of ETSI NFV compliant solutions

• An organic solution based on Kubernetes/ RH OpenShift

The ONAP solution is a relatively new open project between a number of industry operators and vendors. The development teams quickly made progress to produce the first Amsterdam release. This proved the design with specific use cases but was limited in functional scope and proved difficult to install and operate. These difficulties may be considered typical of the first release of a complex and ambitious project. Openet is eagerly looking at the Bejing iteration to provide an appreciable improvement in these areas.

You may wonder why ONAP is needed when the ETSI NFV standards are being finalised. Since 2012 great strides have been made in defining the NFV standards but without actually finalising them. This has allowed many projects, both open and closed, to emerge and offer compliance with the early aspects of the MANO architectural specs. Associated with this evolution is the multiplicity of choice of implementations within the MANO stack and the difficulty of integration with any given interface. For the VNF producer there is a significant overhead to support a given orchestrator or VNFM implementation. For the network operator there is the risky choices between maintaining and operating multiple MANO stacks to support different NF/NS vendors, mandating one stack but facing the limitation of vendors that are willing to support it or using a stack and NS combination provided by one supplier. These are hard choices. Without a clear technology winner, the market vacuum has given momentum to ONAP but also to other technologies that have proven track records in the IT industry.

Dockerised microservices, deployed and managed by kubernetes is a tried, tested and trusted way of making scalable services available in production IT environments. Following the lead from the IT domain this paradigm is increasingly being looked to in the networks domain to be effective in the deployment and management of VNS/VNFs. Given a VNF implemented as a set of decomposed microservices (and that is not in any way to diminish the challenge of producing such a cloud-native NF), ubernetes already solves the problem of deployment, scaling, health monitoring and resiliency. So why not make use of the shoulders of the IT giants?

In fact, the convenience and reliability of kubernetes has already allowed it gain significant traction in the development processes of VNF vendors. This is understandable as a given VNF solution can be very quickly instantiated and supplemented with a wealth of similarly dockerised services to create a more powerful solution. Efficiency in development is the pre-requisite of a dev-ops pipeline and an enabler of an adaptable and focused production environment.

This is why, it is heartening to see that kubernetes is one of the expanded sets of supported VIMs in the ONAP Beijing release. Having the power of the service specification, quality control and runtime management coupled with the choice of deployment environments makes ONAP a compelling solution both for the operator and the supplier. Now the operator can choose the ONAP platform with the VIM layer that suits. This is also good news for the VNF supplier looking to integrate their product with ONAP as from a simple, practical level they can initially choose the cloud support that suits their current development.

The big question for VNF vendors is whether supporting the products on the ONAP platform will open up market opportunities with the adopting operators. Adoption in production is now more feasible with the maturity and hardening of the Bejing release. The success of the release and moreover, the platform will depend on upstream operator take-up and deployment. If that happens and at that point, the NFV platform horse race comes into the home straight with ONAP clearing the final hurdle.