| Internet-Draft | AI-MIB | July 2026 |
| Pant | Expires 20 January 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC1157] — 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.¶
This document makes three contributions:¶
Problem formalisation: characterisation of the AI infrastructure monitoring gap in telecommunications environments with reference to specific deployment scenarios and existing OSS/BSS frameworks (Section 3).¶
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 (Section 4).¶
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 (Section 5).¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 [RFC1157] in 1990 and progressively enhanced through SNMPv2 [RFC1441] (1993) and SNMPv3 [RFC3411] (1999), established the foundational paradigm of manager-agent architecture with MIB-based data modelling. MIB-II [RFC1213] 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 [RFC6241] introduced transactional, model-driven configuration using YANG data models over SSH. RESTCONF [RFC8040] extended NETCONF concepts to RESTful interfaces. gNMI [GNMI-SPEC], 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.¶
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.¶
The TM Forum's Autonomous Network Levels (ANL) framework [TMF-ANL], 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.¶
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 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 [RFC6933] 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 is designed according to five principles:¶
Backward Compatibility: AI-MIB operates within the SNMPv3 framework without modification.¶
Vendor Neutrality: the MIB defines objects applicable to AI accelerators from any vendor without vendor-specific dependencies.¶
TM Forum Alignment: object definitions are aligned with TM Forum data models to facilitate integration with OSS/BSS systems.¶
OpenConfig Complementarity: AI-MIB coexists with gNMI/OpenConfig telemetry.¶
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.¶
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.¶
iso(1).org(3).dod(6).internet(1)
experimental(3)
aiMIB(TBD)
aiMIBObjects(1)
aiGPUGroup(1)
aiGPUTable(1)
aiGPUEntry(1) [indexed by aiGPUIndex]
aiGPUIndex(1)
aiGPUDescr(2)
aiGPUVendor(3)
aiGPUModelName(4)
aiGPUSerialNumber(5)
aiGPUFirmwareVersion(6)
aiGPUComputeUtilization(7)
aiGPUMemoryUtilization(8)
aiGPUMemoryUsed(9)
aiGPUMemoryTotal(10)
aiGPUTemperature(11)
aiGPUPowerDraw(12)
aiGPUPowerLimit(13)
aiGPUClockSpeed(14)
aiGPUECCErrorsUncorrected(15)
aiGPUECCErrorsCorrected(16)
aiGPUOperStatus(17)
aiInterconnectGroup(2)
aiInterconnectTable(1)
aiInterconnectEntry(1)
aiInterconnectIndex(1)
aiInterconnectType(2)
aiInterconnectBandwidth(3)
aiInterconnectUtilization(4)
aiInterconnectErrors(5)
aiInterconnectLatency(6)
aiInterconnectCreditPauses(7)
aiWorkloadGroup(3)
aiWorkloadTable(1)
aiWorkloadEntry(1)
aiWorkloadIndex(1)
aiWorkloadName(2)
aiWorkloadType(3)
aiWorkloadStatus(4)
aiWorkloadGPUCount(5)
aiWorkloadThroughput(6)
aiWorkloadLatencyP99(7)
aiWorkloadStartTime(8)
aiEnergyGroup(4)
aiNodePowerTotal(1)
aiNodePowerGPU(2)
aiNodePowerCPU(3)
aiNodePowerMemory(4)
aiNodeCoolingEfficiency(5)
aiNodePUE(6)
aiMIBConformance(2)
aiMIBCompliances(1)
aiMIBGroups(2)
aiMIBNotifications(3)
aiGPUHighTemperature(1)
aiGPUHighUtilization(2)
aiGPUECCError(3)
aiInterconnectDegraded(4)
aiWorkloadFailed(5)
¶
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¶
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¶
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¶
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¶
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¶
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.¶
The interconnect group provides visibility into high-bandwidth GPU interconnect fabrics: NVLink (intra-node), InfiniBand (inter-node), and RoCE (RDMA over Converged Ethernet).¶
aiInterconnectCreditPauses¶
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.¶
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¶
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.¶
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¶
Description: Power Usage Effectiveness for the managed node. Industry target for AI data centres is PUE below 1.3.¶
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 Appendix A.¶
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.¶
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 [TMF-ODA] of composable, standards-based operations.¶
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.¶
| 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 |
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.¶
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 [RFC2741]) 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.¶
AI-MIB implementations MUST support SNMPv3 with authentication (MD5 or SHA) and privacy (DES or AES) as defined in RFC 3414 [RFC3414]. 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 Section 9.¶
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).¶
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.¶
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.¶
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.¶
This section consolidates the security considerations for AI-MIB introduced in Section 7.2. Implementations MUST support the SNMPv3 User-based Security Model (USM) as defined in RFC 3414 [RFC3414], 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.¶
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 Appendix A.¶
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 Section 8 — 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.¶
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.¶
AI-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Gauge32, Counter64, TimeTicks,
experimental
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
DisplayString, TruthValue
FROM SNMPv2-TC;
aiMIB MODULE-IDENTITY
LAST-UPDATED "202607010000Z"
ORGANIZATION "Independent Submission"
CONTACT-INFO
"Saurabh Pant
research@saurabhpant.com
https://saurabhpant.com"
DESCRIPTION
"The MIB module for management of Artificial
Intelligence and GPU accelerator infrastructure
in telecommunications networks."
REVISION "202607010000Z"
DESCRIPTION "Initial version."
::= { experimental TBD }
aiMIBObjects OBJECT IDENTIFIER ::= { aiMIB 1 }
aiMIBConformance OBJECT IDENTIFIER ::= { aiMIB 2 }
aiMIBNotifications OBJECT IDENTIFIER ::= { aiMIB 3 }
aiGPUGroup OBJECT IDENTIFIER ::= { aiMIBObjects 1 }
aiInterconnectGroup OBJECT IDENTIFIER ::= { aiMIBObjects 2 }
aiWorkloadGroup OBJECT IDENTIFIER ::= { aiMIBObjects 3 }
aiEnergyGroup OBJECT IDENTIFIER ::= { aiMIBObjects 4 }
aiGPUTable OBJECT-TYPE
SYNTAX SEQUENCE OF AiGPUEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of AI accelerator (GPU) instances
present in the managed node."
::= { aiGPUGroup 1 }
aiGPUEntry OBJECT-TYPE
SYNTAX AiGPUEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the GPU table representing
one physical AI accelerator."
INDEX { aiGPUIndex }
::= { aiGPUTable 1 }
AiGPUEntry ::= SEQUENCE {
aiGPUIndex Integer32,
aiGPUDescr DisplayString,
aiGPUVendor DisplayString,
aiGPUModelName DisplayString,
aiGPUSerialNumber DisplayString,
aiGPUComputeUtilization Gauge32,
aiGPUMemoryUtilization Gauge32,
aiGPUMemoryUsed Gauge32,
aiGPUMemoryTotal Gauge32,
aiGPUTemperature Gauge32,
aiGPUPowerDraw Gauge32,
aiGPUECCErrorsUncorrected Counter64,
aiGPUOperStatus INTEGER
}
aiGPUComputeUtilization OBJECT-TYPE
SYNTAX Gauge32 (0..100)
UNITS "percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The percentage of time during which one or
more kernels were executing on the GPU over
the last sampling interval."
::= { aiGPUEntry 7 }
aiGPUOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
degraded(3),
testing(4),
unknown(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational status of the GPU accelerator."
::= { aiGPUEntry 17 }
aiGPUHighTemperature NOTIFICATION-TYPE
OBJECTS { aiGPUIndex, aiGPUTemperature, aiGPUModelName }
STATUS current
DESCRIPTION
"Generated when GPU temperature exceeds the
configured thermal threshold for a sustained
period, indicating risk of thermal throttling."
::= { aiMIBNotifications 1 }
aiGPUECCError NOTIFICATION-TYPE
OBJECTS { aiGPUIndex, aiGPUECCErrorsUncorrected }
STATUS current
DESCRIPTION
"Generated upon detection of any uncorrected
ECC memory error. Requires immediate
operational response."
::= { aiMIBNotifications 3 }
END
¶
The author thanks the broader network management community whose foundational work on SNMP, NETCONF, and gNMI made this proposal possible.¶