Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Contributors

nameOrganizationEmail

Patrick Liu

Huawei Technologies

Patrick.Liu@huawei.com

Nihui

HuaweiTechnologies

nihui@huawei.com

Qinchuan

HuaweiTechnologies

qinchuan@huawei.com

Jiangrui

HuaweiTechnologies

henry.jiangrui@huawei.com

Jiangchuncheng

HuaweiTechnologies

jiangchuncheng@huawei.com

Zhaokexue

HuaweiTechnologies

zhaokexue@huawei.com

Kalyan A

HuaweiTechnologies

kalyana@huawei.com

Vinod Kumar S

HuaweiTechnologies

Vinods.kumar@huawei.com

Gaurav Agrawal

HuaweiTechnologies

Gaurav.agrawal@huawei.com

Bharat Saraswal

HuaweiTechnologies

bharat.saraswal@huawei.com

Vidyashree Rama

HuaweiTechnologies

Vidyashree.Rama@huawei.com

Janani B

HuaweiTechnologies

janani.b@huawei.com

 

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 lack critical capabilities like being easily read and understood by human implementer's, and fell short in providing mechanisms to validate models of configuration data for semantics and syntax.

YANG is a preferred choice to represent interface and behavior semantics (of device/ controller/ component) because of following reason:

  • Human readable, easy to learn representation.

  • Hierarchical configuration data models.

  • Reusable types and groupings (structured types).

  • Extensible through augmentation mechanisms.

  • Supports the definition of operations (RPCs).

  • Formal constraints for configuration validation.

  • Data modularity through modules and submodules.

YANG modeled interfaces needs to be implemented by corresponding application /component.

There are 2 parts in implementing the interface:

a) Syntax/ Semantics processing of the request/response being exchanged.

b) the business logic to compute the request.

Implementation of syntax/ semantics processing is required. This implementation can be a manual approach wherein the data structures are manually implemented in target language. In this approach there is a scope for human error while implementation also it requires considerable efforts for implementation. Alternatively the implementation can be automated wherein these data structure are automatically generated thereby avoiding manual errors and improving efficiency.

We intend to abstract the applications from syntactical processing of information encoding with external world and provide a framework in which the applications only need to implement the business logic and seamlessly support any interface language like REST, NETCONF etc. As a part of this goal following work is proposed in Falcon and Golden Eye release.


Proposed work

Proposed Falcon deliverable:

  • Basic YANG Utils supporting:

    • Basic built-In data type.

    • Individual YANG file support.

  • Sample application (with manual REST implementation)


Proposed Golden Eye release deliverable:

  • Advanced YANG Utils supporting:

    • Derived data types.

    • Augmentation/Grouping/Union support.

    • Module/Sub-module support.

    • Import/Include support.

  • NBI REST framework automation including:

    • Automated APP URI registration.

    • Automated JSON CODEC implementation.

  • Sample application (with automated REST implementation)

 

YANG Utils details:

Overview

YANG Utils are the basic building block to achieve the final goal of abastracting the language based Syntax/Semantics processing by APPs. These UTILS intend to have following:

  1. YANG Parser for parsing YANG file.
  2. Translator tool for auto-generation of JAVA corresponding to a given YANG.
  3. Metadata generation which will be an input for NBI/SBI automation.

 


Example

REST NBI automation details:

Overview

With the current REST mechanism, every APP must perform the Manual Rest Registration and implement the manual CODEC function, thereby slowing down the APP development and increasing chances for manual error. Current REST NBI Mechanism is depicted in below figure:


As a part of this project we intend to model the NBI Interface and augment the REST NBI Framework to Automate the URI Registration and CODEC Implementation, thereby reducing manual error and faster application development. Proposed REST NBI Mechanism is depicted in below figure:


Benefit & impact analysis:

Benefit to service provider

  • Modeled based Services/Network Visibility

  • YANG based Standard Interface Representation.

  • Seamless Standard YANG based Application Adaptation.

Benefit to ONOS developers

  • Smaller Learning Curve

  • Provides Faster APP Development.

  • Better Quality due to Automation.

  • Modeled based application interface.

Impact on existing system

  • Augments the existing work.

  • No impact on existing system.


Long Term Objective:

Abstraction and automation of:

  1. NBI framework where in application's can seamlessly support any NBI interface.
  2. NETCONF SBI framework. (Extend support to ONOS NETCONF for metadata and class generation).
  3. Modeling Driver Behavior and help applications to use it seamlessly.
  4. Modeling of resource information. Application(s) can maintain information of their interest, associated with resource in the resource manager.  

    Below figure gives the long term objective of YANG in ONOS.

Sample application (SFC)


End to End abstraction using YANG

  • Applications expose service model interfaces and map it to network model based on business logic.
  • Drivers maps the generic network model to corresponding device specific model.
  • SBI use the device model to encode the information in protocol packets.

    Below figure depicts the E2E YANG based abstraction.


  • No labels