YumaPro SDK Architectural Components


gNMI Introduction

This document describes the gNMI (gRPC Network Management Interface) integration within the netconfd-pro server and ypgnmi-app application. The model-driven configuration and retrieval of operational data using the gNMI CAPABILITIES, GET and SET gRPCs. gNMI version 0.4.0 is supported.

Throughout this specification the following terminology is used:

  • Telemetry

    • refers to streaming data relating to underlying characteristics of the device - either operational state or configuration

  • Configuration

    • elements within the data schema which are read/write and can be manipulated by the client

  • Target

    • the device within the protocol that acts as the owner of the data that is being manipulated or reported on. Typically this will be a netconfd-pro server that communicates with the client with the help of ypgnmi-app application

  • Client

    • the device or system using the protocol and the service described in this document to query/modify data on the target, or act as a collector for streamed data. Typically this will be a network management system. The client will contact the ypgnmi-app application to query/modify data on the target

gNMI Features

The main gNMI service functionality contains the following requests (gRPC):

  • Capabilities used by the client and target as an initial handshake to exchange capability information

  • Get used to retrieve snapshots of the data on the target by the client

  • Set used by the client to modify the state of the target

  • Subscribe used to control subscriptions to data on the target by the client

The ypgnmi-app application is capable of handling these requests and transferring them to the netconfd-pro server for further processing, as well as handle replies from the netconfd-pro server and transmit them back to the gNMI clients.

gNMI Telemetry Feature

STREAM Feature sets a new benchmark for real-time network monitoring and management. Engineered to deliver instantaneous updates, this feature not only elevates data accuracy but also revolutionizes the way you interact with your network infrastructure.

Key Features

Real-Time Data Transmission

The streaming subscription mode is designed to transmit data in real-time as changes occur within the network. This immediate update mechanism enables network administrators to respond more effectively to real-time conditions, thereby enhancing overall network performance.

Selective Data Subscription

With a streaming subscription, users have the privilege to subscribe to specific data paths. This offers a more targeted and efficient approach to monitoring, as only the data of interest will trigger updates.

Network Load Optimization

By focusing only on changes or specific conditions, the STREAM mode reduces redundant data transmission. This results in optimized network load and bandwidth usage, thus contributing to operational efficiency.

Seamless Integration and Compatibility

The STREAM feature integrates effortlessly into existing gNMI infrastructures, ensuring a smooth transition for organizations looking to adopt this advanced capability. It adheres to gNMI standards and offers compatibility with a range of network elements and devices.


  • Enhanced Decision-making: Real-time updates offer actionable insights for more informed decisions.

  • Resource Efficiency: Minimize network load by focusing only on the essential data points.

  • Improved Monitoring: Targeted data paths mean you spend less time sifting through irrelevant information.


YumaWorks' Streaming Subscription feature for gNMI is a pivotal advancement in the realm of network management. By facilitating real-time, selective, and efficient data transmission, it stands as an invaluable tool for any modern network administrator.

To further explore the capabilities and benefits of the YumaWorks Streaming Subscription feature for gNMI, refer to Running SUBSCRIBE Request.

gNMI Protocol Restrictions

The Phase I of the gNMI protocol integration has several gNMI protocol limitations and does not fully implement the whole set of gNMI protocol features.

Node Values Restrictions for Structured Data Types

The value of a data node (or subtree) is encoded in a 'TypedValue' message as a one of field to allow selection of the data type by setting exactly one of the member fields. The possible data types include:

  • Scalar types

  • Additional types used in some schema languages

  • Structured data types (e.g., to encode objects or subtrees)

When structured data is sent by the client or the target in an Update message, it MUST be serialized according to one of the supported gNMI protocol encodings listed in the Encoding enumeration. The table below lists the gNMI protocol-supported encodings and their corresponding TypedValue fields. The Phase I of the gNMI protocol integration implements only the Structured data types and the JSON IETF encoding. Other encoding types may be implemented in the feature.

The target never utilizes the Encoding enumeration to declare to the client the type of encoding utilized, so the client must infer the encoding from the populated TypedValue field.






A JSON encoded string




An arbitrary sequence of bytes




A Protobuf encoded message using protobuf.any




An ASCII encoded string representing text formatted according to a target-defined convention




A JSON encoded string using JSON encoding compatible with [RFC 7951]



Phase I of the gNMI protocol integration implements JSON_IETF encoding. The client MUST support the JSON encoding as a minimum to successfully utilize the target’s replies.

E.g. using the following example data tree:

root +
     +-- a +
           +-- b[name=b1] +
                          +-- c +
                                +-- d (string)
                                +-- e (uint32)

The following serializations would be used:

For /a/b[name=b1]/c:

update: <
  path: <
    elem: <
      name: "a"
    elem: <
      name: "b"
      key: <
        key: "name"
        value: "b1"
    elem: <
      name: "c"
  val: <
    json_ietf_val: `{ "d": "AStringValue", "e": 10042 }`

For /a:

update: <
  path: <
    elem: <
      name: "a'
  val: <
    json_ietf_val: `{ "b": [
                        "name": "b1",
                        "c": {
                        "d": "AStringValue",
                          "e": 10042

GetRequest Message Wildcards Restriction

A Path is a set of paths for which the client is requesting a data snapshot from the target. The path specified MAY utilize wildcards. The Phase I of the gNMI protocol integration supports only fully-specified paths. The wildcards in GetRequests may be supported in the feature.

Subscribe Restriction

When a client wishes to receive updates relating to the state of data instances on a target, it creates a subscription via the Subscribe RPC. A subscription consists of one or more paths, with a specified subscription mode. The mode of each subscription determines the triggers for updates for data sent from the target to the client.

All requests for new subscriptions are encapsulated within a SubscribeRequest message - which itself has a mode which describes the longevity of the subscription. A client may create a subscription which has a dedicated stream to return one-off data (ONCE Subscription Mode); a subscription that utilizes a stream to periodically request a set of data (POLL Subscription Mode); or a long-lived subscription that streams data according to the triggers specified within the individual subscriptions mode (STREAM Subscription Mode).