gRPC is a modern, open-source, high-performance RPC framework that runs in any environment. In SR OS, this framework is used to implement the gRPC server, which can be then be used for configuration management or telemetry.
The gRPC transport service uses HTTP/2 bidirectional streaming between the gRPC client (the data collector) and the gRPC server (the SR OS device). A gRPC session is a single connection from the gRPC client to the gRPC server over the TCP/TLS port.
The gRPC service runs on port 57400 by default in SR OS. The service is not configurable.
A single gRPC server supports concurrent gRPC sessions and channels.
Figure 21 shows the gRPC protocol stack.
The gRPC server on SR OS can operate in two modes:
TLS encryption is used for added security. However, TLS encryption can be disabled in lab environments.
If TLS is not used, gRPC messages are not encrypted and user-names and passwords required in gRPC communication are visible to anyone capturing the packets. Therefore, Nokia recommends disabling TLS encryption only in a closed environment.
Before a gRPC connection will come up without TLS, the following conditions must both be met:
The following summarizes the process of encryption:
User authentication is based on following principles:
gRPC Network Management Interface (gNMI) is a gRPC based protocol for network management functions, such as configuration and retrieval of information from network elements. In addition, it provides functionality necessary for supporting telemetry. gNMI service is specified in the OpenConfig forum.
The SR OS gRPC server supports gNMI version 0.4.0, and in particular, the following RPC operations:
In gNMI service, the client discovers the capabilities of the gRPC server through a Capability-Discovery RPC, which consists of “CapabiltyRequest” and “CapabilityResponse” messages.
During this message exchange, the gRPC server informs the client about following attributes:
The SR OS server announces the supported models based on the configuration under configure>system>management-interface>yang-modules. The supported models includes the NOKIA-YANG or OpenConfig (OC) models.
The advertised module names and organizations are as follows:
The following is an example of a “Capabilities Response Message”:
Information is retrieved from the NE using GET RPC messages, which consists of “GetRequest” and “GetResponse” messages. The client asks for a given information by specifying following:
There is an upper limit on the size of the “GetResponse” message. This limit cannot exceed 100MB. If the limit is exceeded, the SR OS gRPC server responds with an error message.
In order to modify the information in an NE element, a SET gRPC message is used. This gRPC supports three types of transactions:
A subscription is initiated from the gRPC client by sending a Subscribe RPC that contains a "SubscribeRequest" message to the gRPC server. A prefix can be specified to be used with all paths specified in the "SubscribeRequest". If a prefix is present, it is appended to the start of every path to provide a full path.
A subscription contains:
When a subscription is successfully initiated on the gRPC server, “SubscribeReponse” messages are sent from the gRPC server to the gRPC client. The “SubscribeResponse” message contains update notifications about the subscription's path list.
An update notification contains:
A sync response notification is sent one time, after the gRPC server sends all of the updates for the subscribed-to paths. The sync response must be set to “true” for the gRPC client to consider that the stream has synced one time. A sync response is used to signal the gRPC client that it has a full view of the subscribed-to data.
The gRPC server sends an error if required. The error contains a description of the problem.
SR OS supports ON-CHANGE subscription mode. This subscription mode indicates that Notification messages are sent as follows:
The notification message, as a response to an ON-CHANGE subscription, always contains the new value of the corresponding leaf, as defined in gNMI specification.
The ON-CHANGE subscription is supported for all configuration events as well as for selected state leafs. The tools command can display all state leafs supporting the ON-CHANGE subscription.
ON-CHANGE subscription is accepted for all valid paths. The server sends ON-CHANGE notifications only for leafs within this path that support ON-CHANGE notifications.
Telemetry subscriptions include a set of schema paths used to identify which data nodes are of interest to the collector.
The paths in Telemetry Subscribe RPC requests follow the basic conventions described in the OpenConfig gnmi-path-conventions.md published on github.com (version 0.2.0 from February 24th, 2017).
A path consists of a set of path segments often shown with a “/” character as a delimiter; for example, /configure/router[router-instance=Base]/interface[interface-name=my-interface1]/description.
These paths are encoded as a set of individual string segments in gnmi.proto (without any “/” characters); for example, ["configure", "router[router-instance=Base]", "interface[interface-name=my-interface1]", "description"].
A path selects an entire subtree of the data model and includes all descendants of the node indicated in the path. Table 114 describes the types of schema paths that are supported in SR OS telemetry.
Path example | Description |
/configure/router[router-instance=Base]/interface[interface-name=abc] | Selects all config leafs of interface abc and all descendants. |
/configure/router[router-instance=Base]/interface[interface-name=abc]/description | Selects only the description leaf of interface abc. |
/state/router[router-instance=Base]/interface[interface-name=*] | Selects all state information for all base router interfaces using a wildcard in a single segment of a path. |
/configure/router[router-instance=Base]/interface[interface-name=*]/description | Selects all state information for all base router interfaces using a wildcard in a single segment of a path. |
/ | The root path. This selects all config and state data from all models (in all namespaces) supported on the router. Encoded as “” in gRPC/gPB. |
The following list describes types of telemetry paths that are not supported in SR OS.
The following list describes types of telemetry paths that are supported in SR OS.
The gNMI Service can be used for the following:
Telemetry is a network monitoring and fault management framework. Telemetry is driven by the need to use fresh data obtained from the network to make fast networking decisions such as traffic optimization and preventative troubleshooting.
Unlike legacy monitoring platforms such as SNMP, telemetry does not only rely on continuously pulling data from the network devices. Instead, network devices push and stream data (such as statistics) continuously to data collectors based on subscriptions. The data collectors can then filter, analyze, store, and make decisions using the collected data from the network devices. Figure 22 shows a telemetry application.
This section contains examples of Telemetry subscription requests and responses. The following examples are dumps of protobuf messages from a Python API. Formats may vary across different implementations.
Example 1 — Subscribe to a single path
Example 2 — Subscribe to a single path with wildcard
Example 3: Subscribe to more than one path
Example 4: Subscribe to a list with wildcard
Example 5: Subscribe to path where the object did not exist before subscription
Example 6: Subscribe to a path where the object existed before subscription then was deleted after subscription
Figure 23 shows NE configuration and information retrieval using the gNMI service.
In the context of gNMI, every SET RPC appears as an single commit operation, regardless of the number of paths included in the message. Both, NOKIA and OC models are supported by gNMI SET/GET RPC.
An example of the SET RPC command (including the response message from the gRPC server) follows:
An example of the GET RPC command (including the response message from the gRPC server) follows: