In this section:
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 | 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 objects | sonusOrca.yang |
profiles | Profiles of configuration shared by multiple objects | sonusGen2Profiles.yang |
system | System-level configuration | sonusSystem.yang |
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".
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 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 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:
Result | An enumeration with values “success” or “failure” |
---|---|
Reason | If the operation is not successful, returns a string with the reason for the failure. |
Common SBC data model yang statements include:
Statement | Description | Example |
---|---|---|
| This statement inserts one yang specifications within the tree structure of another yang specifications. | File : augment "/GLOBAL_OBJECTS:global" GLOBAL_OBJECTS is a label defined as: import sonusGlobal { prefix GLOBAL_OBJECTS; } Conclusion: These statements inserts the So the “list carrier” defined in |
| 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 |
| 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 " | Defined in RFC 6020 |
| 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 |
| 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 |
| 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 " | Defined in RFC 6020 |
must | This 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:action | In 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 |
leafref | The |