Combining TOSCA and Netconf/YANG to Deploy Network-Centric Services in NFV and SDN Architectures

In the world of NFV, YANG is a popular data modeling language that serves as a contractor between network devices and those that interact and interface with these devices. The YANG data model enables you to define how to write configuration data, as well as how to communicate state data in hierarchical manner that’s strongly typed.
YANG originated as the data modeling language for the NETCONF protocol, similarly to SMI for the SNMP protocol. In fact, NETCONF is considered by many as the potential successor for SNMP. As such, NETCONF is used to configure and interact with (both physical and virtual) network devices such as routers, firewalls and switches.

Intelligent NFV orchestration for any telecom environment. Download today. Go

TOSCA, in the context of NFV, is a language that enables data modeling as well, however that is not its primary use case (it is only a byproduct of the way it was written – being very flexible). TOSCA’s primary uses is its focus on topology and workflows, processes, and policies. Therefore, when you want to manage the full lifecycle of orchestration in an NFV use case, you usually have to start with provisioning VIM resources, next deploy software components and VNFs, then wire them in and push configurations to these devices to make everything work, and chain them to other services as needed.

When it comes to NFV orchestration, from a MANO perspective, the orchestrator needs to work with different NFV components, such as controllers (primarily SDN controllers, e.g. OpenDaylight, OpenContrail, ONOS), as well as physical and virtual network functions – i.e., load balancers, routers, switches, firewalls. This can be done directly or through an SDN controller, and even by delegating to an SDN controller, or a combination of these options. YANG is often times the language of choice to model and configure these devices in a networking world.

That is why, in the capacity of my work at Cloudify (an open source TOSCA-based orchestrator), I have been working on integrating these languages so that they can communicate seamlessly, in order to enable the orchestrator to also fulfill aspects of the VNFM. This is because, specifically for the VNFM piece, YANG plays an important role, as many of these devices already support YANG and one of its configuration protocols, either NETCONF or RESTCONF. To this end, it’s been interesting to explore the relationship between TOSCA and YANG, and how TOSCA can work with YANG, as well as its related protocols to fulfill the role of VNFM for YANG supported devices.

How does it work?

Basically, a device that supports YANG will typically have YANG modules that represent the data model this device supports. To bring TOSCA and YANG together, we built a YANG to TOSCA translator that enables you to take the YANG files the device supports, and generate TOSCA YAML files from them that define the data and node types that represent the YANG modules the device can understand. This enables the blueprint author to use those types to basically push and read configuration files to and from the devices that support YANG. These become TOSCA files you can import to use in any blueprint you have written.

The nodes that were created from these types will talk either NETCONF or RESTCONF depending on the developer’s choice with these devices, as part of the TOSCA workflow.

So for example, with an install workflow, using Cloudify as an example, the orchestrator first provisions VIM resources, then binds and onboards virtual network functions and apps, and later in the same workflow pushes configurations from the TOSCA nodes generated from the YANG files onto the YANG supported devices. This will enable the quick creation of NFV services such as an IP VPN, or internet activation and many more NFV scenarios.
We are currently POCing the IP VPN concept with a large Telecom vendor and design partner who are looking to leverage their existing YANG modules and assets with orchestration capabilities across hybrid environments. The architecture consists of virtualized infrastructure alongside private cloud, powered by VMware Cloud and VMware Integrated OpenStack, OpenDaylight, and some the leading VNF vendors.

In my next post, I will followup with a deeper dive on the actual technical details and architecture, as well as a snippet of the blueprint for how this was achieved in the real world.
See Cloudify in action at Mobile World Congress in Barcelona demonstrating a cutting-edge NFV solution at Intel booth #3D30 and the deployment of a Multi-VIM vIMS at the VMware booth #3K10.