Data Models

Data Models - Programmatic and Standards-based Configuration

Cisco IOS XR software supports the automation of configuration of multiple routers across the network using Data models. Configuring routers using data models overcomes drawbacks posed by traditional router management techniques.

CLIs are widely used for configuring a router and for obtaining router statistics. Other actions on the router, such as, switch-over, reload, process restart are also CLI-based. Although, CLIs are heavily used, they have many restrictions.

Customer needs are fast evolving. Typically, a network center is a heterogenous mix of various devices at multiple layers of the network. Bulk and automatic configurations need to be accomplished. CLI scraping is not flexible and optimal. Re-writing scripts many times, even for small configuration changes is cumbersome. Bulk configuration changes through CLIs are error-prone and may cause system issues. The solution lies in using data models - a programmatic and standards-based way of writing configurations to any network device, replacing the process of manual configuration. Data models are written in a standard, industry-defined language. Although configurations using CLIs are easier (more human-friendly), automating the configuration using data models results in scalability.

Cisco IOS XR supports the YANG data modeling language. YANG can be used with Network Configuration Protocol (NETCONF) to provide the desired solution of automated and programmable network operations.

YANG model

YANG is a data modeling language used to describe configuration and operational data, remote procedure calls and notifications for network devices. The salient features of YANG are:

  • Human-readable format, easy to learn and represent

  • Supports definition of operations

  • Reusable types and groupings

  • Data modularity through modules and submodules

  • Supports the definition of operations (RPCs)

  • Well-defined versioning rules

  • Extensibility through augmentation

For more details of YANG, refer RFC 6020 and 6087.

NETCONF and gRPC (Google Remote Procedute Call) provide a mechanism to exchange configuration and operational data between a client application and a router and the YANG models define a valid structure for the data (that is being exchanged).

Protocol

Transport

Encoding/ Decoding

NETCONF

SSH

XML

gRPC HTTP/2 XML, JSON

Each feature has a defined YANG model. Cisco-specific YANG models are referred to as synthesized models. Some of the standard bodies, such as IETF , IEEE and Open Config, are working on providing an industry-wide standard YANG models that are referred to as common models.

Components of Yang model

A module defines a single data model. However, a module can reference definitions in other modules and submodules by using the import statement to import external modules or the include statement to include one or more submodules. A module can provide augmentations to another module by using the augment statement to define the placement of the new nodes in the data model hierarchy and the when statement to define the conditions under which the new nodes are valid. Prefix is used when referencing definitions in the imported module.

YANG models are available for configuring a feature and to get operational state (similar to show commands)

This is the configuration YANG model for AAA (denoted by - cfg)

(snippet)
module Cisco-IOS-XR-aaa-locald-cfg {

  /*** NAMESPACE / PREFIX DEFINITION ***/

  namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-cfg";


  prefix "aaa-locald-cfg";

  /*** LINKAGE (IMPORTS / INCLUDES) ***/

  import Cisco-IOS-XR-types { prefix "xr"; }

  import Cisco-IOS-XR-aaa-lib-cfg { prefix "a1"; }

  /*** META INFORMATION ***/

  organization "Cisco Systems, Inc.";
										.........................
										......................... (truncated)

This is the operational YANG model for AAA (denoted by -oper)

(snippet)
module Cisco-IOS-XR-aaa-locald-oper {

  /*** NAMESPACE / PREFIX DEFINITION ***/

  namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-oper";


  prefix "aaa-locald-oper";

  /*** LINKAGE (IMPORTS / INCLUDES) ***/

  import Cisco-IOS-XR-types { prefix "xr"; }

  include Cisco-IOS-XR-aaa-locald-oper-sub1 {
    revision-date 2015-01-07;
  }

  /*** META INFORMATION ***/

  organization "Cisco Systems, Inc.";
				........................
				........................ (truncated)

Note

A module may include any number of sub-modules, but each sub-module may belong to only one module. The names of all standard modules and sub-modules must be unique.

Data types

YANG defines data types for leaf values. These data types help the user in understanding the relevant input for a leaf.

Name Description
binary Any binary data
bits A set of bits or flags
boolean "true" or "false"
decimal64 64-bit signed decimal number
empty A leaf that does not have any value
enumeration Enumerated strings
identityref A reference to an abstract identity
instance-identifier References a data tree node
int (integer-defined values) 8-bit, 16-bit, 32-bit, 64-bit signed integers
leafref A reference to a leaf instance
uint 8-bit, 16-bit, 32-bit, 64-bit unsigned intergers
string Human-readable string
union Choice of member types

Data Model and CLI Comparison

Each feature has a defined YANG model that is synthesized from the schemas. A model in a tree format includes:

  • Top level nodes and their subtrees

  • Subtrees that augment nodes in other yang models

  • Custom RPCs

The options available using the CLI are defined as leaf-nodes in data models. The defined data types, indicated corresponding to each leaf-node, help the user to understand the required inputs.

gRPC

gRPC is a language-neutral, open source, RPC (Remote Procedute Call) system developed by Google. By default, it uses protocol buffers as the binary serialization protocol. It can be used with other serialization protocols as well such as JSON, XML etc. The user needs to define the structure by defining protocol buffer message types in.proto files. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs.

gRPC encodes requests and responses in binary. Although Protobufs was the only format supported in the initial release, gRPC is extensible to other content types. The Protobuf binary data object in gRPC is transported using HTTP/2 (RFC 7540). HTTP/2 is a replacement for HTTP that has been optimized for high performance. HTTP/2 provides many powerful capabilities including bidirectional streaming, flow control, header compression and multi-plexing. gRPC builds on those features, adding libraries for application-layer flow-control, load-balancing and call-cancellation.

gRPC supports distributed applications and services between a client and server. gRPC provides the infrastructure to build a device management service to exchange configuration and operational data between a client and a server in which the structure of the data is defined by YANG models.

Cisco gRPC IDL

The protocol buffers interface definition language (IDL) is used to define service methods, and define parameters and return types as protocol buffer message types.

gRPC requests can be encoded and sent across to the router using JSON. gRPC IDL also supports the exchange of CLI.

For gRPC transport, gRPC IDL is defined in .proto format. Clients can invoke the RPC calls defined in the IDL to program XR. The supported operations are - Get, Merge, Delete, Replace. The gRPC JSON arguments are defined in the IDL. 


syntax = "proto3";
 
package IOSXRExtensibleManagabilityService;
 
service gRPCConfigOper {
     
    rpc GetConfig(ConfigGetArgs) returns(stream ConfigGetReply) {};
 
    rpc MergeConfig(ConfigArgs) returns(ConfigReply) {};
 
    rpc DeleteConfig(ConfigArgs) returns(ConfigReply) {};
 
    rpc ReplaceConfig(ConfigArgs) returns(ConfigReply) {};
 
    rpc CliConfig(CliConfigArgs) returns(CliConfigReply) {};
    
}
gRPC Operations

  • oper get-config—Retrieves a configuration

  • oper merge-config— Appends to an existing configuration

  • oper delete-config—Deletes a configuration

  • oper replace-config—Modifies a part of an existing configuration

  • oper get-oper—Gets operational data using JSON

  • oper cli-config—Performs a configuration

  • oper showcmdtextoutput

NETCONF Operations

NETCONF defines one or more configuration datastores and allows configuration operations on the datastores. A configuration datastore is a complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The configuration datastore does not include state data or executive commands.

The base protocol includes the following NETCONF operations:

|  +--get-config
|  +--edit-Config
|     +--merge        
|     +--replace               
|     +--create
|     +--delete
|     +--remove
|     +--default-operations  
|        +--merge
|  +--get
|  +--lock
|  +--unLock
|  +--close-session
|  +--kill-session

These NETCONF operations are described in the following table:

Table 1.

NETCONF Operation

Description

ExampleDescription

<get-config>

Retrieves specific controller configuration details from running configuration using filter option.

 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <get-config>
    <source>
      <running/>
    </source>
    <filter>
      <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">
        <interface-configuration>
          <active>act</active>
          <interface-name>Ots0/0/0/0</interface-name>
        </interface-configuration>
      </interface-configurations>
    </filter>
  </get-config>
</rpc>

<get>

Retrieves all OTS controllers state information.

 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <get>
    <filter>
      <ots-oper xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-controller-ots-oper"/>
    </filter>
  </get>
</rpc>

<edit-config>

Configure OTS controller configurations using Merge operation.

 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">
        <interface-configuration>
          <active>act</active>
           <interface-name>Ots0/0/0/0</interface-name>
          <ots xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-controller-ots-cfg">
            <ots-egress-amplifier-gain>132</ots-egress-amplifier-gain>
            <ots-egress-amplifier-tilt>0</ots-egress-amplifier-tilt>
            <ots-egress-amplifier-gain-range>normal</ots-egress-amplifier-gain-range>
          </ots>
        </interface-configuration>
      </interface-configurations>
    </config>
  </edit-config>
</rpc>

Commit:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102">
  <commit/>
</rpc>

<lock>

Locks the running configuration.

Request:


<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>

Response:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <ok/>
</rpc-reply>

<unlock>

Unlocks the running configuration from the same session:

Request:

rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>

Response

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>

<close session>

Closes a NETCONF session.

Request:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
 </rpc>

Response: 

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>