The Use Case of Autonomic Traffic Management in the Artificial Intelligence Data Center

With artificial intelligence entering the "Large Model Era", Artificial Intelligence Data Centers (AIDCs) have become important infrastructure for large-scale AI training and inference. As AIDCs support increasingly complex workloads, their communication demands become more dynamic and intensive. In massive clusters composed of thousands of high-performance GPUs, the network is no longer merely a conduit for data transmission; it directly affects the overall efficiency ("Goodput") of the computing cluster. In distributed training, communication delays prolong synchronization waits and leave GPUs idle, wasting computing resources. In distributed inference, communication delays increase end-to-end response times and degrade service quality. Network congestion and unstable communication performance therefore affect not only data transmission but also the effective utilization of AI computing resources. The impact of these network problems is also influenced by task orchestration, compute placement, and scheduling decisions. Placing communication-intensive tasks on computing nodes connected through congested or capacity-constrained paths increases communication overhead and can further extend GPU waiting times. Traffic management therefore needs to account for application requirements and compute resources alongside packet-network conditions and, where deployed, optical transport resources. Traditional network management models based on static planning and manual operations are insufficient to address these dynamic and interdependent demands. AIDCs require autonomic traffic management that acquires relevant resource information, coordinates management decisions, and adjusts traffic behavior as workloads change. The IETF Autonomic Networking Integrated Model and Approach (ANIMA) provides an architectural foundation for autonomic network management, in which Autonomic Service Agents (ASAs) implement autonomic functions, supported by the Autonomic Networking Infrastructure (ANI). Within this architecture, ASAs can acquire relevant operational information, make or coordinate management decisions, initiate appropriate management actions, and adapt their behavior based on feedback. These capabilities provide a basis for distributed coordination and closed-loop traffic management in AIDCs, while ANIMA protocols, such as GRASP, can support interactions among ASAs. This document examines the applicability of the ANIMA architecture to AIDC traffic management and discusses two representative approaches: distributed autonomic traffic management and controller-led hybrid traffic management. The document focuses on architectural considerations and use cases rather than specifying new protocol extensions or detailed implementation mechanisms.

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.

AIDCs support large-scale AI training and inference workloads that impose demanding and dynamic communication requirements on data center networks. Distributed training involves frequent data exchanges among computing nodes, including collective communication operations such as All-Reduce, which may generate periodic traffic bursts and substantial bandwidth demands. Distributed inference workloads, on the other hand, may exhibit more variable communication patterns and latency-sensitive traffic. These characteristics make network performance an important factor affecting training efficiency and inference service quality. Large-scale AIDCs commonly employ multi-path network architectures, such as Clos-based leaf-spine fabrics, to provide high-bandwidth connectivity among computing nodes. However, uneven traffic distribution, resource contention, and changing workload demands may lead to network congestion and performance degradation. Conventional traffic management approaches relying on static configurations or manual intervention are insufficient to effectively address these dynamic conditions. Consequently, AIDCs require more adaptive traffic management capabilities to improve resource utilization and respond to changing network conditions. Furthermore, AIDC traffic is influenced not only by network conditions but also by application requirements, task orchestration, and compute-resource placement. The placement of communication-intensive tasks across computing nodes may affect traffic distribution, communication overhead, and network-resource contention. For example, when multiple distributed training jobs share the same packet network, collective communication during communication-intensive phases may cause traffic concentration on a subset of links, resulting in localized congestion even when sufficient aggregate network capacity is available. In the distributed autonomic approach, autonomic functions coordinate local adjustments, such as path selection and transmission-rate control, to mitigate such congestion. In the controller-led hybrid approach, the centralized controller evaluates broader traffic-engineering decisions in conjunction with workload-placement constraints when congestion persists across multiple links or racks. Where reconfigurable optical networks are deployed, optical connectivity adjustments may also be considered when the expected traffic duration justifies the associated reconfiguration cost. This scenario illustrates the potential need to coordinate traffic-management decisions across application, compute, and packet-network domains and, where available, optical-network domains. Such coordination can enable management functions to consider both communication demands and resource availability when adjusting traffic paths, transmission rates, resource allocation, workload placement, or optical connectivity. Taken together, these challenges require autonomic traffic management to address both localized congestion and resource coordination across broader workload and network domains. The following sections describe two approaches to meeting these requirements: distributed autonomic traffic management and controller-led hybrid traffic management.

Distributed autonomic network technology provides a refined automated traffic management solution for AIDCs with its characteristics of "decentralized control and autonomous node collaboration". As the core signaling protocol of autonomic networks, GRASP supports discovery, synchronization, and negotiation among ASAs. In this distributed approach, AIDC-specific GRASP objectives and ASA behavior support five key phases: topology awareness, multi-path exploration, resource negotiation and reservation, traffic deployment, and resource release. Together, these phases form a closed-loop management mechanism, addressing the compatibility and efficiency issues of autonomous inter-node communication. In the topology awareness phase, each participating computing node uses GRASP discovery to identify peers supporting relevant objectives. The participating ASAs exchange node identity, computing-resource status, and network-interface parameters through GRASP synchronization with the corresponding objectives. The node also receives and processes information from other computing nodes, switches, and routers, maintains its local "neighbor node list", identifies relevant peer ASAs, and obtains topology information from the corresponding network management mechanisms for subsequent traffic scheduling. This process does not require the intervention of a centralized controller, and the node updates its topology information in response to dynamic scenarios such as device plugging and unplugging and temporary failures. After the topology awareness is completed, the node will start the multi-path exploration process. Based on the locally stored topology information, the node will generate multiple paths using shortest-path and suitable multi-path algorithms, combined with indicators such as link bandwidth, transmission delay, packet loss rate, and jitter. For example, when connecting to a target computing node, it will not only explore the shortest path of "local Leaf node - same-area Spine node - target Leaf node", but also plan the redundant path of "local Leaf node - cross-area Spine node - target Leaf node", ensuring rapid switching when the main path is congested. After the path is determined, the node will conduct resource negotiation with the ASAs associated with the relevant network devices using GRASP objectives and corresponding ASA behavior. The requesting ASA sends resource negotiation requests to the ASAs associated with the relevant network devices, specifying parameters such as the required bandwidth and queue priority. The receiving ASAs evaluate the requests based on the available resources of their associated devices. If resources are sufficient, they will return confirmation information and lock the corresponding resources; if resources are insufficient, they will feed back the available resource quota for the node to adjust the path selection. For example, when the remaining bandwidth of a core switch on a certain path cannot fully meet the required bandwidth, the node may select an alternative path for further negotiation, subject to predefined retry limits and resource-release procedures in case of failure. The corresponding ASAs manage resource reservation states and release previously reserved resources when negotiation fails. After the resource reservation is completed, the system will automatically deploy traffic forwarding rules: on the one hand, configure ACL rules and QoS queues on various network devices to ensure that traffic is transmitted according to the reserved resource priority; on the other hand, configure traffic encapsulation and decapsulation parameters on the source node and target node to support the required forwarding behavior and, where applicable, security mechanisms. When the traffic demand ends or the corresponding resources are no longer needed after migration, the node initiates the release of the associated resource reservations, allowing these resources to be reused for other traffic. The five-phase workflow described above incorporates application requirements and the status of compute, packet-network, and, where deployed, optical-network resources. In this use case, ASAs are associated with application schedulers, compute orchestrators, packet-network management functions, and, where deployed, optical-network controllers to facilitate distributed information sharing and resource coordination. The exchanged information includes task phases, communication dependencies, data volumes, completion deadlines, compute-resource availability, workload placement, execution progress, network conditions, and, where applicable, optical transport resources. Through cooperation among ASAs, autonomic functions make traffic-management decisions that consider both application demands and resource availability. GRASP provides the information exchange and negotiation mechanism among ASAs in this use case. When workload placement causes traffic to concentrate on congested network links, distributed autonomic functions first coordinate network-side adjustments, such as multipath selection, rate control, traffic splitting, and queue-priority adjustment. If these adjustments are insufficient to meet application-completion requirements, the autonomic functions further coordinate with compute orchestrators and, where deployed, optical-network controllers to evaluate workload-placement adjustments, lightpath provisioning where available, or both, considering the expected traffic duration, adjustment costs, and anticipated benefits. The resulting decisions are implemented through the corresponding management mechanisms. When the traffic demand ends, temporary resource allocations, including bandwidth, queue, and, where applicable, lightpath reservations, are released, while the compute orchestrator determines whether to maintain or revise workload placement. In this way, the distributed approach combines local autonomous adaptation with cross-domain resource coordination over different timescales.

To address the limitations of distributed autonomic networks in global resource optimization, the controller-led approach uses centralized controllers and traffic orchestrators to build a hybrid architecture of "distributed execution + centralized decision-making", realizing global collaborative scheduling of computing power and network resources. GRASP serves as the communication protocol connecting distributed ASAs and controller-hosted ASAs, enabling global collaborative scheduling of computing power and network resources. This model is particularly applicable in scenarios such as large-model training task iteration and computing node load balancing. Through GRASP, distributed ASAs exchange information with the centralized controller, enabling the controller to maintain a broader view of network and compute-resource states. When a computing node initiates a workload migration or traffic-management request due to high load (such as a single-node GPU utilization rate exceeding 90%), hardware maintenance (such as the need to replace a faulty hard disk), or task iteration (such as the need to adjust the scale of the computing cluster when the training task enters the next phase), its ASA sends a GRASP negotiation request carrying an AIDC-specific objective to the controller-hosted ASA. The objective specifies the demand type, data volume, QoS requirements (such as delay and packet-loss thresholds), and, for workload migration requests, target compute-capacity requirements. The centralized controller will immediately start a multi-dimensional data collection process: collect the operating status of each computing node (including validity, GPU utilization rate, memory occupancy rate, temperature, etc.) through the computing power monitoring module; collect the dynamic occupancy information of the entire link (such as bandwidth utilization rate, delay, fault status of each link) through the network monitoring module; and obtain the priority information of all currently running tasks through the business management module to ensure the comprehensiveness of the decision-making basis. Based on the collected global data, the centralized controller will make decisions through global optimization algorithms such as integer programming and genetic algorithms: in terms of computing node planning, it will screen out target nodes that meet the requirements based on task requirements and computing node status. For example, it will give priority to allocating nodes with larger GPU memory for high-precision inference tasks, and select target nodes in the same Leaf domain as the source node for low-latency tasks; in terms of path planning, it will comprehensively consider link load balancing and transmission efficiency to avoid concentrating a large amount of traffic on several core links. For example, when the link utilization rate of a certain Spine node reaches 75%, it will give priority to planning paths passing through other low-load Spine nodes; in terms of resource reservation, it will uniformly calculate the forwarding resources required by each path according to the traffic scale and negotiate and lock them with relevant network devices in advance to avoid resource competition that may occur in distributed negotiation. After the decision is made, the centralized controller communicates the resulting objectives and policies to relevant ASAs through GRASP. The corresponding ASAs and domain-specific controllers use their respective management and control interfaces to prepare selected workload migrations, configure resources, and schedule traffic. During the execution of the selected traffic-management actions, the centralized controller monitors the relevant traffic and resource states. If sudden congestion is found on a certain link, it will immediately trigger a dynamic adjustment mechanism, re-plan the path and update the resource configuration to maintain service continuity. The closed-loop workflow described above incorporates application requirements and the state of compute, packet-network, and, where deployed, optical-network resources. In addition to handling request-driven traffic management, the centralized controller continuously collects application communication dependencies, task phases, workload-placement information, and, where available, optical-network resource status, together with the compute-node and packet-network information described above, to maintain a unified cross-domain view. This view enables the controller to estimate traffic volume, communication distance, and potential hotspots for alternative workload-placement options, thereby avoiding placement decisions based solely on GPU utilization while neglecting network transport constraints. Based on this cross-domain view, the controller continues to optimize traffic management as its primary objective. It determines traffic paths, transmission rates, priorities, and, where applicable, traffic-splitting ratios. When beneficial and available, it also includes lightpath provisioning while coordinating workload-placement adjustments with compute orchestrators. The controller addresses transient congestion and short-term traffic fluctuations primarily through packet-network mechanisms such as path selection and rate control. If a workload placement persistently generates excessive inter-domain traffic or network hotspots, the controller evaluates workload relocation, task migration, lightpath provisioning where available, or a combination of these actions, considering the expected traffic duration, migration or provisioning cost, and anticipated performance gains. The controller distributes the updated policies to relevant Autonomic Service Agents (ASAs) through the GRASP objectives used in this use case. Compute orchestrators, packet-network controllers, and, where deployed, optical-network controllers then enforce the corresponding actions through their domain-specific control interfaces. Distributed ASAs coordinate rapid local responses to microbursts, transient congestion, and localized failures, while reporting updated state information to the controller. When the demand subsides, temporary bandwidth, queue, and lightpath reservations are released as appropriate, forming a hybrid closed loop that combines global optimization, distributed enforcement, local adaptation, and continuous state feedback.

This document elaborates on the application of autonomic network technology in traffic planning and management of AIDCs. Aiming at the autonomic traffic management demands in AIDCs, this document proposes two solutions: distributed autonomic network and centralized controller-led hybrid architecture. The distributed solution realizes autonomous traffic management through topology awareness, multi-path exploration and other closed-loop processes; the hybrid architecture achieves global resource optimization via centralized decision-making and distributed execution. Both solutions are designed to address the challenges of high dynamics and complexity of traffic in AIDCs and improve the utilization of computing power and network resources. Both approaches incorporate application requirements and compute, packet-network, and, where deployed, optical-network state information to improve traffic-management decisions.

This informational document does not define any IANA items.

This informational document proposes using GRASP for information exchange, resource negotiation, and other related functions. These mechanisms should reuse the security mechanisms defined by the IETF ANIMA WG. Detailed security considerations shall be addressed in the standards documents that define these detailed implementation mechanisms and protocol extensions.