Glossary

gRPC

Google Remote Procedure Calls

What is gRPC

gRPC (Google Remote Procedure Calls) is a high-performance, general-purpose open-source RPC framework released by Google in 2015. It's built on HTTP/2, defines service interfaces using Protocol Buffers, and transmits data in compact binary encoding rather than text — a combination that makes it both fast on the wire and consistent across platforms and languages. Because gRPC handles transport, security, and encoding itself, the two communicating parties only need to define their application-layer interface and build on top of the framework, rather than solving connection management and serialization from scratch each time.

In network devices, gRPC has become the transport of choice for telemetry — the practice of a device proactively and continuously pushing its own metrics, logs, and events to a collector, rather than waiting to be polled. This push model is a deliberate departure from traditional pull-based monitoring like SNMP polling: instead of a collector periodically asking "what's your state now," the device streams updates as they happen, over a persistent gRPC connection, encoded by default in JSON_IETF — the YANG JSON format strictly defined in IETF RFC 7951.

How gRPC-Based Telemetry Works

Telemetry over gRPC supports two subscription modes that determine which side initiates the connection:

· Dial-in mode: The device acts as the gRPC server, and the collector acts as the client — the collector actively connects to the device and listens for data. This keeps device-side configuration minimal and suits short-term, on-demand state monitoring.

· Dial-out mode: The roles flip — the device acts as the gRPC client and proactively connects to the collector, which runs as the server, pushing telemetry data outward. This fits long-term, large-scale monitoring better, since the collector doesn't need to track or reach out to every device individually.

Within these modes, data can be reported in different ways depending on what's needed:

· On-change / stream: Data is reported only when it changes — ideal for state that should be known the instant it shifts, like a PTP grandmaster identity change.

· Sampled / periodic: Data is reported at a fixed interval, suited to metrics that are more useful as a steady trend than as individual events, like CPU or queue counters.

· Poll (dial-in only): The collector explicitly requests data on demand rather than receiving a continuous stream.

Collection itself is scoped by target and path. Targets are either specific system databases (such as COUNTERS_DB or STATE_DB) or a catch-all OTHERS target for non-database system data like CPU or memory statistics. Paths then narrow the target down to a specific table, key, or field — either a custom path the user defines, or one of a set of predefined "virtual paths" the system already exposes for common counters like PFC packets, queue drops, or traffic statistics.

Why gRPC is Beneficial

The core value of gRPC-based telemetry lies in getting device state to where it's needed, faster and more efficiently than polling ever could:

· Push instead of pull: Devices report changes as they happen instead of waiting to be asked, cutting the delay between an event occurring and an operator seeing it.

· Efficient, compact transport: HTTP/2 multiplexing and Protocol Buffers' binary encoding keep telemetry traffic lightweight even at high reporting frequency, compared to older text-based polling protocols.

· Flexible collection scope: Choosing exactly which database, table, or field to subscribe to — down to a single counter on a single interface — avoids flooding the collector with data nobody's looking at.

· Deployment flexibility via dial-in and dial-out: Dial-in suits quick, ad hoc checks; dial-out suits standing, large-scale collection pipelines — administrators can pick the model that fits the operational scale of their network.

· Cross-platform interoperability: Because gRPC and Protocol Buffers are language- and platform-neutral, the collector side can be built with whatever tooling — OpenTelemetry Collector, a custom pipeline, or anything else — fits the operator's existing stack.

At Asteraix

What We Can Do at Asteraix

AsterNOS uses gRPC as the transport for its Telemetry feature, supporting both dial-in and dial-out delivery to standard collectors:

· Dial-in, out of the box: The gRPC service is enabled by default and listens on all interfaces — no manual configuration is needed beyond ensuring Layer 3 reachability to the collector; it can be turned off with feature telemetry state disable if not needed.

· Dial-out client and destination groups: telemetry client enters client configuration, and destination-group <name> together with {ipv4-address <A.B.C.D>|ipv6-address <A::B>} port <port-number> defines where the device should push data — each destination group targets one collector, with multiple groups supported if data needs to reach more than one destination.

· Subscription configuration: subscription <name> creates a telemetry subscription, bound to a destination group and a single collection target (path-target COUNTERS_DB|STATE_DB|OTHERS), with one or more paths specifying exactly what to collect — from a custom table/key/field path to a predefined virtual path like PFC counters or queue drop statistics.

· Reporting control: report-type periodic|stream chooses between fixed-interval and change-triggered reporting, and report-interval <ms> (100–1,800,000 ms, default 5000 ms) tunes how often periodic subscriptions report.

· Display and maintenance: show telemetry-client summary, show telemetry-client destination-group [<name>], and show telemetry-client subscription [all|<name>] let administrators confirm client, destination, and subscription state — including whether a subscription has reached Sub-state: Success.

· Typical deployment: A device streams egress packet-loss counters to an OpenTelemetry Collector by creating a destination group pointed at the collector's gRPC endpoint, then a subscription against COUNTERS_DB with the queue_egress_loss_cnt path reporting periodically every 10 seconds — with the collector's logs and exported JSON confirming each report arrives as expected. The same pattern extends naturally to more demanding cases, like separately subscribing to a PTP grandmaster identity in real-time stream mode for instant change detection, while collecting the rest of a device's PTP status on a steady 10-second periodic cycle — letting operators tune responsiveness independently for each piece of data they care about.