AI-MIB: A Management Information Base Extension for Artificial Intelligence Infrastructure in Telecommunications Networks
draft-pant-ai-mib-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Saurabh Pant | ||
| Last updated | 2026-07-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pant-ai-mib-00
Individual Submission S. Pant
Internet-Draft Independent
Intended status: Informational 19 July 2026
Expires: 20 January 2027
AI-MIB: A Management Information Base Extension for Artificial
Intelligence Infrastructure in Telecommunications Networks
draft-pant-ai-mib-00
Abstract
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.
Status of This Memo
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."
Pant Expires 20 January 2027 [Page 1]
Internet-Draft AI-MIB July 2026
This Internet-Draft will expire on 20 January 2027.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributions . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Evolution of Network Management Protocols . . . . . . 4
2.2. AI Infrastructure Monitoring Today . . . . . . . . . . . 5
2.3. TM Forum and Autonomous Networks . . . . . . . . . . . . 5
3. The AI Infrastructure Monitoring Gap in Telecommunications . 5
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 6
3.2. The Specific Gaps . . . . . . . . . . . . . . . . . . . . 6
4. AI-MIB: Proposed Specification . . . . . . . . . . . . . . . 7
4.1. Design Principles . . . . . . . . . . . . . . . . . . . . 7
4.2. OID Tree Structure . . . . . . . . . . . . . . . . . . . 7
4.3. Object Definitions . . . . . . . . . . . . . . . . . . . 9
4.3.1. GPU Group (aiGPUGroup) . . . . . . . . . . . . . . . 9
4.3.2. Interconnect Group (aiInterconnectGroup) . . . . . . 10
4.3.3. Workload Group (aiWorkloadGroup) . . . . . . . . . . 11
4.3.4. Energy Group (aiEnergyGroup) . . . . . . . . . . . . 11
4.4. Notification Definitions . . . . . . . . . . . . . . . . 11
5. OSS/BSS Integration Framework . . . . . . . . . . . . . . . . 12
5.1. Integration Architecture . . . . . . . . . . . . . . . . 12
5.2. TM Forum Data Model Alignment . . . . . . . . . . . . . . 12
5.3. Coexistence with gNMI/OpenConfig . . . . . . . . . . . . 12
6. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Comparison with Existing Approaches . . . . . . . . . . . 13
6.2. Limitations and Mitigations . . . . . . . . . . . . . . . 13
7. Implementation Considerations . . . . . . . . . . . . . . . . 13
7.1. Agent Implementation . . . . . . . . . . . . . . . . . . 14
7.2. Security Considerations . . . . . . . . . . . . . . . . . 14
7.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
Pant Expires 20 January 2027 [Page 2]
Internet-Draft AI-MIB July 2026
8. Future Extensions Towards a Unified AI Network Management
Framework . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. SNMPv3+: Streaming Extension for AI-Scale Telemetry . . . 15
8.2. SNMP-gNMI Translation Gateway . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. AI-MIB Module Definition . . . . . . . . . . . . . . 18
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. 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 [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.
Pant Expires 20 January 2027 [Page 3]
Internet-Draft AI-MIB July 2026
1.1. 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 (Section 3).
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 (Section 4).
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 (Section 5).
1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Background
2.1. 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
[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
Pant Expires 20 January 2027 [Page 4]
Internet-Draft AI-MIB July 2026
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.
2.2. 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.
2.3. TM Forum and Autonomous Networks
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.
3. The AI Infrastructure Monitoring Gap in Telecommunications
Pant Expires 20 January 2027 [Page 5]
Internet-Draft AI-MIB July 2026
3.1. 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.
3.2. 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.
Pant Expires 20 January 2027 [Page 6]
Internet-Draft AI-MIB July 2026
*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.
4. AI-MIB: Proposed Specification
4.1. 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.
4.2. 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.
iso(1).org(3).dod(6).internet(1)
experimental(3)
aiMIB(TBD)
aiMIBObjects(1)
aiGPUGroup(1)
aiGPUTable(1)
Pant Expires 20 January 2027 [Page 7]
Internet-Draft AI-MIB July 2026
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)
Pant Expires 20 January 2027 [Page 8]
Internet-Draft AI-MIB July 2026
aiNodePUE(6)
aiMIBConformance(2)
aiMIBCompliances(1)
aiMIBGroups(2)
aiMIBNotifications(3)
aiGPUHighTemperature(1)
aiGPUHighUtilization(2)
aiGPUECCError(3)
aiInterconnectDegraded(4)
aiWorkloadFailed(5)
4.3. Object Definitions
4.3.1. 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
Pant Expires 20 January 2027 [Page 9]
Internet-Draft AI-MIB July 2026
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.
4.3.2. 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
Pant Expires 20 January 2027 [Page 10]
Internet-Draft AI-MIB July 2026
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.
4.3.3. 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.
4.3.4. 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.
4.4. 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 Appendix A.
Pant Expires 20 January 2027 [Page 11]
Internet-Draft AI-MIB July 2026
5. OSS/BSS Integration Framework
5.1. 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.
5.2. 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 [TMF-ODA] of composable, standards-based operations.
5.3. 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.
6. Evaluation
Pant Expires 20 January 2027 [Page 12]
Internet-Draft AI-MIB July 2026
6.1. Comparison with Existing Approaches
+=================+===========+=============+==========+==========+
| Dimension |Vendor APIs| Prometheus/ |gNMI/ |AI-MIB |
| | | Exporters |OpenConfig|(Proposed)|
+=================+===========+=============+==========+==========+
| OSS/BSS |None | Manual |Limited |Native |
| Integration | | | | |
+-----------------+-----------+-------------+----------+----------+
| SNMP |None | None |None |Full |
| Compatibility | | | | |
+-----------------+-----------+-------------+----------+----------+
| Vendor |Single | Partial |Partial |Full |
| Neutrality |vendor | | | |
+-----------------+-----------+-------------+----------+----------+
| TM Forum |None | None |Partial |Full |
| Alignment | | | | |
+-----------------+-----------+-------------+----------+----------+
| Standardisation |Proprietary| Open |Open |Proposed |
| | | | |Standard |
+-----------------+-----------+-------------+----------+----------+
Table 1: Comparison of AI infrastructure monitoring approaches
6.2. 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.
7. Implementation Considerations
Pant Expires 20 January 2027 [Page 13]
Internet-Draft AI-MIB July 2026
7.1. 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 [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.
7.2. Security Considerations
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.
7.3. 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).
8. 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.
Pant Expires 20 January 2027 [Page 14]
Internet-Draft AI-MIB July 2026
8.1. 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.
8.2. 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.
9. Security Considerations
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.
Pant Expires 20 January 2027 [Page 15]
Internet-Draft AI-MIB July 2026
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.
10. 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 Appendix A.
11. 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 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.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Pant Expires 20 January 2027 [Page 16]
Internet-Draft AI-MIB July 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990,
<https://www.rfc-editor.org/info/rfc1157>.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II",
RFC 1213, DOI 10.17487/RFC1213, March 1991,
<https://www.rfc-editor.org/info/rfc1213>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414,
DOI 10.17487/RFC3414, December 2002,
<https://www.rfc-editor.org/info/rfc3414>.
[RFC6933] Bierman, B., Romascanu, D., Quittek, J., and M. Ball,
"Entity MIB (Version 4)", RFC 6933, DOI 10.17487/RFC6933,
May 2013, <https://www.rfc-editor.org/info/rfc6933>.
12.2. Informative References
[RFC1441] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to version 2 of the Internet-standard
Network Management Framework", RFC 1441,
DOI 10.17487/RFC1441, April 1993,
<https://www.rfc-editor.org/info/rfc1441>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
STD 67, RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
Pant Expires 20 January 2027 [Page 17]
Internet-Draft AI-MIB July 2026
[RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco,
"Agent Extensibility (AgentX) Protocol Version 1",
RFC 2741, DOI 10.17487/RFC2741, January 2000,
<https://www.rfc-editor.org/info/rfc2741>.
[GNMI-SPEC]
OpenConfig Working Group, "gRPC Network Management
Interface (gNMI) Specification", 2021,
<https://github.com/openconfig/gnmi>.
[TMF-ANL] TM Forum, "Autonomous Network Levels (ANL) Framework",
2025, <https://www.tmforum.org/>.
[TMF-ODA] TM Forum, "Open Digital Architecture (ODA) Component
Framework", 2025, <https://www.tmforum.org/>.
Appendix A. 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.
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"
Pant Expires 20 January 2027 [Page 18]
Internet-Draft AI-MIB July 2026
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
Pant Expires 20 January 2027 [Page 19]
Internet-Draft AI-MIB July 2026
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
Pant Expires 20 January 2027 [Page 20]
Internet-Draft AI-MIB July 2026
Appendix B. Acknowledgements
The author thanks the broader network management community whose
foundational work on SNMP, NETCONF, and gNMI made this proposal
possible.
Author's Address
Saurabh Pant
Independent
Denver, Colorado
United States of America
Email: research@saurabhpant.com
URI: https://saurabhpant.com
Pant Expires 20 January 2027 [Page 21]