TOSCA and YANG for Application and Network Orchestration

I work quite a bit with TOSCA based definitions for application orchestration and more specifically to orchestrate virtual network functions (VNFs AKA NFV – network function virtualization). In this capacity, I’ve recently been encountering quite a number of Telecoms and service providers mentioning TOSCA, YANG and modeling languages in general.

I also have noticed that network personnel mainly discuss Netconf/YANG while application personnel talk TOSCA.
Before I dive into TOSCA and YANG and map them out, I’d like to venture my two cents on where the future is going and basic VNFs requirements to get there.

VNFs are becoming more and more application oriented. They require complex action to be taken, work with databases, records, processes, files — not to mention, dependencies and order between them and external entities, and even H/A capabilities like self-healing and auto-scaling for high performance loads.
<!–

Orchestration for NFV, VNF with TOSCA and Netconf/YANG with Cloudify.  Go

–>

White Paper: NFV from ETSI to MANO to YANG. Get it today.     Go

The border between applications and network functions are becoming blurred in many cases.
Here’s a quick landscape mapping as I see it:

• You have simple VNFs like vRouters (Vyatta from Brocade and CSR from Cisco for example).
• Beyond that you have DNS, LDAP and a like services which are more application-oriented services. You have to add new records when you provision a new tenant, which is an application action.
• More complex VNFs come with their own databases or rely on an open source relational or noSQL database like Cassandra for example.
• The complex VNFs or chains of VNFs like a CDN subsystem or IMS and EPC subsystems require deep orchestration capabilities, creation orders, network dependencies, relationships and complex actions to be performed.

VNFs require support of application orchestration beyond network resource configuration.

TOSCA and YANG are Commentaries.

Here is a sample to provision a tenant’s Cisco Cloud Services Router (CSR) using a TOSCA-based blueprint. Part of the provisioning of the CSR is the attachment of network interfaces to the management network, inbound network and outbound network. Moreover, it could also be configured to point to an LDAP AAAA server with the right OUs (organizational units) definition as well as to a tenant’s DNS.

TOSCA is very good when it comes to defining virtual application topologies, VNF dependencies and relationships, actions to be performed as part of a lifecycle. In a previous post,I described how to build NFV on Openstack with an open source IMS from Clearwater and modeled it with a TOSCA-based blueprint.

YANG is very good at configuring network devices and network services. Netconf is the protocol that represents the YANG model on the wire. YANG provides the ability to easily configure network devices in a human readable fashion.
Using Netconf/YANG one can easily configure devices, separate between configuration and operational data as well as apply versions, and compare configurations across devices.
The Netconf/YANG strength is with configuring network devices.
Here is a YANG snippet that describes a host with a network type interface of ATM or ETHERNET with MTU size of 1500 bytes.

With the introduction of clouds and new requirements to support IaaS, PaaS and SaaS and support distributed applications, a need for an new breed of orchestrators has arisen.
Such orchestrators now need to support diverse operations:

• Automatic installation and deployment of distributed applications. as described above, VNFs are becoming application creatures.
• Installation and deployment of infrastructure services such as compute, network and storage components.
• Monitoring capabilities, ability to monitor hosts, networks, cloud components, e.g. OpenStack Keystone, Glance, Neutron, etc.
• Ability to take proactive actions like self-healing and auto-scaling, failover and other remediation activities when needed.
• Support of multiple data centers deployments, federated management views, etc.
• Support of multi-clouds and hybrid clouds like EC2, Openstack, and VMware.

TOSCA is very good supporting the latter requirements, while Netconf/YANG is very good at configuring network devices. Combining the two fuses the best of both worlds which support of the following:

• Provisioning IaaS components which mainly include compute network and storage. (This would be done with the TOSCA-based templating)
• Configuring network devices which include lots of configuration details per device type (This would be done via Netconf/YANG modeling)
• Topology-driven monitoring (TOSCA)
• Day to day operations that are performed on the topology graph like upgrades, self-healing scaling etc. (TOSCA)

Moreover, TOSCA orchestration can communicate with Netconf/YANG-based components and drive network configurations and orchestration via Netconf/YANG-based products. In this way, we can leverage the best of the two worlds.

Here is the model that I would suggest for such purposes.  TOSCA to drive YANG-based products, e.g. Tail-f, they can be on the same level or TOSCA could eventually be an orchestrator of orchestrators. (I know – sounds like a mouthful). The exact configuration will evolve in the next couple of years to meet the vast Telecom operators requirements for network automation and orchestration of VNFs and subsystems like IMS CDN and EPC.
In my next blog post, I will describe how I actually took a TOSCA-based product and a Netconf/YANG-based product and created a new service ‘Internet service creation”, connecting a new customer to the internet  with a mixture of VNFs like vFW, vRouter and more.

It required the writing of a TOSCA -> Netconf/YANG plugin which knows how to parse TOSCA-based parameters and translate them to YANG.  You can check out the diagram below until then.