• Team
• Overview
• YANG Runtime Architecture
  • Serializer Registry
  • ModelConverter Service
  • Runtime Service
  • Model Registry
  • Helper Utils
    • Runtime Helper
    • Serializer Helper
• Use Cases of YANG Runtime
  • Configuration of devices
  • Configuration of service

Team

...

   serializerRegistry.registerSerializer(newJsonSerializer());

   serializerRegistry.registerSerializer(newXmlSerializer());

...

=>void unregisterSerializer(YANGSerializer serializer)

2)ModelConverter Service 

Model converter provides a mechanism for converting between DataNode and Model Object instances. It is capable of constructing model POJO objects from the DataNode,including any augmentations which may be present in the DataNode structure and creating immutable tree structure from a given POJO.

//Produces a mutable POJO backed by the specified data node

=> ModelObjectcreateModel(DataNode)

//Produces an immutable tree structure rooted at the returned DataNode using the supplied model POJO object

=> DataNode createDataNode(ModelObject)

3)Runtime Service 

It is a service for encoding and decoding between internal and external model representation. This service is used by:

Protocol Application - To encode/decode protocol representation to internal representation

YANG Store – To translate between internal representation and YANG objects for interaction with applications.

 One of the service is to decode the external representation of a configuration model from the specified composite stream into an in-memory representation.Resource identifier stream “URI” will get decoded to resource identifier and resource data stream will get decoded to data node.

=>CompositeData decode(CompositeStream external, RuntimeContext context)

Another service is to encode the internal in-memory representation of a configuration model to an external representation consumable from the resulting input stream.Resource identifier in composite data will get encoded to resource identifier stream and data node will be encoded to resource data stream.

=>CompositeStream encode(CompositeData internal, RuntimeContext context)

4)Model Registry 

This service provides the utility for registering a new YANG model. This is used by:

Applciation - To register application service interface. Ex:L3VPN etc

Provider - To register device schema.

Compiler(live/offline) - To register the extenal applcations schema / device schema.

This service is capable of the following:

Register a new model with parameters specifying any additional information provided by the application.

=>void registerModel(ModelRegistrationParam param)

Unregister the specified model with parameters specifying any addtional information provided by the applciation.

=>void unregisterModel(ModelRegistrationParam param)

5)SchemaContext Provider 

It returns an entity that provides schema context corresponding to a given resource identifier.

  //If the model is not registered the implementation returns null else it returns schema context corresponding to a given resource identifier.

=>SchemaContext getSchemaContext(ResourceId id)

Helper Utils

• Runtime Helper

  Represents utility for runtime.These utilities can be used by the application to get the YANG model for the application and also it can be used by the runtime to get the YANG Node for the given YANG model.

  Examples API's :

  1. To obtain YANG model for given generated class:

  =>YANGModel getModel(Class<?> aClass)

  2. To get YANG node for given YANG model

  =>Set<YANGNode> getNodes(YANGModel model)

  3. To get interface class name of the schema node

  =>String getInterfaceClassName(YANGSchemaNode schemaNode)

   

• Serializer Helper

  These set of utilities are used by Serializer to build the data node and resource identifier without obtaining schema.

  Example API's:

  1. To add to resource identifier builder used by applications which are not aware about the schema name association with key's value.This api will also carry out necessary schema related validations.

  =>ResourceId.Builder addToResourceId(ResourceId.Builder builder, String name, String namespace, List<String> value)

  2. To add a data node to a given data node builder. This API will also carry out necessary schema related validations.

  =>Builder addDataNode(Builder builder, String name, String namespace, String value, DataNode.Type type)

  3. To get the resource identifier for a given data node. This API will be used by serializer to obtain the resource identifier in the scenario when an annotation is associated with a given data node.

  =>ResourceId getResourceId(Builder builder)

Use Cases Of YANG Runtime

• Configuration of devices

  Image Added
  

  Control Flow:

  Prerequisite : Onos NB registers the device YANG model with YANG Runtime

  Step 1: User/Application sends device configuration data in JSON/XML format to RESTCONF.

  Step 2: RESTCONF sends the data to YANG runtime for it to decode the data to DN(data nodes) and then return them back.

  Step 3: RESTCONF pushes the decoded data to Dynamic configuration subsystem.

  Step 4: Dynamic configuration subsystem then sends a notification to NETCONF.

  Step 5: NETCONF removes the additional metadata information and then send it to YANG runtime.

  Step 6: YANG runtime encodes the data to JSON/XML format and send it back to NETCONF.

  Step 7: NETCONF send the encoded data to the SB devices.

   

• Configuration of Service

  Image Added
  

  Control Flow:

  Step 1: Restconf receives the data from user/application in JSON/XML format.

  Step 2: It sends this data to YANG runtime which uses serializer to decode it into DN(data nodes).

  Step 3: Restconf pushes the encoded data to Dynamic Configuratation subsystem.

  Step 4: Dynamic Configuration sends notification to L3VPN application.

  Step 5: After receiving the data, it sends it to YANG runtime for a model conversion from DN to POJO and then sends that back to L3VPN application.

  Step 6: The L3VPN application creates a Standard device model and sends it to vendor.The vendor modifies it accordingly and creates a vendor specific device model and then sends this to L3VPN application .

  Step 7: L3VPN application sends it to YANG runtime for a model conversion from POJO to DN.

  Step 8: L3VPN application pushes the vendor model to Dynamic Configuration subsystem.

  Step 9: Dynamic configuration subsystem sends notification to Netconf.

  Step 10: NETCONF removes the additional metadata information

  Step 11: NETCONF sends the data to YANG runtime which enoded it to JSON/XML format and then return the same to NETCONF.

  Step 12: Finally NETCONF sends the data to the SB devices.