Table of Contents |
---|
Team
Name | Organization | Email |
---|---|---|
Adarsh M | Huawei Technologies | adarsh.m@huawei.com |
Bharat Saraswal | Huawei Technologies | bharat.saraswal@huawei.com |
Brian O'Connor | OnLab | bocon@onlab.us |
Gaurav Agrawal | Huawei Technologies | gaurav.agrawal@huawei.com |
Janani B | Huawei Technologies | janani.b@huawei.com |
Patrick Liu | Huawei Technologies | Partick.Liu@huawei.com |
Ray Milkey | OnLab | ray@onlab.us |
Sathish Kumar M | Huawei Technologies | sathishkumar.m@huawei.com |
Shankara | Huawei Technologies | |
Sonu Gupta | Huawei Technologies | sonu.gupta@huawei.com |
Suchitra H N | Huawei Technologies | suchitra.hn@huawei.com |
Thomas Vachuska | OnLab | tom@onlab.us |
Vidyashree Rama | Huawei Technologies | vidyashree.rama@huawei.com |
Vinod Kumar S | Huawei Technologies | vinods.kumar@huawei.com |
YANG Tools Overview
YANG is a data modeling language used to model configuration & state data. Modeling languages such as SMI (SNMP), UML, XML Schema, and others already existed. However, none of these languages were specifically targeted to the needs of configuration management. They lacked critical capabilities like being easily read and understood by human implementers, and fell short in providing mechanisms to validate models of configuration data for semantics and syntax.
YANG tools are the basic building block to achieve the final goal of abstracting the language based Syntax/Semantics processing by APPs.
The YANG modeled interfaces need to be implemented by corresponding application component. There are 2 parts in implementing the interface:
- Syntax/semantics processing of the request/response being exchanged.
- Business logic to compute the request.
- Syntax/semantics processing of the request/response being exchanged.
YANG Tools is a infrastructure project aiming to develop necessary tool chain and libraries providing support of NETCONF and YANG for Java(JVM-language based) projects and applications.
We intend to abstract the applications from syntactic processing of information encoding with external world.
We intend to provide a framework in which the applications only need to implement the business logic and seamlessly support any interface language like REST, NETCONF etc.
In ONOS, YANG is being used as a general purpose modeling language.
...
Model
YangCompiler
YangSerializer
YangRunTime
Model
Base Models will be used by different YANG components. It includes following:
DataNode
...
Provides a basis for holding information in a tree whose structure corresponds to a set of YANG models (base & augmentations).
...
- Inner node represents container and list.
- Leaf node represents leaf and leaf-list.
ResourceId
...
Resource identifier, Its list of node key to drive path till the resource, where key is contains the local node name and the corresponding module namespace.
- Is immutable.
- Provides a mechanism for mutation (Builder pattern, etc.)
- Used to operate on a given resource.
ModelObject
...
Provides a common basis for all POJOs which are generated from a YANG model.
- It is mutable.
The binding between ModelObject POJO and DataNode is performed by the YANG Runtime.
Each model or application will have a unique identifier, which can be configured using buck or maven as shown below :Code Block language bash title To config mode-ld using maven <configuration> <modelId>xml</modelId> </configuration>
Code Block language bash title To config model-Id using buck yang_model( app_name = 'example.application', model_id = 'example_id' )
In-case model-id is not configured then artifact-Id will be configured as model-Id for that particular application.
YANG Compiler
The compiler consists of YANG language parser and Java code generator(linker & translator).
...
Various components of YANG compiler which helps yang compiler to compiles YANG files and generates the required code with serialized metadata.
Parser
Parse the input YANG file and produces DataModel. It compiles Yang files against the YANG grammar version 1.0 using ANTLR tool and updates the data model tree.
DataModel
Abstract representation of YANG in JAVA tree format, it is later serialized and used by YANG runtime to understand the schema information.
Linker
Links the various Intra File/Inter-File/ Inter-JAR YANG constructs dependencies. For ex: grouping and uses linking, typedef and type linking. Import, imclude depencency.
Translator
Generates Java code corresponding to Data model.
...
https://wiki.onosproject.org/display/ONOS/YANG+Compiler
YANG Live Compiler
Allows on-the-fly compilation & registration of YANG models.
To be updated later...
YANG Serializers
Serializers is an entity capable of encoding and decoding arbitrary structures(Data Node),
which are in-memory representations of YANG models, to and from various external representations, e.g. XML, JSON.
...
It encodes 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.
...
Facilities to convert Input stream to DataNode and vice versa.
...
2) XML Serializer: Convert to/from XML to DataNode
YANG Runtime
The runtime serves as a registry of various YANG models in the system and its primary purpose is serialization and deserialization from various external formats (XML, JSON, Kryo) and their internal Java representations (based on DataNode base-class).
...
https://wiki.onosproject.org/display/ONOS/YANG+Runtime
Design Considerations
Framework components must be model-agnostic
- e.g. runtime, protocol adapters, information store
- must be capable dealing with any potential model
- cannot be linked with the model-specific objects
- hence must deal with data in a neutral format, i.e. raw tree
Applications should be model-aware
- e.g. applications that implement network services
- must understand the semantics of the model to operate
- raw tree representation not expressive or application friendly
- hence should deal with data in domain-friendly model objects
Model-agnostic Tree View
Consider a simple device model
- device has a number of attributes and a number of ports
- each port has a number of attributes
Spread across several tree layers
- data produced by tree augmentation
- data accessed by tree traversal
Model-specific Object View
Rich data types, e.g. Device, Port
- domain-friendly abstractions
- idiomatic Java usage
Consolidates multiple tree layers
- data created through constructors
- data accessed via accessors
- device.swVersion() or device.getPorts()
Model Object & Tree Views
Toolchain facilitate both model-agnostic tree
view and model-specific object views
Toolchain must allow conversion between them
Model ←→ Tree View
Mutable vs Immutable
Immutable data is safer in multi-threaded apps
- free of side-effects when shared by caller
- memory efficient - a single copy can be shared by many threads
… but apps need to easily mutate data
Model objects are mutable
- modified via idiomatic constructors and setters
Tree views are immutable
- constructed via builders
- immutable once constructed
Configuration of Devices
- Goal is to enable a network operator to seamlessly configure devices from different vendors and to verify the configuration with minimal or no human intervention
- Offers significant OPEX savings and vendor independence for network operators
- Offers vendors faster integration of their products into operator’s networks
Configuration of Services
● Goal is to enable a network operator to seamlessly configure and provision a service on the network comprising many devices from many vendors with minimal or no human intervention
● Provides network operators with agility to deploy new services with reduced OPEX
● Offers vendors opportunity to support many services on their devices
Reference of Applications
Schema Aware Applications:
...
Example: RESTCONF, NETCONF, Store
Enhancement with YANG 2.0
| YANG Tools (1.11) + YMS | YANG Tools (2.0) + Dynamic Config |
Generated Classes | Tied to YMS; no common basis between models | Common ancestor for all models; model-agnostic and model-specific access; friendly API for apps |
Storage | Ad hoc; models serialized and stored at the discretion of application | Any and all models in a single store |
Protocols | RESTCONF and NETCONF are tightly coupled and integrated with YMS | RESTCONF and NETCONF can be maintained independently; new protocols (e.g. gNMI are easier to add) |
New Models | Applications must be made aware of all models at compilation time; cannot be stored by YMS | Applications can interact with new models or augmentations at runtime using the model-agnostic interface |
Live Compilation | Not available; introduction of new models requires recompilation | YANG models can be introduced and compiled at runtime (e.g. from a device) |
Modularity and Maintainability | YMS and onos-yang-tools are tightly coupled making maintenance difficult and usage is brittle | YANG tools, dynamic config manager and store are implemented in a modular fashion; they can be evolved and maintained independently from one another; generated classes are not tied to the dynamic config store |
Reference
https://wiki.onosproject.org/display/ONOS/YANG+Compiler
...
https://wiki.onosproject.org/display/ONOS/L3VPN
Future
To be planned:
1) YANG 1.1 version.
...
4) YANG GUI enhancement for live compilation.
5) Sub-module support.