You may have heard that ONAP is preparing for its second release in a few weeks time.Perhaps now is a good time to take another look at the goals of ONAP, its current direction and how ONAP can actually be a part of the final realization of the vision for NFV.

ONAP’s Goals


ONAP’s target is service lifecycle management of three components, all of which are familiar to any long-term follower of the NFV ecosystems, that is the management of VNF,SDN and the corresponding higher level services that use those components(known as service lifecycle management). Furthermore it is important to note that ONAP intends to treat all network functions (NF) as logically the same – that is it won’t matter if it’s a virtual network function(VNF), a physical network function(PNF) or even a human network function(HNF)! This scope is quite broad and of course leads to challenges in terms of integrating into legacy systems where the PNFs reside. As such in a practical step ONAP focuses on the VNF ecosystems in its first releases.

Focusing on ONAPs releases we can see that of the 3 releases detailed so far (Amsterdam, Beijing and Casablanca) the first two are focused on functionality, Amsterdam being more of a Proof of Concept while Beijing is intended to firm up on core functionality. However, Casablanca (due to be released late 2018) is of particular interest. It is the first release that will give a larger focus on deployability – that is, to ensure that ONAP – which currently stands at a large footprint in terms of CPU and memory is capable of being deployed in a modular fashion.

This has interesting implications both in terms of the architectural alignment towards a microservices approach (which has been ongoing in the project for some time) and the corresponding implicit links to standardization of API interfaces and aligning them with ETSI standards – another key ONAP goal. We should also begin to see operators start to deploy ONAP in more live environments, giving more traction to the product and some much-needed real world feedback on platform performance.

 

How ONAP might finally help deliver the NFV vision


Looking at the current ETSI plugtest drive you can notice that the key factor for viability of any NFV solution is compatibility. Ie VNFS must run across multiple SPs from different platforms. How does ONAP help in this instance? Well one could argue purely from a size perspective – AT&T, Verizon and China mobile are all behind the ONAP proposal and they intend to continue to strongly support their vision of the platform and vendors will ensure that their applications work on such an important platform. However, by aligning with ETSI standards there is another point to be made. When we achieve finally cross platform compatibility it will no longer matter which deployment we run on or which ‘wins’ in terms of most actively used. By aligning to standards we all win as NFV begins to be deployed en-masse, allowing operators to deploy services using the more advanced development and validation systems as outlined by our 5GTANGO project, or indeed the development approach taken by ONAP.

 

How 5GTANGO supports this vision

As mentioned in previous blog posts once ONAP begins to be deployed in operator sites there will be a need to deliver services which are tested in a devops like fashion before deployment. Currently there is a gap in ONAP deployments in that validation is limited to the syntactic check of the corresponding service only. Our approach of validating the service on a runtime copy of an ONAP (or indeed any SP) deployment allows us to be much more confident in the reliability of the service when actually deployed.

As noted ONAP’s second release is due mid-year and the critical third release comes at the end of the year. We would hope that as the platform matures we will begin to see more widespread adoption in real world environments and the vision that NFV has promised can be fully delivered.