On-Change Stream Mode

The gNMI-based Dial-in mode telemetry enables the "STREAM" type subscription with "On-Change" mode for the Subscribe RPC. The gNMI-based Dial-in mode telemetry enables the STREAM type subscription with the ON_CHANGE mode for the Subscribe RPC. This mode provides an event-driven data streaming mechanism where updates are sent only when subscribed data values change, optimizing bandwidth and CPU usage compared to periodic streaming.

On-Change Stream Mode Data Flow Description

Figure 7 illustrates a sample gnmic Subscribe Request and Subscribe Response message flow between the gNMI client (collector) and the OcNOS target device when the on-change stream mode is used.

Step 1: Subscription Request

The gNMI client sends a Subscribe Request message to the OcNOS gNMI Server with mode set to on-change, specifying the sensor path(s) and an optional heartbeat interval.

Step 2: Subscription Initialization

The OcNOS gNMI Server forwards this request to the subscribed data objects.

Step 3: Initial Data Transmission

•

The OcNOS target sends a Subscribe Response containing the initial data set for all subscribed paths to the client.

•

A heartbeat timer is started to manage optional periodic refreshes.

Step 4: Monitoring Phase

The OcNOS gNMI Server continuously monitors subscribed data items. Whenever any of these data items change, an event notification is triggered. Each notification includes the timestamp of when the updated path's value changed at source (protocol module).

Step 5: Data Change Detection and Notification Delivery

•

Upon detecting a change, the OcNOS gNMI Server compiles the updated values reports from the hash map based internal database.

•

It immediately sends a gNMI Notification containing the new data to the client.

•

The heartbeat timer is reset each time a notification is sent.

Step 6: Heartbeat Trigger

If no data change occurs and the heartbeat timer expires, the OcNOS gNMI server sends a current data notification to confirm the session remains active. The timestamp in this notification reflects the last data state change, as no new updates have occurred.

Step 7: Delete Notification

If any subscribed node (e.g., VLAN, interface) is deleted, a gNMI notification with a delete field is sent, containing the path of the removed node.

Figure 7. On-Change Stream Mode Message Flow

Resource Usage: Minimal resource usage compared to SAMPLE mode; not paused even under CPU load threshold.

Supported Sensor Path Types in On-Change Mode

•

The On-Change stream mode in OcNOS supports two categories of sensor paths—container-level and leaf-level. The wildcard sensor path type is applicable to both categories, allowing flexible monitoring and notification of data changes across YANG-modeled objects.

•

The On-Change stream mode provides flexible subscription granularity. Depending on the operational requirement, clients can subscribe at the container or leaf level, with optional wildcard sensor paths to extend the scope of change detection within those levels.

•

See the On-change Supported Sensor Paths section for the complete list of supported on-change telemetry sensor paths.

The on-change streaming mode does not support OpenConfig sensor paths.

Sensor Path Type	Description	Example Path	Behavior
Container-level sensor path	Subscribe request specifies a container-level path. Any data item under this container, when changed, triggers a gNMI update notification.	/interfaces/interface/state	If any child node (e.g., admin-status, oper-status) changes, OcNOS sends an update for that leaf.
Leaf-level sensor path	Subscribe request specifies a direct leaf node. OcNOS sends a gNMI update only when this specific attribute changes.	/interfaces/interface/state/oper-status	Update sent only when the operational status changes (e.g., from up to down).
Wildcard sensor path	Subscribe request uses wildcard (*) to match multiple elements. OcNOS supports full wildcards (implicit or explicit), but not partial wildcards.	/interfaces/interface[name=*]/state/oper-status	Sends updates for all matching interface instances when any of their values change.

Sensor Path Type

Description

Example Path

Behavior

Container-level sensor path

Subscribe request specifies a container-level path. Any data item under this container, when changed, triggers a gNMI update notification.

/interfaces/interface/state

If any child node (e.g., admin-status, oper-status) changes, OcNOS sends an update for that leaf.

Leaf-level sensor path

Subscribe request specifies a direct leaf node. OcNOS sends a gNMI update only when this specific attribute changes.

/interfaces/interface/state/oper-status

Update sent only when the operational status changes (e.g., from up to down).

Wildcard sensor path

Subscribe request uses wildcard (*) to match multiple elements.

OcNOS supports full wildcards (implicit or explicit), but not partial wildcards.

/interfaces/interface[name=*]/state/oper-status

Sends updates for all matching interface instances when any of their values change.

On-Change Stream Mode Benefits

Reduced Network Traffic: Transmits data only when actual changes occur, minimizing telemetry volume.
Real-Time Change Visibility: Enables instant awareness of state transitions (e.g., link up or down).
Lower CPU Utilization: Fewer updates reduce overhead on both OcNOS and the collector.
Efficient Storage and Analytics: Downstream collectors store fewer redundant samples.
Ideal for Event-Driven Monitoring: Suited for operational events such as BGP peer state, interface status, or system alarms.