# drafts

name: draft-jain-lisp-network-ai-infra
rev: 03
title: LISP-Based Network for AI Infrastructure
time: 2025-12-13T11:13:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-16T11:13:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Autonomous netops", "Agent discovery/reg"]
tags: []
fetched_at: 2026-03-03T15:50:11.000787+00:00
abstract:
  The Locator/Identifier Separation Protocol (LISP) control plane
     provides the mechanisms to support Scale-Up, Scale-Out and Scale-
     Across backend networks within AI infrastructure.  This document
     describes how LISP enables a unified control plane architecture that
     accommodates different scaling technologies, offering flexibility in
     deployment.  By leveraging lisp mechanisms including EID-to-RLOC-
     mapping/pxTR registrations, publication-subscription and VPN
     instance-based segmentation ([RFC9300][RFC9301][RFC9437][I-D.ietf-
     lisp-site-external-connectivity][I-D.ietf-lisp-vpn]), the
     architecture delivers scalable high bandwidth for large training
     workloads, ultra-low-latency collective operations, and a simplified
     control framework that seamlessly spans heterogeneous accelerator
     fabrics.  This approach allows AI/ML applications (whether focused on
     training or inference) to run workloads efficiently with resiliency
     on a converged infrastructure, supporting diverse deployment
     scenarios using the same underlying network fabric.

full_text:
  Network Working Group                                            P. Jain
  Internet-Draft                                                      MIPS
  Intended status: Experimental                                   S. Hooda
  Expires: 15 June 2026                                      Cisco Systems
                                                             D. Srivastava
                                                                  DataraAI
                                                         P. Pillay-Esnault
                                                               Independent
                                                                 V. Moreno
                                                                    Google
                                                          12 December 2025


                  LISP-Based Network for AI Infrastructure
                    draft-jain-lisp-network-ai-infra-03

  Abstract

     The Locator/Identifier Separation Protocol (LISP) control plane
     provides the mechanisms to support Scale-Up, Scale-Out and Scale-
     Across backend networks within AI infrastructure.  This document
     describes how LISP enables a unified control plane architecture that
     accommodates different scaling technologies, offering flexibility in
     deployment.  By leveraging lisp mechanisms including EID-to-RLOC-
     mapping/pxTR registrations, publication-subscription and VPN
     instance-based segmentation ([RFC9300][RFC9301][RFC9437][I-D.ietf-
     lisp-site-external-connectivity][I-D.ietf-lisp-vpn]), the
     architecture delivers scalable high bandwidth for large training
     workloads, ultra-low-latency collective operations, and a simplified
     control framework that seamlessly spans heterogeneous accelerator
     fabrics.  This approach allows AI/ML applications (whether focused on
     training or inference) to run workloads efficiently with resiliency
     on a converged infrastructure, supporting diverse deployment
     scenarios using the same underlying network fabric.

  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in BCP 14 RFC 2119
     [RFC2119] RFC 8174 [RFC8174].

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.





  Jain, et al.              Expires 15 June 2026                  [Page 1]


  Internet-Draft            LISP Network AI Infra            December 2025


     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 15 June 2026.

  Copyright Notice

     Copyright (c) 2025 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.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  AI Infrastructure Requirements  . . . . . . . . . . . . .   3
       1.2.  LISP Advantages . . . . . . . . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
     4.  AI Infra System Architecture  . . . . . . . . . . . . . . . .   5
     5.  Scale-Out/Scale-Across Network Architecture . . . . . . . . .   7
       5.1.  Scale-Out Registration and Fabric Paths . . . . . . . . .   8
       5.2.  Scale-Out Subscription and Publication  . . . . . . . . .   9
       5.3.  Scale-Out Packet Flow . . . . . . . . . . . . . . . . . .  10
       5.4.  Scale-Out Path Change . . . . . . . . . . . . . . . . . .  11
       5.5.  Deployment Considerations . . . . . . . . . . . . . . . .  11
         5.5.1.  Scale-Out Segmentation and INCC . . . . . . . . . . .  12
         5.5.2.  Scale-Out Mappings  . . . . . . . . . . . . . . . . .  12
         5.5.3.  Scale-Out Mapping System (MS/MR)  . . . . . . . . . .  12
         5.5.4.  Scale-Out Unknown Accelerators  . . . . . . . . . . .  13
     6.  Scale-Up Network Architecture . . . . . . . . . . . . . . . .  13
       6.1.  Scale-Up Registration . . . . . . . . . . . . . . . . . .  14
       6.2.  Scale-Up Subscription and Publication . . . . . . . . . .  15
       6.3.  Scale-Up Packet Flow  . . . . . . . . . . . . . . . . . .  15



  Jain, et al.              Expires 15 June 2026                  [Page 2]


  Internet-Draft            LISP Network AI Infra            December 2025


       6.4.  Scale-Up Path Change  . . . . . . . . . . . . . . . . . .  16
       6.5.  Deployment Considerations . . . . . . . . . . . . . . . .  17
         6.5.1.  Scale-Up Segmentation and INCC  . . . . . . . . . . .  17
         6.5.2.  Scale-Up Mappings . . . . . . . . . . . . . . . . . .  18
         6.5.3.  Scale-Up Mapping System (MS/MR) . . . . . . . . . . .  18
         6.5.4.  Scale-Up Unknown Accelerators . . . . . . . . . . . .  18
         6.5.5.  IP Forwarding of Scale-Up Traffic . . . . . . . . . .  19
     7.  Multihoming & Multipaths  . . . . . . . . . . . . . . . . . .  19
       7.1.  Multihomed Accelerators Registration  . . . . . . . . . .  19
       7.2.  Multihoming xTRs/RLOCs Merging  . . . . . . . . . . . . .  19
       7.3.  Multihoming/Multipath forwarding  . . . . . . . . . . . .  20
     8.  Data Plane Encapsulation Options  . . . . . . . . . . . . . .  20
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
     11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
     12. Normative References  . . . . . . . . . . . . . . . . . . . .  21
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Background


  1.1.  AI Infrastructure Requirements

     Artificial Intelligence (AI) workloads impose stringent requirements
     on data center networks.  Training jobs can span hundreds of
     thousands of accelerators, demanding ultra-low latency (on the order
     of hundreds of nanoseconds to microseconds), massive scalability,
     segmentation for security, high bandwidth, and sustained throughput.
     These workloads also require resiliency, predictable performance, and
     precise synchronization among accelerators for collective operations
     and large-scale data transfer within a PoD or cluster (Scale-Up), as
     well as across PoDs/clusters (Scale-Out and Scale-Across).

  1.2.  LISP Advantages

     The Locator/ID Separation Protocol (LISP) offers decoupling endpoint
     identifiers (EIDs) from routing locators (RLOCs) and introduces
     segmentation through Instance-IDs (IIDs) ([RFC9300][RFC9301][I-
     D.ietf-lisp-site-external-connectivity][I-D.ietf-lisp-vpn]).  This
     enables a unified control plane for AI infrastructure, accommodating
     both non-IP and IP address-based accelerator-IDs [RFC9735]and
     supporting dynamic updates via publish/subscribe mechanisms
     [RFC9437].  As a result, Scale-Up, Scale-Out and Scale-Across domains
     operate as distinct yet interoperable fabrics under a single
     framework.  Additionally, segmentation ensures isolation, supports
     collectives group operations and enforces policies in shared
     environments, enabling flexible deployments without altering the
     underlying architecture.



  Jain, et al.              Expires 15 June 2026                  [Page 3]


  Internet-Draft            LISP Network AI Infra            December 2025


  2.  Introduction

     This document describes the architecture and mechanisms for
     implementing a LISP-based unified control plane to converge Scale-Up,
     Scale-Out, and Scale-Across backend networks within data center AI
     infrastructure.  By leveraging LISP control-plane capabilities, the
     proposed design seamlessly unifies different scaling technologies,
     enabling efficient and scalable AI data center operations.

     The decision to send a flow over the Scale-Up,Scale-Out or Scale-
     Across network is determined by the traffic’s destination.  For
     example, intra-POD traffic (which may be non-IP) is directed to the
     Scale-Up network, while inter-POD traffic (primarily IP-based) is
     routed through the Scale-Out or Scale-Across network.  Segmentation
     enables flexible deployment options, including Scale-Up only, Scale-
     Out/Scale-Across only, or hybrid configurations, without requiring
     changes to the underlying architecture.

     This unified approach optimizes latency, bandwidth, and resiliency
     across scaling domains to support diverse AI/ML workloads for both
     inference and training.  A key advantage is flexibility: while most
     data centers require all three capabilities, some applications may
     rely exclusively on one.  In such cases, LISP-based segmentation
     confines functionality to the appropriate domain, preserving
     architectural integrity, enforcing security and supporting
     application-specific requirements.

  3.  Definition of Terms

     • LISP Terminology: All terms related to the Locator/ID Separation
     Protocol (LISP)—including EID (Endpoint Identifier), RLOC (Routing
     Locator), xTR (Ingress/Egress Tunnel Router), MS/MR (Mapping System),
     and publication-subscription etc—are used as defined in the LISP
     specifications: [RFC9300], [RFC9301], and [RFC9437].

     • Accelerator (Acc): Specialized hardware designed to accelerate AI
     workloads.  Examples include: GPU (Graphics Processing Unit), TPU
     (Tensor Processing Unit), NPU (Neural Processing Unit)

     • PoD (Point of Delivery / Performance-Optimized Datacenter): A
     modular unit within a data center that integrates compute, storage,
     and networking resources to deliver localized services.  PoDs are
     designed for scalability and performance optimization.

     • Scale-Up Network: A segment of the data center backend network
     optimized for intra-PoD communication, typically among up to 1,024
     accelerators.  It supports ultra-low latency operations through
     direct load/store memory access between accelerators.



  Jain, et al.              Expires 15 June 2026                  [Page 4]


  Internet-Draft            LISP Network AI Infra            December 2025


     • Scale-Out Network: A segment of the data center backend network
     designed for inter-PoD communication across clusters of thousands of
     accelerators.  It leverages RDMA (Remote Direct Memory Access) for
     efficient, high-throughput data transfer between distributed compute
     nodes.

     • Scale-Across Network: A segment of the data center backend network
     designed for inter-PoD communication across geographically separated
     data centers hosting clusters of thousands of accelerators.  It
     leverages RDMA (Remote Direct Memory Access), like Scale-Out but
     incorporates additional networking capabilities such as long-haul
     geographic distribution, congestion management, reliability and
     security over WAN.

     • INCC (In-Network Collective Communication): A technique that
     offloads collective communication operations to network switches to
     reduce data movement and improve performance.  These operations (such
     as AllReduce, Broadcast, Gather/Scatter, and AllToAll) are essential
     for synchronizing data across multiple compute nodes during
     distributed AI training.

  4.  AI Infra System Architecture

     The proposed architecture unifies Scale-Up, Scale-Out and Scale-
     Across fabrics under a LISP-based control plane to meet AI workload
     requirements.

     • Scale-Up Network: Handles intra-PoD traffic using non-IP
     accelerator identifiers (AccIDs), resolved to routable locators via
     the LISP Mapping System, ensuring ultra-low latency and predictable
     performance.

     • Scale-Out/Scale-Across Network: Interconnects PoDs using IP-based
     overlay communication with encapsulation and dynamic pub/sub updates,
     delivering high throughput and scalability.

     • Segmentation with Instance-IDs: Provides logical isolation between
     Scale-Up, Scale-Out and Scale-Across domains, supports in-network
     collective communication (INCC), and enables job or tenant-level
     segmentation for multi-tenant environments.

     • Reliability & Resilience: Achieved through multihoming,
     multipathing, and redundant mapping systems with fast pub/sub
     notifications to handle failures.

     • Deployment Flexibility: Operators can deploy Scale-Up only, Scale-
     Out only, or hybrid models without changing application logic, thanks
     to shared LISP control plane.



  Jain, et al.              Expires 15 June 2026                  [Page 5]


  Internet-Draft            LISP Network AI Infra            December 2025


     IP:10.0.0.1  IP:10.0.0.2                 IP:20.0.0.3  IP:20.0.0.4
      '--------'  '--------'                   '--------'  '--------'
      : AccID 1:  : AccID 2:                   : AccID 3:  : AccID 4:
      '--------'  '--------'                   '--------'  '--------'
          |     /\     |                           |     /\     |
      RLOC=IP_A1  RLOC=IP_A2                   RLOC=IP_B1  RLOC=IP_B2
      +-+--+--+    +-+--+--+                    +-+--+--+    +-+--+--+
     .| xTR A1|.-..| xTR A2|.-.                .| xTR B1|.-..| xTR B2|.-.
    ( +-+--+--+    +-+--+--+   )              ( +-+--+--+    +-+--+--+   )
    (         PoD A            )              (         PoD B            )
   (    +-------------------+   )            (    +-------------------+   )
    (   Scale-Up MS/MR & INCC  )              (   Scale-Up MS/MR & INCC  )
   (    +-------------------+ )              (    +-------------------+ )
    (     EID:10.0.0.0/16    )                (     EID:20.0.0.0/16    )
     (+-+--+--+    +-+--+--+)                  (+-+--+--+    +-+--+--+)
      | xTR A3|.-..| xTR A4|                    | xTR B3|.-..| xTR B4|
      +-+--+--+    +-+--+--+                    +-+--+--+    +-+--+--+
     RLOC=IP_A3    RLOC=IP_A4                  RLOC=IP_B3    RLOC=IP_B4
               \       |                            |       /
                .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
            .-.'                                            '.-.
           (             Scale-Out/Scale-Across Fabric          )
          (                   +--+--+   +-+---+                  )
         (                    |MS/MR|   |MS/MR|                   )
          (                   +-+---+   +-----+                  )
           (              (Mapping System with INCC)            )
            '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
              /        |                           |       \
     RLOC=IP_C3    RLOC=IP_C4                  RLOC=IP_D3   RLOC=IP_D4
      +-+--+--+    +-+--+--+                   +-+--+--+    +-+--+--+
     .| xTR C3|.-..| xTR C4|.-.               .| xTR D3|.-..| xTR D4|.-.
    ( +-+--+--+    +-+--+--+   )             ( +-+--+--+    +-+--+--+  )
    (         PoD C             )            (          PoD D           )
   (    +-------------------+    )          (    +-------------------+   )
    (   Scale-Up MS/MR & INCC   )            (   Scale-Up MS/MR & INCC  )
   (    +-------------------+  )            (    +-------------------+ )
    (     EID:30.0.0.0/16    )               (     EID:40.0.0.0/16    )
     (+-+--+--+    +-+--+--+)                 (+-+--+--+    +-+--+--+)
      | xTR C1|.-..| xTR C2|                   | xTR D1|.-..| xTR D2|
      +-+--+--+    +-+--+--+                   +-+--+--+    +-+--+--+
      RLOC=IP_C1  RLOC=IP_C2                   RLOC=IP_D1  RLOC=IP_D2
          |     \/     |                            |    \/     |
      '--------'  '--------'                   '--------'  '--------'
      : AccID 5:  : AccID 6:                   : AccID 7:  : AccID 8:
      '--------'  '--------'                   '--------'  '--------'
     IP:30.0.0.5  IP:30.0.0.6                 IP:40.0.0.7  IP:40.0.0.8

     Figure 1: AI Infra System with converged Scale-Up and Scale-Out



  Jain, et al.              Expires 15 June 2026                  [Page 6]


  Internet-Draft            LISP Network AI Infra            December 2025


     Figure 1 illustrates example system architecture of a data center AI
     infrastructure.  The system comprises four PoDs (A, B, C, and D),
     each equipped with a Scale-Up accelerator fabric, interconnected via
     a Scale-Out or Scale-Across fabric.  Each PoD includes xTRs (Tunnel
     Routers) that register accelerator EIDs with the LISP Mapping System,
     enabling seamless connectivity across the AI infrastructure for both
     inference and training applications.

     The recommended deployment model maps intra-PoD traffic (which may be
     non-IP) to the Scale-Up network, and inter-PoD traffic (typically
     inter-subnet IP) to the Scale-Out/Scale-Across network.  This
     document assumes this traffic mapping model when describing packet
     flows.

     To support this unified architecture, the control plane utilizes two
     primary types of EID-to-RLOC mappings for accelerators:

     • Scale-Up EID ⟨IID, AccID⟩ → RLOC ⟨IP⟩: Used for the Scale-Up
     network.  The AccID may be a non-IP identifier.

     • Scale-Out/Scale-Across EID ⟨IID, AccIP⟩ → RLOC ⟨IP⟩: The
     traditional LISP mapping, used for the Scale-Out/Scale-Across with
     IP-based addressing.

  5.  Scale-Out/Scale-Across Network Architecture

     The Figure 2 illustrates the Scale-Out//Scale-Across backend network
     architecture of Data Center's AI infrastructure.

     Since most inter-PoD design aspects are common to both Scale-Out and
     Scale-Across networks, the term “Scale-Out” will refer to both Scale-
     Out and Scale-Across throughout this document unless explicitly
     stated otherwise.


















  Jain, et al.              Expires 15 June 2026                  [Page 7]


  Internet-Draft            LISP Network AI Infra            December 2025


                PoD A                                    PoD B
             EID:10.0.0.0/16                          EID:20.0.0.0/16
         +-+--+--+    +-+--+--+                  +-+--+--+    +-+--+--+
         | xTR A3|.-..| xTR A4|                  | xTR B3|.-..| xTR B4|
         +-+--+--+    +-+--+--+                  +-+--+--+    +-+--+--+
         RLOC=IP_A3   RLOC=IP_A4                 RLOC=IP_B3   RLOC=IP_B4
                  \       |                           |       /
                   .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
               .-.'                                            '.-.
              (            Scale-Out/Scale-Across Fabric           )
             (               (RLOC Space Across PoDs)               )
             (            +----------------------------------+     )
            (               (Mapping System with INCC)              )
             (            +----------------------------------+       )
              (                  +--+--+   +-+---+                   )
             (                   |MS/MR|   |MS/MR|                  )
              (                  +-+---+   +-----+                 )
               '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
                 /        |                           |       \
         RLOC=IP_C3   RLOC=IP_C4                  RLOC=IP_D3   RLOC=IP_D4
         +-+--+--+    +-+--+--+                   +-+--+--+    +-+--+--+
         | xTR C3|.-..| xTR C4|                   | xTR D3|.-..| xTR D4|
         +-+--+--+    +-+--+--+                   +-+--+--+    +-+--+--+
             EID:30.0.0.0/16                          EID:40.0.0.0/16
                PoD C                                     PoD D

         Figure 2: Scale-Out/Scale-Across AI Infra Network Architecture

  5.1.  Scale-Out Registration and Fabric Paths

     Each PoD is assigned one (or more) unique IP subnet, which is
     provisioned and registered with both the Scale-Out and Scale-Up
     mapping systems by the xTRs/pxTRs participating in the Scale-Out
     network, as illustrated in Figure 2.  MAP-Register message format is
     as specified in [RFC9301] and [I-D.ietf-lisp-site-external-
     connectivity].  Additional Accelerator metadata MAY be encoded using
     vendor-specific LCAF types as defined in [RFC9306]

     Once registered or de-registered, these subnets changes are published
     to all remote xTRs/pxTRs participating in the Scale-Out network and
     to all local xTRs of Scale-Up network within the PoD, following the
     publication mechanisms outlined in [RFC9437] and [I-D.ietf-lisp-site-
     external-connectivity].  MAP-Notify/Publication message format is as
     specified in [RFC9301] and [I-D.ietf-lisp-site-external-
     connectivity].  Additional Accelerator metadata MAY be encoded in the
     MAP-Notify or Publication message formats using vendor-specific LCAF
     types [RFC9306].




  Jain, et al.              Expires 15 June 2026                  [Page 8]


  Internet-Draft            LISP Network AI Infra            December 2025


     Upon receipt, the published subnets are added to the map-cache
     (routing table) of each xTR or pxTR of both Scale-Out and Scale-Up
     domains, establishing forwarding paths toward the xTRs/pxTRs
     responsible for the respective subnet.

     Each accelerator's IP Address within a PoD is also registered with
     the local mapping system (Scale-Up MS/MR in Figure 1) by its
     associated xTR (RLOC).  Within the PoD, these registrations (~1024
     Accelerators) are published to all xTRs including remote xTRs/pxTRs,
     where they are added to the map-cache or routing table as the path to
     the registering xTRs.  Path change mechanisms (due to failures,
     congestions etc) are described in later sections.

  5.2.  Scale-Out Subscription and Publication

     When an accelerator connected via an ITR initiates communication with
     a remote accelerator, the ITR sends a Map-Request for the remote EID.
     The request includes the N-bit set in the EID-Record, indicating that
     the ITR wishes to be notified of any changes to the RLOC-set
     associated with that EID, as defined by the publish-subscribe
     mechanism [RFC9437].  MAP-Request/Subscription message format is as
     specified in [RFC9301] and [I-D.ietf-lisp-site-external-
     connectivity].  Additional Accelerator metadata MAY be encoded using
     vendor-specific LCAF types as defined in [RFC9306].

     Any xTR or pxTR in PoD that had subscribed to updates for the Scale-
     Out EID—via the Scale-Out Mapping System (e.g., Scale-Out MS/MR) or
     Scale-Up Local Mapping System (e.g., Scale-Up MS/MR)—receives a Map-
     Notify from the mapping systems.  This notification includes the
     updated RLOC-set (e.g., addition or removal of locators), as
     specified in the Mapping Notification Publish Procedures in
     [RFC9437].  MAP-Notify/Publication message format is as specified in
     [RFC9301] and [I-D.ietf-lisp-site-external-connectivity].  Additional
     Accelerator metadata MAY be encoded in the MAP-Notify or Publication
     message formats using vendor-specific LCAF types [RFC9306].

     Upon receipt, the published EID is added to the map-cache (routing
     table) of each xTR or pxTR, establishing forwarding paths toward the
     xTR(s) responsible for the respective EID.

     When a destination accelerator is either undiscovered or deregistered
     in the Mapping System, it is treated as an Unknown Accelerator.  In
     such cases, the Map-Server SHOULD respond to a Map-Request or
     subscription targeting the unknown accelerator with a Negative Map-
     Reply specifying the action "Drop" as in [RFC9301] and [I-D.ietf-
     lisp-site-external-connectivity].





  Jain, et al.              Expires 15 June 2026                  [Page 9]


  Internet-Draft            LISP Network AI Infra            December 2025


  5.3.  Scale-Out Packet Flow

     Inter-PoD traffic is encapsulated using Layer 3 (L3) encapsulation,
     following the procedures defined in [RFC9300], [RFC9301], and
     [RFC9437].  It is assumed that the accelerator in PoD A is aware of
     the EID (IP address) of the destination accelerator in PoD D—this may
     be obtained via packet inspection, address resolution, or
     provisioning.  The following example illustrates a unicast packet
     flow and the associated control plane operations for the topology
     shown in Figure 1, where an accelerator in PoD A communicates with an
     accelerator in PoD D:

     • Fabric paths across PoDs are established as described in
     Section 4.1.

     • Within a PoD, each accelerator (Scale-Out EID eg 40.0.07) is also
     registered with the local mapping system (Scale-Up MS/MR in Figure 1)
     by its associated xTRs (RLOCs IP_D1 & IP_D2) as described in
     Section 4.1.  These registrations (mapping 40.0.0.7->IPD1 & IPD2) are
     published to all xTRs/pxTRs within the PoD D, where they are added to
     the map-cache or routing table as the path towards the registering
     xTRs D! & D2 for Accelerator 40.0.0.7.  Accelerators, unknown or
     external to PoD are registered as pETRs to local mapping system, as
     defined in [I-D.ietf-lisp-site-external-connectivity].

     • Accelerator 1 in PoD A sends an IP packet with source
     address 10.0.0.1 and destination address 40.0.0.7.  Since the
     destination lies in a different subnet, the local xTR in PoD A
     forwards the packet based on its map-cache/routing table to pxTR A3,
     which acts as the default gateway for the PoD. pxTR A3 then forwards
     the packet to xTR D3, using its map-cache entry that contains the
     subnet information for PoD D, as published by the Scale-Out mapping
     system described in section 4.1.

     • xTR/pxTR D3 performs a Layer 3 lookup in its local map-cache for
     the destination IP 40.0.0.7.  Since Accelerator 7 is registered with
     the local mapping system and is published in PoD D, xTR D3 has a
     valid map-cache entry pointing to xTR D1 and D2 (with
     RLOCs IP_D1 and IP_D2).

     • xTR D3 encapsulates the packet using LISP, setting the destination
     RLOC to either IP_D1 or IP_D2, depending on the load-balancing or
     redundancy policy.








  Jain, et al.              Expires 15 June 2026                 [Page 10]


  Internet-Draft            LISP Network AI Infra            December 2025


  5.4.  Scale-Out Path Change

     When the Publish/Subscribe mechanism [RFC9437] is used, the signaling
     flow to manage accelerator path changes (due to any failure,
     congestion etc) proceeds as follows:

     • Registration: Upon attachment of Accelerator 7 to PoD D, the local
     ETR D1/D2 updates its local database with the mapping for the
     EID <IID1, 40.0.0.7>.  The ETR then sends a Map-Register message to
     the local mapping system, registering its RLOCs (e.g., IP_D1, IP_D2)
     as locators for the EID.  The mapping system is updated with this
     EID-to-RLOC association.

     • First Communication Request/Subscription: When Accelerator 1
     connected via an ITR A1 initiates communication with a remote
     Accelerator 7, the ITR sends a Map-Request for the remote EID.  The
     request includes the N-bit set in the EID-Record, indicating that the
     ITR wishes to be notified of any changes to the RLOC-set associated
     with that EID, as described in section 4.2.

     • Deregistration: When Accelerator 7 is detached, the mapping system
     receives a deregistration message for the EID <IID1, 40.0.0.7> from
     ETR D1.  It then sends a Map-Notify to ETR D1 to confirm the
     deregistration.  ETR D1 subsequently removes the local mapping entry
     and ceases to advertise the EID.

     • Notification/Publication: Any xTR or pxTR in PoD D (or elsewhere)
     that had subscribed to updates for the EID <IID1, 40.0.0.7>—typically
     via the local mapping system (e.g., Scale-Up MS/MR)—receives a Map-
     Notify from the mapping system.  This notification includes the
     updated RLOC-set (e.g., addition or removal of locators), as
     specified in the Mapping Notification Publish Procedures in
     [RFC9437].

     • Map-Cache Update: Upon receiving the Map-Notify, the subscribing
     ITR (e.g., xTR D3) updates its local map-cache or routing table to
     reflect the new RLOC-set for the EID (Acccelerator 7/40.0.0.7).  For
     example, if IP_D1 is removed for Accelerator 7 (40.0.0.7), xTR D3
     stops forwarding traffic to that locator (IP_D1), ensuring accurate
     and up-to-date routing behavior.

  5.5.  Deployment Considerations









  Jain, et al.              Expires 15 June 2026                 [Page 11]


  Internet-Draft            LISP Network AI Infra            December 2025


  5.5.1.  Scale-Out Segmentation and INCC

     LISP Scale-Out segmentation is based on the use and propagation of
     Instance-IDs (IIDs), which are treated as part of the EID in control
     plane operations.  The encoding format for IIDs is defined in
     [RFC8060].  Instance-IDs are unique within a given Mapping System and
     MAY be used to distinguish between Scale-Up and Scale-Out domains.

     A key aspect of Scale-Out segmentation is the ability to associate
     In-Network Collective Communication (INCC) groups with specific IIDs.
     In this model, an INCC domain—functionally equivalent to a Virtual
     Forwarding (VRF) instance—can be mapped to a corresponding IID
     representing a Scale-Out domain.  Alternatively, each INCC group may
     be mapped in a 1:1 relationship with a unique Scale-Out segment
     instance.

     This use of Instance-IDs enables support for multiple Scale-Out
     segments, similar to extended VRFs or multi-VPN, as described in [I-
     D.ietf-lisp-vpn].

  5.5.2.  Scale-Out Mappings

     When an accelerator is attached or detected in an ETR that provides
     Scale-Out services and path change, Scale-Out Mappings are registered
     to the mapping system with the following structures:

     * The EID 2-tuple (IID, Acc-IP Address) with its binding to a
     corresponding ETR locator set (RLOC IP Address).

     * The EID 2-tuple (IID, Acc-IP Subnet) with its binding to a
     corresponding pETR locator set (RLOC IP Address).

     The registration of these Accelerator/Subnet EIDs MUST follow the
     LCAF format as defined in [RFC8060] with the specific EID record as
     specified in [RFC9301] and can be used with pETR registration [I-
     D.ietf-lisp-site-external-connectivity].

  5.5.3.  Scale-Out Mapping System (MS/MR)

     Scale-Out (across PoDs) Mapping System also uses services from Scale-
     Up Mapping Systems (within PoDs) to establish end to end Scale-Out
     network of Accelerators.









  Jain, et al.              Expires 15 June 2026                 [Page 12]


  Internet-Draft            LISP Network AI Infra            December 2025


     The interface between xTRs/pxTRs and the Mapping System follows the
     procedures defined in [RFC9301] and [I-D.ietf-lisp-site-external-
     connectivity].  The addition and removal of subnets are handled
     through pxTR registration/deregistration and publication processes,
     as described in Section 4.1 and Section 4.5.2.  Mapping System MAY be
     implemented as a distributed mapping system to avoid single point of
     failure.

     To support system convergence following an accelerator or subnet path
     change, the local Mapping System (Scale Up MS/MR) MUST also send a
     Map-Notify message to the full RLOC set—including all relevant
     pxTRs—within the PoD where the affected EID was last registered.
     This notification is triggered upon receiving a registration update
     for that specific accelerator or subnet EID.  The Map-Notify serves
     to indicate the unavailability or change in the accelerator’s path,
     as detailed in Section 4.3.

  5.5.4.  Scale-Out Unknown Accelerators

     When a destination accelerator is either undiscovered or deregistered
     in the Mapping System, it is treated as an Unknown Accelerator.  In
     such cases, the Map-Server SHOULD respond to a Map-Request or
     subscription targeting the unknown accelerator with a Negative Map-
     Reply specifying the action "Drop" as per [RFC9301] and [I-D.ietf-
     lisp-site-external-connectivity].

     Alternatively, the forwarding plane may be configured to default to
     the "Drop" action for Unknown Accelerators, thereby suppressing any
     forwarding attempts toward unregistered or unreachable destinations

  6.  Scale-Up Network Architecture

     Scale Up network architecture is as shown in Figure 3.  This section
     uses PoD C & PoD D to describe the details.

















  Jain, et al.              Expires 15 June 2026                 [Page 13]


  Internet-Draft            LISP Network AI Infra            December 2025


              /        |                           |       \
      RLOC=IP_C3   RLOC=IP_C4                  RLOC=IP_D3   RLOC=IP_D4
      +-+--+--+    +-+--+--+                   +-+--+--+    +-+--+--+
     .| xTR C3|.-..| xTR C4|.-.               .| xTR D3|.-..| xTR D4|.-.
    ( +-+--+--+    +-+--+--+   )             ( +-+--+--+    +-+--+--+   )
    (         PoD C            )             (          PoD D           )
   (    +-------------------+   )           (   +--------------------+   )
    (   Scale-Up MS/MR & INCC  )             (  Scale-Up MS/MR & INCC   )
   (    +-------------------+ )             (   +--------------------+ )
    (     EID:30.0.0.0/16    )               (     EID:40.0.0.0/16    )
     (+-+--+--+    +-+--+--+)                 (+-+--+--+    +-+--+--+)
      | xTR C1|.-..| xTR C2|                   | xTR D1|.-..| xTR D2|
      +-+--+--+    +-+--+--+                   +-+--+--+    +-+--+--+
      RLOC=IP_C1  RLOC=IP_C2                   RLOC=IP_D1  RLOC=IP_D2
          |     \/     |                            |    \/     |
      '--------'  '--------'                   '--------'  '--------'
      :  Acc   :  :  Acc   :                   :  Acc   :  :  Acc   :
      :  ID 5  :  :  ID 6  :                   :  ID 7  :  :  ID 8  :
      '--------'  '--------'                   '--------'  '--------'
     IP:30.0.0.5  IP:30.0.0.6                 IP:40.0.0.7  IP:40.0.0.8

    Figure 3: Scale-Up AI Infra Network Architecture

  6.1.  Scale-Up Registration

     Each accelerator within a PoD is registered by its associated xTR(s)
     (RLOCs) using its AccID as the Scale-Up EID, with the registration
     sent to the local mapping system (Scale-Up MS/MR shown in Figure 3).
     The AccID MAY be a non-IP identifier and MAY be encoded using the
     LISP Name Encoding format defined in [RFC9735].  MAP-Register message
     format is as specified in [RFC9301].  Additional Accelerator metadata
     MAY be encoded using vendor-specific LCAF types as defined in
     [RFC9306].

     The local mapping system then publishes the EID-to-RLOC mappings
     (i.e., AccID to xTR(s)) to all subscribed and authorized xTRs within
     the PoD, in accordance with [RFC9437].  MAP-Notify/Publication
     message format is as specified in [RFC9301].  Additional Accelerator
     metadata MAY be encoded in the MAP-Notify or Publication message
     formats using vendor-specific LCAF types [RFC9306].  These published
     mappings are subsequently added to the map-cache or routing table of
     remote xTRs/pxTRs within the same PoD, establishing the forwarding
     path to the registering xTR(s).








  Jain, et al.              Expires 15 June 2026                 [Page 14]


  Internet-Draft            LISP Network AI Infra            December 2025


  6.2.  Scale-Up Subscription and Publication

     When an accelerator connected via an ITR initiates communication with
     a remote accelerator, the ITR sends a Map-Request for the remote EID.
     The request includes the N-bit set in the EID-Record, indicating that
     the ITR wishes to be notified of any changes to the RLOC-set
     associated with that EID, as defined by the publish-subscribe
     mechanism [RFC9437].  MAP-Request/Subscription message format is as
     specified in [RFC9301] and [I-D.ietf-lisp-site-external-
     connectivity].  Additional Accelerator metadata MAY be encoded using
     vendor-specific LCAF types as defined in [RFC9306].

     Any xTR or pxTR in PoD that had subscribed to updates for the EID
     —via the Scale-Up Mapping System (e.g., Scale-Up MS/MR)— receives a
     Map-Notify from the mapping system.  This notification includes the
     updated RLOC-set (e.g., addition or removal of locators), as
     specified in the Mapping Notification Publish Procedures in
     [RFC9437].  MAP-Notify/Publication message format is as specified in
     [RFC9301] and [I-D.ietf-lisp-site-external-connectivity].  Additional
     Accelerator metadata MAY be encoded in the MAP-Notify or Publication
     message formats using vendor-specific LCAF types [RFC9306].

     Upon receipt, the published EID is added to the map-cache (routing
     table) of each xTR or pxTR, establishing forwarding paths toward the
     xTR(s) responsible for the respective EID.

     When a destination accelerator is either undiscovered or deregistered
     in the Mapping System, it is treated as an Unknown Accelerator.  In
     such cases, the Map-Server SHOULD respond to a Map-Request or
     subscription targeting the unknown accelerator with a Negative Map-
     Reply specifying the action "Drop" as per [RFC9301] and [I-D.ietf-
     lisp-site-external-connectivity]..

  6.3.  Scale-Up Packet Flow

     Scale-Up packet (could be non-IP) utilizes Scale-Up technology (e.g.,
     PCIe or Ethernet) and is encapsulated accordingly.  This section
     illustrates an example of Scale-Up unicast packet flow and the
     associated control plane operations, based on the topology shown in
     Figure 3.  In this scenario, Accelerator 7 in PoD D communicates with
     Accelerator 8, also located in PoD D.  It is assumed that Accelerator
     7 is aware of Accelerator 8’s AccID (e.g., learned via packet
     exchange, dynamic resolution, or a management interface).

     • Each Accelerator within a PoD is registered by its xTRs (RLOCs)
     using its AccID (e.g., AccID 7, AccID 8) as the EID, as described in
     Section 5.1.




  Jain, et al.              Expires 15 June 2026                 [Page 15]


  Internet-Draft            LISP Network AI Infra            December 2025


     • If a path is not pre-established (e.g. default or during
     provisioning), when Accelerator 7 (connected via xTR D1) initiates
     communication with Accelerator 8 (connected via xTR D2), ITR D1
     issues a Map-Request for Accelerator 8.  Following the Mapping
     Request Subscribe Procedures defined in [RFC9437], the Map-Request
     includes the N-bit set on the EID-Record to ensure the ITR is
     notified of the mapping and any RLOC-set changes for the Accelerator.

     • The local mapping system publishes all the AccID-to-xTR(s) mappings
     (EID-to-RLOC(s)) to subscribing xTRs/pxTRs.  These subscribing xTRs/
     pxTRs then establish a path to the registering xTR(s) within the PoD,
     as outlined in Section 5.1.

     • When Accelerator 7 sends a Scale-Up packet, it includes the
     destination AccID 8 and source AccID 7, in accordance with [RFC9300]
     and [RFC9301].

     • ITR D1 performs a lookup in its local map-cache for the destination
     AccID 8.

     • Since ITR D1 already has the EID-to-RLOC mapping for AccID 8
     (pointing to xTR D2), it encapsulates all subsequent packets to AccID
     8 using destination RLOC IP_D2 and source RLOC IP_D1.

  6.4.  Scale-Up Path Change

     This section describes the mechanism for handling path changes of an
     accelerator within a PoD due to failure, upgrade, congestion etc,
     while maintaining uninterrupted communication among accelerators
     connected via multipath in the same Scale-Up domain.  The mechanism
     ensures fast convergence of the Scale-Up network when an
     accelerator’s path changes.  Updates to ITR map-caches are managed
     using the Publish/Subscribe mechanisms defined in [RFC9437].  The
     following steps outline the signaling and packet flow when the link
     between Accelerator 8 and xTR D2 (as shown in Figure 3) becomes
     unavailable due to congestion, link failure, or other issues:

     • Initially, when Accelerator 7 (connected via ITR D1) establishes
     communication with Accelerator 8, ITR D1 issues a Map-Request for
     Accelerator 8.  In accordance with the Mapping Request/Subscribe
     Procedures defined in [RFC9437], the Map-Request includes the N-bit
     set on the EID-Record to enable notification of any RLOC-set changes
     for Accelerator 8.








  Jain, et al.              Expires 15 June 2026                 [Page 16]


  Internet-Draft            LISP Network AI Infra            December 2025


     • When Accelerator 8 experiences a path change within PoD D (e.g.,
     the link to xTR D2 becomes unavailable or congested), ETR D2 removes
     the local mapping for Accelerator 8’s EID ⟨IID, AccID 8⟩. It then
     sends a Map-Deregister message to the local mapping system,
     deregistering RLOC IP_D2 as a locator for that EID.

     • Upon receiving the deregistration, the mapping system updates the
     locator set for Accelerator 8’s EID by removing IP_D2 and sends a
     Map-Notify back to ETR D2.  ETR D2 then deletes the mapping from its
     local database and ceases registration for ⟨IID, AccID 8⟩.

     • Any ITR or PiTR participating in the same Scale-Up domain
     (associated with IID) that was previously encapsulating traffic to
     AccID 8 would have subscribed to receive updates on RLOC-set changes.
     The local mapping system publishes the updated locator set to these
     subscribers by sending Map-Notify messages, as defined in the Mapping
     Notification Publish Procedures in [RFC9437].

     • Upon receiving the Map-Notify, the ITR updates its local map-cache
     for EID ⟨IID, AccID 8⟩. Once the cache is updated, traffic is
     redirected and tunneled to the new xTRs (e.g., xTR D1), and traffic
     via xTR D2 is halted.

  6.5.  Deployment Considerations

  6.5.1.  Scale-Up Segmentation and INCC

     Similar to Scale-Out segmentation, LISP Scale-Up segmentation is
     based on the propagation and use of Instance-IDs (IIDs), which are
     treated as part of the EID in control plane operations.  The encoding
     of Instance-IDs is defined in [RFC8060].  These IIDs are unique
     within a Mapping System and may be used to distinguish between Scale-
     Up and Scale-Out domains.

     A key aspect of Scale-Up segmentation is the potential mapping of
     INCC groups to Instance-IDs.  In this context, an INCC
     Domain—functionally equivalent to a VRF as a forwarding context—can
     be mapped to an IID representing a Scale-Up domain.  Alternatively,
     an INC group may be mapped directly in a one-to-one relationship with
     a Scale-Up segment instance.

     Instance-IDs enable support for multiple Scale-Up segments, similar
     to extended VRFs or multi-VPN, as described in [I-D.ietf-lisp-vpn].








  Jain, et al.              Expires 15 June 2026                 [Page 17]


  Internet-Draft            LISP Network AI Infra            December 2025


  6.5.2.  Scale-Up Mappings

     When an accelerator is attached to or detached from an ETR providing
     Scale-Up services, a corresponding Scale-Up EID is registered or
     deregistered with the mapping system.  The Scale-Up mapping follows
     this structure:

     • EID Tuple: The Endpoint Identifier is represented as a
     2-tuple (IID, AccID), where:

     • AccID may be a non-IP identifier.  If the AccID is non-IP based,
     it may be encoded using the mechanisms described in [RFC9735].

     • The structure of the Accelerator EID record adheres to the format
     defined in [RFC9301].

     • The AccID is bound to a locator set consisting of one or more IP
     RLOCs.

  6.5.3.  Scale-Up Mapping System (MS/MR)

     The interface between xTRs and the Mapping System is defined in
     [RFC9301].  All accelerators are registered with the local Scale-Up
     Mapping System.  Mapping System MAY be implemented as a distributed
     mapping system to avoid single point of failure.

     To support rapid system convergence following a path change, the Map-
     Server MUST send a Map-Notify to the entire RLOC set within the PoD
     that last registered the same EID, as well as to any xTRs in the PoD
     that have subscribed to that EID.  This Map-Notify serves to track
     changes in the path of Accelerator EIDs, as described in Section 5.3.

  6.5.4.  Scale-Up Unknown Accelerators

     When a destination accelerator is either undiscovered or deregistered
     in the Mapping System, it is treated as an Unknown Accelerator.  In
     such cases, the Map-Server SHOULD respond to a Map-Request or
     subscription targeting the unknown accelerator with a Negative Map-
     Reply specifying the action "Drop".

     Alternatively, the forwarding plane may be configured to default to
     the "Drop" action for Unknown Accelerators, thereby suppressing any
     forwarding attempts toward unregistered or unreachable destinations.








  Jain, et al.              Expires 15 June 2026                 [Page 18]


  Internet-Draft            LISP Network AI Infra            December 2025


  6.5.5.  IP Forwarding of Scale-Up Traffic

     Providing non-IP extensions to cloud platforms is not always
     feasible.  As a result, ip/subnets might need to be used and extended
     using Layer 3 (L3) to support intra PoD traffic as well.

  7.  Multihoming & Multipaths

     Multihoming support relies on the mechanisms defined in [RFC9300] and
     [RFC9301] to enable LISP-based multihoming for accelerators within a
     backend network.  To illustrate the multihoming packet flow, this
     section references Figure 3.  For example, in Figure 3, xTRs D1 and
     D2 within PoD D provide multihoming services for Accelerators 7 and
     8.

  7.1.  Multihomed Accelerators Registration

     The Site-ID, as defined in [RFC9301], serves as an identifier for
     logically grouping multiple xTRs that provide multihoming within a
     Scale-Up domain (e.g., a PoD).  All EID-to-RLOC mappings from ETRs in
     a multihomed Scale-Up PoD MUST be registered with the corresponding
     Site-ID (e.g., PoD ID) by setting the 'I' bit in the Map-Register
     message.

  7.2.  Multihoming xTRs/RLOCs Merging

     Supporting multihoming requires that participating xTRs discover one
     another and implement multipath forwarding procedures.  This is
     achieved through the registration of a common accelerator EID by all
     participating xTRs.  Each registration includes the PoD ID as the 
     Site-ID, indicating the PoD in which multihoming is being provided.
     The Mapping System merges these registrations and notifies all
     participating xTRs with the aggregated locator set.
     Using Figure 3 as a reference, the xTR discovery process in a
     multihomed Scale-Up group proceeds as follows:

     • xTR D1 registers the EID "POD-D-AccID-7" with its locator set
     containing IP_D1.

     • The Map-Server creates a mapping entry: EID ("POD-D-AccID-7") →
     RLOC (IP_D1), and sends a Map-Notify to xTR D1 with this mapping.

     • xTR D2 then registers the same EID "POD-D-AccID-7" with its locator
     set containing IP_D2.







  Jain, et al.              Expires 15 June 2026                 [Page 19]


  Internet-Draft            LISP Network AI Infra            December 2025


     • The Map-Server merges this new registration with the existing one,
     resulting in: EID ("POD-D--AccID-7") → RLOC {IP_D1, IP_D2}. It then
     sends a Map-Notify to both xTR D1 and xTR D2 with the updated locator
     set.

     • Whenever an xTR joins or leaves a multihoming group, the Map-Server
     MUST send an updated Map-Notify to all remaining participating xTRs
     to ensure they maintain an accurate and synchronized view of the
     locator set.  As a result, all participating xTRs maintain an up-to-
     date view of the multihomed group, enabling coordinated multipath
     forwarding.

  7.3.  Multihoming/Multipath forwarding

     In a PoD, both Scale-Out and Scale-Up xTRs can be used to provide
     multihomed access and forward traffic to and from remote PoDs or
     accelerators.  Unicast traffic is typically load-balanced or sprayed
     across the multiple xTRs that have registered the accelerator's EID.
     In multicast scenarios, only the designated Scale-Up xTR may join the
     multicast group or replication list.  If a Scale-Out xTR chooses to
     join the multicast group, it MUST implement split-horizon filtering
     and ensure that traffic from PoD is not forwarded back into the PoD,
     in order to prevent duplication. xTRs providing active multihoming
     access to a PoD’s accelerators MUST support the following:

     • Registration: All active xTRs must register the PoD’s Scale-Up
     mappings with the Mapping System.  Each registration must include
     the 'I' bit set and carry both the Site-ID (PoD ID) and the
     corresponding xTR-ID.

     • Multicast forwarding: Only the selected Scale-Up xTR joins the
     Scale-Up multicast group or replication list.

     • Broadcast Forwarding: Only the designated Scale-Out xTR is
     permitted to forward broadcast traffic to and from remote PoDs.

  8.  Data Plane Encapsulation Options

     The LISP control plane is decoupled from the data plane
     encapsulation, allowing flexibility in the choice of encapsulation
     formats for Scale-Up and Scale-Out. Common encapsulation formats
     include VXLAN-GPE, LISP, and VXLAN:

     • VXLAN-GPE Encapsulation: Defined in [RFC9305], VXLAN-GPE supports
     encapsulation of both Scale-Up and Scale-Out packets.  The VNI
     field directly maps to the Instance-ID used in the LISP control
     plane.  For unified deployments, the P-bit is set, and the Next-
     Protocol field is used to indicate the payload type.



  Jain, et al.              Expires 15 June 2026                 [Page 20]


  Internet-Draft            LISP Network AI Infra            December 2025


     • LISP Encapsulation: As specified in [RFC9300], this format also
     supports encapsulation of both Scale-Up and Scale-Out packets.  The 
     Instance-ID embedded in the EID maps directly to the Instance-ID in
     the LISP header.  Upon decapsulation at the ETR, the IID may be used
     to determine whether the packet should be processed as part of a
     Scale-Up or Scale-Out flow.

     Any alternative encapsulation format optimized for backend networks,
     capable of supporting a 24-bit Instance-ID, MAY be used to deploy
     Scale-Up, Scale-Out, or unified network data planes.

  9.  IANA Considerations

     No new IANA considerations apply to this document.

  10.  Security Considerations

     There are no additional security considerations except what already
     discussed in [RFC9301].

  11.  Acknowledgements

     This draft builds on top of many LISP RFCs and drafts.  Many thanks
     to the combined authors of those RFC and drafts.

  12.  Normative References

     [I-D.ietf-lisp-site-external-connectivity]
                Jain, P., Moreno, V., and S. Hooda, "LISP Site External
                Connectivity", Work in Progress, Internet-Draft, draft-
                ietf-lisp-site-external-connectivity-02, 28 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
                site-external-connectivity-02>.

     [I-D.ietf-lisp-vpn]
                Moreno, V. and D. Farinacci, "LISP Virtual Private
                Networks (VPNs)", Work in Progress, Internet-Draft, draft-
                ietf-lisp-vpn-12, 19 September 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
                vpn-12>.

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






  Jain, et al.              Expires 15 June 2026                 [Page 21]


  Internet-Draft            LISP Network AI Infra            December 2025


     [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
                Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
                February 2017, <https://www.rfc-editor.org/info/rfc8060>.

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

     [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
                Cabellos, Ed., "The Locator/ID Separation Protocol
                (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
                <https://www.rfc-editor.org/info/rfc9300>.

     [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
                Ed., "Locator/ID Separation Protocol (LISP) Control
                Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
                <https://www.rfc-editor.org/info/rfc9301>.

     [RFC9305]  Maino, F., Ed., Lemon, J., Agarwal, P., Lewis, D., and M.
                Smith, "Locator/ID Separation Protocol (LISP) Generic
                Protocol Extension", RFC 9305, DOI 10.17487/RFC9305,
                October 2022, <https://www.rfc-editor.org/info/rfc9305>.

     [RFC9306]  Rodriguez-Natal, A., Ermagan, V., Smirnov, A., Ashtaputre,
                V., and D. Farinacci, "Vendor-Specific LISP Canonical
                Address Format (LCAF)", RFC 9306, DOI 10.17487/RFC9306,
                October 2022, <https://www.rfc-editor.org/info/rfc9306>.

     [RFC9437]  Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
                S., and M. Boucadair, "Publish/Subscribe Functionality for
                the Locator/ID Separation Protocol (LISP)", RFC 9437,
                DOI 10.17487/RFC9437, August 2023,
                <https://www.rfc-editor.org/info/rfc9437>.

     [RFC9735]  Farinacci, D. and L. Iannone, Ed., "Locator/ID Separation
                Protocol (LISP) Distinguished Name Encoding", RFC 9735,
                DOI 10.17487/RFC9735, February 2025,
                <https://www.rfc-editor.org/info/rfc9735>.

  Authors' Addresses

     Prakash Jain
     MIPS
     San Jose, CA
     United States of America
     Email: prjain@mips.com





  Jain, et al.              Expires 15 June 2026                 [Page 22]


  Internet-Draft            LISP Network AI Infra            December 2025


     Sanjay Hooda
     Cisco Systems
     San Jose, CA
     United States of America
     Email: shooda@cisco.com


     Durgesh Srivastava
     DataraAI
     Cupertino, CA
     United States of America
     Email: durgesh@DataraAI.ai


     Padma Pillay-Esnault
     Independent
     San Jose, CA
     United States of America
     Email: padma.ietf@gmail.com


     Victor Moreno
     Google
     Mountainview, CA
     United States of America
     Email: vimoreno@google.com

























  Jain, et al.              Expires 15 June 2026                 [Page 23]


name: draft-dunbar-neotec-ac-pe2pe-ucmp-applicability
rev: 01
title: Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies Use Case
time: 2025-12-25T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-12-25T05:48:41Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:11.000793+00:00
abstract:
  This document explores how existing IETF YANG data models can be
     applied to support a use case involving dynamic, time-scoped UCMP
     (Unequal Cost Multipath) policy enforcement across multiple network
     segments interconnecting Edge Cloud sites.  The use case is motivated
     by periodic, high-volume data exchanges between distributed AI
     inference modules placed at geographically dispersed edge data
     centers.  By mapping network requirements such as bandwidth, latency,
     and availability to relevant YANG models, including AC, TE Topology,
     SR Policy, and QoS models, this document serves as a practical
     exercise to evaluate the applicability and limitations of current
     IETF specifications.  It highlights the need for cloud-initiated,
     time-bounded network policy activation and identifies potential gaps
     in model expressiveness, policy lifecycle handling, and API-level
     abstraction required for real-time cloud-network coordination.

full_text:
  NeoTec                                                    L. Dunbar, Ed.
  Internet-Draft                                                 Futurewei
  Intended status: Informational                                    Q. Sun
  Expires: 24 December 2025                                  China Telecom
                                                                B. Wu, Ed.
                                                                    Huawei
                                                  L. CONTRERASMURILLO, Ed.
                                                               Telefornica
                                                                    C. Xie
                                                             China Telecom
                                                              22 June 2025


  Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies
                                  Use Case
             draft-dunbar-neotec-ac-pe2pe-ucmp-applicability-01

  Abstract

     This document explores how existing IETF YANG data models can be
     applied to support a use case involving dynamic, time-scoped UCMP
     (Unequal Cost Multipath) policy enforcement across multiple network
     segments interconnecting Edge Cloud sites.  The use case is motivated
     by periodic, high-volume data exchanges between distributed AI
     inference modules placed at geographically dispersed edge data
     centers.  By mapping network requirements such as bandwidth, latency,
     and availability to relevant YANG models, including AC, TE Topology,
     SR Policy, and QoS models, this document serves as a practical
     exercise to evaluate the applicability and limitations of current
     IETF specifications.  It highlights the need for cloud-initiated,
     time-bounded network policy activation and identifies potential gaps
     in model expressiveness, policy lifecycle handling, and API-level
     abstraction required for real-time cloud-network coordination.

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



  Dunbar, et al.          Expires 24 December 2025                [Page 1]


  Internet-Draft                 Neotec API                      June 2025


     This Internet-Draft will expire on 24 December 2025.

  Copyright Notice

     Copyright (c) 2025 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
     2.  Conventions used in this document . . . . . . . . . . . . . .   5
     3.  Dynamic UCMP Load Balancing for Periodic Inter Site AI
             Traffic . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  UCMP Enforcement for Access Segment . . . . . . . . . . .   6
       3.2.  UCMP Enforcement for SRv6 based PE to PE segment  . . . .  11
       3.3.  UCMP Enforcement for PE to PE segment in Non-SRv6
             networks  . . . . . . . . . . . . . . . . . . . . . . . .  12
         3.3.1.  UCMP over MPLS-TE . . . . . . . . . . . . . . . . . .  12
         3.3.2.  UCMP Over Plain IP (ECMP) . . . . . . . . . . . . . .  13
     4.  Cloud-Initiated UCMP Activation API . . . . . . . . . . . . .  16
     5.  Gaps Analysis . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.1.  Access Segment Gaps Analysis  . . . . . . . . . . . . . .  17
       5.2.  PE to PE Segment Gaps Analysis  . . . . . . . . . . . . .  17
       5.3.  Complexity of Hop-by-Hop UCMP Configuration in IP
             Networks  . . . . . . . . . . . . . . . . . . . . . . . .  18
       5.4.  Inter-Domain Coordination Gaps Analysis . . . . . . . . .  18
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20








  Dunbar, et al.          Expires 24 December 2025                [Page 2]


  Internet-Draft                 Neotec API                      June 2025


  1.  Introduction

     Edge computing enables latency-sensitive applications such as AI
     inference to be deployed closer to end users and data sources.  In
     many deployments, AI workloads are dynamically instantiated across
     multiple Edge Cloud sites based on compute availability, proximity to
     data sources, and overall service objectives.  These distributed AI
     inference modules often need to exchange large volumes of data
     periodically, for example, during model synchronization, aggregated
     result sharing, or collaborative analytics.

     These inter-site data exchanges typically require high bandwidth and
     low latency for short, well-defined time windows.  However, most
     transport networks are optimized for long-lived, static flows and do
     not natively support time-scoped policy enforcement.  Furthermore,
     existing routing mechanisms like Equal Cost Multipath (ECMP) are
     insufficient for granular traffic distribution when link costs and
     available bandwidth are unequal.  As a result, Unequal Cost Multipath
     (UCMP) techniques have emerged to enable more efficient load
     balancing across heterogeneous paths.

     This document focuses on the application of dynamic, cloud-initiated
     UCMP policy updates across multiple segments of the network
     interconnecting Edge Cloud sites.  It assumes the network supports
     multiple paths between sites and that these paths can be selected or
     weighted based on real-time performance metrics (e.g., latency,
     available bandwidth, load).
























  Dunbar, et al.          Expires 24 December 2025                [Page 3]


  Internet-Draft                 Neotec API                      June 2025


               +---------------------+              +---------------------+
               |   Edge Cloud Site A |              |   Edge Cloud Site B |
               +---------------------+              +---------------------+
                          |                                    |
            +-------------+-------------+         +------------+-------------+
            |     Access PE / Gateway   |         |     Access PE / Gateway  |
            +-------------+-------------+         +------------+-------------+
                          \                                    /
                           \                                  /
                              \                          /
                               \                        /
                                \                      /
                      Multiple Provider Transport Segments
                            (with dynamic UCMP policies)
                                /                      \
                               /                        \
                              /                          \
                           /                              \
            +-------------+-------------+         +------------+-------------+
            |     Access PE / Gateway   |         |     Access PE / Gateway  |
            +-------------+-------------+         +------------+-------------+
                          |                                    |
               +---------------------+              +---------------------+
               |   Edge Cloud Site C |              |   Edge Cloud Site D |
               +---------------------+              +---------------------+

                           Periodic AI Traffic Exchange
                      requires time scoped dynamic UCMP adjustments


             Figure 1: Network Segments for AI Data Exchange

     The primary goal of this work is to:

     - Demonstrate how IETF defined YANG data models, such as ietf-
     routing, ietf-ac, ietf-te-topology, ietf-qos-policy, and ietf-sr-
     policy, can be used to realize dynamic UCMP enforcemen.

     - Highlight the requirements for time-scoped policy activation and
     cloud-initiated triggers, which are not natively supported in
     existing models.

     - Propose augmentations or extensions needed to support temporary
     policy enforcement tied to cloud workload events.

     - Identify architectural and modeling gaps that must be addressed to
     enable closed-loop coordination between cloud orchestration systems
     (e.g., Kubernetes) and network controllers.



  Dunbar, et al.          Expires 24 December 2025                [Page 4]


  Internet-Draft                 Neotec API                      June 2025


     By framing this scenario as a concrete use case, the document serves
     both as an applicability exercise and as input for future
     standardization efforts within the IETF aimed at cloud-network
     integration and SLA-driven policy control.

     Disclaimer

     The use of specific YANG data models (e.g., Attachment Circuit and TE
     topology) in this section is intended as a provisional exercise to
     explore how existing IETF models might address aspects of such a use
     case.  These examples are not exclusive or exhaustive.  Other data
     models, such as Network Slicing Service Model (NSSM) or service
     function chaining models, could also be relevant depending on the
     network architecture and service requirements.  The intent is to
     assess the applicability and identify gaps (if any), not to pre-
     define the final solution set.

  2.  Conventions used in this document

     Cloud Manager:  An entity that is primarily responsible for placing
        workloads, managing compute resources across Edge Cloud sites,
        Monitoring the health and scaling status of VMs, containers, or
        services, Making application-level decisions (e.g., where to place
        a function based on latency, CPU, GPU availability), etc..

     Network Orchestrator (or Orchestrator):  A logical entity that
        interfaces with the Cloud Manager to receive service requests or
        queries and coordinates the end-to-end connectivity across
        multiple network domains.  It abstracts underlying domain-specific
        technologies (e.g., L2/L3 VPNs, SR paths, TE tunnels) and
        disseminates policies to individual Network Controllers, enabling
        seamless stitching of diverse network segments to meet service-
        level requirements.

     Network Controller:  A domain specific control entity responsible for
        managing and configuring network resources within a single
        administrative or technological domain (e.g., IP/MPLS core, access
        network).  It receives high-level intent or service instructions
        from a Network Orchestrator and translates them into device-level
        configurations using protocols such as NETCONF, BGP, or PCEP.

     UE:  User Equipment

     UPF:  User Plane Function [TS.23.501-3GPP]







  Dunbar, et al.          Expires 24 December 2025                [Page 5]


  Internet-Draft                 Neotec API                      June 2025


     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.

  3.  Dynamic UCMP Load Balancing for Periodic Inter Site AI Traffic

     In the Neotec use case described in Section 1, AI inference modules
     are deployed across four Edge Cloud sites to support distributed city
     surveillance.  These modules periodically exchange large volumes of
     data, for instance, during result aggregation or synchronized event
     analysis.  These data exchanges are not continuous but are periodic
     and event driven, requiring guaranteed bandwidth and low latency for
     short time windows.

     The underlying network connecting these Edge Cloud sites typically
     includes multiple paths between nodes and across multiple network
     segments.An end-to-end path between Edge Cloud Site A and B spans at
     least three segments:

     - The first is the access segment from the Edge Cloud A to its
     closest PE.  There could be multipe PEs to Edge Cloud A for multi-
     homing.

     - The second segment traverses the provider transport network between
     the PE serving Edge Cloud A and the PE serving the Edge Cloud B.

     - The third segment connects that Edge PE to the Edge Cloud B's
     Gateway

  3.1.  UCMP Enforcement for Access Segment



















  Dunbar, et al.          Expires 24 December 2025                [Page 6]


  Internet-Draft                 Neotec API                      June 2025


                             +-----------------------------+
                         |      Edge Cloud Site        |
                         | +------------------------+  |
                         | |   AI Inference Module  |  |
                         | +------------------------+  |
                         |             |               |
                         |     +----------------+      |
                         |     |  Edge Cloud GW |      |
                         |     +----------------+      |
                         +-------------|---------------+
                                       |
                          Multiple Attachment Circuits
                                       |
        +----------------+   +----------------+   +----------------+
        |     PE1        |   |      PE2       |   |      PE3       |
        +----------------+   +----------------+   +----------------+
               |                     |                    |
        Provider Network     Provider Network      Provider Network

                      Figure 2: Edge Cloud Access Segment

     The Edge Cloud Gateway has multiple logical links (attachment
     circuits) to a set of PEs (e.g., PE1, PE2, PE3).  These links may
     vary in latency, bandwidth, or current load.  During periodic AI data
     bursts, the Edge Cloud GW must push all other traffic away from PE1,
     PE2, and PE3, reserving their full available bandwidth for AI flows.
     Or it could push all other traffic to one of the PEs that has the
     lowest bandwidth and highest latency.  This can be implemented by
     dynamically updating forwarding policies or QoS profiles to
     deprioritize or reroute non-AI traffic, ensuring that the AI
     inference module has uncontested access to network capacity during
     critical synchronization windows.  Depending on the request from the
     Cloud Manager, the Network Orchestrator can determine what exact
     policies to push to the PEs and the Edge GW..

     YANG Data Models for Policy Enforcement:

     To support dynamic UCMP-based traffic steering across PE1, PE2, and
     PE3, the Network Orchestrator can utilize the following IETF YANG
     models:

     - ietf-routing [RFC8349] enables configuration of routing instances
     and static routes.  The data model allows per-prefix route entries
     with multiple weighted next hops, supporting unequal cost paths.  It
     can be used to define static next-hop policies from the Edge GW
     toward PE1, PE2, and PE3.





  Dunbar, et al.          Expires 24 December 2025                [Page 7]


  Internet-Draft                 Neotec API                      June 2025


     - ietf-qos-policy [I-D.claise-opsawg-qos-packet-marking] defines
     traffic classification, marking, and treatment policies.  It can
     enforce rate limits or scheduling priority for non-AI traffic routed
     to PE3.

     - ietf-ac [I-D.ietf-opsawg-teas-attachment-circuit] can provides
     performance characteristics (bandwidth, latency, packet loss), which
     inform the decision to assign traffic classes.

     - ietf-traffic-classifier / ietf-packet-policy (or OpenConfig
     equivalents) can be used to match traffic classes (e.g., AI vs non-AI
     flows), enables forwarding decisions at the Edge GW and ingress of
     PEs.

     Policy Example: Prioritized AI Flow Assignment and Non-AI Rerouting:

     Assuming PE1 has the highest available capacity and best latency
     toward the remote site:

     The orchestrator uses ietf-routing [RFC8349] to define weighted
     static next hops at the Edge GW:

     - PE1: 2/3 of AI traffic.

     - PE2: 1/3 of AI traffic.

     - PE3: no AI traffic.
























  Dunbar, et al.          Expires 24 December 2025                [Page 8]


  Internet-Draft                 Neotec API                      June 2025


  {
    "routing:routing": {
      "routing-instance": [
        {
          "name": "ai-routing-instance",
          "routing-protocols": {
            "routing-protocol": [
              {
                "type": "static",
                "name": "ai-policy",
                "static-routes": {
                  "ipv4": {
                    "route": [
                      {
                        "destination-prefix": "198.51.100.0/24",
                        "next-hop": [
                          { "outgoing-interface": "to-PE1", "weight": 66 },
                          { "outgoing-interface": "to-PE2", "weight": 34 }
                        ]
                      }
                    ]
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }

                      Figure 3: UCMP policy example

     Non-AI traffic is matched by classifiers and redirected entirely to
     PE3:

     - Apply QoS policy using ietf-qos-policy [I-D.claise-opsawg-qos-
     packet-marking] to limit available bandwidth on PE3 to non-AI
     traffic.

     - PE3 may be tagged "degraded" in the ietf-ac model to signal its
     backup nature.

     This ensures that the AI traffic is prioritized through the most
     capable paths (PE1 and PE2) with precise weight.  All non-critical
     traffic is offloaded to the least-desired path (PE3), reducing
     congestion.  Orchestrator needs to dynamically adapt this logic per
     service request.



  Dunbar, et al.          Expires 24 December 2025                [Page 9]


  Internet-Draft                 Neotec API                      June 2025


     Fallback Logic: If available capacity on PE1 and PE2 is not
     sufficient, AI traffic still receives best possible routing via PE1
     and PE2, and Non-AI traffic may be allowed limited access to PE2 with
     reduced weight (e.g., 10%) while still primarily routed via PE3.

     This tiered policy enforcement ensures strict adherence to SLA goals
     for AI inference while maintaining service continuity for other
     traffic classes using standard YANG-based configuration interfaces.

     One critical limitation in existing IETF YANG models is the lack of
     native support for time-scoped UCMP policy activation.  To support
     the bursty nature of AI traffic, the following strategies can be
     applied:

     - Define policy activation via external triggers from the Cloud
     Manager using an API call to the orchestrator.

     - Orchestrator maintains a mapping between the requested activation
     time window and the temporary configuration to be applied.

     - Extend existing YANG models (e.g., ietf-routing or ietf-sr-policy)
     with optional augmentation for: start-time, duration, and expiration-
     action

     Example augmentation (conceptual):


     augment "/routing:routing/routing-instance/static-routes/route" {
       leaf burst-policy-start-time {
         type yang:date-and-time;
       }
       leaf burst-policy-duration-sec {
         type uint32;
       }
       leaf expiration-action {
         type enumeration {
           enum revert-to-default;
           enum retain;
         }
       }
     }


                         Figure 4: Example Augmentation







  Dunbar, et al.          Expires 24 December 2025               [Page 10]


  Internet-Draft                 Neotec API                      June 2025


     In the absence of standard YANG support, this behavior need to be
     implemented in the orchestrator logic by maintaining policy lifecycle
     state and timers, pushing temporary configuration via NETCONF/
     RESTCONF at start-time, and reverting after duration-sec.

  3.2.  UCMP Enforcement for SRv6 based PE to PE segment

     Assuming an SRv6 underlay among the PEs, the network controller can
     use the ietf-sr-policy YANG model to update the traffic distribution
     weights across pre-established paths.  For example, if three SRv6
     paths exist between EdgeSite-A and EdgeSite-C, the controller can
     push the following configuration to the ingress node:


     sr-policy {
       color 4001;
       endpoint "2001:db8:100::1";
       candidate-paths {
         preference 100;
         path {
           weight 70;
           sid-list [2001:db8:10::1, 2001:db8:11::2];
         }
         path {
           weight 20;
           sid-list [2001:db8:20::1, 2001:db8:21::2];
         }
         path {
           weight 10;
           sid-list [2001:db8:30::1, 2001:db8:31::2];
         }
       }
     }

                           Figure 5: Using SR Policy

     This UCMP configuration tells the network to distribute traffic
     unequally across the three paths based on their capability.  The
     underlying topology and metrics are derived from ietf-TE-topology and
     ietf-TE models, which expose bandwidth, latency, and available
     resources for each link.

     Similar UCMP behavior can also be implemented over SR-MPLS, MPLS-TE,
     or enhanced IP networks, using the corresponding IETF YANG models
     (ietf-TE, ietf-routing, etc.).  The key point is that the network
     paths are preexisting, and the only dynamic action is adjusting how
     traffic is forwarded among them in response to a cloud service
     request.



  Dunbar, et al.          Expires 24 December 2025               [Page 11]


  Internet-Draft                 Neotec API                      June 2025


  3.3.  UCMP Enforcement for PE to PE segment in Non-SRv6 networks

     In many operator networks that do not support SRv6, the PE-to-PE
     segment is realized as a logical transport tunnel (e.g., MPLS-TE LSP,
     IPsec tunnel, or GRE) that may traverse multiple intermediate
     routers.  Each of these routers may have multiple outgoing links to
     their respective next hops, making end-to-end UCMP behavior dependent
     on both tunnel-level path selection and interior node forwarding
     decisions.

     Policy Application for UCMP in Non-SRv6 Networks:

     To enable UCMP behavior between PEs in non-SRv6 networks, the network
     controller can provision multiple TE tunnels or IP-layer paths with
     distinct performance characteristics.  The UCMP forwarding behavior
     is realized by adjusting traffic distribution weights among these
     logical tunnels at the ingress PE (or head-end router).  This setup
     also requires the orchestrator to be topology-aware and TE-capable.

  3.3.1.  UCMP over MPLS-TE

     In MPLS-TE-enabled networks, PE-to-PE traffic is carried over logical
     LSPs that are pre-established and maintained by the network
     controller.  These LSPs can be engineered with specific bandwidth,
     latency, or disjointness constraints and serve as the building blocks
     for UCMP.

     Key Characteristics:

     - UCMP logic is enforced at the ingress PE (head-end LSR)

     - Intermediate routers simply perform label switching and do not
     require knowledge of traffic distribution policies.

     - The network controller selects multiple LSPs and configures the PE
     to assign weighted traffic across them.

     YANG Models Used

     - ietf-te-topology [RFC8795]: Describes available TE links and nodes.

     - ietf-routing [RFC8349]: Configures static routes with weighted
     next-hops over the tunnels.








  Dunbar, et al.          Expires 24 December 2025               [Page 12]


  Internet-Draft                 Neotec API                      June 2025


          {
    "routing:routing": {
      "routing-instance": [{
        "name": "ucmp-te",
        "routing-protocols": {
          "routing-protocol": [{
            "type": "static",
            "name": "te-policy",
            "static-routes": {
              "ipv4": {
                "route": [{
                  "destination-prefix": "198.51.100.0/24",
                  "next-hop": [
                    { "outgoing-interface": "mpls-te-tunnel-A", "weight": 60 },
                    { "outgoing-interface": "mpls-te-tunnel-B", "weight": 40 }
                  ]
                }]
              }
            }
          }]
        }
      }]
    }
  }



                   Figure 6: UCMP over MPLS-TE example

     In this model, the network controller dynamically adjusts the route
     weights during AI synchronization periods based on the request from
     the service orchestrator, favoring higher-performing tunnels.

  3.3.2.  UCMP Over Plain IP (ECMP)

     In networks without MPLS, traffic between PEs may traverse IP-based
     ECMP paths.  Each router independently forwards traffic using its own
     hash-based load balancing over equal-cost links.  Enabling UCMP over
     such paths is more complex because intermediate routers may not
     natively support weighted forwarding.

     Options for UCMP Enforcement:

     - Head-End-Based WCMP (Weighted ECMP): If routers support WCMP
     extensions, the ingress PE can apply traffic weights across next-
     hops.  The rest of the network performs standard ECMP; however,
     overall path selection remains coarse.




  Dunbar, et al.          Expires 24 December 2025               [Page 13]


  Internet-Draft                 Neotec API                      June 2025


     - Hop-by-Hop Configuration: If consistent UCMP behavior is required,
     each router along the path must be configured to support either:
     Weighted static routes using ietf-routing, or Traffic classifiers and
     filters using ietf-traffic-classifier or OpenConfig equivalents.
     This approach increases operational complexity and may require
     additional non-trival control logic.

     YANG Models Used:

     - ietf-routing [RFC8349]: Configures static or policy-based routes
     with weighted next-hops.

     - ietf-qos-policy [I-D. claise-opsawg-qos-packet-marking] and ietf-
     traffic-classifier [I-D. opsawg-traffic-classifier]: Used for traffic
     tagging and class-based forwarding.

     Limitations: many routers do not support WCMP or allow fine-grained
     weight control for ECMP paths.  Lack of coordination across routers
     can lead to inconsistent forwarding behavior.  Telemetry feedback
     from mid-path nodes is often unavailable or vendor-specific.

     Here is a JSON-based example using IETF YANG models to enforce UCMP
     behavior via hop-by-hop configuration, assuming each router along the
     path supports: Weighted static routes (ietf-routing), Traffic
     classification (ietf-traffic-classifier), and QoS forwarding rules
     (ietf-qos-policy).

     This example configures each router to: Match AI-related traffic
     using a classifier, Apply weighted next-hops via ietf-routing, and
     Enforce treatment policies using QoS configuration.


   1. Traffic Classifier (per router)
   {
     "traffic-classifier:classifiers": {
       "classifier": [
         {
           "name": "ai-traffic",
           "description": "Classify traffic for AI application",
           "match": {
             "ipv4": {
               "destination-address": "198.51.100.0/24"
             },
             "dscp": 34  // Assumes AI flows are marked with DSCP AF41
           }
         }
       ]
     }



  Dunbar, et al.          Expires 24 December 2025               [Page 14]


  Internet-Draft                 Neotec API                      June 2025


   }

   2. QoS Policy for Forwarding Behavior:
    {
     "qos-policy:policies": {
       "policy": [
         {
           "name": "ucmp-ai-policy",
           "classifier": "ai-traffic",
           "forwarding-actions": {
             "outgoing-interfaces": [
               { "interface": "eth1", "weight": 70 },
               { "interface": "eth2", "weight": 30 }
             ]
           }
         }
       ]
     }
   }

   3. Weighted Static Route for UCMP (applied per-hop)
   {
     "routing:routing": {
       "routing-instance": [
         {
           "name": "ucmp-instance",
           "routing-protocols": {
             "routing-protocol": [
               {
                 "type": "static",
                 "name": "static-ucmp",
                 "static-routes": {
                   "ipv4": {
                     "route": [
                       {
                         "destination-prefix": "198.51.100.0/24",
                         "next-hop": [
                           { "outgoing-interface": "eth1", "weight": 70 },
                           { "outgoing-interface": "eth2", "weight": 30 }
                         ]
                       }
                     ]
                   }
                 }
               }
             ]
           }
         }



  Dunbar, et al.          Expires 24 December 2025               [Page 15]


  Internet-Draft                 Neotec API                      June 2025


       ]
     }
   }


                     Figure 7: Hop by Hop UCMP example

     This configuration must be replicated (with appropriate interface
     changes) on each router along the PE-to-PE path.Traffic
     classification ensures only AI flows are subject to UCMP
     behavior.Each router's forwarding engine must support policy-based
     routing or weighted ECMP for this to work.Orchestration systems must
     maintain synchronized state and rollback mechanisms across devices.

  4.  Cloud-Initiated UCMP Activation API

     A simplified example of a cloud-initiated API call to the network
     controller might look like:



     POST /network-policy/ucmp-activation
     {
       "source-sites": ["EdgeSite-A", "EdgeSite-B"],
       "dest-sites": ["EdgeSite-C", "EdgeSite-D"],
       "start-time": "2025-05-01T10:00:00Z",
       "duration-sec": 300,
       "min-bandwidth-mbps": 5000,
       "max-latency-ms": 10
     }

                        Figure 8: Burst Network Request

     This request informs the network controller that a high-volume, low-
     latency data exchange will occur and that UCMP forwarding policies
     should be applied to optimize transport between the specified sites
     for the specified duration.

  5.  Gaps Analysis

     This section evaluates the limitations and shortcomings of current
     IETF YANG models and network orchestration mechanisms in supporting
     dynamic, time-scoped UCMP policy enforcement across both Access and
     PE-to-PE segments in multi-segment networks interconnecting Edge
     Cloud sites.






  Dunbar, et al.          Expires 24 December 2025               [Page 16]


  Internet-Draft                 Neotec API                      June 2025


  5.1.  Access Segment Gaps Analysis

     In the access segment between Edge Cloud gateways and PEs (e.g., PE1,
     PE2, PE3), traffic distribution policies can be enforced using
     weighted static routing (ietf-routing) and QoS classifiers (ietf-qos-
     policy).  However, the following issues remain:

     - Lack of Time-Bound Policy Support: Existing YANG models do not
     support time-bound routing or QoS policies natively.  Implementing
     time-scoped UCMP (e.g., apply for 5 minutes during AI sync) requires
     custom orchestrator logic, including timers, state tracking, and
     reversion mechanisms.

     - No Native Lifecycle Hooks: YANG models like ietf-ac and ietf-
     routing lack fields for lifecycle hooks such as start-time, duration,
     or expiration-behavior, making transient policy management
     cumbersome.

     - Granular Traffic Steering Limitations: While attachment circuit
     metrics can inform traffic placement decisions, there is no
     standardized way to associate UCMP weights directly with circuit
     performance in an event-driven manner.

     - Policy Interference Risk: There is no clear conflict resolution
     mechanism when temporary UCMP policies override existing long-term
     configurations.  Operators may hesitate to automate access path
     reconfigurations due to unpredictable side effects.

  5.2.  PE to PE Segment Gaps Analysis

     For the transport segment between PEs (especially non-SRv6 networks),
     dynamic UCMP faces additional modeling and orchestration challenges:

     - Inconsistent UCMP Support Across Technologies: While SRv6 supports
     weighted traffic steering via ietf-sr-policy, non-SRv6 networks
     (e.g., MPLS-TE, SR-MPLS, or IP) lack consistent models for applying
     and adjusting UCMP behavior dynamically.  The UCMP logic often has to
     be emulated via unequal TE tunnel provisioning and static route
     weight tuning.

     - Topology Model Limitations: ietf-te-topology and ietf-te expose
     rich metrics but are not inherently reactive to cloud events.  There
     is no trigger mechanism to automatically instantiate or adjust TE
     tunnels based on time-scoped cloud service requests.







  Dunbar, et al.          Expires 24 December 2025               [Page 17]


  Internet-Draft                 Neotec API                      June 2025


     - Limited Feedback Loops: Current YANG models are largely
     configuration-driven.  There is no standardized feedback channel from
     devices to orchestrators to confirm UCMP policy status, enforcement
     success, or SLA compliance during active windows.

  5.3.  Complexity of Hop-by-Hop UCMP Configuration in IP Networks

     In IP-based networks without MPLS-TE or SRv6, traffic distribution
     across multiple paths typically relies on Equal Cost Multipath
     (ECMP), where each router independently forwards traffic based on
     local hash-based algorithms.  Applying Unequal Cost Multipath (UCMP)
     in such environments requires hop-by-hop configuration to ensure
     consistent behavior, introducing substantial complexity.

     Identified Gaps

     - Lack of Unified UCMP Capability Discovery: Current IETF YANG models
     (ietf-routing, ietf-interfaces) do not expose whether a router
     supports Weighted ECMP (WCMP), the granularity of supported weights,
     or the hashing algorithm used for multipath forwarding.  Network
     controller cannot dynamically determine whether a node can
     participate in UCMP enforcement.

     - No Model for Coordinated Hop-by-Hop Weight Distribution:There is no
     standardized method to propagate UCMP weights across multiple nodes
     consistently. ietf-routing supports static routes with weighted next-
     hops, but each router must be configured independently with no
     assurance that downstream nodes share the same view.

     - Limited Telemetry for Flow Distribution Verification: Existing
     telemetry models (e.g., ietf-interfaces, ietf-te) offer counters per
     interface, but do not expose real-time per-class or per-prefix
     distribution across ECMP paths.  Operators lack visibility into
     whether UCMP objectives are being met without custom probes or
     vendor-specific tools.

     - Policy Lifecycle and Rollback Limitations: Time-scoped UCMP
     policies require precise activation and rollback behavior.  Current
     models lack lifecycle attributes (e.g., start time, expiration
     behavior) to automate the temporal aspect of UCMP enforcement.

  5.4.  Inter-Domain Coordination Gaps Analysis

     - Cross-Domain Policy Stitching: When the PE-to-PE path traverses
     multiple administrative domains, coordinating UCMP policy enforcement
     becomes challenging.  There is no standard way for an orchestrator to
     request and verify consistent path weights across AS boundaries.




  Dunbar, et al.          Expires 24 December 2025               [Page 18]


  Internet-Draft                 Neotec API                      June 2025


     - Cloud-to-Network Intent Translation: Cloud controllers (e.g.,
     Kubernetes) cannot directly express intent such as "min 5Gbps to
     EdgeSite-C from 10:00-10:05 UTC" in a format consumable by TE or
     routing models.  This necessitates the creation of a new intent or
     policy model aligned with both cloud-native and IETF constructs.

  6.  Security Considerations

     To be added

  7.  IANA Considerations

     None

  8.  References

  8.1.  Normative References

  8.2.  Informative References

     [Neotec-Zerotrust-Access]
                L. Dunbar and H. Chihi, "Neotec-Zerotrust-Access",
                December 2024, <https://datatracker.ietf.org/doc/draft-
                dunchihi-neotec-zerotrust-access-dm/>.

     [opsawg-teas-attachment-circuit]
                M. Boucadair, et al, "opsawg-teas-attachment-circuit",
                January 2025, <https://datatracker.ietf.org/doc/draft-
                ietf-opsawg-teas-attachment-circuit/>.

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

     [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
                Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
                Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
                2018, <https://www.rfc-editor.org/info/rfc8345>.

     [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
                E., and A. Tripathy, "Subscription to YANG Notifications",
                RFC 8639, DOI 10.17487/RFC8639, September 2019,
                <https://www.rfc-editor.org/info/rfc8639>.



  Dunbar, et al.          Expires 24 December 2025               [Page 19]


  Internet-Draft                 Neotec API                      June 2025


     [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
                for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
                September 2019, <https://www.rfc-editor.org/info/rfc8641>.

     [RFC8776]  Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
                "Common YANG Data Types for Traffic Engineering",
                RFC 8776, DOI 10.17487/RFC8776, June 2020,
                <https://www.rfc-editor.org/info/rfc8776>.

     [RFC8795]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
                O. Gonzalez de Dios, "YANG Data Model for Traffic
                Engineering (TE) Topologies", RFC 8795,
                DOI 10.17487/RFC8795, August 2020,
                <https://www.rfc-editor.org/info/rfc8795>.

     [TS.23.501-3GPP]
                3rd Generation Partnership Project (3GPP), "System
                Architecture for 5G System; Stage 2, 3GPP TS 23.501
                v2.0.1", December 2017.

  Acknowledgements

     The authors would like to thank for following for discussions and
     providing input to this document: xxx.

  Contributors

  Authors' Addresses

     Linda Dunbar (editor)
     Futurewei
     United States of America
     Email: ldunbar@futurewei.com


     Qiong
     China Telecom
     China
     Email: sunqiong@chinatelecom.cn


     Wu Bo (editor)
     Huawei
     China
     Email: lana.wubo@huawei.com






  Dunbar, et al.          Expires 24 December 2025               [Page 20]


  Internet-Draft                 Neotec API                      June 2025


     LUIS MIGUEL CONTRERAS MURILLO (editor)
     Telefornica
     Spain
     Email: luismiguel.contrerasmurillo@telefonica.com


     ChongFeng Xie
     China Telecom
     China
     Email: xiechf@chinatelecom.cn









































  Dunbar, et al.          Expires 24 December 2025               [Page 21]


name: draft-dunbar-onsen-ac-pe2pe-ucmp-applicability
rev: 00
title: Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies Use Case
time: 2026-02-23T20:06:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-27T20:06:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Model serving/inference"]
tags: []
fetched_at: 2026-03-03T15:50:11.000825+00:00
abstract:
  This document explores how existing IETF YANG data models can be
     applied to support a use case involving dynamic, time-scoped UCMP
     (Unequal Cost Multipath) policy enforcement across multiple network
     segments interconnecting Edge Cloud sites.  The use case is motivated
     by periodic, high-volume data exchanges between distributed AI
     inference modules placed at geographically dispersed edge data
     centers.  By mapping network requirements such as bandwidth, latency,
     and availability to relevant YANG models, including AC, TE Topology,
     SR Policy, and QoS models, this document serves as a practical
     exercise to evaluate the applicability and limitations of current
     IETF specifications.  It highlights the need for cloud-initiated,
     time-bounded network policy activation and identifies potential gaps
     in model expressiveness, policy lifecycle handling, and API-level
     abstraction required for real-time cloud-network coordination.

full_text:
  NeoTec                                                    L. Dunbar, Ed.
  Internet-Draft                                                 Futurewei
  Intended status: Informational                                    Q. Sun
  Expires: 27 August 2026                                    China Telecom
                                                                B. Wu, Ed.
                                                                    Huawei
                                                  L. CONTRERASMURILLO, Ed.
                                                               Telefornica
                                                                    C. Xie
                                                             China Telecom
                                                          23 February 2026


  Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies
                                  Use Case
             draft-dunbar-onsen-ac-pe2pe-ucmp-applicability-00

  Abstract

     This document explores how existing IETF YANG data models can be
     applied to support a use case involving dynamic, time-scoped UCMP
     (Unequal Cost Multipath) policy enforcement across multiple network
     segments interconnecting Edge Cloud sites.  The use case is motivated
     by periodic, high-volume data exchanges between distributed AI
     inference modules placed at geographically dispersed edge data
     centers.  By mapping network requirements such as bandwidth, latency,
     and availability to relevant YANG models, including AC, TE Topology,
     SR Policy, and QoS models, this document serves as a practical
     exercise to evaluate the applicability and limitations of current
     IETF specifications.  It highlights the need for cloud-initiated,
     time-bounded network policy activation and identifies potential gaps
     in model expressiveness, policy lifecycle handling, and API-level
     abstraction required for real-time cloud-network coordination.

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



  Dunbar, et al.           Expires 27 August 2026                 [Page 1]


  Internet-Draft                  onsen API                  February 2026


     This Internet-Draft will expire on 27 August 2026.

  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
     2.  Conventions used in this document . . . . . . . . . . . . . .   6
     3.  Dynamic UCMP Load Balancing for Periodic Inter Site AI
             Traffic . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  UCMP Enforcement for Access Segment . . . . . . . . . . .   7
       3.2.  UCMP Enforcement for SRv6 based PE to PE segment  . . . .  11
       3.3.  UCMP Enforcement for PE to PE segment in Non-SRv6
             networks  . . . . . . . . . . . . . . . . . . . . . . . .  12
         3.3.1.  UCMP over MPLS-TE . . . . . . . . . . . . . . . . . .  12
         3.3.2.  UCMP Over Plain IP (ECMP) . . . . . . . . . . . . . .  13
     4.  Cloud-Initiated UCMP Activation API . . . . . . . . . . . . .  16
     5.  Gaps Analysis . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.1.  Access Segment Gaps Analysis  . . . . . . . . . . . . . .  17
       5.2.  PE to PE Segment Gaps Analysis  . . . . . . . . . . . . .  17
       5.3.  Complexity of Hop-by-Hop UCMP Configuration in IP
             Networks  . . . . . . . . . . . . . . . . . . . . . . . .  18
       5.4.  Inter-Domain Coordination Gaps Analysis . . . . . . . . .  18
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20








  Dunbar, et al.           Expires 27 August 2026                 [Page 2]


  Internet-Draft                  onsen API                  February 2026


  1.  Introduction

     Edge computing enables latency-sensitive applications, such as AI
     inference, to be deployed closer to end users and data sources.  In
     many deployments, those latency sensitive applications are
     dynamically instantiated across multiple Edge Cloud sites based on
     compute availability, proximity to data sources, and overall service
     objectives.  These distributed modules, especially AI inference
     instances, often need to exchange large volumes of data periodically,
     for example, during model synchronization, aggregated result sharing,
     or collaborative analytics.

     These inter-site data exchanges typically require high bandwidth and
     low latency for short, well-defined time windows.  However, most
     transport networks are optimized for long-lived, static flows and do
     not natively support time-scoped policy enforcement.  Furthermore,
     existing routing mechanisms like Equal Cost Multipath (ECMP) are
     insufficient for granular traffic distribution when link costs and
     available bandwidth are unequal.  As a result, Unequal Cost Multipath
     (UCMP) techniques have emerged to enable more efficient load
     balancing across heterogeneous paths.

     This document focuses on the application of dynamic, cloud-initiated
     UCMP policy updates across multiple segments of the network
     interconnecting Edge Cloud sites.  It assumes the network supports
     multiple paths between sites and that these paths can be selected or
     weighted based on real-time performance metrics (e.g., latency,
     available bandwidth, load).























  Dunbar, et al.           Expires 27 August 2026                 [Page 3]


  Internet-Draft                  onsen API                  February 2026


                  +---------------------+       +---------------------+
                  |   Edge Cloud Site A |       |   Edge Cloud Site B |
                  +---------------------+       +---------------------+
                             |                             |
               +-------------+-------------+    +----------+-------------+
               |     Access PE / Gateway   |    |   Access PE / Gateway  |
               +-------------+-------------+    +----------+-------------+
                              \                             /
                               \                           /
                                 \                        /
                                  \                      /
                                   \                    /
                         Multiple Provider Transport Segments
                               (with dynamic UCMP policies)
                                   /                   \
                                  /                     \
                                 /                       \
                              /                           \
               +-------------+-------------+    +----------+-------------+
               |     Access PE / Gateway   |    |   Access PE / Gateway  |
               +-------------+-------------+    +----------+-------------+
                             |                             |
                  +---------------------+        +---------------------+
                  |   Edge Cloud Site C |        |   Edge Cloud Site D |
                  +---------------------+        +---------------------+

                              Periodic AI Traffic Exchange
                         requires time scoped dynamic UCMP adjustments


                Figure 1: Network Segments for AI Data Exchange

     The scenario described above can also be considered from a service
     abstraction perspective.  The periodic inter-site AI synchronization
     represents a higher-layer service characterized by parameters such as
     minimum bandwidth, maximum latency, and a bounded activation
     interval.  From the perspective of a Cloud Manager, the requirement
     may be expressed as a connectivity intent (e.g., provide a specified
     bandwidth between selected Edge Cloud sites within a defined time
     window) rather than as a specific routing or traffic engineering
     mechanism.

     To realize such a service abstraction, a Network Orchestrator
     decomposes the intent into multiple network-level constructs.  These
     may include routing context selection, traffic classification and QoS
     treatment, TE path selection, and weighted traffic distribution.
     Existing IETF YANG data models (e.g., ietf-routing, ietf-ac, ietf-te-
     topology, ietf-qos-policy, and ietf-sr-policy) provide configuration



  Dunbar, et al.           Expires 27 August 2026                 [Page 4]


  Internet-Draft                  onsen API                  February 2026


     primitives for these functions.  However, these models operate
     largely independently and do not collectively define a unified,
     lifecycle-aware service abstraction.

     This use case therefore illustrates an operational consideration: a
     time-scoped service objective may require coordinated updates across
     multiple models, network segments, and potentially administrative
     domains.  Lifecycle handling (e.g., activation time, duration, and
     reversion behavior), policy interaction, and verification of service
     compliance are typically implemented in orchestration systems rather
     than expressed directly within the YANG models themselves.  The UCMP
     examples in this document are used to explore this broader
     applicability and to identify areas where additional abstraction or
     coordination mechanisms may be beneficial.

     The primary goal of this work is to:

     - Demonstrate how IETF defined YANG data models, such as ietf-
     routing, ietf-ac, ietf-te-topology, ietf-qos-policy, and ietf-sr-
     policy, can be used to realize dynamic UCMP enforcemen.

     - Highlight the requirements for time-scoped policy activation and
     cloud-initiated triggers, which are not natively supported in
     existing models.

     - Propose augmentations or extensions needed to support temporary
     policy enforcement tied to cloud workload events.

     - Identify architectural and modeling gaps that must be addressed to
     enable closed-loop coordination between cloud orchestration systems
     (e.g., Kubernetes) and network controllers.

     By framing this scenario as a concrete use case, the document serves
     both as an applicability exercise and as input for future
     standardization efforts within the IETF aimed at cloud-network
     integration and SLA-driven policy control.

     Disclaimer

     The use of specific YANG data models (e.g., Attachment Circuit and TE
     topology) in this section is intended as a provisional exercise to
     explore how existing IETF models might address aspects of such a use
     case.  These examples are not exclusive or exhaustive.  Other data
     models, such as Network Slicing Service Model (NSSM) or service
     function chaining models, could also be relevant depending on the
     network architecture and service requirements.  The intent is to
     assess the applicability and identify gaps (if any), not to pre-
     define the final solution set.



  Dunbar, et al.           Expires 27 August 2026                 [Page 5]


  Internet-Draft                  onsen API                  February 2026


  2.  Conventions used in this document

     Cloud Manager:  An entity that is primarily responsible for placing
        workloads, managing compute resources across Edge Cloud sites,
        Monitoring the health and scaling status of VMs, containers, or
        services, Making application-level decisions (e.g., where to place
        a function based on latency, CPU, GPU availability), etc..

     Network Orchestrator (or Orchestrator):  A logical entity that
        interfaces with the Cloud Manager to receive service requests or
        queries and coordinates the end-to-end connectivity across
        multiple network domains.  It abstracts underlying domain-specific
        technologies (e.g., L2/L3 VPNs, SR paths, TE tunnels) and
        disseminates policies to individual Network Controllers, enabling
        seamless stitching of diverse network segments to meet service-
        level requirements.

     Network Controller:  A domain specific control entity responsible for
        managing and configuring network resources within a single
        administrative or technological domain (e.g., IP/MPLS core, access
        network).  It receives high-level intent or service instructions
        from a Network Orchestrator and translates them into device-level
        configurations using protocols such as NETCONF, BGP, or PCEP.

     UE:  User Equipment

     UPF:  User Plane Function [TS.23.501-3GPP]

     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.

  3.  Dynamic UCMP Load Balancing for Periodic Inter Site AI Traffic

     In the Neotec use case described in Section 1, AI inference modules
     are deployed across four Edge Cloud sites to support distributed city
     surveillance.  These modules periodically exchange large volumes of
     data, for instance, during result aggregation or synchronized event
     analysis.  These data exchanges are not continuous but are periodic
     and event driven, requiring guaranteed bandwidth and low latency for
     short time windows.

     The underlying network connecting these Edge Cloud sites typically
     includes multiple paths between nodes and across multiple network
     segments.An end-to-end path between Edge Cloud Site A and B spans at
     least three segments:



  Dunbar, et al.           Expires 27 August 2026                 [Page 6]


  Internet-Draft                  onsen API                  February 2026


     - The first is the access segment from the Edge Cloud A to its
     closest PE.  There could be multipe PEs to Edge Cloud A for multi-
     homing.

     - The second segment traverses the provider transport network between
     the PE serving Edge Cloud A and the PE serving the Edge Cloud B.

     - The third segment connects that Edge PE to the Edge Cloud B's
     Gateway

  3.1.  UCMP Enforcement for Access Segment


                             +-----------------------------+
                         |      Edge Cloud Site        |
                         | +------------------------+  |
                         | |   AI Inference Module  |  |
                         | +------------------------+  |
                         |             |               |
                         |     +----------------+      |
                         |     |  Edge Cloud GW |      |
                         |     +----------------+      |
                         +-------------|---------------+
                                       |
                          Multiple Attachment Circuits
                                       |
        +----------------+   +----------------+   +----------------+
        |     PE1        |   |      PE2       |   |      PE3       |
        +----------------+   +----------------+   +----------------+
               |                     |                    |
        Provider Network     Provider Network      Provider Network

                      Figure 2: Edge Cloud Access Segment

     The Edge Cloud Gateway has multiple logical links (attachment
     circuits) to a set of PEs (e.g., PE1, PE2, PE3).  These links may
     vary in latency, bandwidth, or current load.  During periodic AI data
     bursts, the Edge Cloud GW must push all other traffic away from PE1,
     PE2, and PE3, reserving their full available bandwidth for AI flows.
     Or it could push all other traffic to one of the PEs that has the
     lowest bandwidth and highest latency.  This can be implemented by
     dynamically updating forwarding policies or QoS profiles to
     deprioritize or reroute non-AI traffic, ensuring that the AI
     inference module has uncontested access to network capacity during
     critical synchronization windows.  Depending on the request from the
     Cloud Manager, the Network Orchestrator can determine what exact
     policies to push to the PEs and the Edge GW..




  Dunbar, et al.           Expires 27 August 2026                 [Page 7]


  Internet-Draft                  onsen API                  February 2026


     YANG Data Models for Policy Enforcement:

     To support dynamic UCMP-based traffic steering across PE1, PE2, and
     PE3, the Network Orchestrator can utilize the following IETF YANG
     models:

     - ietf-routing [RFC8349] enables configuration of routing instances
     and static routes.  The data model allows per-prefix route entries
     with multiple weighted next hops, supporting unequal cost paths.  It
     can be used to define static next-hop policies from the Edge GW
     toward PE1, PE2, and PE3.

     - ietf-qos-policy [I-D.claise-opsawg-qos-packet-marking] defines
     traffic classification, marking, and treatment policies.  It can
     enforce rate limits or scheduling priority for non-AI traffic routed
     to PE3.

     - ietf-ac [I-D.ietf-opsawg-teas-attachment-circuit] can provides
     performance characteristics (bandwidth, latency, packet loss), which
     inform the decision to assign traffic classes.

     - ietf-traffic-classifier / ietf-packet-policy (or OpenConfig
     equivalents) can be used to match traffic classes (e.g., AI vs non-AI
     flows), enables forwarding decisions at the Edge GW and ingress of
     PEs.

     Policy Example: Prioritized AI Flow Assignment and Non-AI Rerouting:

     Assuming PE1 has the highest available capacity and best latency
     toward the remote site:

     The orchestrator uses ietf-routing [RFC8349] to define weighted
     static next hops at the Edge GW:

     - PE1: 2/3 of AI traffic.

     - PE2: 1/3 of AI traffic.

     - PE3: no AI traffic.












  Dunbar, et al.           Expires 27 August 2026                 [Page 8]


  Internet-Draft                  onsen API                  February 2026


     {
       "routing:routing": {
         "routing-instance": [
           {
             "name": "ai-routing-instance",
             "routing-protocols": {
               "routing-protocol": [
                 {
                   "type": "static",
                   "name": "ai-policy",
                   "static-routes": {
                     "ipv4": {
                       "route": [
                       {
                         "destination-prefix": "198.51.100.0/24",
                         "next-hop": [
                         { "outgoing-interface": "to-PE1", "weight": 66},
                         { "outgoing-interface": "to-PE2", "weight": 34}
                         ]
                       }
                       ]
                     }
                   }
                 }
               ]
             }
           }
         ]
       }
     }

                         Figure 3: UCMP policy example

     Non-AI traffic is matched by classifiers and redirected entirely to
     PE3:

     - Apply QoS policy using ietf-qos-policy [I-D.claise-opsawg-qos-
     packet-marking] to limit available bandwidth on PE3 to non-AI
     traffic.

     - PE3 may be tagged "degraded" in the ietf-ac model to signal its
     backup nature.

     This ensures that the AI traffic is prioritized through the most
     capable paths (PE1 and PE2) with precise weight.  All non-critical
     traffic is offloaded to the least-desired path (PE3), reducing
     congestion.  Orchestrator needs to dynamically adapt this logic per
     service request.



  Dunbar, et al.           Expires 27 August 2026                 [Page 9]


  Internet-Draft                  onsen API                  February 2026


     Fallback Logic: If available capacity on PE1 and PE2 is not
     sufficient, AI traffic still receives best possible routing via PE1
     and PE2, and Non-AI traffic may be allowed limited access to PE2 with
     reduced weight (e.g., 10%) while still primarily routed via PE3.

     This tiered policy enforcement ensures strict adherence to SLA goals
     for AI inference while maintaining service continuity for other
     traffic classes using standard YANG-based configuration interfaces.

     One critical limitation in existing IETF YANG models is the lack of
     native support for time-scoped UCMP policy activation.  To support
     the bursty nature of AI traffic, the following strategies can be
     applied:

     - Define policy activation via external triggers from the Cloud
     Manager using an API call to the orchestrator.

     - Orchestrator maintains a mapping between the requested activation
     time window and the temporary configuration to be applied.

     - Extend existing YANG models (e.g., ietf-routing or ietf-sr-policy)
     with optional augmentation for: start-time, duration, and expiration-
     action

     Example augmentation (conceptual):


     augment "/routing:routing/routing-instance/static-routes/route" {
       leaf burst-policy-start-time {
         type yang:date-and-time;
       }
       leaf burst-policy-duration-sec {
         type uint32;
       }
       leaf expiration-action {
         type enumeration {
           enum revert-to-default;
           enum retain;
         }
       }
     }


                         Figure 4: Example Augmentation







  Dunbar, et al.           Expires 27 August 2026                [Page 10]


  Internet-Draft                  onsen API                  February 2026


     In the absence of standard YANG support, this behavior need to be
     implemented in the orchestrator logic by maintaining policy lifecycle
     state and timers, pushing temporary configuration via NETCONF/
     RESTCONF at start-time, and reverting after duration-sec.

  3.2.  UCMP Enforcement for SRv6 based PE to PE segment

     Assuming an SRv6 underlay among the PEs, the network controller can
     use the ietf-sr-policy YANG model to update the traffic distribution
     weights across pre-established paths.  For example, if three SRv6
     paths exist between EdgeSite-A and EdgeSite-C, the controller can
     push the following configuration to the ingress node:


     sr-policy {
       color 4001;
       endpoint "2001:db8:100::1";
       candidate-paths {
         preference 100;
         path {
           weight 70;
           sid-list [2001:db8:10::1, 2001:db8:11::2];
         }
         path {
           weight 20;
           sid-list [2001:db8:20::1, 2001:db8:21::2];
         }
         path {
           weight 10;
           sid-list [2001:db8:30::1, 2001:db8:31::2];
         }
       }
     }

                           Figure 5: Using SR Policy

     This UCMP configuration tells the network to distribute traffic
     unequally across the three paths based on their capability.  The
     underlying topology and metrics are derived from ietf-TE-topology and
     ietf-TE models, which expose bandwidth, latency, and available
     resources for each link.

     Similar UCMP behavior can also be implemented over SR-MPLS, MPLS-TE,
     or enhanced IP networks, using the corresponding IETF YANG models
     (ietf-TE, ietf-routing, etc.).  The key point is that the network
     paths are preexisting, and the only dynamic action is adjusting how
     traffic is forwarded among them in response to a cloud service
     request.



  Dunbar, et al.           Expires 27 August 2026                [Page 11]


  Internet-Draft                  onsen API                  February 2026


  3.3.  UCMP Enforcement for PE to PE segment in Non-SRv6 networks

     In many operator networks that do not support SRv6, the PE-to-PE
     segment is realized as a logical transport tunnel (e.g., MPLS-TE LSP,
     IPsec tunnel, or GRE) that may traverse multiple intermediate
     routers.  Each of these routers may have multiple outgoing links to
     their respective next hops, making end-to-end UCMP behavior dependent
     on both tunnel-level path selection and interior node forwarding
     decisions.

     Policy Application for UCMP in Non-SRv6 Networks:

     To enable UCMP behavior between PEs in non-SRv6 networks, the network
     controller can provision multiple TE tunnels or IP-layer paths with
     distinct performance characteristics.  The UCMP forwarding behavior
     is realized by adjusting traffic distribution weights among these
     logical tunnels at the ingress PE (or head-end router).  This setup
     also requires the orchestrator to be topology-aware and TE-capable.

  3.3.1.  UCMP over MPLS-TE

     In MPLS-TE-enabled networks, PE-to-PE traffic is carried over logical
     LSPs that are pre-established and maintained by the network
     controller.  These LSPs can be engineered with specific bandwidth,
     latency, or disjointness constraints and serve as the building blocks
     for UCMP.

     Key Characteristics:

     - UCMP logic is enforced at the ingress PE (head-end LSR)

     - Intermediate routers simply perform label switching and do not
     require knowledge of traffic distribution policies.

     - The network controller selects multiple LSPs and configures the PE
     to assign weighted traffic across them.

     YANG Models Used

     - ietf-te-topology [RFC8795]: Describes available TE links and nodes.

     - ietf-routing [RFC8349]: Configures static routes with weighted
     next-hops over the tunnels.








  Dunbar, et al.           Expires 27 August 2026                [Page 12]


  Internet-Draft                  onsen API                  February 2026


           {
     "routing:routing": {
       "routing-instance": [{
         "name": "ucmp-te",
         "routing-protocols": {
           "routing-protocol": [{
             "type": "static",
             "name": "te-policy",
             "static-routes": {
               "ipv4": {
                 "route": [{
                   "destination-prefix": "198.51.100.0/24",
                   "next-hop": [
                 {"outgoing-interface": "mpls-te-tunnel-A", "weight": 60},
                 {"outgoing-interface": "mpls-te-tunnel-B", "weight": 40}
                 ]
                }]
               }
             }
           }]
         }
       }]
     }
   }



                    Figure 6: UCMP over MPLS-TE example

     In this model, the network controller dynamically adjusts the route
     weights during AI synchronization periods based on the request from
     the service orchestrator, favoring higher-performing tunnels.

  3.3.2.  UCMP Over Plain IP (ECMP)

     In networks without MPLS, traffic between PEs may traverse IP-based
     ECMP paths.  Each router independently forwards traffic using its own
     hash-based load balancing over equal-cost links.  Enabling UCMP over
     such paths is more complex because intermediate routers may not
     natively support weighted forwarding.

     Options for UCMP Enforcement:

     - Head-End-Based WCMP (Weighted ECMP): If routers support WCMP
     extensions, the ingress PE can apply traffic weights across next-
     hops.  The rest of the network performs standard ECMP; however,
     overall path selection remains coarse.




  Dunbar, et al.           Expires 27 August 2026                [Page 13]


  Internet-Draft                  onsen API                  February 2026


     - Hop-by-Hop Configuration: If consistent UCMP behavior is required,
     each router along the path must be configured to support either:
     Weighted static routes using ietf-routing, or Traffic classifiers and
     filters using ietf-traffic-classifier or OpenConfig equivalents.
     This approach increases operational complexity and may require
     additional non-trival control logic.

     YANG Models Used:

     - ietf-routing [RFC8349]: Configures static or policy-based routes
     with weighted next-hops.

     - ietf-qos-policy [I-D. claise-opsawg-qos-packet-marking] and ietf-
     traffic-classifier [I-D. opsawg-traffic-classifier]: Used for traffic
     tagging and class-based forwarding.

     Limitations: many routers do not support WCMP or allow fine-grained
     weight control for ECMP paths.  Lack of coordination across routers
     can lead to inconsistent forwarding behavior.  Telemetry feedback
     from mid-path nodes is often unavailable or vendor-specific.

     Here is a JSON-based example using IETF YANG models to enforce UCMP
     behavior via hop-by-hop configuration, assuming each router along the
     path supports: Weighted static routes (ietf-routing), Traffic
     classification (ietf-traffic-classifier), and QoS forwarding rules
     (ietf-qos-policy).

     This example configures each router to: Match AI-related traffic
     using a classifier, Apply weighted next-hops via ietf-routing, and
     Enforce treatment policies using QoS configuration.


   1. Traffic Classifier (per router)
   {
     "traffic-classifier:classifiers": {
       "classifier": [
         {
           "name": "ai-traffic",
           "description": "Classify traffic for AI application",
           "match": {
             "ipv4": {
               "destination-address": "198.51.100.0/24"
             },
             "dscp": 34  // Assumes AI flows are marked with DSCP AF41
           }
         }
       ]
     }



  Dunbar, et al.           Expires 27 August 2026                [Page 14]


  Internet-Draft                  onsen API                  February 2026


   }

   2. QoS Policy for Forwarding Behavior:
    {
     "qos-policy:policies": {
       "policy": [
         {
           "name": "ucmp-ai-policy",
           "classifier": "ai-traffic",
           "forwarding-actions": {
             "outgoing-interfaces": [
               { "interface": "eth1", "weight": 70 },
               { "interface": "eth2", "weight": 30 }
             ]
           }
         }
       ]
     }
   }

   3. Weighted Static Route for UCMP (applied per-hop)
   {
     "routing:routing": {
       "routing-instance": [
         {
           "name": "ucmp-instance",
           "routing-protocols": {
             "routing-protocol": [
               {
                 "type": "static",
                 "name": "static-ucmp",
                 "static-routes": {
                   "ipv4": {
                     "route": [
                       {
                         "destination-prefix": "198.51.100.0/24",
                         "next-hop": [
                           { "outgoing-interface": "eth1", "weight": 70 },
                           { "outgoing-interface": "eth2", "weight": 30 }
                         ]
                       }
                     ]
                   }
                 }
               }
             ]
           }
         }



  Dunbar, et al.           Expires 27 August 2026                [Page 15]


  Internet-Draft                  onsen API                  February 2026


       ]
     }
   }


                     Figure 7: Hop by Hop UCMP example

     This configuration must be replicated (with appropriate interface
     changes) on each router along the PE-to-PE path.Traffic
     classification ensures only AI flows are subject to UCMP
     behavior.Each router's forwarding engine must support policy-based
     routing or weighted ECMP for this to work.Orchestration systems must
     maintain synchronized state and rollback mechanisms across devices.

  4.  Cloud-Initiated UCMP Activation API

     A simplified example of a cloud-initiated API call to the network
     controller might look like:



     POST /network-policy/ucmp-activation
     {
       "source-sites": ["EdgeSite-A", "EdgeSite-B"],
       "dest-sites": ["EdgeSite-C", "EdgeSite-D"],
       "start-time": "2025-05-01T10:00:00Z",
       "duration-sec": 300,
       "min-bandwidth-mbps": 5000,
       "max-latency-ms": 10
     }

                        Figure 8: Burst Network Request

     This request informs the network controller that a high-volume, low-
     latency data exchange will occur and that UCMP forwarding policies
     should be applied to optimize transport between the specified sites
     for the specified duration.

  5.  Gaps Analysis

     This section evaluates the limitations and shortcomings of current
     IETF YANG models and network orchestration mechanisms in supporting
     dynamic, time-scoped UCMP policy enforcement across both Access and
     PE-to-PE segments in multi-segment networks interconnecting Edge
     Cloud sites.






  Dunbar, et al.           Expires 27 August 2026                [Page 16]


  Internet-Draft                  onsen API                  February 2026


  5.1.  Access Segment Gaps Analysis

     In the access segment between Edge Cloud gateways and PEs (e.g., PE1,
     PE2, PE3), traffic distribution policies can be enforced using
     weighted static routing (ietf-routing) and QoS classifiers (ietf-qos-
     policy).  However, the following issues remain:

     - Lack of Time-Bound Policy Support: Existing YANG models do not
     support time-bound routing or QoS policies natively.  Implementing
     time-scoped UCMP (e.g., apply for 5 minutes during AI sync) requires
     custom orchestrator logic, including timers, state tracking, and
     reversion mechanisms.

     - No Native Lifecycle Hooks: YANG models like ietf-ac and ietf-
     routing lack fields for lifecycle hooks such as start-time, duration,
     or expiration-behavior, making transient policy management
     cumbersome.

     - Granular Traffic Steering Limitations: While attachment circuit
     metrics can inform traffic placement decisions, there is no
     standardized way to associate UCMP weights directly with circuit
     performance in an event-driven manner.

     - Policy Interference Risk: There is no clear conflict resolution
     mechanism when temporary UCMP policies override existing long-term
     configurations.  Operators may hesitate to automate access path
     reconfigurations due to unpredictable side effects.

  5.2.  PE to PE Segment Gaps Analysis

     For the transport segment between PEs (especially non-SRv6 networks),
     dynamic UCMP faces additional modeling and orchestration challenges:

     - Inconsistent UCMP Support Across Technologies: While SRv6 supports
     weighted traffic steering via ietf-sr-policy, non-SRv6 networks
     (e.g., MPLS-TE, SR-MPLS, or IP) lack consistent models for applying
     and adjusting UCMP behavior dynamically.  The UCMP logic often has to
     be emulated via unequal TE tunnel provisioning and static route
     weight tuning.

     - Topology Model Limitations: ietf-te-topology and ietf-te expose
     rich metrics but are not inherently reactive to cloud events.  There
     is no trigger mechanism to automatically instantiate or adjust TE
     tunnels based on time-scoped cloud service requests.







  Dunbar, et al.           Expires 27 August 2026                [Page 17]


  Internet-Draft                  onsen API                  February 2026


     - Limited Feedback Loops: Current YANG models are largely
     configuration-driven.  There is no standardized feedback channel from
     devices to orchestrators to confirm UCMP policy status, enforcement
     success, or SLA compliance during active windows.

  5.3.  Complexity of Hop-by-Hop UCMP Configuration in IP Networks

     In IP-based networks without MPLS-TE or SRv6, traffic distribution
     across multiple paths typically relies on Equal Cost Multipath
     (ECMP), where each router independently forwards traffic based on
     local hash-based algorithms.  Applying Unequal Cost Multipath (UCMP)
     in such environments requires hop-by-hop configuration to ensure
     consistent behavior, introducing substantial complexity.

     Identified Gaps

     - Lack of Unified UCMP Capability Discovery: Current IETF YANG models
     (ietf-routing, ietf-interfaces) do not expose whether a router
     supports Weighted ECMP (WCMP), the granularity of supported weights,
     or the hashing algorithm used for multipath forwarding.  Network
     controller cannot dynamically determine whether a node can
     participate in UCMP enforcement.

     - No Model for Coordinated Hop-by-Hop Weight Distribution:There is no
     standardized method to propagate UCMP weights across multiple nodes
     consistently. ietf-routing supports static routes with weighted next-
     hops, but each router must be configured independently with no
     assurance that downstream nodes share the same view.

     - Limited Telemetry for Flow Distribution Verification: Existing
     telemetry models (e.g., ietf-interfaces, ietf-te) offer counters per
     interface, but do not expose real-time per-class or per-prefix
     distribution across ECMP paths.  Operators lack visibility into
     whether UCMP objectives are being met without custom probes or
     vendor-specific tools.

     - Policy Lifecycle and Rollback Limitations: Time-scoped UCMP
     policies require precise activation and rollback behavior.  Current
     models lack lifecycle attributes (e.g., start time, expiration
     behavior) to automate the temporal aspect of UCMP enforcement.

  5.4.  Inter-Domain Coordination Gaps Analysis

     - Cross-Domain Policy Stitching: When the PE-to-PE path traverses
     multiple administrative domains, coordinating UCMP policy enforcement
     becomes challenging.  There is no standard way for an orchestrator to
     request and verify consistent path weights across AS boundaries.




  Dunbar, et al.           Expires 27 August 2026                [Page 18]


  Internet-Draft                  onsen API                  February 2026


     - Cloud-to-Network Intent Translation: Cloud controllers (e.g.,
     Kubernetes) cannot directly express intent such as "min 5Gbps to
     EdgeSite-C from 10:00-10:05 UTC" in a format consumable by TE or
     routing models.  This necessitates the creation of a new intent or
     policy model aligned with both cloud-native and IETF constructs.

  6.  Security Considerations

     To be added

  7.  IANA Considerations

     None

  8.  References

  8.1.  Normative References

  8.2.  Informative References

     [Neotec-Zerotrust-Access]
                L. Dunbar and H. Chihi, "Neotec-Zerotrust-Access",
                December 2024, <https://datatracker.ietf.org/doc/draft-
                dunchihi-neotec-zerotrust-access-dm/>.

     [opsawg-teas-attachment-circuit]
                M. Boucadair, et al, "opsawg-teas-attachment-circuit",
                January 2025, <https://datatracker.ietf.org/doc/draft-
                ietf-opsawg-teas-attachment-circuit/>.

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

     [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
                Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
                Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
                2018, <https://www.rfc-editor.org/info/rfc8345>.

     [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
                E., and A. Tripathy, "Subscription to YANG Notifications",
                RFC 8639, DOI 10.17487/RFC8639, September 2019,
                <https://www.rfc-editor.org/info/rfc8639>.



  Dunbar, et al.           Expires 27 August 2026                [Page 19]


  Internet-Draft                  onsen API                  February 2026


     [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
                for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
                September 2019, <https://www.rfc-editor.org/info/rfc8641>.

     [RFC8776]  Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
                "Common YANG Data Types for Traffic Engineering",
                RFC 8776, DOI 10.17487/RFC8776, June 2020,
                <https://www.rfc-editor.org/info/rfc8776>.

     [RFC8795]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
                O. Gonzalez de Dios, "YANG Data Model for Traffic
                Engineering (TE) Topologies", RFC 8795,
                DOI 10.17487/RFC8795, August 2020,
                <https://www.rfc-editor.org/info/rfc8795>.

     [TS.23.501-3GPP]
                3rd Generation Partnership Project (3GPP), "System
                Architecture for 5G System; Stage 2, 3GPP TS 23.501
                v2.0.1", December 2017.

  Acknowledgements

     The authors would like to thank for following for discussions and
     providing input to this document: xxx.

  Contributors

  Authors' Addresses

     Linda Dunbar (editor)
     Futurewei
     United States of America
     Email: ldunbar@futurewei.com


     Qiong
     China Telecom
     China
     Email: sunqiong@chinatelecom.cn


     Wu Bo (editor)
     Huawei
     China
     Email: lana.wubo@huawei.com






  Dunbar, et al.           Expires 27 August 2026                [Page 20]


  Internet-Draft                  onsen API                  February 2026


     LUIS MIGUEL CONTRERAS MURILLO (editor)
     Telefornica
     Spain
     Email: luismiguel.contrerasmurillo@telefonica.com


     ChongFeng Xie
     China Telecom
     China
     Email: xiechf@chinatelecom.cn









































  Dunbar, et al.           Expires 27 August 2026                [Page 21]


name: draft-dunbar-onsen-ac-te-applicability
rev: 00
title: Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case
time: 2026-02-23T20:17:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-27T20:17:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Model serving/inference"]
tags: []
fetched_at: 2026-03-03T15:50:11.000838+00:00
abstract:
  This document explores how existing IETF YANG data models,
     specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and
     Traffic Engineering (TE) topology data models, can be applied to
     support a use case involving dynamic AI model placement at Edge Cloud
     sites.  The use case involves selecting optimal Edge locations for
     real-time AI inference based on end-to-end network performance
     between street-level cameras and Edge Cloud compute nodes.  By
     mapping the use case across multiple network segments and applying
     relevant YANG data models to retrieve and request specific services
     objectives such as bandwidth, latency, and reliability, this document
     serves as a practical exercise to evaluate model applicability and
     identify gaps, if any.

full_text:
  onions                                                    L. Dunbar, Ed.
  Internet-Draft                                                 Futurewei
  Intended status: Informational                                    Q. Sun
  Expires: 27 August 2026                                    China Telecom
                                                                B. Wu, Ed.
                                                                    Huawei
                                                  L. CONTRERASMURILLO, Ed.
                                                               Telefornica
                                                                    C. Xie
                                                             China Telecom
                                                          23 February 2026


   Applying Attachmet Circuit and Traffic Engineering YANG Data Model to
                              Edge AI Use Case
                 draft-dunbar-onsen-ac-te-applicability-00

  Abstract

     This document explores how existing IETF YANG data models,
     specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and
     Traffic Engineering (TE) topology data models, can be applied to
     support a use case involving dynamic AI model placement at Edge Cloud
     sites.  The use case involves selecting optimal Edge locations for
     real-time AI inference based on end-to-end network performance
     between street-level cameras and Edge Cloud compute nodes.  By
     mapping the use case across multiple network segments and applying
     relevant YANG data models to retrieve and request specific services
     objectives such as bandwidth, latency, and reliability, this document
     serves as a practical exercise to evaluate model applicability and
     identify gaps, if any.

  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 27 August 2026.



  Dunbar, et al.           Expires 27 August 2026                 [Page 1]


  Internet-Draft                 onions API                  February 2026


  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
     2.  Conventions used in this document . . . . . . . . . . . . . .   4
     3.  YANG Data Models and APIs to Support Dynamic AI Model
             Placement . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Using AC YANG Data Model to Evaluate Access and Edge
             Connectivity  . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.  Using IETF YANG Data Models to Evaluate PE to PE
             Connectivity  . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.  Non-TE-Based PE to PE Connectivity  . . . . . . . . . . .  13
     4.  Potential APIs for Kubernetes to Query Network Conditions . .  13
       4.1.  Behavior and Semantics  . . . . . . . . . . . . . . . . .  14
       4.2.  YANG Model Integration  . . . . . . . . . . . . . . . . .  15
     5.  Dynamic UCMP Load Balancing for Periodic Inter Site AI
             Traffic . . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.  Edge Cloud Site to Local PE (Access Segment)  . . . . . .  15
         5.1.1.  Time-Scoped UCMP Policy Enforcement . . . . . . . . .  19
         5.1.2.  UCMP Enforcement for SRv6 based PE to PE segment  . .  20
       5.2.  Cloud-Initiated UCMP Activation API . . . . . . . . . . .  21
     6.  Gaps Between Existing IETF Specifications and Neotec Use Case
             Needs . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       6.1.  Consumption Model Mismatch  . . . . . . . . . . . . . . .  22
       6.2.  Lack of Time-Bounded, Cloud-Triggered Policy
             Interfaces  . . . . . . . . . . . . . . . . . . . . . . .  22
       6.3.  Absence of Intent and Workload-to-Flow Mapping  . . . . .  22
       6.4.  Lack of Abstracted, Queryable Interfaces  . . . . . . . .  22
       6.5.  Feedback and Acknowledgment Gaps  . . . . . . . . . . . .  23
       6.6.  Security and Access Control Framework Alignment . . . . .  23
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  23



  Dunbar, et al.           Expires 27 August 2026                 [Page 2]


  Internet-Draft                 onions API                  February 2026


     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     This document explores the applicability of the Attachment Circuits
     YANG data model [I-D.ietf-opsawg-teas-attachment-circuit] and TE
     topology YANG data model, to support a simplified version of the use
     case described in China telecom's Neotec side meeting during
     IETF122(Cloud aware Network Operation for AI Services).  Also, the
     document specifies the APIs needed to support the simplified use
     case.

     Simplifed Use Case:

     Let's assume there are 10 Edge Cloud sites.  An City Surveillance AI
     model (e.g., detecting traffic congestion or garbage classification)
     needs to be deployed dynamically to some of these sites in response
     to real time events.

     High level steps for selecting Edge sites to instantiate the City
     Surveillance AI model:

     - Step 1: A Cloud Manager needs to query the network connectivity
     characteristics (bandwidth, latency, topology constraints, etc.)
     between street cameras (or gateways, eNB that connect to those street
     cameras) and candidate Edge Cloud sites in order to determine the
     optimal locations for the City Surveillance AI model deployment.

     - Step 2: Based on the information gathered, the Cloud Manager
     decides to deploy the City Surveillance AI model in a subset of the
     Edge Cloud sites (e.g., 4 sites among 10).

     High level steps to support the following desired outcome:

     - Suppose that the City Surveillance AI model instances in the 4 Edge
     Cloud sites need to exchange large volumes of data with strict
     performance constraints (e.g., XX Gbps bandwidth and YY ms one-way
     delay along the entire end-to-end paths between edge sites).  This
     request is to a network controller to dynamically adjust UCMP
     (Unequal Cost Multipath) load-balancing algorithms [I-D. ietf-bess-
     evpn-unequal-lb][I-D.ietf-idr-link-bandwidth] on all the nodes along
     the paths interconnecting those 4 sites.

     Disclaimer





  Dunbar, et al.           Expires 27 August 2026                 [Page 3]


  Internet-Draft                 onions API                  February 2026


     The use of specific YANG data models (e.g., Attachment Circuit and TE
     topology) in this section is intended as a provisional exercise to
     explore how existing IETF models might address aspects of such a use
     case.  These examples are not exclusive or exhaustive.  Other data
     models, such as Network Slicing Service Model (NSSM) or service
     function chaining models, could also be relevant depending on the
     network architecture and service requirements.  The intent is to
     assess the applicability and identify gaps (if any), not to pre-
     define the final solution set.

  2.  Conventions used in this document

     Cloud Manager:  An entity that is primarily responsible for placing
        service instances and managing compute resources across Edge Cloud
        sites.  It monitors the health and scaling status of VMs,
        containers, or services, and makes infrastructure-level decisions,
        such as where to host service instances based on latency, CPU, GPU
        availability, or other constraints.  In addition, the Cloud
        Manager may provide abstracted status about the cloud environment
        (e.g., resource availability) to external entities.

     Neotec:  Network Operation for Telco Cloud.

     Network Orchestrator (or Orchestrator):  A logical entity that
        interfaces with the Cloud Manager to receive service requests or
        queries and coordinates the end-to-end connectivity across
        multiple network domains.  It abstracts underlying domain-specific
        technologies (e.g., L2/L3 VPNs, SR paths, TE tunnels) and
        disseminates policies to individual Network Controllers, enabling
        seamless stitching of diverse network segments to meet service-
        level requirements.

     Network Controller:  A domain specific control entity responsible for
        managing and configuring network resources within a single
        administrative or technological domain (e.g., IP/MPLS core, access
        network).  It receives high-level intent or service instructions
        from a Network Orchestrator and translates them into device-level
        configurations using protocols such as NETCONF, BGP, or PCEP.

     UE:  User Equipment

     UPF:  User Plane Function [TS.23.501-3GPP]

     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.



  Dunbar, et al.           Expires 27 August 2026                 [Page 4]


  Internet-Draft                 onions API                  February 2026


  3.  YANG Data Models and APIs to Support Dynamic AI Model Placement

     Multiple Edge Cloud sites are located in close geographic proximity,
     allowing any of them to potentially host AI inference model instances
     for city surveillance tasks such as traffic congestion detection or
     garbage classification.  A Cloud Manager must evaluate the end-to-end
     data paths between the street-level cameras and each Edge Cloud site
     to determine which sites offer sufficient compute resources and the
     required network performance (e.g., low latency and high throughput).
     This assessment enables dynamic placement of AI inference models in
     response to real-time events while ensuring reliable data delivery
     from the field.

     This path typically spans three segments:

     - The first is the access segment from the cameras local access node,
     such as a WiFi Access Point or an eNB, to a PE router.

     - The second segment traverses the provider transport network between
     that Access PE and the PE router serving the candidate Edge Cloud
     site.

     - The third segment connects that Edge PE to the Edge Cloud Gateway
     or compute node where the AI workload is deployed.

     There are two primary types of access connectivity for the cameras:
     via cellular networks (e.g., through eNBs/gNBs and User Plane
     Functions (UPFs)) or via WiFi Access Points.  In cellular based
     access, cameras connect to the network through eNBs, which forward
     user data to UPFs via GTP-U tunnels.  The UPFs serve as termination
     points for GTP-U tunnels and are often co-located with or adjacent to
     Edge Cloud sites.  When the Cloud Manager selects Edge Cloud sites
     for hosting AI inference modules, it must ensure that the
     corresponding nearby UPFs are assigned as the serving UPFs for the
     associated eNBs.  This enables the establishment of GTP-U tunnels
     from the eNBs directly to the selected Edge Cloud locations,
     minimizing latency and improving efficiency for real-time AI
     processing.

     For cameras connected through WiFi Access Points, no GTP tunneling is
     involved.  These access points typically connect to PEs through Layer
     2 or Layer 3 links.  In this case, the Attachment Circuit (AC) YANG
     model can be directly used to represent the logical connectivity
     between the WiFi AP and the Access PE.  The Cloud Manager or
     orchestrator can query the AC model to evaluate operational status,
     available bandwidth, latency, and packet loss, and determine whether
     the path is capable of supporting the target AI workload.




  Dunbar, et al.           Expires 27 August 2026                 [Page 5]


  Internet-Draft                 onions API                  February 2026


     In both access scenarios, after determining candidate Edge Cloud
     sites, the Cloud Manager evaluates the transport network (Segment 2)
     between the access side PE (or the PE adjacent to the UPF) and the
     Edge side PE.  This segment may be traffic engineered and can be
     modeled using the IETF TE topology model [RFC8795] and the TE tunnel
     model [RFC8776].  These data models expose metrics such as available
     bandwidth, TE delay, and administrative attributes, which the
     orchestrator can use to assess whether the underlying transport paths
     meet the end-to-end service constraints (captured in an SLA.

     Finally, the last segment (Segment 3: from the PE to the Edge Cloud
     Gateway or compute node) is again modeled using the AC YANG data
     model.  By combining insights from the AC and TE data models across
     all three segments, the Cloud Manager and orchestrator can select
     Edge Cloud sites that not only have available compute capacity but
     also meet the network performance requirements to support low
     latency, high bandwidth AI model inference.

     Important Clarification:

     The Attachment Circuit (AC) and Traffic Engineering (TE) Topology
     YANG models described above are internal network models used by the
     network controller and orchestrator.  They are not directly exposed
     to external entities like the Cloud Manager.  Instead, the network
     controller abstracts relevant information from these internal models
     and presents it through simplified, service-oriented APIs (e.g.,
     onions APIs), allowing the Cloud Manager to query network performance
     metrics (such as latency and available bandwidth) without accessing
     raw topology or low-level link state.






















  Dunbar, et al.           Expires 27 August 2026                 [Page 6]


  Internet-Draft                 onions API                  February 2026


                              +---------------------+
                              |     Street Cameras  |
                              +---------------------+
                                  /             \
                                 /               \
                 (Cellular Access)           (WiFi Access)
                               /                 \
                         +--------+         +-------------+
                         |  eNB   |         |  WiFi AP   |
                         +--------+         +-------------+
                               |                   |
                               |                   |
                 +----------------------+    +----------------------+
                 |        UPF           |    |    Access PE Router  |
                 +----------------------+    +----------------------+
                         |                             |
                         |       Segment 1             |
                         |<--------------------------->|
                                 (Access Segment)

                                 \                 /
                                  \               /
                                   \             /
                                 +----------------------+
                                 |  Provider Transport   |
                                 |     Network (TE)      |
                                 +----------------------+
                                             |
                                  Segment 2  | (PE-to-PE)
                                             v
                               +---------------------------+
                               |   Edge PE Router (per site)|
                               +---------------------------+
                                             |
                                             |
                                Segment 3    v
                                      +--------------------+
                                      |  Edge Cloud Gateway|
                                      |  + AI Model Module |
                                      +--------------------+


                           Figure 1: Network Segments

     For the first and third segments, the Attachment Circuit (AC) YANG
     model, defined in [I-D:ietf-opsawg-teas-attachment-circuit], provides
     a standardized abstraction of the logical link between a service
     access point and the provider's routing infrastructure.  This model



  Dunbar, et al.           Expires 27 August 2026                 [Page 7]


  Internet-Draft                 onions API                  February 2026


     allows the Cloud Manager to retrieve configuration and operational
     status of these links, including encapsulation type, bandwidth, and
     link status.  While the Bearer Service Model [I-D:ietf-opsawg-teas-
     attachment-circuit] can provide additional contextual information,
     such as interface type, location, and administrative details, it is
     not the primary focus of this document.  For the purposes of real-
     time workload placement and path performance assessment, the emphasis
     here is on network performance metrics (e.g., latency, available
     bandwidth) exposed via AC and TE models.  Integration with bearer-
     level metadata (e.g., location) may be considered in future
     enhancements or broader orchestration frameworks.By querying this
     information, the orchestrator can determine whether each access
     circuit is operational and capable of delivering real-time video
     streams to or from the AI inference point.

     The second segment, the PE to PE transport path across the provider
     network, requires querying a different set of YANG models.  The base
     network and topology models defined in [RFC8345] provide the
     foundation, while the Traffic Engineering Topology model [RFC8795]
     adds details such as TE metrics, link delay, bandwidth availability,
     and administrative constraints.  These models are typically
     maintained by network controllers and made accessible via NETCONF or
     RESTCONF interfaces.  The Cloud Manager can initiate a query to
     evaluate the performance characteristics of available transport paths
     between Access PEs and candidate Edge PEs.  This query is handled by
     the Network Orchestrator, which interacts with the Network
     Controllers managing each domain.  The orchestrator uses IETF defined
     topology and TE models, such as the TE Topology model [RFC8795] and
     the TE Tunnel model [RFC8776], to retrieve current path attributes,
     including available bandwidth and latency.  In architectures that
     support a Path Computation Element (PCE), the orchestrator may also
     issue path computation requests via PCEP or a REST API to identify
     transport paths that meet the performance objectives required for AI
     inference workloads.

     While L2SM [RFC8466] and L3SM [RFC8299] offer useful abstractions for
     provisioning Layer 2 and Layer 3 VPN services, they are primarily
     focused on expressing service level intent rather than evaluating
     real time transport performance.  As such, they are not directly
     applicable to the dynamic, performance sensitive selection process
     described in the Neotec use case.

     By combining the Attachment Circuit and TE topology models, the Cloud
     Manager can construct an end to end view of network connectivity from
     each camera access point to every potential Edge Cloud site.  It can
     then select the subset of Edge Cloud locations that not only have
     sufficient computing resources but also meet the required network
     performance criteria for serving the selected set of street cameras.



  Dunbar, et al.           Expires 27 August 2026                 [Page 8]


  Internet-Draft                 onions API                  February 2026


     This allows dynamic, network aware placement of AI inference models,
     ensuring efficient use of edge infrastructure while meeting service
     quality requirements.

  3.1.  Using AC YANG Data Model to Evaluate Access and Edge Connectivity

     In the context of dynamic AI model placement at Edge Cloud sites, the
     AC data model is useful for querying the health and performance of
     the access (Segment 1) which connects Access Points or eNBs to Access
     PE routers, and edge (Segment 3) which links Edge PEs to Edge Cloud
     Gateways or compute nodes.

     Each attachment circuit is modeled with attributes such as
     administrative state, operational status, encapsulation type, and
     configured bandwidth.  When augmented with telemetry or traffic
     engineering extensions, the AC model also supports real time status
     such as current utilization, available bandwidth, latency, and even
     packet loss.

     However, the Cloud Manager does not directly interact with the AC
     model.  Instead, the network controller queries and interprets the AC
     YANG data model and exposes only the relevant service-level metrics
     through the onions API interface.  This ensures that the Cloud
     Manager can assess whether a given access or edge segment supports
     the required performance (e.g., latency less than 10 ms, throughput
     greater than 500 Mbps) without needing detailed knowledge of the
     network.

     For example, if the Cloud Manager specifies a target Edge Cloud site,
     the network controller may internally retrieve attachment circuit
     metrics and present a simple API response indicating available
     bandwidth and latency thresholds met or not met:


     GET https://<controller>/restconf/data/ietf-ac:attachment-circuits
     /ac[pe-address='192.0.2.11']

                            Figure 2: Get AC Status













  Dunbar, et al.           Expires 27 August 2026                 [Page 9]


  Internet-Draft                 onions API                  February 2026


     {
       "ietf-ac:ac": [
         {
           "name": "ac-to-eNB-001",
           "pe-address": "192.0.2.11",
           "ce-interface": "ge-0/0/1",
           "oper-status": "up",
           "admin-status": "enabled",
           "encapsulation-type": "dot1q",
           "bandwidth": {
             "configured": 1000,
             "available": 850,
             "unit": "Mbps"
           },
           "performance-metrics": {
             "latency": {
               "average": 5,
               "max": 10,
               "unit": "ms"
             },
             "packet-loss": {
               "percentage": 0.01
             }
           }
         }
       ]
     }

                       Figure 3: Access Segments Response

     In this example, the attachment circuit is operational (oper-status:
     up), with 850 Mbps of available bandwidth and average latency of 5
     ms, making it a strong candidate for supporting a real time AI
     application.  The Cloud Manager may apply similar queries to all PE
     addresses associated with candidate Edge Cloud sites and their
     corresponding access points, filtering the results to identify which
     circuits meet both latency and throughput thresholds.

  3.2.  Using IETF YANG Data Models to Evaluate PE to PE Connectivity

     Segment 2 of the end-to-end path connects the Access PE to the Edge
     PE router serving a candidate Edge Cloud site.  This segment
     typically traverses the provider's core or aggregation network and is
     crucial for ensuring that real-time AI inference traffic can meet
     stringent latency and bandwidth requirements.






  Dunbar, et al.           Expires 27 August 2026                [Page 10]


  Internet-Draft                 onions API                  February 2026


     The network controller uses internal models such as the IETF Network
     Topology YANG model [RFC8345] and the Traffic Engineering Topology
     YANG model [RFC8795] to monitor transport network characteristics.
     These models describe nodes, TE links, available bandwidth, delay,
     SRLGs, and other performance attributes.  Similarly, TE tunnels can
     be modeled using [RFC8776] to represent established LSPs or segment
     routing paths.

     Importantly, the Cloud Manager does not directly access these
     detailed TE models.  Instead, the controller or orchestrator
     processes this information and presents it via an abstracted API
     interface, exposing key metrics like end-to-end latency, available
     bandwidth, and path health between specified endpoints (e.g., Access
     Node to Edge Site).

     This abstraction enables the Cloud Manager to make workload placement
     decisions based on network performance, without having to manage or
     interpret the detailed topology or traffic engineering constructs.

     For example, to query available transport links from an Access PE at
     PE1 to a set of Edge PEs, the Cloud Manager may retrieve the list of
     TE links and their attributes using the following RESTCONF-style
     request:


     GET https://<controller>/restconf/data/ietf-te-topology:te-topologies
     /topology=default/te-node=PE1


                        Figure 4: Get PE-PE Path Status





















  Dunbar, et al.           Expires 27 August 2026                [Page 11]


  Internet-Draft                 onions API                  February 2026


     {
       "te-links": [
         {
           "name": "PE1-to-PE5",
           "link-id": "link-001",
           "oper-status": "up",
           "te-default-metric": 30,
           "te-bandwidth": {
             "max-link-bandwidth": 10000,
             "available-bandwidth": 7000,
             "unit": "Mbps"
           },
           "delay": {
             "unidirectional-delay": 8,
             "unit": "ms"
           },
           "adjacent-te-node-id": "PE5"
         }
       ]
     }

                            Figure 5: PE-PE Segment

     In this example, the link from PE1 to PE5 offers 7 Gbps of available
     bandwidth with 8 ms unidirectional delay, which may satisfy a 500
     Mbps, sub-10 ms latency requirement for AI data ingestion.  The Cloud
     Manager can evaluate similar TE links or tunnels to other Edge PEs
     (e.g., PE6, PE7) and compare their performance characteristics.

     Alternatively, if the network has PCE deployed, the Cloud Manager can
     issue a path computation request, using PCEP to query the end to end
     path metrics and validate whether a PE to PE segment can meet
     specified SLA constraints.  If Segment Routing (SR-MPLS or SRv6) is
     deployed, these models can also include SR label stacks or SID lists
     needed for forwarding decisions.

     By querying the TE topology and tunnel models, the orchestrator can
     build a filtered set of feasible transport segments that support the
     expected latency and bandwidth for the AI workload.  This insight,
     combined with data from the Attachment Circuit models for Segments 1
     and 3, allows the orchestrator to make holistic decisions about AI
     workload placement and optimal traffic steering across the network.









  Dunbar, et al.           Expires 27 August 2026                [Page 12]


  Internet-Draft                 onions API                  February 2026


  3.3.  Non-TE-Based PE to PE Connectivity

     The previous sections assume that the transport network between
     Access PEs and Edge PEs is traffic-engineered and that the
     orchestrator has access to detailed models, such as ietf-TE-topology,
     ietf-TE, or SR policy models.  However, in some deployments,
     particularly those relying on Internet transit or best effort IP
     core, traffic engineering is not explicitly available.

     In these cases, performance visibility and decision-making must rely
     on more general network telemetry.  Useful data can still be obtained
     through IETF defined YANG models, including:

     - RFC 8343 (Interface Management YANG Model) and RFC 8344 (IP
     Management YANG Model) for retrieving interface status and link-level
     attributes

     - Operational telemetry models, such as ietf-system-telemetry or real
     time telemetry via YANG Push [RFC8641][RFC8639], to gather metrics
     such as interface utilization, packet loss, round trip time (RTT),
     and jitter, especially if measured using active probes or synthetic
     monitoring.

     The Cloud Manager's query can trigger the network orchestrator to
     collect and aggregate per-hop or per-segment metrics using these
     models or active measurements (similar to IP SLA).  The resulting
     data allows the Cloud Manager to estimate end-to-end path performance
     and make workload placement decisions accordingly, even if
     deterministic path selection or policy enforcement is not possible.

     While this approach lacks the fine-grained path control of TE-based
     networks, it still enables adaptive, network-aware service placement
     in less structured or loosely-managed environments.

  4.  Potential APIs for Kubernetes to Query Network Conditions

     This section outlines a potential onions API interface to enable
     Kubernetes (or its external workload orchestrators) to make network-
     aware workload placement decisions, such as selecting appropriate
     Edge Cloud sites for deploying latency-sensitive AI inference
     modules.

     Cloud-native platforms such as Kubernetes do not consume YANG-modeled
     data directly.  Instead, they rely on REST-style APIs or gRPC
     interfaces with JSON or protobuf-encoded payloads.  To support Neotec
     use cases, the network infrastructure can expose an abstracted API
     that translates YANG-modeled topology and performance data into a
     form consumable by Kubernetes or its scheduling extensions.



  Dunbar, et al.           Expires 27 August 2026                [Page 13]


  Internet-Draft                 onions API                  February 2026


     A representative onions API endpoint could take the form:


     GET /network-advisor/query-path-performance?
     source-node=<access-node-id>&target-node=<edge-site-id>


                            Figure 6: REST style API

     This API allows Kubernetes to query the performance of the network
     path between a street camera's access node (e.g., a WiFi AP or eNB/
     UPF) and a candidate Edge Cloud site.  The API response includes
     metrics such as available bandwidth, average path latency, and
     operational status.  A sample response might be:



     {
       "source-node": "AP-235",
       "target-node": "EdgeSite-4",
       "path-latency-ms": 6.5,
       "available-bandwidth-mbps": 920,
       "path-status": "healthy"
     }

                            Figure 7: JSON Response

  4.1.  Behavior and Semantics

     This API provides a read-only, low-latency interface for workload
     schedulers to assess whether a given path meets predefined service-
     level thresholds (e.g., latency less than 10 ms, bandwidth larger
     than 500 Mbps).  The source node and target node identifiers
     correspond to access nodes (e.g., PE routers adjacent to UPFs or WiFi
     APs) and Edge Cloud PE routers respectively.  These identifiers are
     assumed to be mapped within the operator domain.

     The semantics of the fields are as follows:

     - path-latency-ms: Derived from YANG-modeled metrics in ietf-TE-
     topology, representing end to end unidirectional delay.

     - available-bandwidth-mbps: Aggregated from TE-bandwidth in the same
     topology model.

     - path-status: Reflects operational state derived from oper-status
     fields in the TE and AC models.




  Dunbar, et al.           Expires 27 August 2026                [Page 14]


  Internet-Draft                 onions API                  February 2026


  4.2.  YANG Model Integration

     The backend implementation of this API is expected to query IETF
     defined YANG models using RESTCONF or NETCONF.  Specifically:

     - Topology and path delay metrics are sourced from the ietf-te-
     topology and ietf-network-topology models [RFC8795], [RFC8345].

     - Access circuit status and available bandwidth can be derived from
     the AC model [opsawg-teas-attachment-circuit].

     A shim layer exposes REST or gRPC APIs that accept requests from
     cloud managers (e.g., Kubernetes) and translates them into queries
     over IETF defined YANG data models using NETCONF or RESTCONF.  This
     architecture enables real-time network path evaluations without
     requiring cloud systems to interact directly with YANG or underlying
     network protocols.

  5.  Dynamic UCMP Load Balancing for Periodic Inter Site AI Traffic

     In the Neotec use case described in Section 1, AI inference modules
     are deployed across four Edge Cloud sites to support distributed city
     surveillance.  These modules periodically exchange large volumes of
     data, for instance, during result aggregation or synchronized event
     analysis.  These data exchanges are not continuous but are periodic
     and event driven, requiring guaranteed bandwidth and low latency for
     short time windows.

     The underlying network connecting these Edge Cloud sites typically
     includes multiple paths between nodes and across multiple network
     segments.An end-to-end path between Edge Cloud Site A and B spans at
     least three segments:

     - The first is the access segment from the Edge Cloud A to its
     closest PE.  There could be multipe PEs to Edge Cloud A for multi-
     homing.

     - The second segment traverses the provider transport network between
     the PE serving Edge Cloud A and the PE serving the Edge Cloud B.

     - The third segment connects that Edge PE to the Edge Cloud B's
     Gateway

  5.1.  Edge Cloud Site to Local PE (Access Segment)







  Dunbar, et al.           Expires 27 August 2026                [Page 15]


  Internet-Draft                 onions API                  February 2026


                             +-----------------------------+
                         |      Edge Cloud Site        |
                         | +------------------------+  |
                         | |   AI Inference Module  |  |
                         | +------------------------+  |
                         |             |               |
                         |     +----------------+      |
                         |     |  Edge Cloud GW |      |
                         |     +----------------+      |
                         +-------------|---------------+
                                       |
                          Multiple Attachment Circuits
                                       |
        +----------------+   +----------------+   +----------------+
        |     PE1        |   |      PE2       |   |      PE3       |
        +----------------+   +----------------+   +----------------+
               |                     |                    |
        Provider Network     Provider Network      Provider Network

                      Figure 8: Edge Cloud Access Segment

     The Edge Cloud Gateway has multiple logical links (attachment
     circuits) to a set of PEs (e.g., PE1, PE2, PE3).  These links may
     vary in latency, bandwidth, or current load.  During periodic AI data
     bursts, the Edge Cloud GW must push all other traffic away from PE1,
     PE2, and PE3, reserving their full available bandwidth for AI flows.
     Or it could push all other traffic to one of the PEs that has the
     lowest bandwidth and highest latency.  This can be implemented by
     dynamically updating forwarding policies or QoS profiles to
     deprioritize or reroute non-AI traffic, ensuring that the AI
     inference module has uncontested access to network capacity during
     critical synchronization windows.  Depending on the request from the
     Cloud Manager, the Network Orchestrator can determine what exact
     policies to push to the PEs and the Edge GW..

     YANG Data Models for Policy Enforcement:

     To support dynamic UCMP-based traffic steering across PE1, PE2, and
     PE3, the Network Orchestrator can utilize the following IETF YANG
     models:

     - ietf-routing [RFC8349] enables configuration of routing instances
     and static routes.  The data model allows per-prefix route entries
     with multiple weighted next hops, supporting unequal cost paths.  It
     can be used to define static next-hop policies from the Edge GW
     toward PE1, PE2, and PE3.





  Dunbar, et al.           Expires 27 August 2026                [Page 16]


  Internet-Draft                 onions API                  February 2026


     - ietf-qos-policy [I-D.claise-opsawg-qos-packet-marking] defines
     traffic classification, marking, and treatment policies.  It can
     enforce rate limits or scheduling priority for non-AI traffic routed
     to PE3.

     - ietf-ac [I-D.ietf-opsawg-teas-attachment-circuit] can provides
     performance characteristics (bandwidth, latency, packet loss), which
     inform the decision to assign traffic classes.

     - ietf-traffic-classifier / ietf-packet-policy (or OpenConfig
     equivalents) can be used to match traffic classes (e.g., AI vs non-AI
     flows), enables forwarding decisions at the Edge GW and ingress of
     PEs.

     Policy Example: Prioritized AI Flow Assignment and Non-AI Rerouting:

     Assuming PE1 has the highest available capacity and best latency
     toward the remote site:

     The orchestrator uses ietf-routing [RFC8349] to define weighted
     static next hops at the Edge GW:

     - PE1: 2/3 of AI traffic.

     - PE2: 1/3 of AI traffic.

     - PE3: no AI traffic.
























  Dunbar, et al.           Expires 27 August 2026                [Page 17]


  Internet-Draft                 onions API                  February 2026


   {
     "routing:routing": {
       "routing-instance": [
         {
           "name": "ai-routing-instance",
           "routing-protocols": {
             "routing-protocol": [
               {
                 "type": "static",
                 "name": "ai-policy",
                 "static-routes": {
                   "ipv4": {
                     "route": [
                       {
                         "destination-prefix": "198.51.100.0/24",
                         "next-hop": [
                           {"outgoing-interface": "to-PE1", "weight": 66},
                           {"outgoing-interface": "to-PE2", "weight": 34}
                         ]
                       }
                     ]
                   }
                 }
               }
             ]
           }
         }
       ]
     }
   }

                       Figure 9: UCMP policy example

     Non-AI traffic is matched by classifiers and redirected entirely to
     PE3:

     - Apply QoS policy using ietf-qos-policy [I-D.claise-opsawg-qos-
     packet-marking] to limit available bandwidth on PE3 to non-AI
     traffic.

     - PE3 may be tagged "degraded" in the ietf-ac model to signal its
     backup nature.

     This ensures that the AI traffic is prioritized through the most
     capable paths (PE1 and PE2) with precise weight.  All non-critical
     traffic is offloaded to the least-desired path (PE3), reducing
     congestion.  Orchestrator needs to dynamically adapt this logic per
     service request.



  Dunbar, et al.           Expires 27 August 2026                [Page 18]


  Internet-Draft                 onions API                  February 2026


     Fallback Logic: If available capacity on PE1 and PE2 is not
     sufficient, AI traffic still receives best possible routing via PE1
     and PE2, and Non-AI traffic may be allowed limited access to PE2 with
     reduced weight (e.g., 10%) while still primarily routed via PE3.

     This tiered policy enforcement ensures strict adherence to SLA goals
     for AI inference while maintaining service continuity for other
     traffic classes using standard YANG-based configuration interfaces.

  5.1.1.  Time-Scoped UCMP Policy Enforcement

     One critical limitation in existing IETF YANG models is the lack of
     native support for time-scoped UCMP policy activation.  To support
     the bursty nature of AI traffic, the following strategies can be
     applied:

     - Define policy activation via external triggers from the Cloud
     Manager using an API call to the orchestrator.

     - Orchestrator maintains a mapping between the requested activation
     time window and the temporary configuration to be applied.

     - Extend existing YANG models (e.g., ietf-routing or ietf-sr-policy)
     with optional augmentation for: start-time, duration, and expiration-
     action

     Example augmentation (conceptual):


     augment "/routing:routing/routing-instance/static-routes/route" {
       leaf burst-policy-start-time {
         type yang:date-and-time;
       }
       leaf burst-policy-duration-sec {
         type uint32;
       }
       leaf expiration-action {
         type enumeration {
           enum revert-to-default;
           enum retain;
         }
       }
     }


                        Figure 10: Example Augmentation





  Dunbar, et al.           Expires 27 August 2026                [Page 19]


  Internet-Draft                 onions API                  February 2026


     In the absence of standard YANG support, this behavior need to be
     implemented in the orchestrator logic by maintaining policy lifecycle
     state and timers, pushing temporary configuration via NETCONF/
     RESTCONF at start-time, and reverting after duration-sec.

  5.1.2.  UCMP Enforcement for SRv6 based PE to PE segment

     Assuming an SRv6 underlay among the PEs, the network controller can
     use the ietf-sr-policy YANG model to update the traffic distribution
     weights across pre-established paths.  For example, if three SRv6
     paths exist between EdgeSite-A and EdgeSite-C, the controller can
     push the following configuration to the ingress node:


     sr-policy {
       color 4001;
       endpoint "2001:db8:100::1";
       candidate-paths {
         preference 100;
         path {
           weight 70;
           sid-list [2001:db8:10::1, 2001:db8:11::2];
         }
         path {
           weight 20;
           sid-list [2001:db8:20::1, 2001:db8:21::2];
         }
         path {
           weight 10;
           sid-list [2001:db8:30::1, 2001:db8:31::2];
         }
       }
     }

                           Figure 11: Using SR Policy

     This UCMP configuration tells the network to distribute traffic
     unequally across the three paths based on their capability.  The
     underlying topology and metrics are derived from ietf-TE-topology and
     ietf-TE models, which expose bandwidth, latency, and available
     resources for each link.

     Similar UCMP behavior can also be implemented over SR-MPLS, MPLS-TE,
     or enhanced IP networks, using the corresponding IETF YANG models
     (ietf-TE, ietf-routing, etc.).  The key point is that the network
     paths are preexisting, and the only dynamic action is adjusting how
     traffic is forwarded among them in response to a cloud service
     request.



  Dunbar, et al.           Expires 27 August 2026                [Page 20]


  Internet-Draft                 onions API                  February 2026


  5.2.  Cloud-Initiated UCMP Activation API

     A simplified example of a cloud-initiated API call to the network
     controller might look like:



     POST /network-policy/ucmp-activation
     {
       "source-sites": ["EdgeSite-A", "EdgeSite-B"],
       "dest-sites": ["EdgeSite-C", "EdgeSite-D"],
       "start-time": "2025-05-01T10:00:00Z",
       "duration-sec": 300,
       "min-bandwidth-mbps": 5000,
       "max-latency-ms": 10
     }

                        Figure 12: Burst Network Request

     This request informs the network controller that a high-volume, low-
     latency data exchange will occur and that UCMP forwarding policies
     should be applied to optimize transport between the specified sites
     for the specified duration.

  6.  Gaps Between Existing IETF Specifications and Neotec Use Case Needs

     The Neotec use case, supporting real time, event driven placement and
     coordination of AI inference workloads across Edge Cloud sites,
     requires close interaction between cloud orchestration platforms and
     programmable transport networks.  While IETF has standardized robust
     YANG models for traffic engineering (e.g., ietf-te-topology, ietf-sr-
     policy, and ietf-ac), these models are network-internal, and fall
     short in addressing cloud-driven, time-scoped network adaptation
     requirements.

     This document evaluates two core capabilities against existing IETF
     YANG models:

     - Network-aware workload placement at Edge sites

     - Dynamic UCMP policy activation for inter-site AI data exchange

     From these exercises, the following gaps have been identified:








  Dunbar, et al.           Expires 27 August 2026                [Page 21]


  Internet-Draft                 onions API                  February 2026


  6.1.  Consumption Model Mismatch

     Most IETF YANG models are accessed via NETCONF/RESTCONF, and are
     designed for network operator tools.  In contrast, cloud-native
     environments rely on REST/gRPC APIs, JSON payloads, and declarative
     interfaces (e.g., Kubernetes CRDs).  There is no standardized
     translation layer that exposes network topology or path performance
     in a form consumable by external cloud orchestrators or AI services.

  6.2.  Lack of Time-Bounded, Cloud-Triggered Policy Interfaces

     In the UCMP use case, the cloud controller must be able to request
     changes in traffic distribution policy across existing network paths
     for a specific time window, such as when AI model instances begin
     inter-site synchronization.  Current IETF models (e.g., ietf-sr-
     policy) allow weighted path configuration but do not support time-
     scoping, activation triggers, or scheduling.  These functions are
     essential for on-demand, just-in-time optimization and must be added.

  6.3.  Absence of Intent and Workload-to-Flow Mapping

     There is no YANG model or API that allows the cloud controller to
     associate a workload (e.g., "AI inference service X") with network
     traffic that should receive enhanced treatment.  While SR policies
     can be assigned to colors or DSCPs, there is no abstracted intent
     interface for service-aware flow classification or network SLA
     expression based on application context.

  6.4.  Lack of Abstracted, Queryable Interfaces

     Even for read-only functions like path selection, there is no IETF-
     standardized API to answer high-level queries such as:

     - "Which Edge sites have less than 10ms latency from these access
     nodes?"

     - "What is the bandwidth-latency profile of the path from Access PE A
     to Edge PE B?"

     Operators must instead manually interpret TE link state and construct
     custom tooling.  A standardized API to query the aggregated path
     metrics between logical service endpoints is missing.









  Dunbar, et al.           Expires 27 August 2026                [Page 22]


  Internet-Draft                 onions API                  February 2026


  6.5.  Feedback and Acknowledgment Gaps

     There is no defined mechanism for the network controller to confirm
     whether a policy request (e.g., UCMP activation) was accepted or
     enforced, nor to notify the cloud when SLA targets are not being met
     during the activation window.  A bi-directional feedback channel is
     required to support closed-loop coordination between the cloud and
     the network.

  6.6.  Security and Access Control Framework Alignment

     While the IETF has defined robust identity and access control
     mechanisms (e.g., OAuth2, RPKI, TLS), integrating these mechanisms
     with cloud-native identity systems (such as Kubernetes RBAC, SPIFFE/
     SPIRE, or cloud IAM services) is still ad hoc.  A standard framework
     for mutual trust establishment and token exchange between cloud and
     network domains is needed to support secure onions APIs under Zero
     Trust principles.

  7.  Security Considerations

     To be added

  8.  IANA Considerations

     None

  9.  References

  9.1.  Normative References

  9.2.  Informative References

     [Neotec-Zerotrust-Access]
                L. Dunbar and H. Chihi, "Neotec-Zerotrust-Access",
                December 2024, <https://datatracker.ietf.org/doc/draft-
                dunchihi-neotec-zerotrust-access-dm/>.

     [opsawg-teas-attachment-circuit]
                M. Boucadair, et al, "opsawg-teas-attachment-circuit",
                January 2025, <https://datatracker.ietf.org/doc/draft-
                ietf-opsawg-teas-attachment-circuit/>.

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




  Dunbar, et al.           Expires 27 August 2026                [Page 23]


  Internet-Draft                 onions API                  February 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>.

     [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
                Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
                Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
                2018, <https://www.rfc-editor.org/info/rfc8345>.

     [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
                E., and A. Tripathy, "Subscription to YANG Notifications",
                RFC 8639, DOI 10.17487/RFC8639, September 2019,
                <https://www.rfc-editor.org/info/rfc8639>.

     [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
                for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
                September 2019, <https://www.rfc-editor.org/info/rfc8641>.

     [RFC8776]  Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
                "Common YANG Data Types for Traffic Engineering",
                RFC 8776, DOI 10.17487/RFC8776, June 2020,
                <https://www.rfc-editor.org/info/rfc8776>.

     [RFC8795]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
                O. Gonzalez de Dios, "YANG Data Model for Traffic
                Engineering (TE) Topologies", RFC 8795,
                DOI 10.17487/RFC8795, August 2020,
                <https://www.rfc-editor.org/info/rfc8795>.

     [TS.23.501-3GPP]
                3rd Generation Partnership Project (3GPP), "System
                Architecture for 5G System; Stage 2, 3GPP TS 23.501
                v2.0.1", December 2017.

  Acknowledgements

     The authors would like to thank for following for discussions and
     providing input to this document: xxx.

  Contributors

  Authors' Addresses

     Linda Dunbar (editor)
     Futurewei
     United States of America
     Email: ldunbar@futurewei.com




  Dunbar, et al.           Expires 27 August 2026                [Page 24]


  Internet-Draft                 onions API                  February 2026


     Qiong
     China Telecom
     China
     Email: sunqiong@chinatelecom.cn


     Wu Bo (editor)
     Huawei
     China
     Email: lana.wubo@huawei.com


     LUIS MIGUEL CONTRERAS MURILLO (editor)
     Telefornica
     Spain
     Email: luismiguel.contrerasmurillo@telefonica.com


     ChongFeng Xie
     China Telecom
     China
     Email: xiechf@chinatelecom.cn





























  Dunbar, et al.           Expires 27 August 2026                [Page 25]


name: draft-calabria-bmwg-ai-fabric-terminology
rev: 00
title: Benchmarking Terminology for AI Network Fabrics
time: 2026-02-27T09:02:34Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-30T17:54:33Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:11.000864+00:00
abstract:
  This document defines benchmarking terminology for evaluating
     Ethernet-based network fabrics used in distributed Artificial
     Intelligence (AI) training and inference workloads.  It provides a
     unified vocabulary consolidating and extending terms from RFC 1242,
     RFC 8238, and the companion AI fabric methodology documents,
     establishing precise, vendor-neutral definitions for collective
     communication primitives, RDMA transport mechanisms (RoCEv2 and Ultra
     Ethernet Transport), congestion control behaviors, AI-specific Key
     Performance Indicators (KPIs), and fabric topology concepts.

     This document is a companion to draft-bmwg-ai-fabric-training-
     bench-00 and draft-bmwg-ai-fabric-inference-bench-00.  Those
     documents SHOULD NOT be applied without first consulting the
     terminology defined herein.  Where definitions herein overlap with
     RFC 1242 or RFC 8238, the AI fabric context definition in this
     document takes precedence.

full_text:
  BMWG Working Group                                           F. Calabria
  Internet-Draft                                                     Cisco
  Intended status: Informational                              C. Pignataro
  Expires: 30 August 2026                             Blue Fern Consulting
                                                                     Q. Wu
                                                               G. Fioccola
                                                                    Huawei
                                                          26 February 2026


              Benchmarking Terminology for AI Network Fabrics
                draft-calabria-bmwg-ai-fabric-terminology-00

  Abstract

     This document defines benchmarking terminology for evaluating
     Ethernet-based network fabrics used in distributed Artificial
     Intelligence (AI) training and inference workloads.  It provides a
     unified vocabulary consolidating and extending terms from RFC 1242,
     RFC 8238, and the companion AI fabric methodology documents,
     establishing precise, vendor-neutral definitions for collective
     communication primitives, RDMA transport mechanisms (RoCEv2 and Ultra
     Ethernet Transport), congestion control behaviors, AI-specific Key
     Performance Indicators (KPIs), and fabric topology concepts.

     This document is a companion to draft-bmwg-ai-fabric-training-
     bench-00 and draft-bmwg-ai-fabric-inference-bench-00.  Those
     documents SHOULD NOT be applied without first consulting the
     terminology defined herein.  Where definitions herein overlap with
     RFC 1242 or RFC 8238, the AI fabric context definition in this
     document takes precedence.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://fcalabri.github.io/bmwg-ai-fabric-terminology/draft-calabria-
     bmwg-ai-fabric-terminology-00.html.  Status information for this
     document may be found at https://datatracker.ietf.org/doc/draft-
     calabria-bmwg-ai-fabric-terminology/.

     Source for this draft and an issue tracker can be found at
     https://github.com/fcalabri/bmwg-ai-fabric-terminology.







  Calabria, et al.         Expires 30 August 2026                 [Page 1]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


  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 30 August 2026.

  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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope and Purpose . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Relationship to Existing BMWG Work  . . . . . . . . . . .   3
       1.4.  Relationship to Companion Documents . . . . . . . . . . .   4
     2.  General Benchmarking Terms  . . . . . . . . . . . . . . . . .   4
     3.  Collective Communication Terms  . . . . . . . . . . . . . . .   6
     4.  Distributed Parallelism Strategy Terms  . . . . . . . . . . .   8
     5.  Network Transport Terms . . . . . . . . . . . . . . . . . . .   9
       5.1.  RoCEv2 and RDMA Terms . . . . . . . . . . . . . . . . . .   9
       5.2.  Ultra Ethernet Transport (UET) Terms  . . . . . . . . . .  11
         5.2.1.  UET Transport Services Comparison . . . . . . . . . .  12
     6.  Congestion Control and Fabric Behavior Terms  . . . . . . . .  13
       6.1.  Load Balancing Strategy Comparison  . . . . . . . . . . .  15
     7.  Fabric Topology and Infrastructure Terms  . . . . . . . . . .  16



  Calabria, et al.         Expires 30 August 2026                 [Page 2]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     8.  Training-Specific Terms . . . . . . . . . . . . . . . . . . .  18
     9.  Inference-Specific Terms  . . . . . . . . . . . . . . . . . .  19
       9.1.  Inference Phase Characteristics . . . . . . . . . . . . .  22
     10. KPI Classification Terms  . . . . . . . . . . . . . . . . . .  22
       10.1.  KPI Tier Summary . . . . . . . . . . . . . . . . . . . .  24
     11. Referenced Standards Abbreviations  . . . . . . . . . . . . .  24
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  26
     References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
       Normative References  . . . . . . . . . . . . . . . . . . . . .  26
       Informative References  . . . . . . . . . . . . . . . . . . . .  26
     Appendix A: Term Cross-Reference to Companion Documents . . . . .  27
     Appendix B: Term Taxonomy Summary . . . . . . . . . . . . . . . .  28
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

  1.  Introduction

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

  1.2.  Scope and Purpose

     This document defines terminology specifically for benchmarking
     Ethernet-based AI network fabrics in controlled laboratory
     environments.  The defined terms cover: distributed AI training
     collective communication patterns, LLM inference serving
     architectures, RDMA transport semantics (RoCEv2 and UET), congestion
     control mechanisms, fabric topology characteristics, and performance
     metric definitions.

     This document does not define acceptance criteria, performance
     requirements, or configuration recommendations.  It does not address
     benchmarking of live operational networks, intra-node (NVLink/PCIe)
     interconnects, or storage networking.

  1.3.  Relationship to Existing BMWG Work

     This document extends the foundational BMWG terminology established
     in [RFC1242] (network interconnect benchmarking terminology) and
     [RFC8238] (data center benchmarking terminology).  Where terms are
     defined in those RFCs, this document provides AI fabric context
     extensions; the core definitions remain as established.  This
     document also extends the test methodology framework of [RFC2544] and
     [RFC8239] as applied in the companion AI fabric methodology



  Calabria, et al.         Expires 30 August 2026                 [Page 3]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     documents.

  1.4.  Relationship to Companion Documents

     This document is one of three companion Internet-Drafts addressing AI
     fabric benchmarking:

     *  draft-bmwg-ai-fabric-terminology-00 (this document): Terminology
        definitions.

     *  [TRAINING-BENCH]: Benchmarking methodology for AI training
        workloads.

     *  [INFERENCE-BENCH]: Benchmarking methodology for AI inference
        serving workloads.

     Implementers and evaluators SHOULD read this terminology document
     before applying the companion methodology documents.  Terms defined
     here are used normatively in those documents and are not redefined
     there unless the specific workload context introduces a substantive
     difference, which is noted explicitly.

  2.  General Benchmarking Terms

     The following terms establish the general measurement framework
     applicable to all AI fabric benchmarking activities.

     +=============+====================================================+
     | Term        | Definition                                         |
     +=============+====================================================+
     | *AI Fabric* | The dedicated Ethernet backend network             |
     |             | interconnecting accelerators (GPUs/XPUs) for       |
     |             | distributed AI training and inference workloads.   |
     |             | Typically implemented as a non-blocking Clos (fat- |
     |             | tree) topology running RoCEv2 or UET transport.    |
     |             | Distinct from the front-end (management/storage)   |
     |             | network.                                           |
     +-------------+----------------------------------------------------+
     | *DUT*       | Device Under Test.  The network element(s) whose   |
     |             | performance characteristics are being measured.    |
     |             | In AI fabric benchmarking the DUT is one or more   |
     |             | fabric elements: leaf switches, spine switches,    |
     |             | NICs, or the complete fabric assembly.             |
     +-------------+----------------------------------------------------+
     | *SUT*       | System Under Test.  The complete AI compute system |
     |             | including accelerators, NICs, the fabric DUT, and  |
     |             | serving/training software, when end-to-end metrics |
     |             | are the measurement objective.                     |



  Calabria, et al.         Expires 30 August 2026                 [Page 4]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     +-------------+----------------------------------------------------+
     | *RT*        | Router Tester / Traffic Generator.  Test equipment |
     |             | capable of generating and receiving network        |
     |             | traffic at specified rates with nanosecond-        |
     |             | resolution timestamping sufficient for the         |
     |             | measurements defined in the companion methodology  |
     |             | documents.                                         |
     +-------------+----------------------------------------------------+
     | *JFI*       | Jain's Fairness Index.  A scalar measure of flow-  |
     |             | level throughput fairness across n flows: JFI =    |
     |             | (Σxᵢ)² / (n · Σxᵢ²) where xᵢ is the throughput of  |
     |             | flow i.  A value of 1.0 indicates perfect          |
     |             | fairness; lower values indicate disparity.         |
     |             | *SHOULD* be computed per [RFC1242] reporting       |
     |             | conventions.                                       |
     +-------------+----------------------------------------------------+
     | *Offered    | The total traffic rate presented to the DUT from   |
     | Load*       | test equipment, expressed as a fraction of line    |
     |             | rate (0–100%) or as absolute bit/s.  Offered load  |
     |             | is controlled independently of DUT absorption,     |
     |             | enabling characterization of saturation behavior.  |
     +-------------+----------------------------------------------------+
     | *Trial      | The time interval over which a single measurement  |
     | Duration*   | is conducted.  For AI fabric tests, the            |
     |             | *RECOMMENDED* minimum is 60 seconds for throughput |
     |             | tests and 300 seconds for soak/stability tests,    |
     |             | per the methodology in [RFC2544] as extended       |
     |             | herein.                                            |
     +-------------+----------------------------------------------------+
     | *Warmup     | A mandatory pre-measurement interval during which  |
     | Period*     | traffic is sent but results are not recorded.      |
     |             | Ensures adaptive routing tables, PFC watermarks,   |
     |             | and DCQCN/UET congestion controllers reach steady  |
     |             | state before measurement begins. *RECOMMENDED*     |
     |             | minimum: 10 seconds.                               |
     +-------------+----------------------------------------------------+
     | *Binary     | An iterative test procedure for determining the    |
     | Search*     | maximum offered load at which a DUT meets a        |
     |             | specified acceptance criterion (e.g., zero packet  |
     |             | loss).  The search halves the candidate load range |
     |             | at each iteration, converging to a resolution of   |
     |             | 0.1% offered load within 10 iterations.            |
     +-------------+----------------------------------------------------+
     | *Percentile | A latency statistic expressing that the specified  |
     | Latency*    | fraction of all measured latency samples fall at   |
     |             | or below the reported value.  Denoted Pxx (e.g.,   |
     |             | P50, P95, P99, P99.9).  Tail latency (P99 and      |
     |             | above) is especially relevant for AI fabric        |



  Calabria, et al.         Expires 30 August 2026                 [Page 5]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     |             | benchmarking because SLO violations are determined |
     |             | by worst-case, not median, performance.            |
     +-------------+----------------------------------------------------+

                     Table 1: General Benchmarking Terms

  3.  Collective Communication Terms

     The following terms define the collective communication operations
     that are the primary traffic sources in distributed AI workloads.

     +=================+================================================+
     | Term            | Definition                                     |
     +=================+================================================+
     | *Collective     | A coordinated communication pattern executed   |
     | Operation*      | simultaneously across all accelerators in a    |
     |                 | training or inference group.  Core             |
     |                 | collectives: AllReduce (gradient aggregation), |
     |                 | AllGather (parameter distribution),            |
     |                 | ReduceScatter (partial reduction + scatter),   |
     |                 | and AllToAll (expert dispatch in MoE models).  |
     +-----------------+------------------------------------------------+
     | *AllReduce*     | A collective in which each participant         |
     |                 | contributes a tensor and all participants      |
     |                 | receive the element-wise sum (or other         |
     |                 | reduction) of all contributions.  The dominant |
     |                 | communication primitive in data-parallel and   |
     |                 | tensor-parallel training.  BusBW is the        |
     |                 | primary KPI.                                   |
     +-----------------+------------------------------------------------+
     | *AllGather*     | A collective in which each participant         |
     |                 | contributes a shard of a tensor and all        |
     |                 | participants receive the concatenation of all  |
     |                 | shards.  Used in tensor-parallel (Megatron-    |
     |                 | style) layers to reconstruct distributed       |
     |                 | activations or parameters.                     |
     +-----------------+------------------------------------------------+
     | *ReduceScatter* | A collective combining an element-wise         |
     |                 | reduction with a scatter, so each participant  |
     |                 | receives a distinct slice of the reduced       |
     |                 | result.  Used in ZeRO-stage optimizer          |
     |                 | strategies and as the first half of a ring-    |
     |                 | AllReduce.                                     |
     +-----------------+------------------------------------------------+
     | *AllToAll*      | A collective in which each participant sends a |
     |                 | distinct payload to every other participant    |
     |                 | and receives a distinct payload from every     |
     |                 | other participant.  The critical collective    |



  Calabria, et al.         Expires 30 August 2026                 [Page 6]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     |                 | for Mixture-of-Experts token dispatch.         |
     |                 | Generates N²−1 independent point-to-point      |
     |                 | flows for N participants.                      |
     +-----------------+------------------------------------------------+
     | *Ring           | An AllReduce (or AllGather/ReduceScatter)      |
     | Algorithm*      | algorithm structured as a logical ring of      |
     |                 | participants.  Each participant sends to its   |
     |                 | right neighbor and receives from its left      |
     |                 | neighbor in 2(N−1) steps.  Bus bandwidth       |
     |                 | efficiency = 2(N−1)/N, approaching 100% for    |
     |                 | large N.  Standard baseline for BusBW          |
     |                 | calculation.                                   |
     +-----------------+------------------------------------------------+
     | *BusBW*         | Bus Bandwidth.  Effective per-accelerator      |
     |                 | throughput during a collective, normalizing    |
     |                 | for algorithm overhead: BusBW = (data_size ×   |
     |                 | algo_factor) / elapsed_time.  For ring         |
     |                 | AllReduce, algo_factor = 2(N−1)/N.  Enables    |
     |                 | comparison across cluster sizes and collective |
     |                 | algorithms.                                    |
     +-----------------+------------------------------------------------+
     | *CCL*           | Collective Communication Library.  A software  |
     |                 | library providing optimized implementations of |
     |                 | collective operations (AllReduce, AllGather,   |
     |                 | etc.) over a specific transport.  The CCL      |
     |                 | implementation *MUST* be documented in the     |
     |                 | test report.                                   |
     +-----------------+------------------------------------------------+
     | *SPMD*          | Single Program Multiple Data.  The execution   |
     |                 | model underlying bulk-synchronous distributed  |
     |                 | training, in which all accelerators execute    |
     |                 | identical computation on distinct data         |
     |                 | partitions, synchronizing at collective        |
     |                 | barriers between steps.                        |
     +-----------------+------------------------------------------------+
     | *Bulk           | A distributed computation model structured as  |
     | Synchronous     | alternating compute and communicate phases     |
     | Parallel (BSP)* | with a global synchronization barrier between  |
     |                 | phases.  Standard training workloads follow    |
     |                 | BSP: forward pass → backward pass → AllReduce  |
     |                 | gradient sync → optimizer step.                |
     +-----------------+------------------------------------------------+

                   Table 2: Collective Communication Terms







  Calabria, et al.         Expires 30 August 2026                 [Page 7]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


  4.  Distributed Parallelism Strategy Terms

     The following terms define the parallelism strategies used in
     distributed AI model training and inference, which determine traffic
     patterns and fabric requirements.

      +=============+==================================================+
      | Term        | Definition                                       |
      +=============+==================================================+
      | *Data       | A distributed training strategy replicating the  |
      | Parallelism | full model on each accelerator, partitioning the |
      | (DP)*       | training dataset across replicas.  Gradient      |
      |             | synchronization after each backward pass         |
      |             | requires an AllReduce across all DP ranks.       |
      |             | Memory-efficient for small models; communication |
      |             | overhead scales with parameter count.            |
      +-------------+--------------------------------------------------+
      | *Tensor     | A distributed training and inference strategy    |
      | Parallelism | partitioning individual weight matrices across   |
      | (TP)*       | multiple accelerators.  Each rank computes a     |
      |             | partial result; AllGather or ReduceScatter       |
      |             | collectives are required within each layer to    |
      |             | aggregate results.  Dominant parallelism within  |
      |             | a node (intra-node).                             |
      +-------------+--------------------------------------------------+
      | *Pipeline   | A distributed strategy assigning contiguous      |
      | Parallelism | groups of transformer layers to distinct stages  |
      | (PP)*       | (accelerators or nodes).  Each stage processes   |
      |             | one microbatch and forwards activations to the   |
      |             | next stage.  Generates point-to-point inter-     |
      |             | stage traffic across the fabric (activations and |
      |             | gradients).                                      |
      +-------------+--------------------------------------------------+
      | *Expert     | A parallelism strategy for Mixture-of-Experts    |
      | Parallelism | models distributing expert sub-networks across   |
      | (EP)*       | accelerators.  Each token is routed to its       |
      |             | designated experts (typically top-K of E total   |
      |             | experts), requiring AllToAll communication for   |
      |             | dispatch.  Wide EP (e.g., 96-way) generates      |
      |             | dense inter-node AllToAll at every MoE layer.    |
      +-------------+--------------------------------------------------+
      | *MoE*       | Mixture of Experts.  A transformer architecture  |
      |             | replacing dense feed-forward layers with a set   |
      |             | of E expert sub-networks, of which only top-K    |
      |             | experts (typically K=2 or K=4) are activated per |
      |             | token via a learned router.  MoE enables large   |
      |             | model capacity with sub-linear compute, but      |
      |             | introduces AllToAll communication requirements   |



  Calabria, et al.         Expires 30 August 2026                 [Page 8]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


      |             | proportional to E and sequence length.           |
      +-------------+--------------------------------------------------+
      | *DP         | Data Parallelism applied to the attention        |
      | Attention*  | computation, where the KV cache is partitioned   |
      |             | across data-parallel ranks.  Each rank holds 1/  |
      |             | DP_SIZE of the KV cache; AllToAll communication  |
      |             | exchanges attention outputs.  Used in inference  |
      |             | to reduce per-accelerator memory footprint for   |
      |             | long contexts.                                   |
      +-------------+--------------------------------------------------+
      | *ZeRO*      | Zero Redundancy Optimizer.  A memory             |
      |             | optimization strategy for data-parallel training |
      |             | that shards model states (parameters, gradients, |
      |             | optimizer states) across DP ranks instead of     |
      |             | replicating them.  Stage 1 shards optimizer      |
      |             | states; Stage 2 adds gradient sharding; Stage 3  |
      |             | adds parameter sharding.  Each stage increases   |
      |             | AllGather/ReduceScatter communication.           |
      +-------------+--------------------------------------------------+

               Table 3: Distributed Parallelism Strategy Terms

  5.  Network Transport Terms

  5.1.  RoCEv2 and RDMA Terms

     The following terms define RDMA and RoCEv2 transport semantics as
     used in AI fabric benchmarking.

      +===========+====================================================+
      | Term      | Definition                                         |
      +===========+====================================================+
      | *RDMA*    | Remote Direct Memory Access.  A transport          |
      |           | mechanism enabling direct memory-to-memory data    |
      |           | transfer between hosts without involving the       |
      |           | destination CPU, providing zero-copy semantics and |
      |           | kernel bypass.  Implementations include InfiniBand |
      |           | Verbs (native IB), iWARP (RDMA over TCP), and      |
      |           | RoCEv2 (RDMA over Converged Ethernet v2).          |
      +-----------+----------------------------------------------------+
      | *RoCEv2*  | RDMA over Converged Ethernet version 2.  An RDMA   |
      |           | transport encapsulating InfiniBand transport layer |
      |           | (BTH) over UDP/IP, enabling RDMA semantics on      |
      |           | standard Ethernet infrastructure.  Requires        |
      |           | lossless fabric operation (PFC or equivalent) for  |
      |           | correctness.  Standardized in IBTA Annex 16;       |
      |           | transported over UDP destination port 4791.        |
      +-----------+----------------------------------------------------+



  Calabria, et al.         Expires 30 August 2026                 [Page 9]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


      | *QP*      | Queue Pair.  The fundamental RDMA communication    |
      |           | endpoint comprising a Send Queue (SQ) and Receive  |
      |           | Queue (RQ).  QPs are connection-oriented in        |
      |           | Reliable Connected (RC) mode.  Multiple QPs per    |
      |           | source-destination pair are used to increase ECMP  |
      |           | entropy in fabric load balancing.                  |
      +-----------+----------------------------------------------------+
      | *Reliable | An RDMA QP transport service type providing        |
      | Connected | reliable, in-order delivery between exactly two    |
      | (RC)*     | endpoints.  The primary QP type for AI collective  |
      |           | operations via RoCEv2.  Requires connection setup  |
      |           | before data transfer and maintains per-QP state    |
      |           | for retransmission.                                |
      +-----------+----------------------------------------------------+
      | *RDMA     | An operation primitive of the RDMA programming     |
      | Verb*     | model.  Key verbs: SEND/RECV (two-sided, receiver  |
      |           | must post a buffer), WRITE (one-sided, target      |
      |           | memory written directly), READ (one-sided, remote  |
      |           | memory read), and Atomic (compare-and-swap, fetch- |
      |           | and-add).  AI collectives predominantly use WRITE  |
      |           | and SEND.                                          |
      +-----------+----------------------------------------------------+
      | *UET*     | Ultra Ethernet Transport.  A transport protocol    |
      |           | defined by the Ultra Ethernet Consortium (UEC)     |
      |           | Specification 1.0 as a next-generation AI/HPC      |
      |           | fabric transport.  UET is connectionless, supports |
      |           | native packet spraying (RUD), and integrates       |
      |           | multipath load balancing and congestion control.   |
      |           | Transported over UDP destination port 4793         |
      |           | (pending IANA verification).                       |
      +-----------+----------------------------------------------------+
      | *PDC*     | Packet Delivery Context.  The ephemeral,           |
      |           | lightweight transport endpoint in UET, analogous   |
      |           | to but distinct from an RDMA Queue Pair.  PDCs are |
      |           | connectionless (no setup handshake), enabling low- |
      |           | latency initiation and reduced per-flow state in   |
      |           | the NIC and switch.                                |
      +-----------+----------------------------------------------------+
      | *ROD*     | Reliable Ordered Delivery.  A UET transport        |
      |           | service providing reliable, in-order packet        |
      |           | delivery, semantically equivalent to RoCEv2 RC     |
      |           | mode.  Suitable for legacy RDMA applications       |
      |           | requiring strict ordering guarantees.              |
      +-----------+----------------------------------------------------+

               Table 4: Distributed Parallelism Strategy Terms





  Calabria, et al.         Expires 30 August 2026                [Page 10]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


  5.2.  Ultra Ethernet Transport (UET) Terms

     The following terms define UET-specific concepts introduced by the
     Ultra Ethernet Consortium (UEC) Specification 1.0 [UEC-SPEC-1.0].

     +===========+=======================================================+
     | Term      | Definition                                            |
     +===========+=======================================================+
     | *RUD*     | Reliable Unordered Delivery.  A UET transport         |
     |           | service providing reliable delivery without           |
     |           | maintaining packet order across paths.  Enables       |
     |           | native packet spraying across ECMP paths without      |
     |           | reorder-buffer overhead at the receiver NIC.  The     |
     |           | preferred UET service class for AI training           |
     |           | collectives.                                          |
     +-----------+-------------------------------------------------------+
     | *RUDI*    | Reliable Unordered Delivery for Idempotent            |
     |           | operations.  A UET transport service optimized for    |
     |           | operations safe to execute more than once (e.g.,      |
     |           | RDMA Writes to non-accumulating targets), allowing    |
     |           | simplified retransmission logic with reduced state    |
     |           | overhead.                                             |
     +-----------+-------------------------------------------------------+
     | *UUD*     | Unreliable Unordered Delivery.  A UET transport       |
     |           | service providing best-effort, unordered packet       |
     |           | delivery with minimal overhead.  Suitable for         |
     |           | telemetry, speculative operations, or workloads       |
     |           | with application-layer loss tolerance.                |
     +-----------+-------------------------------------------------------+
     | *UEC      | A defined subset of UET features targeting a          |
     | Profile*  | specific use case: AI Base (core AI training/         |
     |           | inference, mandatory feature set), AI Full (AI Base   |
     |           | plus deferred send, exact-match tagging, extended     |
     |           | atomics), or HPC (latency-optimized for traditional   |
     |           | HPC workloads with fine-grained synchronization).     |
     +-----------+-------------------------------------------------------+
     | *LLR*     | Link Layer Retry.  An optional UEC link-layer         |
     |           | enhancement providing fast per-hop error recovery     |
     |           | at the Ethernet link layer.  LLR detects symbol       |
     |           | errors at the FEC level and retransmits the           |
     |           | affected frame before it is dropped, reducing the     |
     |           | frequency of transport-layer retransmission and       |
     |           | improving tail latency.                               |
     +-----------+-------------------------------------------------------+
     | *Packet   | An optional UEC link-layer behavior in which a        |
     | Trimming* | congested switch, rather than dropping the full       |
     |           | packet, transmits only the packet header (trimmed     |
     |           | packet) to the receiver.  Trimming enables the        |



  Calabria, et al.         Expires 30 August 2026                [Page 11]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     |           | receiver to detect loss and initiate selective        |
     |           | retransmission more rapidly, reducing bandwidth       |
     |           | waste versus silent drop.                             |
     +-----------+-------------------------------------------------------+
     | *CBFC*    | Credit-Based Flow Control.  An optional UEC link-     |
     |           | layer buffer management mechanism using explicit      |
     |           | credit grants from downstream to upstream devices.    |
     |           | CBFC provides backpressure without transmitting PFC   |
     |           | PAUSE frames, eliminating the head-of-line blocking   |
     |           | and storm propagation risks associated with PFC.      |
     +-----------+-------------------------------------------------------+
     | *Entropy  | A per-packet field in the UET header used to          |
     | Value*    | distribute packets of a single message across         |
     |           | available ECMP paths, providing explicit spray        |
     |           | entropy independent of the IP 5-tuple.  Enables       |
     |           | hardware-assisted packet spraying without requiring   |
     |           | transport-layer state in the switch.                  |
     +-----------+-------------------------------------------------------+
     | *GIN*     | GPU-Initiated Networking.  A communication paradigm   |
     |           | in which GPU threads directly initiate network RDMA   |
     |           | operations (sends, one-sided writes/reads) to the     |
     |           | NIC hardware without CPU involvement, eliminating     |
     |           | the CPU-GPU synchronization round-trip.  Reduces      |
     |           | effective latency by several microseconds for fine-   |
     |           | grained operations.                                   |
     +-----------+-------------------------------------------------------+
     | *KVCXL*   | KV Cache Transfer Library.  A software library        |
     |           | providing standardized point-to-point data transfer   |
     |           | primitives (register, transfer, notify) for           |
     |           | inference engines, abstracting underlying transport   |
     |           | mechanisms (intra-node interconnect, RDMA, PCIe,      |
     |           | storage interfaces).  Enables transport-agnostic KV   |
     |           | cache migration in disaggregated serving              |
     |           | architectures.                                        |
     +-----------+-------------------------------------------------------+

                 Table 5: Ultra Ethernet Transport (UET) Terms

  5.2.1.  UET Transport Services Comparison

      +=========+=========+==========+================+================+
      | Service | Ordered | Reliable | Retransmission | Primary Use    |
      |         |         |          | Complexity     | Case           |
      +=========+=========+==========+================+================+
      | *ROD*   | Yes     | Yes      | Full per-QP    | Legacy RDMA /  |
      |         |         |          | state          | ordered AI ops |
      +---------+---------+----------+----------------+----------------+
      | *RUD*   | No      | Yes      | Reduced        | AI training    |



  Calabria, et al.         Expires 30 August 2026                [Page 12]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


      |         |         |          | (unordered)    | collectives    |
      |         |         |          |                | with spray     |
      +---------+---------+----------+----------------+----------------+
      | *RUDI*  | No      | Yes      | Minimal        | RDMA Writes;   |
      |         |         |          | (idempotent)   | simple         |
      |         |         |          |                | retransmit     |
      +---------+---------+----------+----------------+----------------+
      | *UUD*   | No      | No       | None           | Telemetry,     |
      |         |         |          |                | speculative    |
      |         |         |          |                | ops            |
      +---------+---------+----------+----------------+----------------+

                  Table 6: UET Transport Services Comparison

  6.  Congestion Control and Fabric Behavior Terms

     The following terms define congestion management mechanisms and
     associated fabric behaviors critical to AI workload performance.

     +===========+=======================================================+
     | Term      | Definition                                            |
     +===========+=======================================================+
     | *PFC*     | Priority Flow Control (IEEE 802.1Qbb).  A             |
     |           | lossless Ethernet mechanism in which a receiver       |
     |           | transmits a PAUSE frame to its upstream               |
     |           | neighbor on a specific priority class when its        |
     |           | ingress buffer approaches a configured                |
     |           | threshold, temporarily halting transmission of        |
     |           | that priority.  Required for lossless RoCEv2          |
     |           | operation.  PFC operates hop-by-hop and can           |
     |           | propagate congestion upstream (PFC storm risk).       |
     +-----------+-------------------------------------------------------+
     | *PFC      | A pathological condition in which PFC PAUSE           |
     | Storm*    | frames propagate across multiple hops, causing        |
     |           | widespread throughput degradation or deadlock         |
     |           | unrelated to the original congestion source.          |
     |           | Detection and mitigation *SHOULD* be part of          |
     |           | soak test evaluation per the companion                |
     |           | methodology documents.                                |
     +-----------+-------------------------------------------------------+
     | *PFC      | A circular PFC dependency in which sets of            |
     | Deadlock* | flows mutually pause each other indefinitely,         |
     |           | resulting in zero progress for affected traffic       |
     |           | classes.  Deadlock risk is elevated in non-tree       |
     |           | topologies and *MUST* be evaluated in fabric-         |
     |           | level soak tests.                                     |
     +-----------+-------------------------------------------------------+
     | *ECN*     | Explicit Congestion Notification ([RFC3168]).         |



  Calabria, et al.         Expires 30 August 2026                [Page 13]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     |           | An IP-layer mechanism in which a congested            |
     |           | router marks packets with the Congestion              |
     |           | Experienced (CE) codepoint in the IP ECN field        |
     |           | instead of dropping them.  The receiver echoes        |
     |           | congestion feedback to the sender via the             |
     |           | transport protocol, triggering rate reduction.        |
     |           | Used with RoCEv2 as part of DCQCN.                    |
     +-----------+-------------------------------------------------------+
     | *DCQCN*   | Data Center Quantized Congestion Notification.        |
     |           | An end-to-end congestion control algorithm for        |
     |           | RoCEv2 flows, combining ECN marking at                |
     |           | congested switches with rate-based sender             |
     |           | reduction using an AIMD scheme.  Note: PFC            |
     |           | serves as a separate, orthogonal backstop to          |
     |           | prevent packet loss during DCQCN convergence;         |
     |           | PFC is *not* a component of the DCQCN algorithm       |
     |           | itself.                                               |
     +-----------+-------------------------------------------------------+
     | *ECN      | The fraction of packets (expressed as a               |
     | Marking   | percentage) that are marked with the CE               |
     | Ratio*    | codepoint in the IP ECN field over a                  |
     |           | measurement interval.  A high ECN Marking Ratio       |
     |           | indicates persistent congestion and is a              |
     |           | primary Fabric Health Indicator.                      |
     +-----------+-------------------------------------------------------+
     | *Incast*  | A traffic pattern in which multiple sources           |
     |           | simultaneously send to a single destination,          |
     |           | potentially overwhelming the destination's NIC        |
     |           | receive buffer and the switch's egress port           |
     |           | buffer.  Incast is a dominant congestion              |
     |           | mechanism in AllReduce and collective                 |
     |           | operations.                                           |
     +-----------+-------------------------------------------------------+
     | *Incast   | The ratio of concurrent senders to receivers in       |
     | Ratio*    | an incast communication pattern (N:1).  The           |
     |           | incast ratio determines the oversubscription          |
     |           | factor at the destination port and is a primary       |
     |           | test parameter for congestion characterization.       |
     +-----------+-------------------------------------------------------+
     | *Packet   | A load balancing strategy distributing                |
     | Spray*    | individual packets of a single RDMA message           |
     |           | across all available ECMP paths, maximizing           |
     |           | link utilization at the cost of potential out-        |
     |           | of-order delivery at the receiver.  Native in         |
     |           | UET (RUD mode); requires NIC reorder buffering        |
     |           | for RoCEv2 RC mode.                                   |
     +-----------+-------------------------------------------------------+
     | *DLB /    | Dynamic Load Balancing using flowlet detection.       |



  Calabria, et al.         Expires 30 August 2026                [Page 14]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     | Flowlet*  | A per-flow rerouting mechanism that reassigns a       |
     |           | flow to a new ECMP path when the flow has been        |
     |           | idle longer than the flowlet gap threshold            |
     |           | (typically 500 ns–2 µs), reducing out-of-order        |
     |           | packet risk compared to packet spray while            |
     |           | improving utilization over static per-flow            |
     |           | ECMP.                                                 |
     +-----------+-------------------------------------------------------+
     | *ECMP*    | Equal-Cost Multi-Path routing.  A forwarding          |
     |           | mechanism distributing traffic across multiple        |
     |           | equal-cost paths, typically via hash of the IP        |
     |           | 5-tuple (or entropy field in UET).  ECMP              |
     |           | imbalance (MMR > 1.0) is a primary fabric             |
     |           | efficiency metric for AI traffic.                     |
     +-----------+-------------------------------------------------------+
     | *MMR*     | Max-Mean Ratio.  The ratio of the flow count          |
     |           | (or traffic load) on the most heavily utilized        |
     |           | link to the average flow count per link across        |
     |           | all fabric links.  MMR = 1.0 indicates perfect        |
     |           | ECMP balance; MMR > 1.0 quantifies imbalance          |
     |           | that degrades effective fabric bandwidth.             |
     +-----------+-------------------------------------------------------+

             Table 7: Congestion Control and Fabric Behavior Terms

  6.1.  Load Balancing Strategy Comparison

     +============+=============+============+=============+============+
     | Strategy   | Granularity | Reorder    | Utilization | Complexity |
     |            |             | Risk       |             |            |
     +============+=============+============+=============+============+
     | *ECMP      | Per-flow    | None       | Low         | Low        |
     | (5-tuple   |             |            | (elephant   |            |
     | hash)*     |             |            | flow bias)  |            |
     +------------+-------------+------------+-------------+------------+
     | *DLB /     | Per-flowlet | Low        | Medium      | Medium     |
     | Flowlet*   |             |            |             |            |
     +------------+-------------+------------+-------------+------------+
     | *Packet    | Per-packet  | High       | High        | High (NIC  |
     | Spray      |             |            |             | reorder    |
     | (RoCEv2)*  |             |            |             | buffer)    |
     +------------+-------------+------------+-------------+------------+
     | *Packet    | Per-packet  | None       | High        | Low        |
     | Spray (UET |             | (transport |             |            |
     | RUD)*      |             | tolerates  |             |            |
     |            |             | OOO)       |             |            |
     +------------+-------------+------------+-------------+------------+




  Calabria, et al.         Expires 30 August 2026                [Page 15]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


                 Table 8: Load Balancing Strategy Comparison

  7.  Fabric Topology and Infrastructure Terms

     The following terms define fabric topology architectures and
     infrastructure components referenced in the companion methodology
     documents.

      +===================+=============================================+
      | Term              | Definition                                  |
      +===================+=============================================+
      | *Clos / Fat-Tree  | A multi-stage switch topology providing     |
      | Topology*         | non-blocking or oversubscribed connectivity |
      |                   | between all leaf-to-leaf pairs.  In AI      |
      |                   | fabric deployments, a two-tier (leaf-spine) |
      |                   | or three-tier (leaf-spine-superspine) Clos  |
      |                   | is standard.  Full bisection bandwidth      |
      |                   | (1:1) is the target for training fabrics;   |
      |                   | 2:1 or 4:1 oversubscription may be          |
      |                   | acceptable for inference fabrics.           |
      +-------------------+---------------------------------------------+
      | *Rail-Optimized   | A topology in which the NIC ports of each   |
      | Topology*         | server are distributed across multiple ToR  |
      |                   | switches (one NIC port per switch), such    |
      |                   | that collective traffic between adjacent    |
      |                   | servers traverses different physical paths. |
      |                   | Minimizes switch-to-switch traffic during   |
      |                   | ring AllReduce, maximizing effective BusBW. |
      |                   | Requires ECMP-aware collective placement.   |
      +-------------------+---------------------------------------------+
      | *Bisection        | The aggregate bandwidth across the minimum  |
      | Bandwidth*        | cut that divides the fabric into two equal  |
      |                   | halves.  Non-blocking fabrics provide       |
      |                   | bisection bandwidth equal to half the total |
      |                   | edge (server-facing) bandwidth.  Limits     |
      |                   | worst-case all-to-all communication         |
      |                   | throughput.                                 |
      +-------------------+---------------------------------------------+
      | *Oversubscription | The ratio of total edge (server-facing)     |
      | Ratio*            | bandwidth to total bisection bandwidth in a |
      |                   | Clos fabric.  A 1:1 ratio is non-blocking;  |
      |                   | higher ratios (e.g., 2:1, 4:1) reduce       |
      |                   | fabric cost but may bottleneck all-to-all   |
      |                   | and AllReduce patterns when all server      |
      |                   | ports are active simultaneously.            |
      +-------------------+---------------------------------------------+
      | *ToR Switch*      | Top-of-Rack switch.  The first-hop          |
      |                   | aggregation switch connecting accelerator   |



  Calabria, et al.         Expires 30 August 2026                [Page 16]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


      |                   | servers in a rack to the spine layer of the |
      |                   | fabric.  In rail-optimized topologies,      |
      |                   | multiple ToR switches serve a single rack,  |
      |                   | with each server's NICs distributed across  |
      |                   | ToRs.                                       |
      +-------------------+---------------------------------------------+
      | *Spine /          | Intermediate and top-layer switches in a    |
      | Superspine*       | multi-tier Clos fabric, providing inter-    |
      |                   | rack and inter-pod connectivity             |
      |                   | respectively.  Spine switches aggregate     |
      |                   | multiple ToR switches; superspine switches  |
      |                   | aggregate multiple spine pods.              |
      +-------------------+---------------------------------------------+
      | *NIC*             | Network Interface Controller.  The hardware |
      |                   | device providing network connectivity for   |
      |                   | an accelerator host.  AI fabric NICs        |
      |                   | support RDMA (RoCEv2 or UET), hardware      |
      |                   | offload for collective operations, and,     |
      |                   | optionally, GPU-Initiated Networking (GIN). |
      |                   | NIC model and firmware version *MUST* be    |
      |                   | documented in all benchmark reports.        |
      +-------------------+---------------------------------------------+
      | *Buffer           | The instantaneous or time-averaged fill     |
      | Occupancy*        | level of a switch port's packet buffer,     |
      |                   | expressed in bytes or as a fraction of      |
      |                   | total buffer capacity.  Elevated sustained  |
      |                   | buffer occupancy indicates congestion.  P99 |
      |                   | buffer occupancy is a Fabric Health         |
      |                   | Indicator in the companion methodology      |
      |                   | documents.                                  |
      +-------------------+---------------------------------------------+
      | *Zero-Impact      | Sub-microsecond automatic path convergence  |
      | Failover*         | upon a link or switch failure resulting in  |
      |                   | no measurable increase to JCT or TTFT.      |
      |                   | Requires pre-programmed alternate paths and |
      |                   | hardware-level fast reroute (FRR) with sub- |
      |                   | microsecond detection, not relying on       |
      |                   | routing protocol convergence.               |
      +-------------------+---------------------------------------------+
      | *Link             | The fraction of the nominal link capacity   |
      | Utilization*      | actually used for data transmission over a  |
      |                   | measurement interval, expressed as a        |
      |                   | percentage.  Reported as mean, P95, and P99 |
      |                   | per link.  High asymmetric link utilization |
      |                   | (low average but high peak) is              |
      |                   | characteristic of bursty AI inference       |
      |                   | traffic.                                    |
      +-------------------+---------------------------------------------+



  Calabria, et al.         Expires 30 August 2026                [Page 17]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


               Table 9: Fabric Topology and Infrastructure Terms

  8.  Training-Specific Terms

     The following terms are specific to AI training workload benchmarking
     and are used normatively in [TRAINING-BENCH].

      +==================+==============================================+
      | Term             | Definition                                   |
      +==================+==============================================+
      | *JCT*            | Job Completion Time.  The wall-clock elapsed |
      |                  | time from the start of a training job (or    |
      |                  | benchmark iteration) until all participating |
      |                  | accelerators complete their work, inclusive  |
      |                  | of all forward pass, backward pass, and      |
      |                  | collective communication phases.  JCT is the |
      |                  | primary end-to-end training efficiency KPI.  |
      +------------------+----------------------------------------------+
      | *Roofline JCT*   | The theoretical minimum JCT assuming perfect |
      |                  | (zero-contention, zero-queuing) network      |
      |                  | behavior: Roofline JCT = computation_time +  |
      |                  | serialization_delay, where                   |
      |                  | serialization_delay = message_size /         |
      |                  | link_rate.  Provides a reference for         |
      |                  | evaluating fabric overhead.                  |
      +------------------+----------------------------------------------+
      | *JCT Ratio*      | The ratio of measured JCT to Roofline JCT.   |
      |                  | A value of 1.0 indicates no network-induced  |
      |                  | overhead.  Values > 1.0 quantify fabric      |
      |                  | inefficiency: JCT Ratio = JCT_measured /     |
      |                  | JCT_roofline.  The JCT Ratio is the primary  |
      |                  | comparative metric for AI training fabric    |
      |                  | benchmarking.                                |
      +------------------+----------------------------------------------+
      | *Gradient        | The AllReduce collective operation performed |
      | Synchronization* | after the backward pass of each training     |
      |                  | step to sum the locally computed gradients   |
      |                  | across all data-parallel replicas.  The      |
      |                  | dominant communication event in data-        |
      |                  | parallel training, occurring once per        |
      |                  | training step per layer.                     |
      +------------------+----------------------------------------------+
      | *Step Time*      | The wall-clock duration of a single training |
      |                  | iteration (forward pass + backward pass +    |
      |                  | gradient synchronization + optimizer step).  |
      |                  | Step time = computation time + communication |
      |                  | time, where the communication time is        |
      |                  | dominated by the AllReduce collective.       |



  Calabria, et al.         Expires 30 August 2026                [Page 18]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


      +------------------+----------------------------------------------+
      | *Soak Test*      | A sustained-load test run for an extended    |
      |                  | period (minimum 24 hours for stability       |
      |                  | evaluation) at a defined offered load        |
      |                  | fraction (e.g., 70% or 90% of maximum        |
      |                  | throughput).  Soak tests detect buffer       |
      |                  | leaks, ECMP imbalance drift, PFC storm       |
      |                  | initiation, and long-tail error accumulation |
      |                  | not visible in short-duration tests.         |
      +------------------+----------------------------------------------+

                       Table 10: Training-Specific Terms

  9.  Inference-Specific Terms

     The following terms are specific to AI inference serving workload
     benchmarking and are used normatively in [INFERENCE-BENCH].

     +==================+================================================+
     | Term             | Definition                                     |
     +==================+================================================+
     | *TTFT*           | Time to First Token.  The elapsed time         |
     |                  | from receipt of an inference request by        |
     |                  | the serving system to emission of the          |
     |                  | first output token.  Encompasses prompt        |
     |                  | processing (prefill), KV cache generation,     |
     |                  | optional KV cache transfer (in                 |
     |                  | disaggregated architectures), and the          |
     |                  | initial decode step.  Interactive serving      |
     |                  | target: TTFT < 500 ms at P99.                  |
     +------------------+------------------------------------------------+
     | *ITL*            | Inter-Token Latency.  The elapsed time         |
     |                  | between successive output tokens during        |
     |                  | the autoregressive decode phase.  Measured     |
     |                  | at P50, P95, P99, and P99.9 to                 |
     |                  | characterize tail latency behavior.            |
     |                  | Interactive serving target: ITL < 50 ms at     |
     |                  | P99.                                           |
     +------------------+------------------------------------------------+
     | *TPS*            | Tokens Per Second.  Aggregate throughput       |
     |                  | of the inference serving system, measured      |
     |                  | as the total number of output tokens           |
     |                  | generated per second across all concurrent     |
     |                  | requests.  Reported separately for input-      |
     |                  | side (prefill) TPS and output-side             |
     |                  | (decode) TPS.                                  |
     +------------------+------------------------------------------------+
     | *KV Cache*       | Key-Value Cache.  The intermediate             |



  Calabria, et al.         Expires 30 August 2026                [Page 19]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     |                  | attention state (key and value projection      |
     |                  | matrices from multi-head attention layers)     |
     |                  | computed during the prefill phase and          |
     |                  | reused during each decode step to avoid        |
     |                  | redundant recomputation.  KV cache size        |
     |                  | scales with: layers × attention_heads ×        |
     |                  | head_dim × sequence_length × precision.        |
     |                  | The attention head configuration *MUST* be     |
     |                  | reported in all benchmark results.             |
     +------------------+------------------------------------------------+
     | *Prefill Phase*  | The compute-bound phase of LLM inference       |
     |                  | in which the entire input prompt is            |
     |                  | processed in parallel to generate the KV       |
     |                  | cache and the first output token.              |
     |                  | Characterized by high arithmetic intensity     |
     |                  | (200–400 ops/byte), high accelerator           |
     |                  | utilization (90–95%), and large activation     |
     |                  | tensors.  Prefill latency dominates TTFT       |
     |                  | for long prompts.                              |
     +------------------+------------------------------------------------+
     | *Decode Phase*   | The memory-bandwidth-bound phase of LLM        |
     |                  | inference in which output tokens are           |
     |                  | generated autoregressively, one token per      |
     |                  | forward pass, by reading the KV cache.         |
     |                  | Characterized by low arithmetic intensity      |
     |                  | (60–80 ops/byte), lower accelerator            |
     |                  | utilization (20–40%), and memory-              |
     |                  | bandwidth-limited KV cache reads.  Decode      |
     |                  | throughput limits TPS.                         |
     +------------------+------------------------------------------------+
     | *Disaggregated   | An inference serving architecture in which     |
     | Serving*         | the prefill phase and decode phase are         |
     |                  | executed on physically separate groups of      |
     |                  | accelerators (workers), connected by a         |
     |                  | network fabric.  Allows independent            |
     |                  | scaling of prefill and decode resources        |
     |                  | (xPyD) but introduces KV cache transfer as     |
     |                  | a fabric-critical data movement.               |
     +------------------+------------------------------------------------+
     | *xPyD Ratio*     | The allocation ratio of x prefill workers      |
     |                  | to y decode workers in a disaggregated         |
     |                  | serving cluster.  Example: 3P9D denotes 3      |
     |                  | prefill nodes and 9 decode nodes.  The         |
     |                  | optimal xPyD ratio depends on model size,      |
     |                  | prompt/output length distributions, and        |
     |                  | TTFT/ITL SLO targets.                          |
     +------------------+------------------------------------------------+
     | *Continuous      | A dynamic inference scheduling technique       |



  Calabria, et al.         Expires 30 August 2026                [Page 20]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     | Batching*        | that inserts new requests into an active       |
     |                  | decode batch as slots become available         |
     |                  | (without waiting for the current batch to      |
     |                  | complete), improving accelerator               |
     |                  | utilization compared to static batching.       |
     |                  | Generates variable batch sizes that affect     |
     |                  | fabric traffic burstiness.                     |
     +------------------+------------------------------------------------+
     | *PagedAttention* | A KV cache memory management technique         |
     |                  | storing attention keys and values in           |
     |                  | fixed-size, non-contiguous virtual pages       |
     |                  | (typically 16–64 KB), inspired by OS           |
     |                  | virtual memory management.  Reduces memory     |
     |                  | fragmentation and enables efficient KV         |
     |                  | cache sharing across requests with common      |
     |                  | prefixes.                                      |
     +------------------+------------------------------------------------+
     | *Prefix Caching* | Reuse of previously computed KV cache          |
     |                  | segments for inference requests sharing a      |
     |                  | common prompt prefix (e.g., a fixed system     |
     |                  | prompt), eliminating redundant prefill         |
     |                  | computation.  Prefix cache hit rate is a       |
     |                  | secondary KPI for inference serving            |
     |                  | efficiency.                                    |
     +------------------+------------------------------------------------+
     | *Normal          | An AllToAll MoE dispatch communication         |
     | Dispatch*        | mode optimized for the prefill phase.          |
     |                  | Payload sizes are variable (depending on       |
     |                  | token-to-expert routing), generating           |
     |                  | dynamic tensor shapes incompatible with        |
     |                  | static graph capture.  Maximizes               |
     |                  | throughput for large batches at the cost       |
     |                  | of higher per-dispatch latency.                |
     +------------------+------------------------------------------------+
     | *Low-Latency     | An AllToAll MoE dispatch communication         |
     | Dispatch*        | mode optimized for the decode phase.           |
     |                  | Payload sizes are padded to fixed maximum      |
     |                  | dimensions (compatible with static graph       |
     |                  | capture), enabling lower kernel-launch         |
     |                  | overhead at the cost of slight bandwidth       |
     |                  | inefficiency.  Target: < 200 µs per            |
     |                  | dispatch round trip.                           |
     +------------------+------------------------------------------------+
     | *SLO*            | Service Level Objective.  A quantitative       |
     |                  | target for an inference serving KPI.  AI       |
     |                  | inference SLOs typically specify maximum       |
     |                  | TTFT (e.g., < 500 ms P99) and maximum ITL      |
     |                  | (e.g., < 50 ms P99) under a specified          |



  Calabria, et al.         Expires 30 August 2026                [Page 21]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     |                  | request arrival rate.                          |
     +------------------+------------------------------------------------+
     | *Speculative     | An inference acceleration technique using      |
     | Decoding*        | a small draft model to generate candidate      |
     |                  | token sequences verified in parallel by        |
     |                  | the target model.  Reduces effective ITL       |
     |                  | but generates bursty, variable-length KV       |
     |                  | cache traffic; noted as a future               |
     |                  | benchmarking area not fully specified in       |
     |                  | the current companion documents.               |
     +------------------+------------------------------------------------+

                       Table 11: Inference-Specific Terms

  9.1.  Inference Phase Characteristics

      +===========+===============+============+=============+=========+
      | Phase     | Compute Bound | Arithmetic | Accelerator | Primary |
      |           |               | Intensity  | Util.       | KPI     |
      +===========+===============+============+=============+=========+
      | *Prefill* | Yes           | 200–400    | 90–95%      | TTFT    |
      |           |               | ops/byte   |             |         |
      +-----------+---------------+------------+-------------+---------+
      | *Decode*  | No (memory BW | 60–80 ops/ | 20–40%      | ITL,    |
      |           | bound)        | byte       |             | TPS     |
      +-----------+---------------+------------+-------------+---------+

                  Table 12: Inference Phase Characteristics

  10.  KPI Classification Terms

     The following terms define the three-tier KPI taxonomy used across
     both companion methodology documents.


















  Calabria, et al.         Expires 30 August 2026                [Page 22]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     +============+======================================================+
     | Term       | Definition                                           |
     +============+======================================================+
     | *Primary   | A top-level performance indicator directly           |
     | KPI*       | representing end-user experience or training         |
     |            | efficiency.  In training: JCT Ratio and BusBW.  In   |
     |            | inference: TTFT and ITL.  Primary KPIs are the       |
     |            | principal reporting metric and the basis for         |
     |            | comparative benchmarking across DUT                  |
     |            | implementations.                                     |
     +------------+------------------------------------------------------+
     | *Secondary | A fabric-level performance indicator providing       |
     | KPI*       | mechanistic explanation for primary KPI values.      |
     |            | Examples: collective operation throughput (BusBW),   |
     |            | KV cache transfer goodput, AllToAll dispatch         |
     |            | latency, ECMP imbalance (MMR), and link              |
     |            | utilization.  Secondary KPIs enable root-cause       |
     |            | analysis of Primary KPI deviations.                  |
     +------------+------------------------------------------------------+
     | *Fabric    | An operational metric characterizing fabric          |
     | Health     | stability and anomaly conditions rather than peak    |
     | Indicator  | performance.  FHIs include: PFC event rate, PFC      |
     | (FHI)*     | storm occurrence, ECN marking ratio, packet loss     |
     |            | rate, buffer occupancy (P99), and retransmission     |
     |            | rate.  FHIs *SHOULD* be continuously monitored and   |
     |            | reported throughout all test categories.             |
     +------------+------------------------------------------------------+
     | *Goodput*  | The application-useful data delivered per unit       |
     |            | time, excluding retransmitted packets, protocol      |
     |            | overhead, and padding.  Goodput may differ           |
     |            | significantly from raw throughput during congestion  |
     |            | events; both *SHOULD* be reported in benchmarking    |
     |            | results.                                             |
     +------------+------------------------------------------------------+
     | *Zero      | A test acceptance criterion requiring that no        |
     | Packet     | packets are dropped by the DUT during the            |
     | Loss*      | measurement interval.  For RoCEv2 and UET            |
     |            | transports, zero packet loss is the target           |
     |            | operating condition.  The binary search procedure    |
     |            | in the companion methodology documents determines    |
     |            | the maximum offered load satisfying this criterion.  |
     +------------+------------------------------------------------------+

                       Table 13: KPI Classification Terms







  Calabria, et al.         Expires 30 August 2026                [Page 23]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


  10.1.  KPI Tier Summary

     +============+=================+==================+=================+
     | Tier       | Training        | Inference        | Purpose         |
     |            | Examples        | Examples         |                 |
     +============+=================+==================+=================+
     | *Primary   | JCT Ratio,      | TTFT, ITL, TPS   | Direct end-user |
     | KPI*       | BusBW           |                  | experience /    |
     |            |                 |                  | business impact |
     +------------+-----------------+------------------+-----------------+
     | *Secondary | AllReduce       | AllToAll         | Root cause      |
     | KPI*       | BusBW, MMR,     | dispatch         | analysis of     |
     |            | Link            | latency, KV      | Primary KPI     |
     |            | Utilization     | transfer goodput | deviations      |
     +------------+-----------------+------------------+-----------------+
     | *Fabric    | PFC events,     | PFC events, ECN  | Ongoing fabric  |
     | Health     | ECN ratio,      | ratio, packet    | stability and   |
     | Indicator  | packet loss,    | loss, buffer P99 | anomaly         |
     | (FHI)*     | buffer P99,     |                  | detection       |
     |            | retx rate       |                  |                 |
     +------------+-----------------+------------------+-----------------+

                           Table 14: KPI Tier Summary

  11.  Referenced Standards Abbreviations

     The following abbreviations refer to normative and informative IETF
     documents referenced throughout this document and the companion
     methodology documents.






















  Calabria, et al.         Expires 30 August 2026                [Page 24]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     +===========+=======================================================+
     | Reference | Definition                                            |
     +===========+=======================================================+
     | *RFC      | "Benchmarking Terminology for Network                 |
     | 1242*     | Interconnect Devices" (Bradner, 1991).  Defines       |
     |           | foundational benchmarking terms (throughput,          |
     |           | latency, frame loss rate, back-to-back frames).       |
     |           | The baseline terminology reference for BMWG           |
     |           | work.  Where terms in this document overlap           |
     |           | with RFC 1242 definitions, the AI fabric              |
     |           | context definitions herein take precedence.           |
     +-----------+-------------------------------------------------------+
     | *RFC      | "Benchmarking Methodology for Network                 |
     | 2544*     | Interconnect Devices" (Bradner & McQuaid,             |
     |           | 1999).  Defines test methodologies for                |
     |           | throughput, latency, frame loss rate, and back-       |
     |           | to-back measurements.  The AI fabric                  |
     |           | methodology documents extend RFC 2544                 |
     |           | procedures for AI-specific traffic patterns and       |
     |           | test durations.                                       |
     +-----------+-------------------------------------------------------+
     | *RFC      | "Data Center Benchmarking Terminology" (Bitar         |
     | 8238*     | et al., 2017).  Extends RFC 1242 with data            |
     |           | center-relevant terms including forwarding            |
     |           | table scaling, congestion, and VM/SDN.  Incast,       |
     |           | ECN, and buffer occupancy concepts in this            |
     |           | document align with RFC 8238 definitions.             |
     +-----------+-------------------------------------------------------+
     | *RFC      | "Data Center Benchmarking Methodology" (Bitar         |
     | 8239*     | et al., 2017).  Defines test methodologies for        |
     |           | data center network functions including incast,       |
     |           | ECN marking, and lossless behavior.  The AI           |
     |           | fabric companion methodology documents extend         |
     |           | RFC 8239 for distributed AI collective traffic        |
     |           | patterns.                                             |
     +-----------+-------------------------------------------------------+
     | *RFC 2119 | "Key words for use in RFCs to Indicate                |
     | / RFC     | Requirement Levels" (Bradner, 1997; Leiba,            |
     | 8174*     | 2017).  Define the normative requirement              |
     |           | language: MUST, MUST NOT, REQUIRED, SHALL,            |
     |           | SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED,           |
     |           | MAY, and OPTIONAL.  RFC 8174 clarifies that           |
     |           | these terms are normative only when in                |
     |           | uppercase; lowercase uses are not normative.          |
     +-----------+-------------------------------------------------------+

                  Table 15: Referenced Standards Abbreviations




  Calabria, et al.         Expires 30 August 2026                [Page 25]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


  Acknowledgments

     TODO acknowledge.

  References

  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/rfc/rfc2119>.

     [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
                Network Interconnect Devices", RFC 2544,
                DOI 10.17487/RFC2544, March 1999,
                <https://www.rfc-editor.org/rfc/rfc2544>.

     [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/rfc/rfc8174>.

  Informative References

     [IBTA-ROCE]
                InfiniBand Trade Association, "InfiniBand Architecture
                Specification, Annex 16: RoCE", 2010,
                <https://www.infinibandta.org>.

     [INFERENCE-BENCH]
                Calabria, F. and C. Pignataro, "Benchmarking Methodology
                for AI Inference Serving Network Fabrics", Work in
                Progress, Internet-Draft, draft-bmwg-ai-fabric-inference-
                bench-00, February 2026,
                <https://datatracker.ietf.org/doc/html/draft-bmwg-ai-
                fabric-inference-bench-00>.

     [RFC1242]  Bradner, S., "Benchmarking Terminology for Network
                Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
                July 1991, <https://www.rfc-editor.org/rfc/rfc1242>.

     [RFC8238]  Avramov, L. and J. Rapp, "Data Center Benchmarking
                Terminology", RFC 8238, DOI 10.17487/RFC8238, August 2017,
                <https://www.rfc-editor.org/rfc/rfc8238>.

     [RFC8239]  Avramov, L. and J. Rapp, "Data Center Benchmarking
                Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017,
                <https://www.rfc-editor.org/rfc/rfc8239>.



  Calabria, et al.         Expires 30 August 2026                [Page 26]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     [TRAINING-BENCH]
                Calabria, F. and C. Pignataro, "Benchmarking Methodology
                for AI Training Network Fabrics", Work in Progress,
                Internet-Draft, draft-bmwg-ai-fabric-training-bench-00,
                February 2026, <https://datatracker.ietf.org/doc/html/
                draft-bmwg-ai-fabric-training-bench-00>.

     [UEC-SPEC-1.0]
                Ultra Ethernet Consortium, "Ultra Ethernet Specification
                1.0", 2024, <https://ultraethernet.org>.

  Appendix A: Term Cross-Reference to Companion Documents

     The following table identifies which terms from this document are
     used in each companion methodology document.

      +====================+====================+=======================+
      | Term Category      | Used in Training   | Used in Inference     |
      |                    | Bench              | Bench                 |
      +====================+====================+=======================+
      | General            | All terms          | All terms             |
      | Benchmarking Terms |                    |                       |
      | (§2)               |                    |                       |
      +--------------------+--------------------+-----------------------+
      | Collective         | AllReduce,         | AllToAll, BusBW       |
      | Communication (§3) | AllGather,         |                       |
      |                    | ReduceScatter,     |                       |
      |                    | AllToAll, BusBW,   |                       |
      |                    | CCL, Ring          |                       |
      |                    | Algorithm, BSP,    |                       |
      |                    | SPMD               |                       |
      +--------------------+--------------------+-----------------------+
      | Parallelism        | DP, TP, PP, EP,    | EP, MoE, DP Attention |
      | Strategies (§4)    | MoE, ZeRO          |                       |
      +--------------------+--------------------+-----------------------+
      | RDMA / RoCEv2      | RDMA, RoCEv2, QP,  | RDMA, RoCEv2, QP, RC  |
      | (§5.1)             | RC mode, RDMA Verb | mode, GIN, KVCXL      |
      +--------------------+--------------------+-----------------------+
      | UET Terms (§5.2)   | UET, PDC, ROD,     | UET, RUD, GIN         |
      |                    | RUD, RUDI, UUD,    |                       |
      |                    | LLR, Packet        |                       |
      |                    | Trimming, CBFC,    |                       |
      |                    | UEC Profile,       |                       |
      |                    | Entropy Value      |                       |
      +--------------------+--------------------+-----------------------+
      | Congestion Control | PFC, PFC Storm,    | PFC, ECN, DCQCN,      |
      | (§6)               | PFC Deadlock, ECN, | Incast, Packet Spray, |
      |                    | DCQCN, ECN Marking | ECMP                  |



  Calabria, et al.         Expires 30 August 2026                [Page 27]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


      |                    | Ratio, Incast,     |                       |
      |                    | Incast Ratio,      |                       |
      |                    | Packet Spray, DLB/ |                       |
      |                    | Flowlet, ECMP, MMR |                       |
      +--------------------+--------------------+-----------------------+
      | Fabric Topology    | Clos, Rail-        | Clos, Bisection BW,   |
      | (§7)               | Optimized,         | ToR, NIC, Buffer      |
      |                    | Bisection BW,      | Occupancy, Link       |
      |                    | Oversubscription,  | Utilization           |
      |                    | ToR, Spine, NIC,   |                       |
      |                    | Buffer Occupancy,  |                       |
      |                    | Zero-Impact        |                       |
      |                    | Failover, Link     |                       |
      |                    | Utilization        |                       |
      +--------------------+--------------------+-----------------------+
      | Training-Specific  | JCT, Roofline JCT, | Soak Test             |
      | (§8)               | JCT Ratio,         |                       |
      |                    | Gradient Sync,     |                       |
      |                    | Step Time, Soak    |                       |
      |                    | Test               |                       |
      +--------------------+--------------------+-----------------------+
      | Inference-Specific | —                  | TTFT, ITL, TPS, KV    |
      | (§9)               |                    | Cache, Prefill,       |
      |                    |                    | Decode, Disaggregated |
      |                    |                    | Serving, xPyD,        |
      |                    |                    | Continuous Batching,  |
      |                    |                    | PagedAttention,       |
      |                    |                    | Prefix Caching,       |
      |                    |                    | Normal/Low-Latency    |
      |                    |                    | Dispatch, SLO         |
      +--------------------+--------------------+-----------------------+
      | KPI Classification | Primary KPI (JCT   | Primary KPI (TTFT,    |
      | (§10)              | Ratio, BusBW),     | ITL), Secondary KPI,  |
      |                    | Secondary KPI,     | FHI, Goodput, Zero    |
      |                    | FHI, Goodput, Zero | Packet Loss           |
      |                    | Packet Loss        |                       |
      +--------------------+--------------------+-----------------------+

             Table 16: Term Cross-Reference to Companion Documents

  Appendix B: Term Taxonomy Summary

     The following table provides a concise summary of all defined terms
     organized by category, with the section reference for the full
     definition.






  Calabria, et al.         Expires 30 August 2026                [Page 28]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     +=========+====================================+====================+
     | Section | Term(s)                            | Category           |
     +=========+====================================+====================+
     | 2       | DUT, SUT, RT, JFI, Offered         | General            |
     |         | Load, Trial Duration, Warmup       | Benchmarking       |
     |         | Period, Binary Search,             |                    |
     |         | Percentile Latency, AI             |                    |
     |         | Fabric                             |                    |
     +---------+------------------------------------+--------------------+
     | 3       | Collective Operation,              | Collective         |
     |         | AllReduce, AllGather,              | Communication      |
     |         | ReduceScatter, AllToAll,           |                    |
     |         | Ring Algorithm, BusBW, CCL,        |                    |
     |         | SPMD, BSP                          |                    |
     +---------+------------------------------------+--------------------+
     | 4       | Data Parallelism, Tensor           | Parallelism        |
     |         | Parallelism, Pipeline              | Strategies         |
     |         | Parallelism, Expert                |                    |
     |         | Parallelism, MoE, DP               |                    |
     |         | Attention, ZeRO                    |                    |
     +---------+------------------------------------+--------------------+
     | 5.1     | RDMA, RoCEv2, QP, Reliable         | Transport — RDMA / |
     |         | Connected (RC), RDMA Verb,         | RoCEv2             |
     |         | UET, PDC, ROD                      |                    |
     +---------+------------------------------------+--------------------+
     | 5.2     | RUD, RUDI, UUD, UEC Profile,       | Transport — UET    |
     |         | LLR, Packet Trimming, CBFC,        |                    |
     |         | Entropy Value, GIN, KVCXL          |                    |
     +---------+------------------------------------+--------------------+
     | 6       | PFC, PFC Storm, PFC                | Congestion Control |
     |         | Deadlock, ECN, DCQCN, ECN          |                    |
     |         | Marking Ratio, Incast,             |                    |
     |         | Incast Ratio, Packet Spray,        |                    |
     |         | DLB/Flowlet, ECMP, MMR             |                    |
     +---------+------------------------------------+--------------------+
     | 7       | Clos/Fat-Tree, Rail-               | Fabric Topology    |
     |         | Optimized, Bisection               |                    |
     |         | Bandwidth, Oversubscription        |                    |
     |         | Ratio, ToR Switch, Spine/          |                    |
     |         | Superspine, NIC, Buffer            |                    |
     |         | Occupancy, Zero-Impact             |                    |
     |         | Failover, Link Utilization         |                    |
     +---------+------------------------------------+--------------------+
     | 8       | JCT, Roofline JCT, JCT             | Training-Specific  |
     |         | Ratio, Gradient                    |                    |
     |         | Synchronization, Step Time,        |                    |
     |         | Soak Test                          |                    |
     +---------+------------------------------------+--------------------+



  Calabria, et al.         Expires 30 August 2026                [Page 29]


  Internet-Draft     AI Fabric Benchmarking Terminology      February 2026


     | 9       | TTFT, ITL, TPS, KV Cache,          | Inference-Specific |
     |         | Prefill Phase, Decode Phase,       |                    |
     |         | Disaggregated Serving, xPyD        |                    |
     |         | Ratio, Continuous Batching,        |                    |
     |         | PagedAttention, Prefix             |                    |
     |         | Caching, Normal Dispatch,          |                    |
     |         | Low-Latency Dispatch, SLO,         |                    |
     |         | Speculative Decoding               |                    |
     +---------+------------------------------------+--------------------+
     | 10      | Primary KPI, Secondary KPI,        | KPI Classification |
     |         | Fabric Health Indicator,           |                    |
     |         | Goodput, Zero Packet Loss          |                    |
     +---------+------------------------------------+--------------------+
     | 11      | RFC 1242, RFC 2544, RFC            | Referenced         |
     |         | 8238, RFC 8239, RFC                | Standards          |
     |         | 2119/8174                          |                    |
     +---------+------------------------------------+--------------------+

                        Table 17: Complete Term Taxonomy

  Authors' Addresses

     Fernando Calabria
     Cisco
     Email: fcalabri@cisco.com


     Carlos Pignataro
     Blue Fern Consulting
     Email: carlos@bluefern.consulting


     Qin Wu
     Huawei
     Email: bill.wu@huawei.com


     Giuseppe Fioccola
     Huawei
     Email: giuseppe.fioccola@huawei.com











  Calabria, et al.         Expires 30 August 2026                [Page 30]


name: draft-ruan-spring-priority-flow-control-sid
rev: 03
title: SRv6 behavior extention for Flow Control in WAN
time: 2026-02-27T10:13:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T10:13:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "A2A protocols"]
tags: []
fetched_at: 2026-03-03T15:50:11.000879+00:00
abstract:
  In the wake of the continuous emergence of novel AI technologies,
     including collaborative training, distributed inference and the like,
     the scenario in which different data centers communicate via the RDMA
     (Remote Direct Memory Access) protocol has emerged as a new
     requirement. similar to data center networks, wide area networks
     (WANs) should also be equipped with certain flow control
     capabilities, nodes in the wide area network (WAN) need to quickly
     and accurately notify upstream traffic nodes of their congestion
     status.  Upon receiving the congestion notification, upstream nodes
     can take responsive actions to mitigate network congestion.  By
     extending SRv6[RFC 8986] technology, specific services can be carried
     over SRv6 policies, which enables the precise delivery and response
     of congestion signals.

     For traffic carried over SRv6 policies, the service traffic path is
     explicitly orchestrated via the Segment List in the SRH header.  By
     parsing the sequence of the Segment List, downstream nodes or
     controllers can accurately identify the upstream nodes and interfaces
     corresponding to the current traffic, thus enabling the rapid
     notification of congestion information to the upstream.  Since each
     SID in the Segment List is a 128-bit IPv6 address that represents a
     specific behaviour (e.g., End, End.X), extending existing behaviours
     to mark their capability to receive and process congestion signals
     allows flexible control over the delivery mode of congestion signals
     in the WAN.

     The specific packet formats and contents of congestion signals vary
     in various ways and are continuously being updated.  This document
     takes the most commonly used PFC backpressure notification mechanism
     as an example to elaborate on the overall workflow of WAN congestion
     information notification and the extensions to the SRv6 protocol.
     PFC technology is widely deployed in RoCEv2 networks within data
     centers to report congestion signals.  By leveraging SRv6 and NRP
     technologies, it is possible to effectively control the propagation
     range and path of PFC backpressure signals in wide area networks,
     thereby avoiding issues such as deadlocks and the excessive
     propagation of congestion scope.

full_text:
  SPRING                                                      Z. Ruan, Ed.
  Internet-Draft                                              China Unicom
  Intended status: Standards Track                             Y. Liu, Ed.
  Expires: 31 August 2026                                              ZTE
                                                               M. Han, Ed.
                                                                    Z. Han
                                                                    Y. Liu
                                                              China Unicom
                                                          27 February 2026


              SRv6 behavior extention for Flow Control in WAN
               draft-ruan-spring-priority-flow-control-sid-03

  Abstract

     In the wake of the continuous emergence of novel AI technologies,
     including collaborative training, distributed inference and the like,
     the scenario in which different data centers communicate via the RDMA
     (Remote Direct Memory Access) protocol has emerged as a new
     requirement. similar to data center networks, wide area networks
     (WANs) should also be equipped with certain flow control
     capabilities, nodes in the wide area network (WAN) need to quickly
     and accurately notify upstream traffic nodes of their congestion
     status.  Upon receiving the congestion notification, upstream nodes
     can take responsive actions to mitigate network congestion.  By
     extending SRv6[RFC 8986] technology, specific services can be carried
     over SRv6 policies, which enables the precise delivery and response
     of congestion signals.

     For traffic carried over SRv6 policies, the service traffic path is
     explicitly orchestrated via the Segment List in the SRH header.  By
     parsing the sequence of the Segment List, downstream nodes or
     controllers can accurately identify the upstream nodes and interfaces
     corresponding to the current traffic, thus enabling the rapid
     notification of congestion information to the upstream.  Since each
     SID in the Segment List is a 128-bit IPv6 address that represents a
     specific behaviour (e.g., End, End.X), extending existing behaviours
     to mark their capability to receive and process congestion signals
     allows flexible control over the delivery mode of congestion signals
     in the WAN.

     The specific packet formats and contents of congestion signals vary
     in various ways and are continuously being updated.  This document
     takes the most commonly used PFC backpressure notification mechanism
     as an example to elaborate on the overall workflow of WAN congestion
     information notification and the extensions to the SRv6 protocol.
     PFC technology is widely deployed in RoCEv2 networks within data



  Ruan, et al.             Expires 31 August 2026                 [Page 1]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


     centers to report congestion signals.  By leveraging SRv6 and NRP
     technologies, it is possible to effectively control the propagation
     range and path of PFC backpressure signals in wide area networks,
     thereby avoiding issues such as deadlocks and the excessive
     propagation of congestion scope.

  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 31 August 2026.

  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.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Conventions and Definitions . . . . . . . . . . . . . . .   5
       1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  End.X.PFC behavior  . . . . . . . . . . . . . . . . . . . . .   5
     3.  Using End.X.PFC Behavior For Congestion Notification  . . . .   7
     4.  OAM Considerations  . . . . . . . . . . . . . . . . . . . . .   8
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9



  Ruan, et al.             Expires 31 August 2026                 [Page 2]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     With the continuous emergence of new AI technologies such as
     collaborative training and distributed inference, the scenario in
     which different data centers communicate via the RDMA (Remote Direct
     Memory Access) protocol has emerged as a new requirement.

     Given the high sensitivity of RDMA technology to packet loss, PFC
     technology is widely deployed in RoCEv2 networks within data centers.
     The working flow of PFC is shown in Figure 1, which is mainly
     composed of the following steps:

    ...............................................................................
    .                                                                             .
    .  +--------------------+                          +--------------------+     .
    .  |            queues  |                          |  buffers           |     .
    .  |          |  1st |  |                          | |  1st  |          |     .
    .  |          |  2nd |  |  PFC backpressure frame  | |  2nd  |          |     .
    .  |          |  3rd |  |  <---------------------  | |  3rd  |          |     .
    .  |          |  4th |  |------------------------- | |  4th  |          |     .
    .  |          |  5th |  |    Ethernet Link         | |  5th  |          |     .
    .  |          |  6th |  |                          | |  6th  |          |     .
    .  |          |  7th |  |                          | |  7th  |          |     .
    .  |          |  8th |  |                          | |  8th  |          |     .
    .  +--------------------+                          +--------------------+     .
    .    Device A (sender)                                Device B (receiver)     .
    .................................. ............................................

                Figure 1: Diagram of PFC Working Mechanism

     a.  Devices supporting PFC have multiple priority queues on the
     transmit interface, and the receive interface has an equal number of
     receive buffers.

     b.When a receive buffer on a downstream device (such as Device B)
     becomes congested, that is, the queue buffer is consumed quickly and
     exceeds a certain threshold (such as 1/2 or 3/4 of the port queue
     buffer), the corresponding mechanism will be triggered.

     c.Device B detects congestion sends a back-pressure signal "STOP" to
     the upstream device (Device A) in the data-entry direction.





  Ruan, et al.             Expires 31 August 2026                 [Page 3]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


     d.After receiving the back-pressure signal, the upstream device
     (Device A) stops sending the packets of the corresponding priority
     queue according to the signal indication and stores the data in the
     local interface buffer.  If the consumption of the local interface
     buffer of Device A also exceeds the threshold, it will continue to
     apply back-pressure to the upstream.

     e.When the congestion situation of the receive buffer is alleviated,
     that is, the used buffer of the queue is reduced below the PFC
     threshold, the receiving device (device B) will send a PFC back-
     pressure stop message to the upstream to notify the upstream device
     to send packets again and resume the traffic transmission of the
     corresponding priority queue.

  1.1.  Requirements

     In the scenario of cross-data center communication, back-pressure
     frames may need to be propagated across wide area networks.  The
     transmission conditions of wide area networks are much more
     complicated than those of data center networks, and thus will face
     some constraints.

     a.  Tenant-Granular Back-pressure In the wide area network scenario,
     a physical link may carry the services of multiple tenants
     simultaneously.In order to avoid the mutual influence of traffic
     among different tenants,back-pressure signaling should support
     tenant-level granularity,this can be achieved by leveraging the
     technology of SRv6[RFC 8986]and Enhanced VPN[draft-ietf-spring-sr-
     for-enhanced-vpn-10] .

     b.  Legacy Device Constraints There is a wide variety of devices in
     the wide area network, and many of them do not support congestion
     notification,upgrading all the equipment is uneconomical and
     difficult to implement.As a result, in many scenarios, backpressure
     packets cannot be transmitted hop by hop as in the data center
     network.Therefore, a more flexible method for conveying congestion
     signals is needed.

     Take the Figure 2 diagram as an example.The direction of traffic is
     R1 -> R2 -> R3-> R4-> R5.  Among them, R1 and R5 support the
     generation and processing of back-pressure signals, while the device
     R2,R3,R4 does not support it.  When congestion occurs on the
     interface between R5 and DC2, if the back-pressure signal can be
     transmitted to the corresponding interface of R1 in a timely manner,
     then it can be ensured that there will be no packet loss in the
     traffic.  Therefore, a mechanism is needed that enables R5 to
     perceive the device and interface among the upstream devices of the
     current traffic that support the processing of back-pressure signals.



  Ruan, et al.             Expires 31 August 2026                 [Page 4]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


                                 +----+       +----+
                                 | R3 |-------| R4 |
                                 +----+       +----+
                                 /               \
                                /                 \
                               /                   \
                              /                     \
                +-----+   +----+     +----+      +----+    +------+
                | DC1 |---| R1 |-----| R2 |------| R5 |--- | DC2  |
                +-----+   +----+     +----+      +----+    +------+

                    Figure 2: Topo for Cross-DC WAN network

  1.2.  Conventions and Definitions

  1.3.  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.  End.X.PFC behavior

     The "Endpoint with L3 cross-connect and Priority-based Flow Control"
     behavior (abbreviated as "End.X.PFC") is a variant of the End.X
     behavior defined in [RFC8986].  Based on the original End.X behavior,
     it incorporates additional meanings to facilitate the identification
     of interfaces in the network that possess the capability to handle
     PFC packets.  Its main use is to identify a PFC-capable interface
     within the wide area network.  By advertising this information across
     the network, it enables other devices and controllers in the network
     to implement traffic control strategies more easily.

     The specific behavior of a device upon receiving an End.X.PFC packet
     can be divided into two scenarios:

     case1:When the device acts as an intermediate node in the SRv6 path
     and the End.X.PFC is the non-final hop SID in the Segment list, the
     End.X.PFC behaviour exhibits the same forwarding characteristics as
     the End.X behaviour, that is, forwarding the traffic to the next hop
     through the specified L3 adjacency interface.








  Ruan, et al.             Expires 31 August 2026                 [Page 5]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


     case2:When the device acts as the final destination node of the SRv6
     tunnel for PFC backpressure signals and the End.X.PFC is the final
     hop SID in the Segment list, the End.X.PFC behaviour parses the inner
     payload of the encapsulated packet, extracts the PFC backpressure
     frame, and executes the corresponding PFC flow control action
     according to the content of the frame.

     When N receives a packet destined to S and S is a local End.X.PFC
     behavior, N does the following:

      S01.  When an SRH is processed {
       S02.  If (Segments Left == 0) {
       S03.  Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
       S04.  }
       S05.  If (IPv6 Hop Limit <= 1) {
       S06.     Send an ICMP Time Exceeded message to the Source Address
                 with Code 0 (Hop limit exceeded in transit),
                 interrupt packet processing, and discard the packet.
       S07.  }
       S08.  max_LE =(Hdr Ext Len / 2) - 1
       S09.  If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
       S10.      Send an ICMP Parameter Problem to the Source Address
                 with Code 0 (Erroneous header field encountered) and
                 pointer set to the Segments Left field, interrupt
                 packet processing,and discard the packet.
       S11.  }
       S12.  Decrement IPv6 Hop Limit by 1
       S13.  Decrement Segments Left by 1
       S14.  Update IPv6 DA with Segment List[Segments Left]
       S15.  Submit the packet to the IPv6 module for transmission to the new
             destination via interface J
       S16. }

     When processing the Upper-Layer header of a packet matching a FIB
     entry locally instantiated as an End.X.PFC SID, N does the following:

     S01.  If (Upper-Layer header type == 143(Ethernet) ) {
     S02.    Remove the outer IPv6 header with all its extension headers
     S03.     If(Destination MAC==01-80-C2-00-00-01)
     S04.       Interface J will perform flow control actions based on the
                content in the Priority - Flow Control (PFC) frames.
     S05. } Else {
     S06.  Process as per Section 4.1.1 defined in [RFC8986]
     S07. }





  Ruan, et al.             Expires 31 August 2026                 [Page 6]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


  3.  Using End.X.PFC Behavior For Congestion Notification

     In the topology shown in Figure 3, it is assumed that the edge
     devices R1 and R3 of the wide area network support the processing of
     PFC (Priority-based Flow Control) frames, while R2 does not.  R1 and
     R3 can configure the behavior of End.X.PFC locally and advertise it
     by IGP and BGP-LS protocols.

                                         +----------+
                                         |Controller|
                                         +----------+
                                            /  |  \
                                           /   |   \
                                          /    |    \
                                         /     |     \
                                        /      |      \
                                       /       |       \
                                      /        |        \
                     +------+   +----+       +----+     +----+    +------+
                     | DC1  |---| R1 |-------| R2 |-----| R3 |----| DC2  |
                     +------+   +----+       +----+     +----+    +------+
                               End.X.PFC(R1)   End(R2)       End(R3)

                                    L3VPN over SRv6 policy
                               ---------------------------------->
                                   tunnel for PFC frames
                              <----------------------------------

           Figure 3: Using the End.X.PFC Behaviour for flow control

     Assume that a tenant needs to transmit data over RDMA protocol from
     DC1 to DC2.  The operator can deploy an L3VPN over SRv6 Policy
     service in the wide area network to carry this traffic.

     When congestion occurs at interface between R3 and DC2, or when R3
     receives a PFC back-pressure signal from DC2 and its buffer exceeds
     the set threshold, R3 needs to propagate a back-pressure signal
     upstream.  There are two scenarios for how R3 can accurately send the
     back-pressure signal to the corresponding interface on R1:

     Scenario 1: Controller-Pre-deployed Tunnels for PFC Back-pressure
     Frames The controller first calculates an SRv6 policy
     {R1.End.X.PFC,R2.End,R3.End} between R1 and R3 ,After the SRv6 Policy
     is provisioned and programmed, the controller verifies the nodes
     involved in the Policy, and retrieves that R1 and R3 are devices with
     PFC capability.The controller can identify the upstream-downstream
     relationship between R1 and R3 in the segment list, then pre-deploys
     an SRv6 tunnel from R3 to R1 with a segment list of {R3.End , R2.End,



  Ruan, et al.             Expires 31 August 2026                 [Page 7]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


     R1.End.X.PFC } . When R3 generates a PFC back-pressure frame, the
     frame is encapsulated into this tunnel.  Upon reaching the final hop
     R1, R1 processes the End.X.PFC behavior.  Similarly, the controller
     pre-deploys a reverse tunnel from R1 to R3 for carrying PFC frames.

     To improve the orchestration efficiency of the controller, similar to
     End.X.PFC, a new End.PFC behavior(eg.R3.End.PFC) can be defined to
     identify nodes with PFC capability.By using this behavior, the nodes
     along the path that require the creation of reverse tunnels can be
     more easily identified by the controller.

     Scenario 2: Device-Auto-triggered Tunnel Creation for PFC Back-
     pressure Frames When R3(PFC-capable node) receives the first data
     packet of an SRv6 policy, it analyzes the segment list in the SRH
     header (e.g., {R1.End.X.PFC , R2.End, R3.End }).  Upon detecting an
     End.X.PFC behavior in the upstream path, R3 dynamically creates a
     reverse tunnel with a segment list of {R3.End ,R2.End, R1.End.X.PFC }
     to carry PFC frames.

     A reverse tunnel can be based on SRv6 Policy or an SRv6 BE.  In the
     SRv6 BE scenario, it is only required to encapsulate R1.End.X.PFC
     into the destination IP of the packet.

     It should be noted that, in order to avoid packet loss on devices
     that do not support the PFC (Priority-based Flow Control)
     functionality, network slicing technology [RFC9543] can be utilized.
     Tenant-level slices can be deployed on the interfaces traversed by
     SRv6 to provide independent queues and bandwidth resources.If slicing
     technology is used, the information of the reverse tunnel should also
     include the corresponding slicing information, such as the slice ID,
     etc

  4.  OAM Considerations

     It is necessary to perform network quality probing between the two
     devices that need to exchange backpressure signals.  As illustrated
     in Figure 3, the downstream node is required to conduct real-time
     probing of the reachability and network status of the relevant
     behaviours on the upstream node.  This capability enables the
     downstream node to dynamically adjust its own watermarks and the size
     of reserved buffers.

  5.  Security Considerations

     The security considerations of SRv6 in RFC8754 [RFC8986] apply to
     this document.





  Ruan, et al.             Expires 31 August 2026                 [Page 8]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


  6.  IANA Considerations

     This document defines a new SRv6 Endpoint behavior called END.X.PFC.

     IANA is requested to allocate four new code points from the "SRv6
     Endpoint Behaviors" sub-registry in the "Segment-routing with IPv6
     data plane (SRv6) Parameters" registry:

              +-------+--------+--------------------------+-----------+
              | Value |  Hex   |     Endpoint Behavior    | Reference |
              +-------+--------+--------------------------+-----------+
              |  TBA  |  TBA   |        End.X.PFC         | [This ID] |
              |  TBA  |  TBA   |   End.X.PFC with PSP     | [This ID] |
              |  TBA  |  TBA   |   End.X.PFC with USP     | [This ID] |
              |  TBA  |  TBA   | End.X.PFC with PSP & USP | [This ID] |
              |  TBA  |  TBA   |     End.X.PFC with USD   | [This ID] |
              +-------+--------+--------------------------+-----------+

  7.  References

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

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

     [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
                Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
                (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
                <https://www.rfc-editor.org/info/rfc8754>.

     [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
                D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
                (SRv6) Network Programming", RFC 8986,
                DOI 10.17487/RFC8986, February 2021,
                <https://www.rfc-editor.org/info/rfc8986>.

  7.2.  Informative References

     [I-D.ietf-spring-sr-for-enhanced-vpn]
                Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li,
                "Segment Routing based Network Resource Partition (NRP)
                for Enhanced VPN", Work in Progress, Internet-Draft,



  Ruan, et al.             Expires 31 August 2026                 [Page 9]


  Internet-Draft    SRv6 behavior for Flow Control in WAN    February 2026


                draft-ietf-spring-sr-for-enhanced-vpn-10, 15 December
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                spring-sr-for-enhanced-vpn-10>.

     [RFC9543]  Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
                Makhijani, K., Contreras, L., and J. Tantsura, "A
                Framework for Network Slices in Networks Built from IETF
                Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
                <https://www.rfc-editor.org/info/rfc9543>.

  Authors' Addresses

     Zheng Ruan (editor)
     China Unicom
     Beijing
     China
     Email: ruanz6@chinaunicom.cn


     Yao Liu (editor)
     ZTE
     Nanjing
     China
     Email: liu.yao71@zte.com.cn


     MengYao Han (editor)
     China Unicom
     Beijing
     China
     Email: hanmy12@chinaunicom.cn


     Zhengxin Han
     China Unicom
     Beijing
     China
     Email: hanzx21@chinaunicom.cn


     Ying Liu
     China Unicom
     Beijing
     China
     Email: liuy619@chinaunicom.cn






  Ruan, et al.             Expires 31 August 2026                [Page 10]


name: draft-li-spring-rdma-multicast-over-srv6
rev: 00
title: SRv6 Extensions for RDMA Multicast Delivery
time: 2026-03-01T01:59:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-02T01:59:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "A2A protocols"]
tags: []
fetched_at: 2026-03-03T15:50:11.000885+00:00
abstract:
  This document specifies SRv6 (Segment Routing over IPv6) extensions
     for multicast delivery of RDMA (Remote Direct Memory Access) Reliable
     Connection (RC) traffic.  It defines a new SRv6 endpoint behavior,
     End.MT, that performs per-receiver RDMA Base Transport Header (BTH)
     modifications at edge nodes of the multicast tree.  It also specifies
     procedures for hop-by-hop aggregation of RDMA ACK, NACK, and CNP
     response messages along the reverse path.  Together, these extensions
     allow RDMA RC endpoints to communicate using standard point-to-point
     Queue Pair (QP) semantics while the network distributes data packets
     over an IP multicast tree.  Target deployment scenarios include
     multi-replica distributed storage writes, HPC collective
     communications, AI training parameter distribution, and large-scale
     inference KV cache distribution.

full_text:
  SPRING                                                             Z. Li
  Internet-Draft                                                     Z. Du
  Intended status: Standards Track                            China Mobile
  Expires: 1 September 2026                                       W. Cheng
                                                                   J. Wang
                                                                  G. Zhang
                                                           Centec Networks
                                                          28 February 2026


                SRv6 Extensions for RDMA Multicast Delivery
                draft-li-spring-rdma-multicast-over-srv6-00

  Abstract

     This document specifies SRv6 (Segment Routing over IPv6) extensions
     for multicast delivery of RDMA (Remote Direct Memory Access) Reliable
     Connection (RC) traffic.  It defines a new SRv6 endpoint behavior,
     End.MT, that performs per-receiver RDMA Base Transport Header (BTH)
     modifications at edge nodes of the multicast tree.  It also specifies
     procedures for hop-by-hop aggregation of RDMA ACK, NACK, and CNP
     response messages along the reverse path.  Together, these extensions
     allow RDMA RC endpoints to communicate using standard point-to-point
     Queue Pair (QP) semantics while the network distributes data packets
     over an IP multicast tree.  Target deployment scenarios include
     multi-replica distributed storage writes, HPC collective
     communications, AI training parameter distribution, and large-scale
     inference KV cache distribution.

  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 1 September 2026.






  Li, et al.              Expires 1 September 2026                [Page 1]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  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.  Relationship to Other Work  . . . . . . . . . . . . . . .   4
       1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Network Roles . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Reference Topology  . . . . . . . . . . . . . . . . . . .   6
     5.  Data Plane Specification  . . . . . . . . . . . . . . . . . .   7
       5.1.  Multicast Group Setup . . . . . . . . . . . . . . . . . .   7
       5.2.  Downstream Data Forwarding  . . . . . . . . . . . . . . .   7
       5.3.  Reverse-Path Response Processing  . . . . . . . . . . . .   8
         5.3.1.  ACK Aggregation . . . . . . . . . . . . . . . . . . .   9
         5.3.2.  NACK Aggregation  . . . . . . . . . . . . . . . . . .   9
         5.3.3.  CNP Aggregation . . . . . . . . . . . . . . . . . . .   9
     6.  SRv6 End.MT Behavior  . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .  10
       6.2.  Pseudocode  . . . . . . . . . . . . . . . . . . . . . . .  10
     7.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .  11
       7.1.  SRH Usage . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.2.  End.MT TLV Format . . . . . . . . . . . . . . . . . . . .  11
     8.  Intermediate Node State Requirements  . . . . . . . . . . . .  12
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
       10.1.  SRv6 Endpoint Behavior . . . . . . . . . . . . . . . . .  13
       10.2.  SRH TLV Type . . . . . . . . . . . . . . . . . . . . . .  14
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
       11.2.  Informative References . . . . . . . . . . . . . . . . .  15
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16




  Li, et al.              Expires 1 September 2026                [Page 2]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  1.  Introduction

     Large-scale distributed computing deployments, including data center
     interconnection, distributed AI training and inference, and national-
     scale computing networks, rely on high-throughput data transport.
     RDMA (Remote Direct Memory Access) provides kernel-bypass data
     transfer with low CPU overhead on both sending and receiving hosts.
     RDMA one-sided operations, where receive buffers are pre-registered
     at the receiver's Network Interface Card (NIC), further reduce CPU
     involvement at the receiving end.

     Many distributed applications exhibit one-to-many traffic patterns,
     including multi-replica storage writes, HPC collective communications
     (broadcast, scatter), AI training parameter distribution, and KV
     cache distribution in inference pipelines.  IP multicast delivery of
     such traffic can reduce total network bandwidth consumption compared
     to per-receiver unicast replication at the source.

     The RDMA Reliable Connection (RC) transport mode is the most widely
     adopted RDMA mode because it supports the complete set of RDMA
     operations: Read, Write, and Atomic.  However, each RC Queue Pair
     (QP) is a point-to-point association between exactly one sending QP
     and one receiving QP.  RC packets carry per-connection identifiers in
     the Base Transport Header (BTH), specifically the Destination Queue
     Pair Number (QPN) and Packet Sequence Number (PSN).  These per-
     connection fields prevent direct application of IP multicast
     replication to RC traffic because each receiver requires its own QPN
     and independently tracks PSN state.

     Existing application-layer approaches in distributed frameworks (MPI,
     NCCL, Spark) address this limitation in two ways: by opening separate
     RC QP connections to each receiver, which results in source bandwidth
     consumption proportional to the number of receivers, or by
     constructing application-layer relay trees (tree or ring topologies),
     which introduce per-hop host-stack traversal latency and additional
     memory copy overhead at relay nodes.

     This document specifies SRv6 extensions that bridge the gap between
     RDMA RC point-to-point semantics and IP multicast one-to-many
     delivery.  Edge nodes of the multicast tree execute a new SRv6
     endpoint behavior (End.MT) that rewrites per-receiver RDMA BTH fields
     in replicated packet copies.  Intermediate and edge nodes aggregate
     reverse-path RDMA response messages (ACK, NACK, CNP) before they
     reach the source.  RDMA RC endpoints are not required to implement
     any multicast-specific extensions.






  Li, et al.              Expires 1 September 2026                [Page 3]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  1.1.  Relationship to Other Work

     The Segment Routing Replication segment defined in [RFC9524] provides
     a general-purpose SRv6 packet replication behavior (End.Replicate).
     The End.MT behavior specified in this document is complementary: it
     performs RDMA-specific BTH header modifications in addition to packet
     replication at edge nodes.  Transit nodes in the multicast tree MAY
     use End.Replicate or any other IP multicast forwarding mechanism for
     tree-interior replication.

     Fast Congestion Notification Packet (Fast CNP) mechanisms for RoCEv2
     networks, such as those described in
     [I-D.xiao-rtgwg-rocev2-fast-cnp], define switch-originated CNPs sent
     directly to the sender on a point-to-point basis.  The reverse-path
     CNP aggregation specified in this document operates on the multicast
     tree topology and is independent of, and compatible with, Fast CNP on
     individual links.

     RoCEv2-based collective communication offloading, as described in
     [I-D.liu-nfsv4-rocev2], implements in-network aggregation functions
     for collective operations.  This document differs in scope: it
     addresses one-to-many data distribution (multicast) rather than many-
     to-one aggregation (reduce), and it does not require RDMA connections
     between hosts and switches.

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

     This document uses the following terms.  Familiarity with SRv6
     terminology from [RFC8402], [RFC8754], and [RFC8986] is assumed.

     RDMA:  Remote Direct Memory Access, as specified in the InfiniBand
        Architecture [ROCEV2].

     RoCEv2:  RDMA over Converged Ethernet version 2, an RDMA transport
        encapsulated in UDP/IPv6 (or UDP/IPv4).

     RC:  Reliable Connection, an RDMA transport mode providing
        connection-oriented reliable delivery.

     QP:  Queue Pair, the RDMA communication endpoint consisting of a Send



  Li, et al.              Expires 1 September 2026                [Page 4]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


        Queue (SQ) and a Receive Queue (RQ).

     QPN:  Queue Pair Number, a 24-bit identifier for a QP.

     BTH:  Base Transport Header, the RDMA transport header containing the
        opcode, Destination QPN, PSN, and other fields.

     AETH:  ACK Extended Transport Header, an RDMA header carrying
        acknowledgment information.

     PSN:  Packet Sequence Number, a 24-bit sequence number used for
        ordering and acknowledgment in RDMA reliable transport.

     ACK:  Acknowledgment, an RDMA response confirming successful
        reception.

     NACK:  Negative Acknowledgment, an RDMA response requesting
        retransmission.

     CNP:  Congestion Notification Packet, used in the RoCEv2 ECN-based
        congestion control mechanism.

     SRv6:  Segment Routing over IPv6 [RFC8402].

     SRH:  Segment Routing Header [RFC8754].

     SID:  Segment Identifier, a 128-bit IPv6 address in SRv6.

     End.MT:  A new SRv6 endpoint behavior defined in this document for
        RDMA multicast header transformation at edge nodes.

     Designated QPN:  A QPN value agreed upon by all multicast group
        participants during group setup, used as the Destination QPN in
        data packets traversing the multicast tree.

     Proxy Address:  An IPv6 address used as the common destination by the
        source and all receivers to represent the multicast group at the
        RDMA layer.

  3.  Applicability

     The extensions specified in this document apply to networks that meet
     all of the following conditions:

     1.  RDMA transport uses RoCEv2 in Reliable Connection (RC) mode over
         IPv6.





  Li, et al.              Expires 1 September 2026                [Page 5]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


     2.  The network underlay supports SRv6 as defined in [RFC8754] and
         [RFC8986].

     3.  IP multicast forwarding is available in the underlay between the
         source and the edge nodes, using any combination of PIM, static
         multicast routing, or SRv6 Replication segments [RFC9524].

     4.  Edge nodes are capable of maintaining per-receiver RDMA
         connection state and performing BTH field modification at line
         rate.

     These extensions do not modify RDMA endpoint behavior.  Hosts run
     unmodified RoCEv2 protocol stacks and establish standard RC QP
     connections.  All multicast-related packet transformations occur
     within the network.

  4.  Architecture

  4.1.  Network Roles

     This specification defines the following network roles:

     Multicast Source (S):  The RDMA sending host.  S establishes a
        standard RDMA RC QP to the Proxy Address using the Designated QPN.
        S obtains the unicast IPv6 addresses and QPNs of all receivers via
        a control plane (the control plane protocol is out of scope).

     Multicast Receivers (R1..Rn):  RDMA receiving hosts.  Each Ri
        establishes a standard RDMA RC QP to the Proxy Address using its
        own locally assigned QPN.

     Edge Nodes:  SRv6-capable network nodes adjacent to receivers (e.g.,
        N1-N3 in Figure 1).  Edge nodes instantiate the End.MT SID and
        perform: (a) RDMA BTH Destination QPN replacement, (b) IPv6
        Destination Address replacement, (c) ICRC recomputation, and (d)
        reverse-path ACK/NACK/CNP aggregation.

     Transit Nodes:  Intermediate forwarding nodes in the multicast tree
        (e.g., N4-N6 in Figure 1).  Transit nodes replicate and forward
        packets using IP multicast procedures and participate in reverse-
        path response aggregation.

  4.2.  Reference Topology








  Li, et al.              Expires 1 September 2026                [Page 6]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


                                 S1
                                  |
                                 N6 (transit)
                               /    \
                    (transit) N4     N5 (transit)
                             /  \    /  \
                   (edge)  N1   N2    N3 (edge)
                          / \    |   / \
                        R1   R2  R3 R4  R5

                      Figure 1: Reference Network Topology

     In Figure 1, S1 is the multicast source.  R1 through R5 are multicast
     receivers.  N1, N2, and N3 are edge nodes executing the End.MT
     behavior.  N4, N5, and N6 are transit nodes performing IP multicast
     replication.

  5.  Data Plane Specification

  5.1.  Multicast Group Setup

     Prior to data transmission, a multicast group MUST be established as
     follows:

     1.  All participants (source S1 and receivers R1..Rn) MUST each
         create an RDMA RC QP directed at the Proxy Address.  All QPs MUST
         use the Designated QPN as the remote (destination) QPN.

     2.  The source S1 MUST obtain the unicast IPv6 address and the actual
         local QPN of each receiver Ri via the control plane.  The control
         plane protocol and its signaling procedures are outside the scope
         of this document.

     3.  Each edge node MUST be configured to receive IP multicast traffic
         addressed to the Proxy Address.

     4.  S1 MUST encode each edge node's associated receiver information
         (unicast IPv6 addresses and QPNs) into End.MT TLVs within the SRH
         of data packets, as specified in Section 7.2.

  5.2.  Downstream Data Forwarding

     The source-to-receiver data path operates as follows:








  Li, et al.              Expires 1 September 2026                [Page 7]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


     1.  S1 constructs RDMA RC data packets with the IPv6 Destination
         Address set to the Proxy Address and the BTH Destination QPN set
         to the Designated QPN.  S1 encapsulates the packets in an outer
         IPv6 header with an SRH containing the End.MT SID(s) and
         associated TLVs.

     2.  Transit nodes forward the traffic according to their IP multicast
         forwarding tables, performing tree replication as needed.

     3.  When a packet arrives at an edge node whose local End.MT SID
         matches the IPv6 Destination Address, the edge node MUST execute
         the End.MT behavior (Section 6):

         a.  Parse the End.MT TLV from the SRH to obtain the list of
             downstream receivers (unicast addresses and QPNs).

         b.  Create one copy of the inner packet for each downstream
             receiver.

         c.  In each copy, replace the IPv6 Destination Address with the
             receiver's unicast address.

         d.  In each copy, replace the BTH Destination QPN with the
             receiver's actual QPN.

         e.  Recompute the Invariant CRC (ICRC) and any other affected
             checksums.

         f.  Forward each modified copy toward its destination.

     4.  Each receiver Ri receives a standard RDMA RC unicast packet
         addressed to its own IPv6 address and QPN.  No multicast-specific
         behavior is required at Ri.

  5.3.  Reverse-Path Response Processing

     Receivers generate three types of response messages toward the
     source: ACK (acknowledgment of successful reception), NACK (request
     for retransmission), and CNP (congestion notification).  These
     responses MUST be aggregated hop-by-hop at intermediate nodes before
     reaching the source, so that the source's retransmission and rate
     control logic operates correctly without multicast-specific
     modifications.








  Li, et al.              Expires 1 September 2026                [Page 8]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  5.3.1.  ACK Aggregation

     The source MUST receive an AckPSN value satisfying the following
     invariant: for every receiver Ri and every packet with PSN less than
     or equal to AckPSN, Ri has confirmed successful reception.

     Each intermediate node (edge or transit) MUST maintain a record of
     the most recent AckPSN reported by each downstream branch.  When an
     ACK is received from a downstream branch, the node MUST update the
     stored AckPSN for that branch.  The node MUST forward an ACK upstream
     carrying an AckPSN equal to the minimum of all downstream branches'
     stored AckPSN values.  The node adjacent to the source (N6 in
     Figure 1) MUST write this minimum value into the AETH AckPSN field of
     the ACK forwarded to the source.

  5.3.2.  NACK Aggregation

     When a receiver detects missing packets, it sends a NACK containing
     an expected PSN (ePSN) indicating the start of the retransmission
     range.  The source MUST receive an ePSN satisfying the following
     invariant: for every receiver Ri, all packets with PSN less than ePSN
     have been successfully received by Ri.

     Each intermediate node MUST maintain a per-branch record of ePSN
     values.  For branches that have sent only ACKs (no NACK), the
     effective ePSN SHOULD be treated as AckPSN + 1.  The NACK forwarded
     upstream MUST carry the minimum ePSN across all downstream branches.

  5.3.3.  CNP Aggregation

     Each intermediate node MUST maintain a per-branch counter (CCount)
     that records the number of CNP messages received from each downstream
     branch within a configurable time window T.

     At the expiration of each time window T, the node MUST select the
     branch with the highest CCount value and forward a single CNP
     upstream representing the most congested downstream path.  All CCount
     values MUST be reset to zero at the start of each new time window.

     The time window T MAY be adjusted dynamically based on observed
     network conditions.  The node adjacent to the source MUST rewrite CNP
     packet headers so that the source processes the CNP as a standard
     RoCEv2 congestion notification.

  6.  SRv6 End.MT Behavior






  Li, et al.              Expires 1 September 2026                [Page 9]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  6.1.  Definition

     End.MT is an SRv6 endpoint behavior instantiated at edge nodes of the
     RDMA multicast tree.  When a node N receives a packet whose IPv6
     Destination Address matches a locally instantiated End.MT SID, N
     performs the processing described in Section 6.2.

     End.MT combines the following operations: SRH segment processing,
     End.MT TLV parsing, per-receiver packet replication, BTH Destination
     QPN replacement, IPv6 Destination Address replacement, and ICRC
     recomputation.

  6.2.  Pseudocode

     The following pseudocode follows the conventions of [RFC8986]
     Section 4.

     When N receives a packet destined to S, where S is a local
     End.MT SID, N does:

       S01. If NH=SRH and SL > 0 {
       S02.   Decrement SL
       S03.   Update the IPv6 DA with SRH[SL]         ;; Ref1
       S04.   Parse the End.MT TLV associated with S
       S05.   Let RecvList = list of (IPv6_Addr, QPN) from TLV
       S06.   For each entry (Addr_i, QPN_i) in RecvList {
       S07.     Copy the packet                        ;; Ref2
       S08.     In the copy, set IPv6 DA = Addr_i
       S09.     In the copy, set BTH.DestQPN = QPN_i
       S10.     Recompute ICRC over the modified headers
       S11.     Forward the copy based on Addr_i       ;; Ref3
       S12.   }
       S13. } Else {
       S14.   Drop the packet                          ;; Ref4
       S15. }

     Ref1: Standard SRH processing per RFC 8754 Section 4.3.1.1.

     Ref2: The copy includes all payload beyond the outer IPv6
           and SRH headers that are relevant to the inner RDMA
           frame.

     Ref3: FIB lookup on Addr_i determines the outgoing
           interface.

     Ref4: A packet arriving with SL=0 or without SRH is not
           valid for End.MT processing.




  Li, et al.              Expires 1 September 2026               [Page 10]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  7.  Packet Formats

  7.1.  SRH Usage

     This specification uses the standard IPv6 Segment Routing Header
     (SRH) as defined in [RFC8754].  The SRH carries the End.MT SID in its
     Segment List and the End.MT TLV in its Optional TLV field.

  7.2.  End.MT TLV Format

     The End.MT TLV is carried in the Optional TLV field of the SRH and
     conveys per-edge-node receiver information.  Its format is as
     follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |     Length    |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |          Edge Node Address (128 bits IPv6)                    |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num Receivers |                  Reserved                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |         Receiver 1 Address (128 bits IPv6)                    |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Receiver 1 QPN (24 bits)            |   Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                            ...                                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |         Receiver N Address (128 bits IPv6)                    |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Receiver N QPN (24 bits)            |   Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2: End.MT TLV Format

     The fields are defined as follows:

     Type (8 bits):  SRH TLV type code, to be assigned by IANA (see



  Li, et al.              Expires 1 September 2026               [Page 11]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


        Section 10).

     Length (8 bits):  Length of the Value field in octets, not including
        the Type and Length fields.

     Edge Node Address (128 bits):  The IPv6 unicast address of the edge
        node associated with this TLV entry.

     Num Receivers (8 bits):  The number of receiver entries following
        this field.

     Receiver i Address (128 bits):  The IPv6 unicast address of the i-th
        receiver.

     Receiver i QPN (24 bits):  The RDMA Queue Pair Number of the i-th
        receiver.

     Reserved:  MUST be set to zero on transmission and MUST be ignored on
        reception.

     Multiple End.MT TLVs MAY be present in a single SRH, one per edge
     node in the multicast tree.  Each End.MT TLV is associated with the
     End.MT SID of the corresponding edge node.

  8.  Intermediate Node State Requirements

     Each intermediate node (both edge and transit) participating in
     reverse-path response aggregation MUST maintain the following per-
     multicast-group state:

     Per-branch AckPSN:  The most recent AckPSN value received from each
        downstream branch.  Initial value: 0.

     Per-branch ePSN:  The most recent expected PSN from any NACK received
        from each downstream branch.  For branches that have not sent a
        NACK, this value SHOULD be set to AckPSN + 1.

     Per-branch CCount:  A counter of CNP messages received from each
        downstream branch within the current time window T.  Reset to zero
        at the start of each new time window.

     The amount of state is proportional to the number of downstream
     branches at each node, not to the total number of receivers in the
     multicast group.  Edge nodes additionally maintain the receiver
     information (addresses and QPNs) learned from the End.MT TLV or from
     control-plane provisioning.





  Li, et al.              Expires 1 September 2026               [Page 12]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


  9.  Security Considerations

     The security considerations of [RFC8754] and [RFC8986] apply to all
     SRv6 aspects of this specification.  The following additional
     considerations are specific to RDMA multicast delivery.

     The End.MT TLV carries receiver IPv6 addresses and QPNs in the SRH.
     An on-path attacker able to read SRH contents can obtain receiver
     topology and RDMA connection identifiers.  Implementations operating
     outside a single administrative trust domain SHOULD protect SRH
     integrity and confidentiality using the HMAC TLV defined in Section 7
     of [RFC8754] or IPsec Encapsulating Security Payload (ESP)
     encapsulation.

     Intermediate nodes maintain per-branch ACK/NACK/CNP aggregation
     state.  An attacker injecting forged response messages could corrupt
     this state, causing the source to prematurely consider data as
     acknowledged (via inflated AckPSN) or to trigger unnecessary
     retransmissions (via forged NACKs).  Nodes SHOULD validate that
     reverse-path response messages originate from addresses within the
     expected downstream receiver set.  BCP 38 [RFC2827] ingress filtering
     SHOULD be applied at network boundaries.

     An attacker injecting a high volume of forged CNP messages could
     force the source into continuous rate reduction, creating a denial-
     of-service condition.  Intermediate nodes SHOULD implement per-branch
     CNP rate limiting.  The configurable time window T for CNP
     aggregation provides an inherent dampening effect.

     If End.MT TLV contents are modified in transit, packets could be
     delivered to incorrect RDMA QPs, resulting in data corruption or
     information disclosure at unintended receivers.  The SRH HMAC TLV
     [RFC8754] provides integrity protection for this purpose.  Edge nodes
     SHOULD verify HMAC before processing End.MT TLVs when operating
     across trust domain boundaries.

  10.  IANA Considerations

  10.1.  SRv6 Endpoint Behavior

     This document requests IANA to allocate a new codepoint in the "SRv6
     Endpoint Behaviors" sub-registry under the "Segment Routing" registry
     group [RFC8986]:








  Li, et al.              Expires 1 September 2026               [Page 13]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


     +=======+======+===================+===========+===================+
     | Value | Hex  | Endpoint Behavior | Reference | Change Controller |
     +=======+======+===================+===========+===================+
     | TBD1  | TBD1 | End.MT            | [This     | IETF              |
     |       |      |                   | document] |                   |
     +-------+------+-------------------+-----------+-------------------+

                 Table 1: SRv6 Endpoint Behavior Registration

  10.2.  SRH TLV Type

     This document requests IANA to allocate a new Type value in the
     "Segment Routing Header TLVs" registry [RFC8754]:

                   +=======+=============+=================+
                   | Value | Description | Reference       |
                   +=======+=============+=================+
                   | TBD2  | End.MT TLV  | [This document] |
                   +-------+-------------+-----------------+

                       Table 2: SRH TLV Type Registration

  11.  References

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

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

     [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
                Decraene, B., Litkowski, S., and R. Shakir, "Segment
                Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
                July 2018, <https://www.rfc-editor.org/info/rfc8402>.

     [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
                Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
                (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
                <https://www.rfc-editor.org/info/rfc8754>.







  Li, et al.              Expires 1 September 2026               [Page 14]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


     [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
                D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
                (SRv6) Network Programming", RFC 8986,
                DOI 10.17487/RFC8986, February 2021,
                <https://www.rfc-editor.org/info/rfc8986>.

     [RFC9524]  Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
                Z. Zhang, "Segment Routing Replication for Multipoint
                Service Delivery", RFC 9524, DOI 10.17487/RFC9524, 28
                February 2026, <https://www.rfc-editor.org/info/rfc9524>.

  11.2.  Informative References

     [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
                Defeating Denial of Service Attacks which employ IP Source
                Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
                May 2000, <https://www.rfc-editor.org/info/rfc2827>.

     [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
                of Explicit Congestion Notification (ECN) to IP",
                RFC 3168, DOI 10.17487/RFC3168, September 2001,
                <https://www.rfc-editor.org/info/rfc3168>.

     [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
                Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
                Explicit Replication (BIER)", RFC 8279,
                DOI 10.17487/RFC8279, November 2017,
                <https://www.rfc-editor.org/info/rfc8279>.

     [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
                Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
                for Bit Index Explicit Replication (BIER) in MPLS and Non-
                MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
                2018, <https://www.rfc-editor.org/info/rfc8296>.

     [I-D.xiao-rtgwg-rocev2-fast-cnp]
                Min, X. and H. Li, "Fast Congestion Notification Packet
                (CNP) in RoCEv2 Networks", Work in Progress, Internet-
                Draft, draft-xiao-rtgwg-rocev2-fast-cnp-04, 28 February
                2026, <https://datatracker.ietf.org/doc/html/draft-xiao-
                rtgwg-rocev2-fast-cnp-04>.

     [I-D.liu-nfsv4-rocev2]
                Liu, Y., "RoCEv2-based Collective Communication
                Offloading", Work in Progress, Internet-Draft, draft-liu-
                nfsv4-rocev2-00, 28 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-liu-
                nfsv4-rocev2-00>.



  Li, et al.              Expires 1 September 2026               [Page 15]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


     [I-D.hu-rtgwg-rocev2-fcn]
                Hu, Z. and Y. Zhu, "Fast Congestion Notification for
                Distributed RoCEv2 Network Based on SRv6", Work in
                Progress, Internet-Draft, draft-hu-rtgwg-rocev2-fcn-00, 28
                February 2026, <https://datatracker.ietf.org/doc/html/
                draft-hu-rtgwg-rocev2-fcn-00>.

     [ROCEV2]   InfiniBand Trade Association, "Supplement to InfiniBand
                Architecture Specification Volume 1 Release 1.2.1 - Annex
                A17: RoCEv2", 28 February 2026.

  Acknowledgments

     The authors thank the members of the SPRING and RTGWG working groups
     for their review and feedback.

  Authors' Addresses

     Zhiqiang Li
     China Mobile
     32 Xuanwumen West Street
     Beijing
     100053
     China
     Email: lizhiqiangyjy@chinamobile.com


     Zongpeng Du
     China Mobile
     32 Xuanwumen West Street
     Beijing
     100053
     China
     Email: duzongpeng@chinamobile.com


     Wei Cheng
     Centec Networks
     Suzhou
     215000
     China
     Email: chengw@centec.com









  Li, et al.              Expires 1 September 2026               [Page 16]


  Internet-Draft          RDMA Multicast over SRv6           February 2026


     Junjie Wang
     Centec Networks
     Suzhou
     215000
     China
     Email: wangjj@centec.com


     Guoying Zhang
     Centec Networks
     Suzhou
     215000
     China
     Email: zhanggy@centec.com





































  Li, et al.              Expires 1 September 2026               [Page 17]


name: draft-intellinode-ai-semantic-contract
rev: 00
title: Semantic-Driven Traffic Shaping Contract for AI Networks
time: 2026-03-02T08:37:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T08:37:42Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:11.000899+00:00
abstract:
  This document defines a "Semantic-Driven Shaping Contract".
     Traditional network protocols treat AI training and inference traffic
     as opaque byte streams, leading to highly inefficient scheduling.
     This contract allows applications or distributed training frameworks
     to explicitly pass "minimum necessary semantics" to the underlying
     network.  In exchange, the network commits to executing fine-grained,
     differentiated forwarding and resource allocation actions for tensor
     flows with diverse semantics, based on predefined rules and global
     real-time states.  This model significantly improves overall resource
     utilization and task completion times in heterogeneous computing
     networks, cross-domain intelligent computing centers, and integrated
     training-inference scenarios.

full_text:
  Computing-Aware Traffic Steering                                  T. Gao
  Internet-Draft                                     Peng Cheng Laboratory
  Intended status: Standards Track                            1 March 2026
  Expires: 2 September 2026


          Semantic-Driven Traffic Shaping Contract for AI Networks
                 draft-intellinode-ai-semantic-contract-00

  Abstract

     This document defines a "Semantic-Driven Shaping Contract".
     Traditional network protocols treat AI training and inference traffic
     as opaque byte streams, leading to highly inefficient scheduling.
     This contract allows applications or distributed training frameworks
     to explicitly pass "minimum necessary semantics" to the underlying
     network.  In exchange, the network commits to executing fine-grained,
     differentiated forwarding and resource allocation actions for tensor
     flows with diverse semantics, based on predefined rules and global
     real-time states.  This model significantly improves overall resource
     utilization and task completion times in heterogeneous computing
     networks, cross-domain intelligent computing centers, and integrated
     training-inference scenarios.

  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 2 September 2026.

  Copyright Notice

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






  Gao                     Expires 2 September 2026                [Page 1]


  Internet-Draft          Semantic Shaping Contract             March 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.

  Table of Contents

     1.  Problem Statement: Limitations of Existing Network
             Mechanisms  . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Cross-Domain Amplification of Challenges  . . . . . . . . . .   3
     3.  The Semantic-Driven Mapping Loop: The Contract  . . . . . . .   3
       3.1.  Semantic Information Model (Metadata Model) . . . . . . .   3
       3.2.  Network Policy / Action Set . . . . . . . . . . . . . . .   4
     4.  Extended Use Case: Top-K Routing Semantics for MoE
             Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5
       5.1.  Decision Location: Why In-Network?  . . . . . . . . . . .   5
       5.2.  RDMA / RoCEv2 Integration . . . . . . . . . . . . . . . .   5
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Problem Statement: Limitations of Existing Network Mechanisms

     In the era of large AI models, the "importance" of traffic
     dynamically shifts with the model's phase and exhibits a high degree
     of computability.  Existing traffic control and Quality of Service
     (QoS) mechanisms suffer from fundamental flaws in this context:

     *  *Coarse QoS Granularity and Invalid Implicit Assumptions:*
        Traditional QoS assumes that traffic within the same class has
        negligible variance and its importance remains stable at the
        session level.  However, in AI scenarios, QoS fails to
        differentiate between "early-layer activations" and "late-layer
        activations," nor can it distinguish between the "KV Cache of
        early tokens" and "tail tokens."

     *  *Static and Incomputable DiffServ Semantics:* Differentiated
        Services (DiffServ/DSCP) rely on static markings that the network
        blindly executes.  It cannot express dynamic computing semantics,
        such as "this flow is quantizable during congestion," "this flow
        tolerates a 5ms store-and-forward delay," or "this flow requires
        absolute preemption."




  Gao                     Expires 2 September 2026                [Page 2]


  Internet-Draft          Semantic Shaping Contract             March 2026


     *  *Passive and Dimensionless ECN Feedback:* Existing Explicit
        Congestion Notification (ECN) mechanisms operate on the assumption
        that "end-systems know best how to respond to congestion" and that
        "rate reduction is the only correct response."  It possesses zero
        understanding of computing semantics, treating activations,
        gradients, blocking, and non-blocking operations equally.  In AI
        inference, the correct response to congestion is often "precision
        degradation (quantization)" or "prioritizing the draining of
        critical tensors," rather than blind rate reduction.

  2.  Cross-Domain Amplification of Challenges

     In cross-domain intelligent computing networks characterized by
     multi-tasking, multi-tenancy, and integrated training and inference,
     the aforementioned flaws are severely amplified:

     *  *Time-scale Mismatch:* Cross-domain Round-Trip Times (RTT) reach
        the millisecond level, easily exceeding the "effective value
        window" of sensitive tensors like late-layer activations.  The
        network MUST make differentiation and routing decisions
        instantaneously during forwarding; post-facto congestion control
        feedback is entirely ineffective.

     *  *Resource & Path Asymmetry:* Cross-domain links are scarce, high-
        cost resources.  Delay-tolerant and compressible intermediate
        activations absolutely MUST NOT compete equally for cross-domain
        bandwidth with critical gradients that require immediate delivery.

     *  *Tight Compute-Network Coupling:* Traffic steering is no longer
        merely about "delivery to a fixed destination."  It requires
        dynamic selection based on compute heterogeneity (e.g., local GPU
        vs. remote FPGA).  A lack of semantic understanding leads to a
        severe mismatch between computing power and network resources.

  3.  The Semantic-Driven Mapping Loop: The Contract

     The core of this draft is to establish a closed-loop mapping
     mechanism from "application-layer semantic input" to "network-side
     action commitment."

  3.1.  Semantic Information Model (Metadata Model)

     The application layer MUST expose "exchangeable Semantic Metadata" to
     the network.  Based on the commonalities and specifics of training
     and inference tasks, this is categorized as follows:






  Gao                     Expires 2 September 2026                [Page 3]


  Internet-Draft          Semantic Shaping Contract             March 2026


     *  *Traffic Class:* Explicitly identifies the data type (e.g.,
        Activation, Gradient, KV Cache, Parameter, Collaborative State
        Synchronization).

     *  *Urgency & Dependency:* Provides coarse-grained dependency hints
        (e.g., Early-token vs. Late-token) and the current layer or stage
        of the model (Layer ID / Pipeline Stage).

     *  *Tolerance & Sensitivity:*

        -  *Fidelity/Accuracy Sensitivity:* Indicates whether in-network
           low-precision quantization is permitted.

        -  *Loss/Latency Tolerance:* Indicates whether the flow permits
           buffering (store-and-forward) or dropping.

     *  *Compute Affinity:* Indicates the preferred characteristics of the
        underlying computing power (e.g., GPU, FPGA, CPU, or specific
        operator acceleration hardware).

  3.2.  Network Policy / Action Set

     Upon receiving the aforementioned semantics, network nodes with
     global state awareness can execute a set of policies that transcend
     traditional routing:

     *  *Queueing / Scheduling:* Identifies flow states to guarantee
        absolute preemption for highly time-sensitive traffic.

     *  *Buffering / Store-and-forward:* Utilizes the storage resources of
        network devices to temporarily delay flows with high latency
        tolerance (e.g., large-block parameter pulls); it also implements
        cache multiplexing for inference requests from different users,
        directly optimizing hardware throughput without altering the model
        structure.

     *  *Shaping & In-network Quantization:* Triggers in-network low-
        precision quantization and sparsity strategies during congestion,
        rather than relying on simple packet dropping.

     *  *Steering:* Intelligently guides task flows to the most
        appropriate heterogeneous computing nodes based on Compute
        Affinity.








  Gao                     Expires 2 September 2026                [Page 4]


  Internet-Draft          Semantic Shaping Contract             March 2026


  4.  Extended Use Case: Top-K Routing Semantics for MoE Architecture

     For dynamic computing architectures like Mixture-of-Experts (MoE),
     this contract supports the definition of more complex routing
     metadata for intelligent scheduling in the network data plane:

     *  *Model Router Metadata:* Carries Token ID / Query vector
        summaries, Top-K candidate expert lists, weights/confidence
        levels, and positional markers (Token_pos).

     *  *System State Semantics:* Network nodes maintain real-time metrics
        for each expert node, including backlog queues, computing load,
        network latency, and bandwidth utilization.

     By matching these two semantics, the network can instantaneously
     determine which Expert node with the lightest load should receive the
     Token flow at the moment of forwarding.

  5.  Deployment Considerations

  5.1.  Decision Location: Why In-Network?

     Compared to edge devices (GPUs/NICs) that only possess local queuing
     information, in-network nodes (e.g., Core/Spine Switches) maintain a
     global perspective.  The network can perceive concurrent multi-tenant
     tasks and real-time multipath congestion states.  Crucially, it can
     make immediate decisions to buffer, slice, or reroute cross-domain
     traffic before it enters high-cost bottleneck links.

  5.2.  RDMA / RoCEv2 Integration

     Intelligent computing centers rely heavily on RDMA.  The Semantic
     Header defined in this contract will be designed as Extension Headers
     for RoCEv2/UDP packets, or carried using specific reserved fields.
     This enables supporting hardware (such as the FPGA and parsing
     pipelines in the IntelliNode architecture) to extract metadata and
     execute policies at line rate (e.g., 400Gbps).

  6.  Security Considerations

     To ensure the integrity of the Semantic-Driven Shaping Contract, the
     system MUST:

     *  *Authentication and Anti-Spoofing:* Prevent malicious tenants from
        tampering with the Urgency level or forging network states to
        unfairly preempt high-priority queues.





  Gao                     Expires 2 September 2026                [Page 5]


  Internet-Draft          Semantic Shaping Contract             March 2026


  7.  IANA Considerations

     This document requests that IANA allocate specific protocol numbers
     or RoCEv2 option type spaces for the AI Semantic Header to facilitate
     standardized deployment.

  Author's Address

     Teng Gao
     Peng Cheng Laboratory
     Email: gaot@pcl.ac.cn








































  Gao                     Expires 2 September 2026                [Page 6]


name: draft-li-cats-idn
rev: 00
title: A Framework of Intelligence Delivery Network (IDN) for Deep Learning Inference
time: 2026-03-02T08:55:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T08:55:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Model serving/inference", "Agent discovery/reg"]
tags: []
fetched_at: 2026-03-03T15:50:11.000905+00:00
abstract:
  The rapid growth of deep learning inference workloads is placing
     increasing pressure on existing Internet and computing
     infrastructures.  To support latency-aware, privacy-enhanced, and
     scalable inference services, this document introduces the concept of
     Intelligence Delivery Network (IDN), in which models with different
     inference capabilities are deployed across geographically distributed
     servers and selected to serve inference requests.  This document
     describes the challenges motivating such networks, presents an
     architectural framework, and defines a common vocabulary for
     discussing the systems.  This document does not specify protocol
     details, which are left to future documents.

full_text:
  Computing-Aware Traffic Steering                                   Q. Li
  Internet-Draft                                                   H. Wang
  Intended status: Informational                      Pengcheng Laboratory
  Expires: 3 September 2026                                       Y. Jiang
    Tsinghua Shenzhen International Graduate School & Pengcheng Laboratory
                                                                     M. Xu
                                                       Tsinghua University
                                                              2 March 2026


    A Framework of Intelligence Delivery Network (IDN) for Deep Learning
                                 Inference
                            draft-li-cats-idn-00

  Abstract

     The rapid growth of deep learning inference workloads is placing
     increasing pressure on existing Internet and computing
     infrastructures.  To support latency-aware, privacy-enhanced, and
     scalable inference services, this document introduces the concept of
     Intelligence Delivery Network (IDN), in which models with different
     inference capabilities are deployed across geographically distributed
     servers and selected to serve inference requests.  This document
     describes the challenges motivating such networks, presents an
     architectural framework, and defines a common vocabulary for
     discussing the systems.  This document does not specify protocol
     details, which are left to future documents.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://kongyanye.github.io/draft-li-cats-idn/draft-li-cats-idn.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-li-cats-idn/.

     Discussion of this document takes place on the Computing-Aware
     Traffic Steering Working Group mailing list (mailto:cats@ietf.org),
     which is archived at https://mailarchive.ietf.org/arch/browse/cats/.
     Subscribe at https://www.ietf.org/mailman/listinfo/cats/.

     Source for this draft and an issue tracker can be found at
     https://github.com/kongyanye/draft-li-cats-idn.







  Li, et al.              Expires 3 September 2026                [Page 1]


  Internet-Draft                     IDN                        March 2026


  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 3 September 2026.

  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
     2.  Background and Challenges . . . . . . . . . . . . . . . . . .   4
       2.1.  Characteristics of Deep Learning Inference Workloads  . .   4
       2.2.  Limitations of Existing Computing Infrastructures . . . .   4
       2.3.  Emerging Capabilities in Model Deployment . . . . . . . .   5
       2.4.  Architectural Challenges  . . . . . . . . . . . . . . . .   5
     3.  Intelligence Delivery Network Framework . . . . . . . . . . .   6
       3.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   6
       3.2.  High-Level Architecture . . . . . . . . . . . . . . . . .   7
       3.3.  Inference Capability Representation . . . . . . . . . . .   8
       3.4.  Capability Placement and Distribution . . . . . . . . . .   8
       3.5.  Inference Request Handling  . . . . . . . . . . . . . . .   9
       3.6.  Caching and Capability Reuse  . . . . . . . . . . . . . .   9
       3.7.  Model Evolution and Lifecycle . . . . . . . . . . . . . .  10
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  10



  Li, et al.              Expires 3 September 2026                [Page 2]


  Internet-Draft                     IDN                        March 2026


     5.  Security, Privacy, and Trust Considerations . . . . . . . . .  12
       5.1.  Data Privacy and Locality . . . . . . . . . . . . . . . .  12
       5.2.  Model Integrity and Authenticity  . . . . . . . . . . . .  13
       5.3.  Trust Across Administrative Domains . . . . . . . . . . .  13
       5.4.  Inference Result Reuse and Isolation  . . . . . . . . . .  13
       5.5.  Availability and Abuse Considerations . . . . . . . . . .  14
     6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
     7.  Informative References  . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     The increasing deployment of deep learning models has led to rapid
     growth in inference workloads across the Internet.  Unlike model
     training, which is typically performed in centralized data centers
     using batch-oriented processing, inference workloads are often
     latency-sensitive, geographically distributed, and closely coupled
     with user data.  These characteristics introduce new requirements
     that were not primary design considerations in earlier Internet and
     computing architectures.

     Current approaches to deep learning inference largely rely on
     centralized or regionally centralized cloud infrastructures.  In such
     systems, user data is transmitted to a limited number of locations
     where inference is performed.  While effective for certain
     applications, this model can introduce challenges related to end-to-
     end latency, scalability, and privacy [RFC9556].  As inference demand
     continues to grow and applications increasingly require real-time
     responses, these limitations become more significant.

     At the same time, advances in model compression, quantization,
     distillation, and specialization have enabled inference capabilities
     to be represented in models of varying size and complexity.  As a
     result, it has become feasible to deploy different models at
     different locations in the network, ranging from large, general-
     purpose models in cloud data centers to smaller, task-oriented models
     on edge devices.  These developments motivate a shift from data-
     centric inference processing toward a model-centric approach to
     inference delivery.

     Inspired by the architectural principles of Content Delivery Networks
     (CDNs), this document introduces the concept of Intelligence Delivery
     Network (IDN).  An IDN is a network architecture in which inference
     capabilities, encoded in trained deep learning models, are deployed
     across a set of interconnected nodes.  Analogous to how CDNs cache
     content closer to users to improve delivery performance, IDNs place
     model-encoded intelligence closer to inference request sources in
     order to reduce latency and improve scalability.  In this framework,



  Li, et al.              Expires 3 September 2026                [Page 3]


  Internet-Draft                     IDN                        March 2026


     inference requests are served by appropriate model instances based on
     factors such as task requirements, locality, and system conditions,
     rather than being uniformly directed to a single centralized
     location.

     The remainder of this document is organized as follows.  Section 2
     provides background and discusses the challenges motivating IDNs.
     Section 3 presents the IDN architectural framework.  Section 4
     defines the terminology used in IDNs and explains the relationships
     among these terms.  Section 5 discusses security, privacy, and trust
     considerations.

  2.  Background and Challenges

     This section provides background on deep learning inference
     deployment and identifies challenges that motivate the Intelligence
     Delivery Network (IDN).

  2.1.  Characteristics of Deep Learning Inference Workloads

     Deep learning inference workloads differ from traditional Internet
     services and deep learning training workloads in several important
     aspects.  First, inference requests are often generated by
     interactive applications (e.g., conversational interfaces and
     programming assistants) and therefore tend to be latency-sensitive.
     Second, they are geographically distributed, reflecting the locations
     of end users and data sources.  Third, inference usually operates
     directly on user-generated or user-specific data, increasing
     sensitivity to data locality and privacy requirements.

     Inference workloads are also heterogeneous [Elf].  Different
     applications impose different requirements in terms of model
     accuracy, response time, resource consumption, and availability.  A
     single inference service may involve a mix of simple tasks that can
     be handled by lightweight models and more complex tasks that require
     larger or more capable models.  This diversity complicates uniform
     deployment and execution strategies.

  2.2.  Limitations of Existing Computing Infrastructures

     Today, large-scale deep learning models, exemplified by large
     language models (LLMs), have become dominant solutions across a wide
     range of application domains.  Due to their substantial computational
     and memory requirements, these models are typically deployed in
     centralized or regionally centralized cloud infrastructures.  In this
     deployment paradigm, inference requests and associated data are
     transmitted from clients to a limited number of data centers where
     the models are hosted and executed.  This approach benefits from



  Li, et al.              Expires 3 September 2026                [Page 4]


  Internet-Draft                     IDN                        March 2026


     operational simplicity and centralized management, and it aligns well
     with existing cloud computing practices.

     However, centralized inference deployment also exhibits limitations.
     Routing all inference requests to a limited set of locations can
     increase end-to-end latency, particularly for users far from data
     center locations.  Centralized processing may create scalability
     bottlenecks during demand spikes, and it can increase network traffic
     as raw data has to be transmitted over wide-area networks.  In
     addition, transferring user data to centralized locations may raise
     privacy, regulatory, or policy concerns in certain environments.

  2.3.  Emerging Capabilities in Model Deployment

     Recent advances in deep learning have enabled inference capabilities
     to be packaged in models of varying size, complexity, and
     specialization.  Techniques such as model compression, quantization,
     distillation, and task-specific fine-tuning allow smaller models to
     approximate the behavior of larger models for specific tasks or
     domains.  These developments make it possible to deploy inference
     models on a broader range of platforms and locations, including
     regional servers and edge devices.

     As a result, inference capability is no longer inherently tied to a
     small number of large data centers.  Instead, it can be distributed
     across multiple layers of the network, with different models
     providing different levels of capability and performance.  This
     flexibility creates opportunities for architectures that place
     inference closer to data sources or users while retaining access to
     more capable models when needed.

  2.4.  Architectural Challenges

     Despite these advances, several architectural challenges remain
     unaddressed by existing deployment paradigm:

     *  Capability Placement: Determining where different inference
        capabilities should be deployed to balance latency, accuracy,
        resource usage, and operational cost.

     *  Request Selection and Steering: Selecting appropriate model
        instances for individual inference requests based on task
        requirements, locality, and system conditions.

     *  Scalability: Supporting large and dynamic inference demand without
        introducing centralized bottlenecks.





  Li, et al.              Expires 3 September 2026                [Page 5]


  Internet-Draft                     IDN                        March 2026


     *  Data Locality and Privacy: Limiting unnecessary data movement
        while meeting privacy and regulatory requirements.

     *  Operational Heterogeneity: Managing inference services across
        diverse hardware platforms, network conditions, and administrative
        domains.

     These challenges motivate the need for a new architectural framework
     that treats inference capability as a distributable, cacheable, and
     selectable entity within the network, rather than binding inference
     execution to a small number of centralized locations.

  3.  Intelligence Delivery Network Framework

     This section presents the architectural framework for Intelligence
     Delivery Network (IDN).  The framework describes how inference
     capabilities are organized, deployed, and selected across
     interconnected nodes, and how these components relate to one another
     at a conceptual level.

  3.1.  Design Principles

     The IDN framework is guided by the following design principles:

     *  Capability-Centric Delivery: Inference capability, encoded in
        trained models, is treated as a first-class entity that can be
        deployed, selected, and reused independently of specific compute
        resources.

     *  Hierarchical and Distributed Deployment: Inference capabilities
        are deployed across multiple layers of the network, including
        centralized data centers, regional infrastructure, and edge
        devices, to balance performance, cost, and scalability.

     *  Locality Awareness: Placement and selection of inference
        capabilities should account for network proximity, data locality,
        and latency sensitivity.

     *  Reuse and Efficiency: The framework encourages reuse of inference
        results, intermediate representations, and distilled capabilities
        to reduce redundant computation and unnecessary data movement.

     *  Incremental Evolution: The framework accommodates continuous
        evolution of inference capabilities, including updates,
        specialization, and replacement, without requiring global
        redeployment.





  Li, et al.              Expires 3 September 2026                [Page 6]


  Internet-Draft                     IDN                        March 2026


  3.2.  High-Level Architecture

                        +---------------------------+
                        |   Central Data Centers    |
                        |  (General-Purpose Models) |
                        |                           |
                        | - Large foundation        |
                        |     inference models      |
                        | - Capability distillation |
                        +-------------+-------------+
                                      |
                                      |
                            Capability Distribution
                                      |
                                      |
                  +-------------------+--------------------+
                  |                                        |
     +------------+-------------+             +------------+-------------+
     |    Regional IDN Nodes    |             |    Regional IDN Nodes    |
     |(Specialized Capabilities)|             |(Specialized Capabilities)|
     |                          |             |                          |
     | - Domain-specific models |             |  - Task-oriented models  |
     | - Cached popular skills  |             |  - Cached popular skills |
     +------------+-------------+             +------------+-------------+
                  |                                        |
         Inference|                                        | Inference
         Requests |                                        | Requests
                  |                                        |
     +------------+-------------+            +-------------+-------------+
     |    Edge / Access Nodes   |            |     Edge / Access Nodes   |
     |(Lightweight Capabilities)|            | (Lightweight Capabilities)|
     |                          |            |                           |
     |  - Latency-sensitive     |            |   - Privacy-sensitive     |
     |      inference tasks     |            |       inference tasks     |
     +------------+-------------+            +-------------+-------------+
                  |                                        |
                  +-------------------+--------------------+
                                      |
                                      |
                                  End Users

     At a high level, an IDN consists of a set of interconnected nodes
     capable of hosting and executing inference models.  These nodes may
     belong to different administrative domains and may operate under
     diverse hardware and network conditions.  Each node may host one or
     more inference capabilities, represented by trained models.





  Li, et al.              Expires 3 September 2026                [Page 7]


  Internet-Draft                     IDN                        March 2026


     Inference requests enter the IDN from clients or upstream systems and
     are directed to appropriate nodes based on capability requirements
     and operational considerations.  Rather than uniformly forwarding
     requests to a centralized location, the IDN enables selection among
     multiple candidate nodes that offer suitable inference capabilities.

     The architecture allows inference capabilities to be replicated,
     cached, or specialized at different locations.  Popular or frequently
     invoked capabilities may be deployed closer to request sources, while
     less frequently used or more complex capabilities may remain
     centralized.

  3.3.  Inference Capability Representation

     In the IDN framework, inference capability refers to the ability of a
     model to perform a particular class of inference tasks with defined
     accuracy, latency, and resource characteristics.  Capabilities may
     differ in scope and complexity, ranging from general-purpose models
     to highly specialized or task-specific models.

     Inference capabilities may be derived from larger models through
     techniques such as distillation, compression, fine-tuning, or
     specialization.  In addition, analysis of usage patterns across users
     or applications may identify frequently invoked tasks or “hot”
     capabilities.  Such capabilities can be decomposed or extracted from
     more general models and represented as smaller, specialized models
     that retain task-level accuracy while reducing computational and
     memory requirements.

     Each inference capability is associated with a set of descriptive
     attributes, such as supported tasks, expected resource usage,
     accuracy characteristics, performance profiles, and update frequency.
     These attributes provide an abstract description of the capability
     independent of its deployment location and serve as inputs to
     placement, distribution, and request selection decisions within the
     IDN.

  3.4.  Capability Placement and Distribution

     The IDN framework separates the concept of capability placement from
     inference execution.  Placement refers to decisions about where
     inference capabilities are deployed within the network, while
     execution refers to the processing of individual inference requests
     by deployed capability instances.

     Based on capability attributes and observed demand, capabilities may
     be proactively deployed in anticipation of expected usage or
     dynamically replicated in response to changing access patterns.



  Li, et al.              Expires 3 September 2026                [Page 8]


  Internet-Draft                     IDN                        March 2026


     Frequently used or latency-sensitive capabilities may be placed
     closer to inference request sources, such as regional or edge nodes,
     while less frequently used or more resource-intensive capabilities
     may remain at centralized locations.

     The ability to represent popular or task-specific capabilities as
     smaller models enables selective distribution of such capabilities to
     locations closer to users.  This approach allows the framework to
     reduce inference latency and resource consumption while preserving
     access to larger, more general models when higher capability is
     required.  The placement and distribution of inference capabilities
     are conceptually analogous to the distribution of popular content in
     Content Delivery Networks (CDNs).

     The framework allows multiple capability instances providing the same
     task to exist at different locations, potentially with different
     operational characteristics, enabling flexible trade-offs among
     performance, cost, and scalability.

  3.5.  Inference Request Handling

     When an inference request is issued, the IDN framework enables
     selection of an appropriate capability instance based on factors such
     as task requirements, locality, availability, and current system
     conditions.  This selection may involve an explicit or implicit
     request resolution step, in which a client or intermediary is
     directed to an appropriate IDN node that hosts a suitable inference
     capability.  Such resolution may be performed using existing Internet
     mechanisms or application-layer services.

     The framework does not prescribe specific routing or selection
     mechanisms.  Instead, it defines the architectural context in which
     such mechanisms operate, enabling flexible request steering across
     distributed capability instances.

  3.6.  Caching and Capability Reuse

     To improve efficiency and scalability, the IDN framework supports
     caching and reuse at multiple levels.  Inference results or
     intermediate representations may be reused across similar requests,
     including requests from different users, when appropriate [KVShare].
     This reuse can reduce repeated computation for common or popular
     inference tasks.

     Caching and reuse decisions are influenced by factors such as
     workload characteristics, resource constraints, and consistency
     requirements.




  Li, et al.              Expires 3 September 2026                [Page 9]


  Internet-Draft                     IDN                        March 2026


  3.7.  Model Evolution and Lifecycle

     Inference capabilities within an IDN are expected to evolve over
     time.  Models may be updated, replaced, refined, or specialized as
     new data becomes available, as usage patterns change, or as
     application requirements evolve.  The framework supports incremental
     updates and the coexistence of multiple capability versions, enabling
     gradual transitions rather than requiring global or disruptive
     replacements.

     Model evolution may be driven by multiple sources.  Updates can be
     produced centrally, for example through cloud-side retraining,
     refinement, or distillation of models, and subsequently distributed
     to appropriate locations within the IDN.  In addition, where
     permitted by policy and regulatory constraints, inference
     capabilities deployed at edge or near-user locations may be locally
     adapted using user-provided or locally observed data.  Such local
     adaptation may follow federated or privacy-preserving learning
     approaches, in which locally derived updates contribute to global
     model improvement without requiring raw data to leave the local
     environment.

     Lifecycle management of inference capabilities includes deployment,
     update, versioning, deprecation, and removal.  Different versions of
     a capability may coexist at the same or different locations, allowing
     the framework to balance stability, performance, and innovation.
     While this document does not specify how lifecycle management
     processes are implemented, it assumes that mechanisms for controlled
     rollout, compatibility management, and rollback are necessary to
     ensure operational stability and consistency within an IDN.

  4.  Terminology

     This section defines the terminology used throughout this document.
     The terms defined here are intended to provide a common vocabulary
     for discussing IDNs.

     Phrases in upper-case refer to other defined terms.

     CACHE AND REUSE

     CACHE AND REUSE refers to mechanisms that reduce redundant inference
     execution by reusing inference results, intermediate representations,
     or derived capabilities across multiple requests or users.  Caching
     may apply to complete inference outputs or to partial results,
     depending on workload characteristics and policy constraints.

     CAPABILITY DISTRIBUTION



  Li, et al.              Expires 3 September 2026               [Page 10]


  Internet-Draft                     IDN                        March 2026


     CAPABILITY DISTRIBUTION refers to the dissemination of INFERENCE
     CAPABILITIES or their derived forms across IDN nodes.  Distribution
     may involve replication, specialization, or relocation of
     capabilities to support demand and performance objectives.

     CAPABILITY PLACEMENT

     CAPABILITY PLACEMENT refers to the process of determining where
     INFERENCE CAPABILITIES or MODEL INSTANCES are deployed within an IDN.
     Placement decisions may consider factors such as demand, locality,
     resource availability, and operational cost.

     IDN

     Intelligence Delivery Network.  IDN is a network architecture in
     which INTELLIGENCE, encoded in deep learning models, is deployed,
     distributed, and selected across interconnected nodes to serve
     INFERENCE REQUESTS.  An IDN enables INFERENCE CAPABILITIES to be
     placed at different locations in the network and selected based on
     task requirements, locality, and operational conditions.

     IDN NODE

     A network-accessible entity that hosts one or more MODEL INSTANCES
     and is capable of executing INFERENCE REQUESTS.  IDN nodes may be
     located in cloud data centers, regional infrastructure, or edge
     environments and may operate under different administrative domains.

     INFERENCE CAPABILITY

     The ability of a model to perform a defined class of inference tasks
     with specified accuracy, performance, and resource characteristics.
     INFERENCE CAPABILITY may be provided by a single model or by a set of
     related model artifacts derived from a common source.

     INFERENCE REQUEST

     A request to perform inference using a specified or implied INFERENCE
     CAPABILITY on provided input data.  An INFERENCE REQUEST may include
     task-specific parameters, quality requirements, or constraints
     relevant to capability selection.

     INFERENCE REQUEST STEERING

     The process of selecting and directing an INFERENCE REQUEST to an
     appropriate MODEL INSTANCE within an IDN.  Steering decisions may
     take into account task requirements, proximity, system load, and
     policy constraints.



  Li, et al.              Expires 3 September 2026               [Page 11]


  Internet-Draft                     IDN                        March 2026


     INTELLIGENCE

     INTELLIGENCE refers to INFERENCE CAPABILITY encoded in a trained deep
     learning model.  This includes the ability to perform specific tasks,
     reasoning functions, or predictions based on input data.  In this
     document, INTELLIGENCE is treated as a distributable and reusable
     capability.

     MODEL EVOLUTION

     MODEL EVOLUTION describes the process by which INFERENCE CAPABILITIES
     change over time, including updates, specialization, replacement, or
     deprecation of models.  Model evolution may result in multiple
     versions of a capability coexisting within an IDN.

     MODEL INSTANCE

     A deployed realization of an INFERENCE CAPABILITY at a specific
     network node.  Multiple MODEL INSTANCE may provide the same INFERENCE
     CAPABILITY and may differ in operational characteristics such as
     latency, capacity, or availability.

  5.  Security, Privacy, and Trust Considerations

     IDNs introduce new security, privacy, and trust considerations by
     distributing inference capabilities and processing across multiple
     network locations and administrative domains.  This section discusses
     these considerations at an architectural level.

  5.1.  Data Privacy and Locality

     Inference workloads frequently operate on user-generated or user-
     specific data, which may be sensitive in nature.  Transmitting such
     data across the network to centralized locations can raise privacy,
     regulatory, or policy concerns.  IDNs may mitigate some of these
     concerns by enabling inference to be performed closer to data
     sources, thereby reducing unnecessary data movement.

     However, distributing inference capabilities across multiple nodes
     also increases the number of locations where data may be processed.
     This expansion of the processing surface requires careful
     consideration of data handling policies, access controls, and
     compliance with applicable regulations.  The IDN framework does not
     mandate specific privacy mechanisms but assumes that privacy
     requirements influence capability placement and request steering
     decisions.





  Li, et al.              Expires 3 September 2026               [Page 12]


  Internet-Draft                     IDN                        March 2026


  5.2.  Model Integrity and Authenticity

     Inference capabilities in an IDN are encoded in trained models that
     may be distributed, replicated, or derived across the network.
     Ensuring the integrity and authenticity of these models is critical,
     as tampered or malicious models could produce incorrect or harmful
     inference results.

     Architectural considerations include the ability to verify that a
     capability instance corresponds to an authorized and unmodified
     model, and to ensure that model updates or derived capabilities
     originate from trusted sources.  The framework assumes the existence
     of mechanisms to support model provenance and integrity, but does not
     specify how such mechanisms are implemented.

  5.3.  Trust Across Administrative Domains

     IDNs may span multiple administrative domains, particularly when
     inference capabilities are deployed across cloud, edge, and user-
     managed environments.  In such scenarios, each administrative domain
     may operate under distinct operational policies, trust assumptions,
     and security controls.  As a result, inference requests and inference
     capabilities may traverse trust boundaries, requiring explicit
     consideration of trust relationships among participating entities.

     Trust considerations include determining which nodes are permitted to
     host or execute specific inference capabilities, which entities are
     authorized to distribute or update models, and under what conditions
     inference requests may be forwarded across domains.  The IDN
     framework assumes that trust relationships influence capability
     distribution and request steering, but does not define trust
     establishment or enforcement mechanisms.

  5.4.  Inference Result Reuse and Isolation

     Caching and reuse of inference results or intermediate
     representations can improve efficiency and scalability, but may
     introduce security and privacy risks if not properly managed.  Reuse
     across different users or contexts may lead to unintended information
     disclosure or inference of sensitive attributes.

     Architectural considerations include ensuring appropriate isolation
     between inference contexts, defining conditions under which reuse is
     permissible, and preventing cross-user data leakage.  The framework
     treats reuse as an optional optimization whose applicability depends
     on workload characteristics and policy constraints.





  Li, et al.              Expires 3 September 2026               [Page 13]


  Internet-Draft                     IDN                        March 2026


  5.5.  Availability and Abuse Considerations

     As inference capabilities become more widely distributed, IDN nodes
     may be exposed to abuse, misuse, or denial-of-service attacks.
     Concentration of popular capabilities at specific nodes may create
     attractive targets for attacks that aim to degrade service
     availability.

     The IDN framework recognizes the need to consider resilience and
     robustness in the presence of such threats, including the ability to
     distribute load, replicate capabilities, or redirect requests in
     response to failures or attacks.

  6.  Acknowledgments

     The authors would like to thank colleagues and reviewers in the
     community who provided feedback on the early version of this draft.

  7.  Informative References

     [Elf]      Zhang, W., He, Z., Liu, L., Jia, Z., Liu, Y., Gruteser,
                M., Raychaudhuri, D., and Y. Zhang, "Elf: accelerate high-
                resolution mobile deep vision with content-aware parallel
                offloading", Proceedings of the 27th Annual International
                Conference on Mobile Computing and Networking,
                DOI 10.1145/3447993.3448628, September 2021,
                <https://dl.acm.org/doi/abs/10.1145/3447993.3448628>.

     [KVShare]  Yang, H., Zhang, R., Huang, M., Wang, W., Tang, Y., Li,
                Y., Liu, Y., and D. Zhang, "KVShare: An LLM Service System
                with Efficient and Effective Multi-Tenant KV Cache Reuse",
                arXiv preprint arXiv:2503.16525, May 2025,
                <https://arxiv.org/abs/2503.16525>.

     [RFC9556]  Hong, J., Hong, Y., de Foy, X., Kovatsch, M., Schooler,
                E., and D. Kutscher, "Internet of Things (IoT) Edge
                Challenges and Functions", RFC 9556, DOI 10.17487/RFC9556,
                April 2024, <https://www.rfc-editor.org/rfc/rfc9556>.

  Authors' Addresses

     Qing Li
     Pengcheng Laboratory
     Email: liq@pcl.ac.cn


     Hanling Wang
     Pengcheng Laboratory



  Li, et al.              Expires 3 September 2026               [Page 14]


  Internet-Draft                     IDN                        March 2026


     Email: wanghl03@pcl.ac.cn


     Yong Jiang
     Tsinghua Shenzhen International Graduate School & Pengcheng Laboratory
     Email: jiangy@sz.tsinghua.edu.cn


     Mingwei Xu
     Tsinghua University
     Email: xumw@tsinghua.edu.cn








































  Li, et al.              Expires 3 September 2026               [Page 15]


