VNF Onboarding, TOSCA, and ONAP – Why Operators and VNF Vendors Need to Care

Who cares about VNF onboarding?

In a word – EVERYONE. Today although there are many different implementations of MANO stacks and many VNFs – the cost to onboard a VNF with MANO is quite high. The promise of automating workflows for lifecycle events requires every network operator to work with the VNF vendors and make sure that the proper care is taken integrating the various virtual network functions as part of automation workflow.
This complexity is a major barrier to NFV deployment. There isn’t a single network operator out there that can ignore the software revolution that has become a reality through software virtualization and workload automation.
The legacy network vendors use the complexities in the current VNF onboarding process to promote their proprietary approach to network automation that provides a fraction of the benefits that open environments and NFV can allow.

The year of TOSCA – What this has to do with VNF onboarding

My colleague, Michael Brenner, provided a brief overview of how important TOSCA is for NFV and its ability to provide a standard method to describe model-based orchestration in his post The TOSCA Times Pt I – The TOSCA Landscape in 2017.
When we look at our long history with using TOSCA to onboard simple to complex VNFs, we realize how much easier it is to use model-based TOSCA to describe the VNF topology, interfaces, infrastructure requirements, telemetry and lifecycle events – all described in a TOSCA template that is not bound to any specific infrastructure, VIM, or even target cloud.
The VNF model describes the service’s components, relationships between components of the service, dependencies, requirements, and capabilities of each component in the template. The model declares reusable types and uses them to construct the structure of the application. Types can represent Nodes and Relationships helping to define connections between nodes of the model. Read more about this in an earlier post titles Utilizing Declarative Model-Driven TOSCA Orchestration for NFV.
Moreover, TOSCA is an open standard, ensuring that operators and VNF vendors will not be locked into a single VNF-M product. TOSCA allows for custom deployment variants of the VNF, making it possible for the operator to fine tune performance and costs per customer. VNF vendors have control over the parameters of these variants.
And beyond all this, TOSCA is the right tool for the job with its support for service composition, meaning that one VNF topology could be substituted with a variant or entirely new VNF product within an already existing service chain.
Last but not least, TOSCA (specifically the TOSCA Simple Profile in YAML 1.x) is “right-sized” as a standard, and it uniquely stands out amongst its peers in that sense. What that means is that it specifies (or will have) just enough normative types to allow the modeling of various topologies based on data types, nodes, requirements, capabilities, relationships, interfaces, and LCM, and no more than that. TOSCA does not force one into thinking of a specific, concrete information model that may be soon dated; instead it allows vendors and operators choices when describing their functions and services that meet their specific requirements. It is purposefully under-specified, which is also ideally suited to describe intent (what), instead of describing implementation (how) – thus providing for continuous growth, evolution, and migration from legacy to future architectures. That makes TOSCA a standard that is future-proof, and as a consequence, products based on it are future proof.

What do Open Source communities like Open-O and ONAP have to do with VNF onboarding?

Cloudify joined Open-O to help promote the model-first approach to orchestration. We have contributed our core TOSCA parser and workflow engine to Open-O, as part of the Apache ARIA project, to promote model-driven orchestration – then we joined Intel and Huawei on the VNF-SDK project. As a community, we worked to create vendor tools to model the VNF, package it, and make it ready to be deployed on any MANO stack.
When openECOMP and Open-O decided to merge, the VNF-SDK was one of the three projects that was to be ported from Open-O to the new ONAP.
I think this sends a very clear message about the importance of VNF onboarding agreement – one that the industry can look forward to. And, since ONAP is all about creating an open-source code base, this code can be the rendezvous point that can align the industry around a single way to package VNFs to be used in any MANO environment.

What’s the call to action for VNF vendors?

The Apache ARIA project was designed as a open-source, open-governance project that allows VNF vendors to adopt the VNF packaging tools as part of the CI/CD environment. We have also teamed up with Intel and VMware to make sure that this tool is integrated with Intel’s EZ-VNF initiative (of which VMware are also part).
VNF vendors that want to make cloud native, NFV-ready packages, can work with us and our partners VMware and Intel to build their NFV ready and cloud native VNFs using the ARIA tools and design them for high performance, and multi-VIM environments.  
The program we launched earlier this year is designed to reduce the financial and technical risks faced by VNF vendors. Rather than taking on the hefty costs of re-architecting their VNFs for cloud-native deployments, VNF vendors can now tie the expense of this transition to the success and scaling of commercial, revenue-generating production deployments. As a result, up-front fees for re-architecting a VNF can fall by orders of magnitude under the Cloud-Native VNF Program offered by Cloudify.
To demonstrate the effectiveness of this program, we did a really cool hackathon at MWC17, as well as NFV World Congress in San Jose. See a quick demo video: http://y2u.be/33gI7NX0FpY.

What do I get from Cloudify’s VNF Onboarding Program?

The VNF onboarding toolkit includes the following components:
1. Simple Template Generator Wizard
2. Advance Template Composer
3. Embeddable Orchestrator for VNF Provider

• Light/Embeddable
• Single Library
• TOSCA
• Multi VIM
• Cloud Native
• Open Source, Open Governance
• Built-in configuration management (Netcof/YANG..)
• Extendable through Plugins
• Kubernetes / Docker Swarm
• OpenStack
• VMware VCD/ VIO
• Azure
• AWS
• GCP
• Mesos
• CoreOS
• And much more 

4. VNF Catalog

• DE Experience
• Dual Editing (new)
• Drag and Drop experience
• Available as SaaS (new)