Abel Tong (@EnableBlue) is part of Ciena's Blue Planet division and is responsible for helping network operators transform their networks by leveraging SDN and NFV to create new services while simplifying their network operations. 

This is the second in a series of posts highlighting Blue Planet’s new architecture and features.  Other posts:

• Ciena Blue Planet unveils the dawn of service orchestration
• Apply BPMN to Enable Network Transformation at the OSS
• Behind the scenes with Ciena's new Blue Planet architecture
• What is the "Right" Approach to Open Source?
• Four Reasons You Want a Micro-Services Architecture

As network operators move to a more open and software-based services model that leverages new technologies like SDN and NFV, a host of new standards and open-source projects come into the picture for consideration.  And while the revolution towards virtualized network services can be exhilarating, it can also be rather confusing. 

One of these new areas of thought is around data modeling and templating technologies.  Network operators are looking for dev-ops style self-service programmability as a way to break the system integration stranglehold. This is where incumbent back-office vendors charge professional services fees for every incremental change to a network or services - which can end up costing millions.

Data modeling helps us describe or model the resources we have.  Templating makes it easy to understand and easy for the operator to make changes to the services themselves.

So related to this self-service programmability and the automation of the network, here’s one specific question we’ve heard a number of network operators asking: “I don’t know whether to go with TOSCA or YANG?  TOSCA seems better for cloud and YANG better for networking.  Help me make the right choice.”

Well, the way we see it; it’s not an “either/or” choice.  We would recommend leveraging the respective strengths of each technology and applying TOSCA and YANG where it makes sense. Here’s what we mean:

Defining TOSCA

TOSCA is Topology and Orchestration Specification for Cloud Applications.  TOSCA’s mission is to facilitate the creation cloud applications and services.  TOSCA provides mechanisms to control workflow, describe relationships and reflect dependencies between resources. 

Defining YANG

YANG is a data modeling language used to describe configuration and state information.  YANG has been used to model networking devices and services – i.e., an object and its attributes.  YANG defines the data models that are then manipulated through the NETCONF protocol. 

YANG’s strength is in configuring networking devices.  So for example, a device such as a router can be modeled in YANG.  The router can then be configured via NETCONF.  The configuration is plain text and human readable.  It’s easy to copy and paste and compare across other configurations.

TOSCA’s strength is orchestration.  In other words, TOSCA can describe the coordination between diverse resources across a potentially complex application environment.  For example, in the cloud, TOSCA can describe the creation of a web hosting service where a webserver on multiple hosts is connected to a database and includes networking functions such as DNS, load balancer and firewall, which all need to be configured.

TOSCA and YANG: Friends not foes

Interestingly, TOSCA and YANG can be used together.  For example, consider an infrastructure-as-a-service (IaaS) application where an Enterprise relies on high performance connectivity across the WAN to access dynamic compute and storage in the data center. 

In this case, the cloud components – compute and storage would be described by TOSCA.  The connectivity service and networking equipment in the WAN would be described by YANG.  TOSCA would provide the overarching description that combines WAN connectivity with the cloud to create the IaaS application. The below diagram shows the coexisting relationship between TOSCA and YANG.

Now consider a scenario using network function virtualization (NFV).  NFV includes a combination of cloud and WAN.  TOSCA would be used to describe the cloud environment and how to instantiate virtualized network functions (VNFs). 

YANG could be used to define the interfaces for configuring the individual VNFs.  And then, TOSCA would describe how the end-to-end service including the creation, configuration and chaining of VNFs.  The below diagram depicts this NFV scenario.

In summary, use TOSCA to describe orchestration.  Use YANG to describe devices.  Use a combination of TOSCA and YANG when describing end-to-end services spanning WAN and cloud.

This is complicated stuff, but it’s a topic our Ciena Blue Planet team helps network operators navigate on a regular basis.  Blue Planet provides a highly programmable orchestrator that is not tied to any particular interface, language, or resource type. The architecture leverages a number of information models and orchestration tools – including TOSCA and NetConf/YANG – to enable complete lifecycle management of cloud and NFV applications, and to configure the virtual and physical devices that comprise an end-to-end service.

If you have questions, I invite you to ask them in the comments section below, or find me on Twitter at @EnableBlue.

UPDATE:

We've received a couple of important questions related to this TOSCA and YANG blog since we first posted it:

Q: Isn't YANG being used to describe services?

The point of the blog is choosing the right technology for the task at hand. YANG is a modeling "language." As mentioned in the blog, YANG provides a way for describing "what a service is." However, YANG is not an orchestration language. YANG does NOT provide a mechanism for describing "what to do." In other words, YANG is not effective for describing how a service should be implemented, the topology of underlying resources, or how resources may be related or dependent upon each other.

TOSCA, an acronym for Topology and Orchestration Specification for Cloud Applications, is a standard language built specifically for orchestration. TOSCA is widely deployed across the IT and Cloud space for the orchestration of all kinds of services. In this case, TOSCA describes both "what it is" and "what to do." So yes, you can use YANG to describe a service. But, if you choose to use YANG to describe the service, you would still use TOSCA to describe the orchestration of the service.

Q: TOSCA is widely used for the orchestration of cloud-based applications and services, but can TOSCA be used to describe network functional virtualization (NFV) or wide-area networking services?

Yes, in fact OASIS, the standards organization responsible for TOSCA, has a technical committee draft document providing a profile for NFV that includes networking E-Line and E-LAN connectivity.

Infonetics Webinar: YANG & TOSCA – Service Models Critical to SDN and NFV Automation