Converting YANG to TOSCA

YANG is a data modeling language that is the de-facto standard in the networking industry for defining schemas for network configuration data and runtime state. Most vendors provide YANG modules for configuring their equipment, and many internet RFCs have been created that standardize configuration data schemas that can be adopted by multiple vendors.

However, YANG has also seen applications that go beyond configuration data modeling. In fact, some standards bodies have used YANG to model end-to-end services. Those standards use YANG to define the components of which a service is composed as well as the configuration data and runtime state for each of those components.

Unfortunately, given that YANG is strictly a data modeling language, YANG cannot be used to express service-related semantics. For example, YANG does not allow you to specify which parts of the model define service components and which parts define configuration data for those components. That information can only be found in the standards documents that define the services in the first place. Similarly, the YANG language alone can also not be used to define dependencies between service components, or to express how some components can be decomposed using entire other service models. The YANG language does not have support for expressing those semantics in a general-purpose fashion.

Of course, service semantics are a must-have for service lifecycle management. Automated service lifecycle management systems must know which components make up a service, how those components depend on one-another, how instantiation and activation of those components must be sequenced, how configuration information may need to be propagated between components, etc. To avoid having to build knowledge of service semantics for each individual service into the lifecycle management system, it must be possible to express service semantics using the service modeling language.

This is where TOSCA shines. TOSCA is a service modeling language for automating service lifecycle management:

• Whereas YANG documents are trees, TOSCA uses graphs to model services. TOSCA service topology graphs explicitly model service components (using TOSCA nodes) and the dependencies between these components (using TOSCA relationships).
• TOSCA includes data types for defining the schemas of configuration data for nodes and relationships. As such, TOSCA data type definitions are similar to YANG schema definitions.
• For each component, TOSCA allows component designers to define the ports through which their components interact. TOSCA introduces capabilities and requirements for this purpose. Capabilities and requirements allow for modular design of reusable components.
• TOSCA allows individual components to be modeled using their own service sub topologies. This is useful to model how network functions can be disaggregated into collections of finer grain components.

Using TOSCA, it is possible to build general-purpose service lifecycle management systems that rely strictly on the semantics built into the TOSCA language without having to introduce service-specific knowledge into the management system.

One possible approach for allowing YANG-based service models to be “consumed” by general-purpose service lifecycle management systems is to convert those YANG models to TOSCA. We have created a tool called yang2tosca that aims to do just that. The conversion involves two steps:

1. First, YANG models are converted automatically by yang2tosca to (almost) equivalent TOSCA date type definitions. 
2. Next, service designers must (manually) convert some of the resulting TOSCA data types into node types, relationship types, requirements, and capabilities. This step requires knowledge of service-specific semantics and cannot be automated.

The tool can be found at https://github.com/lauwers/yang2tosca

Please try it out and let us know what you think.