In this section:


Overview

Yang is a data modelling language (refer RFC 6020) which models configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. Sonus SBC Core configuration details are defined as Yang specifications. Yang supports SBC yang file extensions. These extensions provide additional information to the EMA. 

The SBC Core supports configuration and operational resources using REST API.

 The SBC data model contains several tree structures. The table below describes the root levels.

 

Resource Category
(Root Level)

Description

 Yang File Name

addressContext

Objects scoped to a specific IP addressing domain

 sonusAddressContext.yang

alarms

Alarms Management

NOTE: Some alarms reside under oam root level as well.

sonusAlarmMgr.yang

global

Global objects applicable node-wide 

 sonusGlobal.yang

oam

Operations and Maintenance objectssonusOrca.yang

profiles

Profiles of configuration shared by multiple objects 

 sonusGen2Profiles.yang

system

System-level configuration 

 sonusSystem.yang

Configuration Data

Configuration data is the set of write-enabled data that is required to transform a system from its initial default state into its current state. When a node is tagged with config "true", its sub-hierarchy is flagged as configuration data. For example,  In the leaf or list statement, configuration data is defined by  “config true".

Setting Configuration Data

This section describes some important concepts for setting configuration data defined in Yang specs. Configuration data is defined by either “config true;” or the absence of “config false;” in a list or leaf statement. There are many ways to constrain the values of a leaf.

The “type” statement in a leaf constrains the values of a leaf to the “typedef” referenced by the “type” statement. The values of the leaf can be further constrained by the Yang “must” statement.

Leafs may be further constrained by semantic validation. Semantic validation is not defined in a Yang specs usually due to complex interactions between leaf values. Some SBC configuration elements cannot be changed while being actively used by the SBC application. Occasionally, there will be a “state” leaf in a list that must be set to “disabled” before changing other leafs in the list. Any request to change configuration that is rejected by semantic validation will include an error message in the response.

Leafs may be constrained by leafrefs. A leaf that references another leaf via a leafref can only take on the values currently set in the referenced leafs.

Leafs may be mandatory or optional. If a leaf is mandatory is must be set when creating an entry in a list. Optional leafs may have a default value. If an optional leaf is not set when an entry in a list is created, it will take on the default value. If an optional leaf does not have a default value and it is not set when creating a list entry, the leaf will not exist in the entry.

State Data

State data is read-only non-configuration data, such as status and statistics information. When a node is tagged with config "false", its sub-hierarchy is flagged as state data .For example,  In the leaf or list statement, state data is defined by  “config false".

Operations

Operations are actions such as saving/restoring configuration, initiating upgrade that are executed. All operations are defined in SBC Yang specifications using tailf:action. The action definition specifies how the action is invoked, and includes the input and output parameters (if any).

The SBC operations return two output values:

ResultAn enumeration with values “success” or “failure”
ReasonIf the operation is not successful, returns a string with the reason for the failure.

Common SBC data model yang statements include:

Statement

Description

 Example

augment

This statement inserts one yang specifications within the tree structure of another yang specifications.

 File : sonusCarrier.yang

augment "/GLOBAL_OBJECTS:global"
GLOBAL_OBJECTS is a label defined as:
 import sonusGlobal {
   prefix GLOBAL_OBJECTS;
 }

Conclusion:

These statements inserts the sonusCarrier.yang specification into the sonusGlobal module defined in sonusGlobal.yang at “container global”.

So the “list carrier” defined in sonusCarrier.yang in now a branch under “container global” in sonusGlobal.yang.

container

This statement defines an interior data node in the data model tree. It takes one argument, which is an identifier, followed by a block of sub-statements, that hold detailed container information. A container node does not have a value, but it has a list of child nodes in the data tree. The child nodes are defined in the container's sub-statements. Defined in RFC 6020

list

This statement is used to define an interior data node in the data model tree. A list node may exist in multiple instances in the data tree. Each such instance is known as a list entry. The "list" statement takes one argument, which is an identifier, followed by a block of sub-statements that holds detailed list information. A list entry is uniquely identified by the values of the list's keys. Each entry in a list has a unique set of key values.

 Defined in RFC 6020

module

This statement defines the module's name, and groups all the statements that belong to the module together. The "module" statement's argument is the name of the module, followed by a block of sub-statements that hold detailed module information. There is generally one module in a yang file.  Defined in RFC 6020

leaf

This statement is used to define a leaf node in the data model tree. It takes one argument, which is an identifier, followed by a block of sub-statements that holds detailed leaf information. A leaf node has a value, but no child nodes in the data tree.

 Defined in RFC 6020

typedef

This statement defines a new type that may be used locally in the module, in modules or sub-modules which include it, and by other modules that import from it. The new type is called the "derived type", and the type from which it was derived is called the "base type". All derived types can be traced back to a YANG built-in type. The "typedef" statement's argument is an identifier that is the name of the type to be defined, and MUST be followed by a block of sub-statements that holds detailed typedef information.

 Defined in RFC 6020
mustThis statement is optional, takes as an argument in a string that contains an XPath expression. It is used to formally declare a constraint on valid data. Defined in RFC 6020
tailf:actionIn yang language, operations are supported with RPC statements.  However, RPC statements are limited in that they cannot be a part of lists.The tailf:action has no such limitations. This statement is a yang extension that allows for a much more flexible operations.

File Name:

tailf:action "removeSavedConfig" {
  tailf:info "Removes a previously saved configuration from the server.";
  input {
    leaf fileName {
      type TC:SonusLongName;
      mandatory true;
      tailf:info "Name of the configuration file to remove.";
    }
  }
  output {
    leaf result {
      type TC:SonusActionResult;
      mandatory true;
    }
    leaf reason {
      type TC:SonusActionReason;
      mandatory true;
    }
  }
}

Conclusion: The action removeSavedConfig takes filename as an input parameter. It returns the result and reason as output parameters.

leafref

The leafref type is used to reference a particular leaf instance in the data tree. The "path" sub-statement selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances. If the leaf with the leafref type represents configuration data, the leaf it refers to MUST also represent configuration. Such a leaf puts a constraint on the valid data.


 
  • No labels