Over a million developers have joined DZone.

TOSCA and YANG for Application and Network Orchestration

DZone's Guide to

TOSCA and YANG for Application and Network Orchestration

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

NFV | Network Automation | VNF - Netconf/YANG - TOSCA

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 Telcos 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

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.
        type: cloudify.openstack.nodes.Server
            use_external_resource: False
            resource_id: tenant_router
            install_agent: false
                image: { get_input: router_image_id }
                flavor_name: { get_input: flavor_name }
            management_network_name: { get_property: [management_network, resource_id] }
            - target: management_network
              type: cloudify.relationships.connected_to
            - target: management_subnet
              type: cloudify.relationships.depends_on
            - target: tenant_network
              type: cloudify.relationships.connected_to
            - target: tenant_subnet
              type: cloudify.relationships.depends_on
            - target: firewall_inbound
              type: cloudify.relationships.connected_to
            - target: firewall_subnet
              type: cloudify.relationships.depends_on

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.

container system {
  leaf host-name {
  type string;
leaf-list domain-search {
  type string;
list interface {
  key "name";
  leaf name {
    type string;
  leaf type {
    type enumeration {
    enum ethernet;
    enum atm;
  leaf mtu {
    type int32;
  must ``ifType != 'ethernet' or ``+
  ``(ifType = 'ethernet' and `` +
  ``mtu = 1500)`` {                                                                          -

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 Telco 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.


Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}