The Use Case of Autonomic Traffic Management in the Artificial Intelligence Data Center
draft-jiang-anima-traffic-management-in-aidc-01

ANIMA                                                           S. Jiang
Internet-Draft                                                    L. Zhu
Intended status: Informational                                      BUPT
Expires: 28 April 2027                                   25 October 2026

     The Use Case of Autonomic Traffic Management in the Artificial
                        Intelligence Data Center
            draft-jiang-anima-traffic-management-in-aidc-01

Abstract

   This document describes the use case of autonomic traffic management
   in Artificial Intelligence Data Centers (AIDCs), including the
   associated management requirements and challenges.  It discusses two
   representative approaches based on the ANIMA architecture:
   distributed autonomic traffic management and controller-led hybrid
   traffic management.

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."

   This Internet-Draft will expire on 28 April 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jiang & Zhu               Expires 28 April 2027                 [Page 1]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  AIDC Traffic Management Challenges and Requirements . . . . .   4
   4.  Distributed Autonomic Traffic Management Mechanism in AIDC  .   5
   5.  Traffic Orchestration and Management by Centralized Controllers
           in AIDC . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   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

Jiang & Zhu               Expires 28 April 2027                 [Page 2]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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)[RFC8993].  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[RFC8990], 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.

2.  Terminology

   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.

Jiang & Zhu               Expires 28 April 2027                 [Page 3]
Internet-Draft            auto-traffic-in-aidc              October 2026

3.  AIDC Traffic Management Challenges and Requirements

   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.

Jiang & Zhu               Expires 28 April 2027                 [Page 4]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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.

4.  Distributed Autonomic Traffic Management Mechanism in AIDC

   Distributed autonomic network technology [RFC8993] 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.

Jiang & Zhu               Expires 28 April 2027                 [Page 5]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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

Jiang & Zhu               Expires 28 April 2027                 [Page 6]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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.

Jiang & Zhu               Expires 28 April 2027                 [Page 7]
Internet-Draft            auto-traffic-in-aidc              October 2026

5.  Traffic Orchestration and Management by Centralized Controllers in
    AIDC

   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

Jiang & Zhu               Expires 28 April 2027                 [Page 8]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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.

Jiang & Zhu               Expires 28 April 2027                 [Page 9]
Internet-Draft            auto-traffic-in-aidc              October 2026

   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.

6.  Summary

   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.

7.  IANA Considerations

   This informational document does not define any IANA items.

8.  Security Considerations

   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.

9.  References

9.1.  Normative References

Jiang & Zhu               Expires 28 April 2027                [Page 10]
Internet-Draft            auto-traffic-in-aidc              October 2026

   [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>.

   [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>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

9.2.  Informative References

   [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
              L., and J. Nobre, "A Reference Model for Autonomic
              Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
              <https://www.rfc-editor.org/info/rfc8993>.

Authors' Addresses

   Sheng Jiang
   Beijing University of Posts and Telecommunications
   No. 10 Xitucheng Road
   Haidian District, Beijing
   China
   Email: shengjiang@bupt.edu.cn

   Longwei Zhu
   Beijing University of Posts and Telecommunications
   No. 10 Xitucheng Road
   Haidian District, Beijing
   China
   Email: lwzhu@bupt.edu.cn

Jiang & Zhu               Expires 28 April 2027                [Page 11]