An on-change subscription streams out data only when a change in the data has occurred, such as when an interface or a neighbor relationship goes down. This type of subscription is useful for when a data value changes occasionally but the information needs to be sent in a timely manner. An on-change subscription capability must be described in a YANG module definition in order to prevent erroneous association to a YANG subscription. It is not recommended to use on-change subscriptions for frequently changing data values such as counters incrementing on an interface.
Defining GRPC and GNMI
Google Remote Procedure Call (gRPC) is a new and modern API that provides an RPC framework. It’s developed and open-sourced by Google.
Like RESTCONF, it is a subset of NETCONF and uses HTTP/2 as a transport. Major differences include enhanced security and bi-directional streaming support.
The following are key features of gRPC:
- Google RPC provides an open-sourced RPC framework.
- The interface definition supports device operations for Cisco IOS XR.
- It provides high performance and simple client development.
- It provides a functional subnet of NETCONF and uses HTTPS transport.
Table 12-8 describes gRPC protocol operations.
Table 12-8 gRPC Protocol Operations
Operation | Description |
GetConfig | Retrieve configuration data |
MergeConfig | Merge configuration data |
DeleteConfig | Delete configuration data |
ReplaceConfig | Replace configuration data |
GetOper | Retrieve operational data |
ShowCmdTextOutput | Retrieve CLI show command output data |
gNMI is a gRPC network management protocol developed by Google. gNMI provides the mechanism to install, change, and delete the configuration of network devices as well as view operational data. The data provided by gNMI can be modeled using YANG.
During a failure, the gNMI broker (GNMIB) will indicate an operational change of state from up to down, and RPCs will deliver a service unavailable message until the database is up and running again. After recovery, the GNMIB will indicate a change of operational state from down to up and will resume normal handling of RPC messages.
Dial-In Approaches
In dial-in mode, a network device listens until the receiver dials in and sends the initial SYN packet to start the TCP connection. After the initial TCP connection is established, the network device pushes data out to the receiver at the configured interval. The network device acts as the server, and the receiver is the client. Don’t let the direction of the SYN packet throw you off because there is no polling mechanism in model-driven telemetry. The dial-in mode of the subscription is dynamic and terminates only when the receiver cancels the subscription or when the session is terminated. Dial-in mode uses a single channel to communicate via a single transport and protocol for both configuration data and streaming operational data.
Here are two examples of methods to request sensor paths in a dynamic subscription:
- OpenConfig RPC: The subscribe RPC command is used to specify sensor paths and frequency. A subsequent cancel RPC command is used to remove the existing dynamic subscription.
- IOS XR MDT RPC: With IOS XR, RPCs are used to subscribe or cancel configured subscriptions. The sensor paths and frequency are part of the telemetry configuration.