]> Independent

Denver Colorado United States of America research@saurabhpant.com https://saurabhpant.com

Operations and Management Individual Submission SNMP MIB AI Infrastructure GPU Monitoring gNMI OpenConfig Telecommunications OSS/BSS The rapid proliferation of Artificial Intelligence (AI) and Graphics Processing Unit (GPU) infrastructure within telecommunications networks has exposed a fundamental gap in existing network management frameworks. The Simple Network Management Protocol (SNMP), the de facto standard for network element monitoring since RFC 1157 (1990), provides no native support for monitoring AI accelerators, GPU clusters, high-bandwidth interconnects such as NVLink and InfiniBand, or AI workload telemetry. This document proposes AI-MIB: a Management Information Base extension that defines a standardised Object Identifier (OID) tree for AI infrastructure management within the SNMP framework. AI-MIB is designed to operate alongside existing Operations Support Systems and Business Support Systems (OSS/BSS) in telecommunications environments, preserving backward compatibility with SNMPv3 while extending the framework's scope to cover GPU health, accelerator interconnect metrics, AI workload performance indicators, and energy consumption. This document also outlines two future extensions: a subscription-based streaming capability for SNMPv3 (informally designated SNMPv3+), and a schema-mapping specification for a SNMP-gNMI Translation Gateway that bridges SNMP/MIB and gNMI/YANG data models.

Introduction The telecommunications industry is undergoing a structural transformation driven by the convergence of artificial intelligence and network infrastructure. Operators deploying AI-driven Radio Access Networks (RAN), autonomous network operations, and edge inference platforms are building heterogeneous environments that combine traditional network elements — routers, switches, optical transponders — with AI accelerators, GPU clusters, and high-bandwidth interconnect fabrics. By 2026, major cloud providers have deployed NVIDIA Blackwell-class hardware at scale, with GPU revenue projected to grow substantially through the remainder of the decade. Within this heterogeneous environment, a management paradox has emerged. Traditional network elements are richly observable through SNMP — the protocol provides access to thousands of standardised OIDs covering interface counters, routing protocol states, physical inventory, and performance metrics across virtually every network device category. AI accelerators, by contrast, are essentially invisible to SNMP. Current-generation GPU accelerators expose no native SNMP Management Information Base. Their operational state, thermal status, memory utilisation, interconnect performance, and workload metrics are accessible only through proprietary vendor APIs. This creates a practical problem for telecommunications operators whose OSS/BSS platforms are built around SNMP as the fundamental telemetry collection mechanism. A network operator monitoring a 5G edge deployment that includes both traditional IP routers and AI inference accelerators for real-time RAN processing finds that their Network Management System (NMS) provides complete visibility of the network layer and none of the AI layer. This document proposes a standardised MIB extension to close that gap.

Contributions This document makes three contributions:

1. Problem formalisation: characterisation of the AI infrastructure monitoring gap in telecommunications environments with reference to specific deployment scenarios and existing OSS/BSS frameworks ().
2. AI-MIB specification: a concrete MIB module design defining a standardised OID tree for AI accelerator management within the SNMP framework, aligned with TM Forum data models ().
3. Integration framework: a description of how AI-MIB integrates with existing OSS/BSS architectures, co-exists with gNMI/OpenConfig telemetry, and supports the TM Forum Autonomous Network Levels (ANL) framework ().

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Background

The Evolution of Network Management Protocols Network management protocol evolution reflects successive generations of thinking about how operational data should flow between managed devices and management systems. SNMP, first specified in RFC 1157 in 1990 and progressively enhanced through SNMPv2 (1993) and SNMPv3 (1999), established the foundational paradigm of manager-agent architecture with MIB-based data modelling. MIB-II defines the essential objects for managing TCP/IP-based internets and remains the foundation of network element monitoring more than three decades after its publication. NETCONF introduced transactional, model-driven configuration using YANG data models over SSH. RESTCONF extended NETCONF concepts to RESTful interfaces. gNMI , developed through the OpenConfig initiative, represents the most recent generation of network management thinking: a push-based streaming telemetry protocol using gRPC and Protocol Buffers over HTTP/2, capable of millisecond-resolution data delivery. Unlike SNMP's periodic polling model, gNMI's subscription mechanism enables continuous device-initiated data streaming, providing the sub-second visibility needed to detect transient conditions such as buffer microbursts, fabric congestion events, and interconnect credit pauses that define the operational behaviour of AI infrastructure. Despite the emergence of gNMI, SNMP remains deeply embedded in telecommunications OSS/BSS architectures. The installed base of SNMP-managed devices is measured in billions. A wholesale migration from SNMP to gNMI, while technically desirable for new deployments, is operationally impractical for the majority of operators managing live networks. The pragmatic path forward is one of coexistence and extension, not replacement.

AI Infrastructure Monitoring Today Current monitoring of GPU and AI accelerator infrastructure relies on a fragmented set of vendor-proprietary and open-source tools, none of which are integrated into the SNMP management framework. Vendor management libraries provide programmatic access to GPU metrics including utilisation, memory usage, temperature, power draw, and error counts, but expose no SNMP interface and provide no MIB definition. Group-level cluster management tools extend these libraries with health checks and diagnostics for data centre deployments, typically integrating with Prometheus through exporter plugins rather than SNMP. The result is a structural divide: network operations teams managing traditional network elements through SNMP-based NMS platforms have no visibility into the AI accelerators running on the same physical infrastructure, and AI operations teams monitoring GPU clusters have no visibility into the network performance parameters that affect AI workload execution.

TM Forum and Autonomous Networks The TM Forum's Autonomous Network Levels (ANL) framework , jointly developed by TM Forum and industry partners, defines a progression from ANL Level 1 (unification of fragmented legacy databases) through ANL Level 5 (full autonomy with zero-touch predictive lifecycle management). The framework explicitly requires accurate, unified, real-time operational data as the precondition for advancing through autonomy levels. AI-MIB directly supports the ANL framework by extending the scope of SNMP-based inventory and telemetry collection to include AI infrastructure, enabling OSS/BSS systems to build the unified operational picture that ANL Level 3 and above require, without requiring the wholesale replacement of SNMP-based toolchains.

The AI Infrastructure Monitoring Gap in Telecommunications

Deployment Scenarios Three specific deployment scenarios illustrate the monitoring gap that AI-MIB addresses. Scenario 1: AI-Native RAN Processing. Telecommunications operators deploying Open RAN architectures are increasingly moving baseband processing functions to AI accelerators at the network edge. A distributed unit (DU) site incorporating GPU cards for AI-enhanced signal processing presents a fundamental management challenge: the underlying IP connectivity is monitored through SNMP, the radio parameters through vendor-specific NMS platforms, and the GPU workloads through proprietary vendor APIs. There is no unified management interface. Scenario 2: Edge AI Inference for Network Automation. Operators deploying closed-loop network automation at the edge run AI inference models for traffic prediction, anomaly detection, and service quality optimisation. These workloads execute on GPU or AI ASIC accelerators co-located with traditional network elements. Fault correlation between network performance degradation and AI accelerator issues is impossible without a unified management framework. Scenario 3: Data Centre AI Fabric in Telecom Clouds. Tier-1 operators building private telecom clouds for 5G core functions and AI-driven network services deploy GPU clusters connected by high-bandwidth fabrics: NVLink within nodes, InfiniBand or RoCE between nodes. The performance of AI workloads running on these clusters is critically dependent on interconnect health, none of which is visible through SNMP today.

The Specific Gaps The monitoring gap has five dimensions: GPU Health and Utilisation: core GPU operational metrics — compute utilisation, memory utilisation, temperature, power draw, fan speed, clock frequencies — are not defined in any existing SNMP MIB. Accelerator Interconnect Performance: NVLink bandwidth utilisation and error rates, InfiniBand port counters, and RoCE congestion events (credit pauses) are invisible to SNMP. AI Workload Telemetry: active job counts, inference throughput, training iteration time, and job completion rates provide operational context for interpreting GPU utilisation metrics. No SNMP MIB defines these objects. Energy and Thermal Management: GPU power consumption is a material operational parameter for data centre management. Rack-level power budgets, cooling efficiency, and thermal headroom are not addressable through existing SNMP infrastructure. Physical Inventory Integration: the Entity MIB provides a framework for physical inventory management through SNMP. AI accelerators are not represented in existing Entity MIB implementations, creating an inventory gap that affects asset management, lifecycle planning, and capacity forecasting.

AI-MIB: Proposed Specification

Design Principles AI-MIB is designed according to five principles:

1. Backward Compatibility: AI-MIB operates within the SNMPv3 framework without modification.
2. Vendor Neutrality: the MIB defines objects applicable to AI accelerators from any vendor without vendor-specific dependencies.
3. TM Forum Alignment: object definitions are aligned with TM Forum data models to facilitate integration with OSS/BSS systems.
4. OpenConfig Complementarity: AI-MIB coexists with gNMI/OpenConfig telemetry.
5. Extensibility: following the SMI extensibility principles established in MIB-II, AI-MIB defines a core set of essential objects and provides extension points for vendor-specific and workload-specific additions.

OID Tree Structure AI-MIB is proposed for registration under the IETF experimental subtree (1.3.6.1.3) for initial publication, with the intent to seek assignment under the IETF management subtree (1.3.6.1.2) upon standardisation.

Object Definitions

GPU Group (aiGPUGroup) The GPU group provides per-accelerator operational visibility. Each row in the aiGPUTable represents one physical GPU or AI accelerator installed in the managed node. aiGPUComputeUtilization

Syntax:

Gauge32 (0..100)

Units:

percent

Access:

read-only

Status:

current

Description: the percentage of time over the last sampling interval during which one or more kernels were executing on the GPU. A value of 0 indicates an idle GPU. Values above 80 sustained over multiple polling intervals may indicate a compute bottleneck. aiGPUTemperature

Syntax:

Gauge32

Units:

degrees Celsius

Access:

read-only

Status:

current

Description: current GPU core temperature in degrees Celsius. Thermal throttling typically initiates at vendor-defined thresholds; for current-generation high-end GPU accelerators this is typically above 83 degrees Celsius for sustained workloads. aiGPUPowerDraw

Syntax:

Gauge32

Units:

milliwatts

Access:

read-only

Status:

current

Description: current total power consumption of the GPU in milliwatts. For high-end data-centre-class devices, values may reach 1,000,000 milliwatts (1000W) under full load. aiGPUECCErrorsUncorrected

Syntax:

Counter64

Access:

read-only

Status:

current

Description: the total number of uncorrected ECC memory errors since last reset. A non-zero value is a critical indicator requiring immediate attention and potential device replacement. aiGPUOperStatus

Syntax:

INTEGER {up(1), down(2), degraded(3), testing(4), unknown(5)}

Access:

read-only

Status:

current

Description: the operational status of the GPU. up(1) indicates the GPU is operating normally; down(2) indicates the GPU is not operational; degraded(3) indicates the GPU is operational but with reduced capability (e.g. thermal throttling); testing(4) indicates the GPU is undergoing diagnostics; unknown(5) indicates status cannot be determined.

Interconnect Group (aiInterconnectGroup) The interconnect group provides visibility into high-bandwidth GPU interconnect fabrics: NVLink (intra-node), InfiniBand (inter-node), and RoCE (RDMA over Converged Ethernet). aiInterconnectCreditPauses

Syntax:

Counter64

Access:

read-only

Status:

current

Description: the number of RoCE credit pause events on this interconnect since last reset. Credit pauses occur when a receiver's buffer is exhausted, causing the sender to stall. In AI training workloads using collective communications (AllReduce, AllGather), sustained credit pauses can inflate job completion time by 10 to 30 percent.

Workload Group (aiWorkloadGroup) The workload group provides visibility into active AI workloads executing on the managed node. This group has no equivalent in any existing SNMP MIB and represents the most novel contribution of AI-MIB. aiWorkloadLatencyP99

Syntax:

Gauge32

Units:

microseconds

Access:

read-only

Status:

current

Description: the 99th percentile end-to-end inference latency in microseconds over the last measurement interval. P99 latency is the standard SLA metric for inference services.

Energy Group (aiEnergyGroup) The energy group addresses the distinctive power management requirements of AI infrastructure, where individual nodes may draw 10 to 140 kW depending on GPU density and configuration. aiNodePUE

Syntax:

Gauge32

Units:

0.01 PUE units

Access:

read-only

Status:

current

Description: Power Usage Effectiveness for the managed node. Industry target for AI data centres is PUE below 1.3.

Notification Definitions AI-MIB defines five notification types that enable event-driven alerting through existing SNMP trap infrastructure: aiGPUHighTemperature, aiGPUHighUtilization, aiGPUECCError, aiInterconnectDegraded, and aiWorkloadFailed. Full definitions are provided in .

OSS/BSS Integration Framework

Integration Architecture AI-MIB integrates into existing telecom OSS/BSS management architecture without requiring changes to the management plane infrastructure. An AI-MIB agent — implementable as a Net-SNMP extension module, a sidecar process, or an embedded firmware component — translates vendor-specific AI infrastructure telemetry into the standardised AI-MIB OID space. The NMS polls AI-MIB agents using the same SNMPv3 mechanisms used for traditional network elements, enabling unified collection, storage, and alerting.

TM Forum Data Model Alignment AI-MIB objects are aligned with TM Forum's common information model and Open API framework. aiGPUGroup aligns with PhysicalResourceSpec (TMF634 Resource Catalog); aiWorkloadGroup aligns with ServiceSpecification (TMF633 Service Catalog); aiEnergyGroup aligns with ResourceCharacteristic (TMF639 Resource Inventory); and aiMIBNotifications aligns with Alarm (TMF642 Alarm Management). This alignment enables AI infrastructure data collected through AI-MIB to flow directly into TM Forum-compliant OSS/BSS systems without custom transformation, supporting the TM Forum Open Digital Architecture (ODA) vision of composable, standards-based operations.

Coexistence with gNMI/OpenConfig AI-MIB and gNMI/OpenConfig are complementary, not competing, approaches. SNMP/AI-MIB serves existing NMS infrastructure, inventory management systems, and BSS systems requiring structured SNMP data, with polling intervals typically 30 to 300 seconds. gNMI Subscribe serves real-time analytics, AIOps platforms, and closed-loop automation systems requiring sub-second telemetry, with push intervals as low as 100 milliseconds. SNMP polling suits relatively stable, slowly changing data such as physical inventory, configuration state, and routing protocol status, where periodic snapshots are sufficient. AI-MIB specifically targets this SNMP-appropriate use case.

Evaluation

Comparison with Existing Approaches Comparison of AI infrastructure monitoring approaches

Dimension	Vendor APIs	Prometheus/Exporters	gNMI/OpenConfig	AI-MIB (Proposed)
OSS/BSS Integration	None	Manual	Limited	Native
SNMP Compatibility	None	None	None	Full
Vendor Neutrality	Single vendor	Partial	Partial	Full
TM Forum Alignment	None	None	Partial	Full
Standardisation	Proprietary	Open	Open	Proposed Standard

Limitations and Mitigations Polling Latency: SNMP polling intervals (typically 30 to 300 seconds) are insufficient for real-time AI workload management. Mitigation: AI-MIB notifications provide event-driven alerting for critical conditions; gNMI subscription provides high-frequency telemetry for real-time use cases. Agent Implementation Complexity: implementing AI-MIB agents requires interfacing with vendor-specific APIs. Mitigation: an open-source AI-MIB agent reference implementation is planned as a companion deliverable. OID Tree Scalability: large GPU clusters with hundreds of accelerators may generate substantial SNMP polling load. Mitigation: AI-MIB supports SNMPv2c GetBulk and SNMPv3 bulk transfer operations.

Implementation Considerations

Agent Implementation AI-MIB agents can be implemented through several mechanisms. For Linux-based AI infrastructure hosts, Net-SNMP's dlmod mechanism enables AI-MIB implementation as a dynamically-loaded shared library that bridges vendor management library calls to SNMP OID responses, requiring no modification to existing SNMP infrastructure. Alternatively, a standalone process implementing an SNMP subagent protocol (AgentX ) can be deployed alongside AI workloads in containerised environments. For AI accelerator vendors committed to standards-based management, native AI-MIB support in device firmware provides the most complete and accurate implementation.

Security Considerations AI-MIB implementations MUST support SNMPv3 with authentication (MD5 or SHA) and privacy (DES or AES) as defined in RFC 3414 . AI workload data — including throughput metrics, job counts, and model identifiers — may constitute commercially sensitive information. Access control lists MUST be implemented to restrict AI-MIB read access to authorised management stations. Write access is not defined in the current specification; all AI-MIB objects are read-only, reducing the attack surface relative to writable MIB objects. This is discussed further in .

Scalability For clusters exceeding 1,000 GPU instances, direct SNMP polling of individual aiGPUTable entries may generate significant management plane traffic. Operators should consider hierarchical collection (cluster-level AI-MIB aggregation agents), selective polling (longer intervals for capacity planning, real-time traps for alerting), and hybrid collection (AI-MIB for inventory and threshold alerting, Prometheus/DCGM for real-time analytics).

Future Extensions Towards a Unified AI Network Management Framework The AI-MIB specification presented in this document addresses the immediate problem of AI infrastructure visibility within existing SNMP frameworks. This section outlines two complementary extensions presented as directions for future work.

SNMPv3+: Streaming Extension for AI-Scale Telemetry The most fundamental limitation of the current SNMP framework in AI environments is its polling model. This document proposes, as a future extension, a subscription-based streaming capability for SNMPv3 that preserves the protocol's security model, MIB-based data modelling, and agent architecture while adding a native push mechanism. Designated SNMPv3+ in this document (the designation is informal and does not represent a Working Group position), this extension would introduce three new Protocol Data Unit (PDU) types: SubscribeRequest, SubscribeResponse, and StreamNotify. Full specification of SNMPv3+ PDU formats is reserved for a companion Internet-Draft.

SNMP-gNMI Translation Gateway The coexistence of SNMP and gNMI in operational environments is the permanent reality for the majority of telecommunications operators. This motivates a standardised translation layer between the two protocol worlds. The SNMP-gNMI Translation Gateway proposed here addresses this through a three-layer architecture: Schema Mapping (a formally defined mapping between AI-MIB OID subtrees and their OpenConfig YANG equivalents), Protocol Adaptation (a stateful proxy translating between polling and subscription models), and Data Normalisation (handling unit conversions and type system differences). The gateway is intended for open-source implementation as a companion deliverable under the Apache 2.0 licence.

Security Considerations This section consolidates the security considerations for AI-MIB introduced in . Implementations MUST support the SNMPv3 User-based Security Model (USM) as defined in RFC 3414 , providing both authentication and privacy. Deployments SHOULD use SHA-based authentication and AES-based privacy in preference to MD5 and DES respectively, consistent with current SNMPv3 best current practice. AI workload telemetry exposed through the aiWorkloadGroup, including throughput metrics, job counts, and workload naming, may reveal commercially sensitive information about an operator's AI service offerings or an enterprise customer's proprietary model usage patterns. Access control lists (View-based Access Control Model, RFC 3415) MUST be configured to restrict read access to authorised management stations only. All objects defined in this document are read-only (max-access of read-only or not-accessible). No writable objects are defined in this version of AI-MIB, which eliminates the risk of unauthorised configuration changes via this MIB. Future extensions that introduce writable objects (for example, configuration of alert thresholds) will require additional security analysis at that time.

IANA Considerations This document requests that IANA assign an object identifier to the AI-MIB module under the mib-2 subtree, or alternatively confirms continued use of the experimental subtree (1.3.6.1.3) pending further Working Group review. The MIB module contained in this document is intended to be registered in the SMI Network Management MIB Module Registry maintained by IANA upon advancement of this document. This document defines the following MIB module registered in the "SMI Security for SNMPv2 Module Names" registry (or successor): AI-MIB, as specified in .

Conclusion This document has presented AI-MIB, a proposed Management Information Base extension for AI and GPU infrastructure management within the SNMP framework. AI-MIB addresses the AI infrastructure monitoring gap by extending the proven SNMP/MIB framework to cover GPU health and utilisation, accelerator interconnect performance, AI workload telemetry, and energy management, while preserving backward compatibility with existing OSS/BSS systems and aligning with TM Forum data models and the Autonomous Network Levels framework. The two future extensions outlined in — SNMPv3+ streaming and the SNMP-gNMI Translation Gateway — together form a comprehensive framework for AI-native network management that builds on AI-MIB's foundational data model. Feedback from the OPSAWG community is welcomed on the scope, object definitions, and registration approach proposed in this document.

References Normative References Informative References OpenConfig Working Group TM Forum TM Forum

AI-MIB Module Definition This appendix presents an abbreviated ASN.1 MIB module definition for the core AI-MIB objects, following the Structure of Management Information Version 2 (SMIv2) conventions defined in RFC 2578. This is a partial listing for readability; the complete module with all object definitions will accompany the next revision of this document.

Acknowledgements The author thanks the broader network management community whose foundational work on SNMP, NETCONF, and gNMI made this proposal possible.