ypgnmi-app Internals

ypgnmi-app Subsystem Overview

The ypgnmi-app subsystem provides connectivity between the netconfd-pro server and external gNMI clients. It serves as an intermediary layer that enables seamless communication between the YumaPro server infrastructure and OpenConfig-compliant telemetry clients.

This architecture enables bidirectional, real-time communication between gNMI clients and the YumaPro datastore using standardized protocols and data models.

The application continuously listens for communication from the netconfd-pro server and maintains an active AF_LOCAL or TCP socket connection.

At the same time, the ypgnmi-app functions as a gNMI server, handling client connections and requests over gRPC as defined in the gnmi.proto.

ypgnmi-app Initialization Processing

The ypgnmi-app application has the following startup steps:

• Initialize all the prerequisites and parse all the CLI parameters

• Based on the netconfd-pro server modules capability create gNMI target

• Open TCP socket to listen for gNMI clients requests

• Open another socket and send <ncx-connect> request to the netconfd-pro server with

  • transport = netconf-aflocal

  • protocol = yp-gnmi

• Register yp-gnmi service

  • Send <register-request> to the server

  • Register ypgnmi-app subsystem and initialize all corresponding code in the netconfd-pro server to be ready to handle ypgnmi-app application requests

• Create a data model structure that will be used for gNMI client/server communication

  • Send <config-request> to the server

  • Feed the gNMI ModelData with all supported modules

• Serve any incoming gNMI messages from gNMI clients and re-transmit them to the netconfd-pro server.

Message Processing Overview

The following diagram illustrates the message processing flow between gNMI clients, the ypgnmi-app application, the netconfd-pro server, and the internal datastore used for configuration and state retrieval.

The end-to-end message processing path from gNMI clients to the netconfd-pro server can be divided into the following stages:

• gNMI Client -> ypgnmi-app - Handles incoming gNMI messages encoded in Protocol Buffers (protobuf) format and transmitted over gRPC. The ypgnmi-app parses, validates, and converts these protobuf-encoded messages into XML representations that are compatible with the netconfd-pro server's internal YControl communication format.

• ypgnmi-app -> netconfd-pro - Performs bidirectional message exchange between the ypgnmi-app and the netconfd-pro server using YControl protocol messages encoded in XML.

• Internal netconfd-pro Processing - Executes subsystem registration, message handling, and parsing within the server. The received XML requests are converted into internal RESTCONF control blocks for further processing:

  • YANG-PATCH - Used for handling gNMI SetRequest operations.

  • RESTCONF GET - Used for handling gNMI GetRequest and Subscribe operations.

ypgnmi-app Message Format

The ypgnmi-app application uses several messages to interact with the netconfd-pro server.

These messages are defined in the yumaworks-yp-gnmi.yang YANG module. The ypgnmi-app payload is defined as a YANG container that augments the YControl "message-payload" container.

The following diagram illustrates the YControl messages overview:

ypgnmi-app Registration Message Flow

During the startup phase, the server will initialize the yp-gnmi subsystem callback functions and handlers (similar way as for db-api module does).

The connection with the server is getting started with <ncx-connect> message that adds the YControl subsystem with the "yp-gnmi" subsystem ID to the server.

YControl protocol connection parameters:

• transport: netconf-aflocal

• protocol: yp-gnmi

• <port-num> not used

Additional parameters:

• subsys-id: yp-gnmi

The Registration message flow looks as follows:

• ypgnmi-app to Server: config-request The service requests the netconfd-pro server its configuration in 1 message.

• Server to ypgnmi-app: config-response The server responds to the config request with a list of modules that need to be loaded to gNMI server DataModel

• ypgnmi-app to Server: register-request The ypgnmi-app service registers callbacks supported by the subsystem.

• Server to ypgnmi-app: ok The server responds to the register request with an <ok> or an <error> message.

gNMI Request Processing

This section describes the internal processing flow of gNMI requests within the ypgnmi-app subsystem and their subsequent handling by the netconfd-pro server.

Together, these components provide complete end-to-end message processing for model-driven telemetry in YumaPro.

ypgnmi-app Processing

The ypgnmi-app subsystem employs multiple goroutines to manage client connections, message parsing, and response delivery. These concurrent routines ensure efficient, asynchronous communication between gNMI clients and the netconfd-pro server.

Goroutine Responsibilities:

• Client Manager. Manages all active gNMI client connections. Upon receiving a connection request, this goroutine registers the client, maintains session information, performs certificate verification, and enforces authentication policies. It also initiates connection termination when validation fails or a session expires.

• Reply Manager. Handles messages that have been parsed and are ready for processing. It maintains a queue of pending replies, matches them to corresponding client sessions, and initiates the appropriate response procedures.

• Message Parser. Responsible for decoding and encoding messages. Incoming client messages encoded in Protocol Buffers (protobuf) over gRPC are parsed and converted into XML-encoded YControl messages destined for the netconfd-pro server. Conversely, responses from the server are converted from XML back into protobuf before being sent to the clients.

• Message Manager. Coordinates all outbound and inbound message queues. It stores messages ready to be processed or forwarded, both to the netconfd-pro server and from the server back to the clients.

All of these managers operate as independent goroutines, running concurrently and asynchronously to maintain continuous, high-throughput communication.

ypgnmi-app gNMI Server Implementation

At its core, the ypgnmi-app implements a full gNMI server built on top of a gRPC server framework.

This implementation is responsible for handling all major gNMI service operations and maintaining secure communication channels with clients.

Core Responsibilities:

• Facilitate gNMI client to netconfd-pro server communication.

• Handle Get, Set, Subscribe, and Capabilities RPC callbacks.

• Manage message exchange between gNMI clients and the netconfd-pro server.

• Register and initialize the internal gNMI and gRPC servers for protobuf message handling.

• Execute the main service loop that manages all incoming and outgoing communication.

The ypgnmi-app runs as an HTTP/2 server over TLS, implemented using the Go standard package golang.org/x/net/http2.

This package provides the complete set of authentication, connection management, and listener mechanisms required for secure and reliable operation.

netconfd-pro Request Processing for gNMI

The diagram below illustrates the internal request handling flow within the netconfd-pro server after receiving messages from the ypgnmi-app subsystem.

The message processing steps:

• The server parses the received <ycontrol> message originating from the subsystem.

• The message is dispatched to the corresponding YControl service handler registered for yp-gnmi.

• The YControl yp-gnmi service callbacks process the incoming message according to its operation type.

• The internal RESTCONF dispatcher is invoked to process the corresponding operation:

  • Dispatch RESTCONF GET request in case of gNMI GetRequest.

  • Dispatch YANG-PATCH processing in case of gNMI SetRequest.

• The netconfd-pro server builds a response message based on the results returned by the RESTCONF dispatcher.

• The completed response is sent back to the ypgnmi-app service via YControl, which then delivers it to the appropriate gNMI client.