# drafts

name: draft-zhu-anima-service-intent
rev: 00
title: Definition of Service Intent in Autonomic Networks
time: 2026-03-02T12:15:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T12:15:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.795672+00:00
source: ietf
source_id: 153972
source_url: https://datatracker.ietf.org/doc/draft-zhu-anima-service-intent/
doc_status: active
abstract:
  While ANIMA Intent enables goal-oriented control within an Autonomic
     Domain, emerging services (e.g., AI inference) require a common,
     interoperable representation for expressing service-level objectives
     and constraints that span network, compute, and storage resources,
     rather than connection-centric descriptions.  This document defines
     Service Intent for Autonomic Networks by specifying a structured
     semantic model and a concise format with identification, scope,
     versioning, and lifecycle semantics.

full_text:
  ANIMA                                                             L. Zhu
  Internet-Draft                                                   B. Wang
  Intended status: Standards Track                                S. Jiang
  Expires: 3 September 2026                                           BUPT
                                                              2 March 2026


             Definition of Service Intent in Autonomic Networks
                     draft-zhu-anima-service-intent-00

  Abstract

     While ANIMA Intent enables goal-oriented control within an Autonomic
     Domain, emerging services (e.g., AI inference) require a common,
     interoperable representation for expressing service-level objectives
     and constraints that span network, compute, and storage resources,
     rather than connection-centric descriptions.  This document defines
     Service Intent for Autonomic Networks by specifying a structured
     semantic model and a concise format with identification, scope,
     versioning, and lifecycle semantics.

  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



  Zhu, et al.             Expires 3 September 2026                [Page 1]


  Internet-Draft               service-intent                   March 2026


     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Definition of Service Intent  . . . . . . . . . . . . . . . .   4
       3.1.  Overview and Metadata . . . . . . . . . . . . . . . . . .   4
       3.2.  Resource Requirement Intents  . . . . . . . . . . . . . .   6
         3.2.1.  Network Resource Requirement Intent . . . . . . . . .   6
         3.2.2.  Compute Resource Requirement Intent . . . . . . . . .   7
         3.2.3.  Storage Resource Requirement Intent . . . . . . . . .   8
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     Within the ANIMA framework, intent is an abstract, declarative, high-
     level policy applicable to an Autonomic Domain.  Expressed in terms
     of desired goals and constraints, intent steers network operation
     rather than acting as device-level configuration commands.  It is
     distributed across the domain and interpreted by autonomic nodes,
     which translate it into target configurations while considering local
     state and environmental constraints.  This approach enables closed-
     loop automation and reduces the operational burden on human operators
     by shifting from imperative configuration to goal-oriented
     management.






  Zhu, et al.             Expires 3 September 2026                [Page 2]


  Internet-Draft               service-intent                   March 2026


     However, emerging services increasingly rely on the coordinated use
     of heterogeneous resources beyond simple connectivity.  Traditional
     connection-centric service descriptions, which primarily specify
     endpoints and basic transport characteristics, are insufficient to
     represent user-perceived quality objectives for complex tasks such as
     AI inference, interactive media processing, and large-scale content
     rendering.  These services are often constrained not only by network
     performance (e.g., bandwidth, latency, and jitter), but also by
     compute availability (e.g., processing capacity and placement-induced
     request latency) and storage capabilities (e.g., capacity and access
     throughput).  Moreover, practical deployment decisions frequently
     require expressing cross-resource coordination constraints, such as
     coupling compute placement with transport path selection, or
     accounting for the time cost of data access along selected paths.

     This document introduces and defines the concept of Service Intent
     for Autonomic Networks by analyzing the characteristics of user
     service demand expressed as intent.  The aim is to provide a
     structured, declarative, semantic framework that enables service-
     level requirements and constraints across network, compute, and
     storage dimensions to be specified consistently.  By enabling the
     autonomic interpretation of these requirements within an Autonomic
     Domain, the Service Intent model facilitates the automated discovery,
     selection, routing, and scheduling of resources, thereby supporting
     the automated deployment of services and reducing the complexity of
     using heterogeneous resources.  The detailed mechanisms for realizing
     intent interpretation and automated service deployment are out of
     scope for this document and are described in
     [I-D.ietf-anima-network-service-auto-deployment] and [draft-du-anima-
     service-intent-auto-deployment].

     In addition, this document specifies a concrete, machine-readable
     format for Service Intent to support interoperable intent exchange
     and processing within an Autonomic Domain, including essential fields
     for identification, scoping, versioning, and lifecycle management,
     and a structured representation of intent content aligned with
     network-, compute-, and storage-resource requirement intents.

  2.  Requirements

     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.






  Zhu, et al.             Expires 3 September 2026                [Page 3]


  Internet-Draft               service-intent                   March 2026


  3.  Definition of Service Intent

     This section defines a Service Intent as a structured, machine-
     interpretable declaration of the desired service objectives and
     associated resource constraints for autonomic service deployment
     within Autonomic Networks.

  3.1.  Overview and Metadata

     Unlike traditional connectivity-oriented service descriptions that
     primarily specify endpoints and transport parameters, a Service
     Intent expresses coordinated, multi-dimensional requirements across
     heterogeneous infrastructure resources.  These requirements MAY span
     compute resources, storage resources, transport resources, and cross-
     layer or cross-domain constraints.  By abstracting the desired
     service outcome rather than specific configuration actions, a Service
     Intent enables automated resource discovery, path computation,
     compute scheduling, and storage placement, thereby supporting goal-
     driven service orchestration and deployment.

     The Service Intent model defined herein is outcome-oriented rather
     than configuration-oriented.  It specifies the intended operational
     state of a service without mandating implementation procedures,
     device-level configurations, or specific realization mechanisms.

     The Service Intent consists of the following fields:

      service-intent = {
      "intent-id"        : uint,
      "intent-version"   : uint,
      "intent-timestamp" : uint,        ; Epoch time
      "intent-scope"     : scope-obj,   ; in seconds
      "intent-content"   : content-obj
      }

     *  Intent Identifier(unsigned integer).  The Intent Identifier
        uniquely identifies an intent instance within its applicable
        scope.  It MUST be unique within the defined scope and MUST remain
        stable across version updates of the same intent.

     *  Intent Version(unsigned integer).  The Intent Version indicates
        the revision of a Service Intent.  It MUST increase monotonically
        upon modification and MUST enable determination of the most recent
        intent state.

     *  Intent Timestamp(unsigned integer, epoch time).  The Intent
        Timestamp indicates the time at which a Service Intent instance
        was created, issued, or last updated.



  Zhu, et al.             Expires 3 September 2026                [Page 4]


  Internet-Draft               service-intent                   March 2026


     *  Intent Lifetime(unsigned integer, seconds).  The Intent Lifetime
        defines the temporal validity period during which a Service Intent
        is considered active, observable, and eligible for evaluation or
        enforcement within its declared Intent Scope.  A Service Intent
        instance MUST be considered expired when its defined lifetime
        condition is met.

     *  Intent Scope (object).  The Intent Scope defines the applicability
        scope of a Service Intent.  It MUST identify at least one
        Autonomic Domain in which the intent is valid, and MAY further
        restrict applicability to specific sub-domains, logical
        partitions, tenants, service slices, or topology segments.  An
        autonomic node MUST only process the Service Intent applicable
        within its operational scope.

         scope-obj = {
          "domain"             : tstr,
          ? "subdomain"        : tstr,
          ? "tenant"           : tstr,
          ? "topology-segment" : tstr
        }

     *  Intent Content (object).  A Service Intent MUST be expressed as a
        structured object that MAY include one or more of the following
        logical components defined in Section 3.2: a) Network resource
        requirement intent; b) Compute resource requirement intent; c)
        Storage resource requirement intent.  Each component declaratively
        specifies the desired target state of the corresponding resource
        dimension and MAY include inter-resource dependency constraints.
        The content-obj MAY include any subset of the three members,
        depending on the service scenario.  Processing of content-obj MUST
        handle each present member independently according to the
        semantics defined in Section 3.2, and SHOULD combine multiple
        present members to derive a consistent multi-resource provisioning
        decision.  If none of the three members is present, content-obj is
        invalid and MUST be ignored.  Any unrecognized additional member
        MUST be ignored and MUST NOT cause failure in processing of
        recognized members.

         content-obj = {
          ? "network" : network-intent,
          ? "compute" : compute-intent,
          ? "storage" : storage-intent
        }







  Zhu, et al.             Expires 3 September 2026                [Page 5]


  Internet-Draft               service-intent                   March 2026


  3.2.  Resource Requirement Intents

  3.2.1.  Network Resource Requirement Intent

     The Network resource requirement intent specifies the required
     network resource capabilities necessary to satisfy the service.  It
     expresses quantitative and qualitative requirements over transport
     resources within the declared Intent Scope.  These requirements
     define the desired performance, availability, and forwarding
     characteristics of network resources allocated for the service.

     The Network resource requirement intent includes the following
     fields:

     network-intent = {
      "Bandwidth-Requirement" :  uint,   ; Bandwidth Requirement(bps)
      "latency-bound"         : uint,    ; Latency Bound(ms)
      "jitter-bound"          : uint,    ; Jitter Bound(ms)
      "destinations"          : 1* tstr, ; non-empty array of text strings
      "multipath-permission"  : bool,    ; TRUE allows multipath
     }

     *  Bandwidth Requirement (unsigned integer, bps).  The minimum or
        guaranteed bandwidth required.  The value MUST be greater than or
        equal to 0; if it is specified as zero, no minimum bandwidth
        constraint is imposed.

     *  Latency Bound (unsigned integer, ms).  The maximum acceptable end-
        to-end delay.  The value MUST be greater than or equal to 0; if it
        is specified as zero, no latency constraint is imposed.

     *  Jitter Bound (unsigned integer, ms).  The maximum acceptable delay
        variation.  The value MUST be greater than or equal to 0; if it is
        specified as zero, no jitter constraint is imposed.

     *  Destinations (array of text strings, non-empty).  Target endpoint
        or location identifiers; MUST contain at least one element.

     *  Multipath Permission (boolean).  A boolean indicator specifying
        whether multipath transport MAY be used; TRUE allows multipath,
        FALSE forbids multipath.










  Zhu, et al.             Expires 3 September 2026                [Page 6]


  Internet-Draft               service-intent                   March 2026


  3.2.2.  Compute Resource Requirement Intent

     The Compute resource requirement intent specifies the required
     computational resource capabilities necessary to satisfy the service.
     It expresses quantitative and qualitative requirements over compute
     resources within the declared Intent Scope.  These requirements
     define the desired processing capacity, placement constraints, and
     latency characteristics of compute resources allocated for the
     service.

     The Compute resource requirement intent includes the following
     fields.

      compute-intent = {
       ; Request Latency Bound(ms)
       "request-latency"         : uint,

       ; TRUE allows concurrent transport/compute
       "transport-coordination"  : bool,

       ; Compute Capacity Requirement
       "compute-capacity"        : 1* compute-capa
     }

     compute-capa = {
       ; "cpu" or "gpu"
       "type"       : ("cpu" / "gpu"),

       ; Compute capacity value(GFLOPS)
       "capacity"   : uint
     }

     *  Request Latency Bound (unsigned integer, ms).  The maximum
        acceptable request-to-response latency between the service and the
        compute resource.  The value MUST be greater than or equal to 0;
        if it is specified as zero, no latency constraint is imposed.

     *  Transport Coordination (boolean).  A boolean indicator that
        specifies whether compute processing and data transport are
        permitted to proceed concurrently.

        -  TRUE: Compute processing and data transport MAY proceed
           concurrently (i.e., streaming or pipelined execution).  Data
           MAY be transmitted incrementally during processing.

        -  FALSE: Compute processing and data transport MUST be executed
           in separate phases.  Data MUST be fully processed before
           transmission, or fully transmitted before processing begins.



  Zhu, et al.             Expires 3 September 2026                [Page 7]


  Internet-Draft               service-intent                   March 2026


     *  Compute Capacity Requirement (array).  Contains at leaset one
        compute-capacity element.  Each compute-capacity element is a
        structured requirement that specifies the minimum compute capacity
        needed to satisfy the service for a given type of computing
        resource.  The compute-capacity is as follows.

        -  Type (text).  Indicates the type of compute resource.  The
           values "cpu" and "gpu" are defined by this document.

        -  Capacity (unsigned integer, GFLOPS).  The minimum compute
           capacity required for the specified type.  The value MUST be
           greater than or equal to 0; if it is specified as zero, no
           minimum compute capacity constraint is imposed for that type.

  3.2.3.  Storage Resource Requirement Intent

     The Storage resource requirement intent specifies the required
     storage resource capabilities necessary to satisfy the service.  It
     expresses quantitative and qualitative requirements over storage
     resources within the declared Intent Scope.  These requirements
     define the desired capacity, performance, locality, and persistence
     characteristics of storage resources allocated for the service.

     The Storage resource requirement intent includes the following
     fields:

      storage-intent = {
       ; Storage Capacity Requirement(GB)
       "storage-capacity"          : uint,

       ; Throughput numeric value
       "storage-throughput"        : uint,

       ? "storage-throughput-unit" : ("MB/s" / "GB/s"),
     }

     *  Storage Capacity Requirement (unsigned integer, GB).  The required
        storage capacity representing the temporary or persistent space
        necessary to satisfy the service.  The value MUST be greater than
        or equal to 0; if it is specified as zero, no minimum storage
        capacity constraint is imposed.

     *  Storage Throughput Requirement (unsigned integer, MB/s or GB/s).
        The required data access throughput representing the read and
        write rate necessary to satisfy the workload.  The value MUST be
        greater than or equal to 0; if it is specified as zero, no minimum
        storage throughput constraint is imposed.




  Zhu, et al.             Expires 3 September 2026                [Page 8]


  Internet-Draft               service-intent                   March 2026


  4.  IANA Considerations

     There is currently no IANA consideration.

  5.  Security Considerations

     A strong security environment is required for the Service Intent,
     since malicious injection or tampering would pose a significant risk
     to automated resource selection and service deployment.  If a Service
     Intent is disseminated and synchronized across an autonomic domain,
     the signaling channel must provide mutual authentication and
     integrity protection consistent with the Autonomic Domain security
     environment.  In addition, an intent instance should employ an
     explicit signature to provide object-level authentication, integrity,
     and non-repudiation.

     TODO more security considerations.

  6.  References

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

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

  6.2.  Informative References

     [I-D.ietf-anima-network-service-auto-deployment]
                Jiang, S. and Z. Du, "An Intent-based Framework of Network
                Services Autonomic Deployment and Management", Work in
                Progress, Internet-Draft, draft-ietf-anima-network-
                service-auto-deployment-07, 1 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                network-service-auto-deployment-07>.






  Zhu, et al.             Expires 3 September 2026                [Page 9]


  Internet-Draft               service-intent                   March 2026


     [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
                Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
                Networking: Definitions and Design Goals", RFC 7575,
                DOI 10.17487/RFC7575, June 2015,
                <https://www.rfc-editor.org/info/rfc7575>.

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

  Authors' Addresses

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


     Bizhu Wang
     Beijing University of Posts and Telecommunications
     No. 10 Xitucheng Road
     Haidian District, Beijing
     China
     Email: wangbizhu_7@bupt.edu.cn


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
















  Zhu, et al.             Expires 3 September 2026               [Page 10]


name: draft-zhang-rtgwg-multicast-requirements-gaps-aidc
rev: 00
title: Requirements and Gap Analysis of Multicast in AI Data Centers
time: 2026-03-02T14:14:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T14:14:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.800383+00:00
source: ietf
source_id: 153982
source_url: https://datatracker.ietf.org/doc/draft-zhang-rtgwg-multicast-requirements-gaps-aidc/
doc_status: active
abstract:
  Multicast has the potential to be applied in Artificial Intelligence
     Data Centers (AIDCs) to improve the efficiency of point-to-multipoint
     data transmission during large language model training and inference.
     This document identifies key requirements of multicast in AIDCs, and
     analyzes the gaps between these requirements and the capabilities of
     existing multicast technologies.

full_text:
  RTGWG                                                           J. Zhang
  Internet-Draft                                                  W. Cheng
  Intended status: Informational                              China Mobile
  Expires: 3 September 2026                                   2 March 2026


       Requirements and Gap Analysis of Multicast in AI Data Centers
           draft-zhang-rtgwg-multicast-requirements-gaps-aidc-00

  Abstract

     Multicast has the potential to be applied in Artificial Intelligence
     Data Centers (AIDCs) to improve the efficiency of point-to-multipoint
     data transmission during large language model training and inference.
     This document identifies key requirements of multicast in AIDCs, and
     analyzes the gaps between these requirements and the capabilities of
     existing multicast technologies.

  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.



  Zhang & Cheng           Expires 3 September 2026                [Page 1]


  Internet-Draft              Abbreviated Title                 March 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Multicast Requirements  . . . . . . . . . . . . . . . . . . .   3
       2.1.  Bidirectional Interactivity . . . . . . . . . . . . . . .   3
       2.2.  High Reliability  . . . . . . . . . . . . . . . . . . . .   4
       2.3.  High Dynamics . . . . . . . . . . . . . . . . . . . . . .   5
       2.4.  Sparseness  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.5.  Simplicity  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Typical Multicast Technologies  . . . . . . . . . . . . .   6
       3.2.  Gap Analysis Against Requirements . . . . . . . . . . . .   7
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     Artificial Intelligence (AI) Data Centers (AIDCs) serve as the key
     infrastructure for AI large language model (LLM) training and
     inference, where point-to-multipoint (P2MP) communication patterns
     are pervasive and critical to overall system efficiency.  Network
     multicast leverages in-network data replication to achieve efficient
     distribution of identical data, reducing processing overhead and
     network bandwidth consumption of the sender, thereby enhancing the
     efficiency of P2MP data transmission.  Multicast is a promising
     technique for deployment in AIDCs.  The typical use cases of
     multicast in AIDCs are as follows:

     *  Token dispatch in Mixture-of-Experts (MoE) models: MoE is a
        mainstream architecture for LLMs.  During execution, input tokens
        are dispatched to multiple expert nodes based on routing
        decisions.  This token dispatch process naturally follows the
        multicast communication pattern
        [I-D.zzhang-bier-optimized-use-in-aidc].

     *  Data broadcast in AllReduce operations: In distributed training of
        LLMs, AllReduce is a core collective communication operation for
        data parallelism and tensor parallelism.  Although AllReduce can
        be implemented in multiple ways, decomposing it into Reduce and
        Broadcast phases is a basic approach, where the Broadcast phase
        can benefit from efficient network multicast.





  Zhang & Cheng           Expires 3 September 2026                [Page 2]


  Internet-Draft              Abbreviated Title                 March 2026


     *  Multi-replica checkpoint storage: To avoid loss of training
        progress due to failures, training programs periodically save
        model states, i.e., checkpoints, to multiple storage nodes.
        Multicast is a promising technique in this scenario, which is
        supposed to improve the efficiency of transmitting massive data to
        multiple replicas [I-D.liu-multicast-for-computing-storage].

     Despite these potential opportunities, existing multicast
     technologies are not originally designed to address the specific
     characteristics of AIDC networks.  AIDC networks are defined by
     ultra-high bandwidth (often 400 Gbps or greater), microsecond-level
     latency, and high reliability that demands near-zero packet loss.
     These core performance characteristics necessitate corresponding
     qualities in multicast technologies, including interactivity,
     reliability, and simplicity.  Furthermore, emerging multicast use
     cases in AIDCs, such as MoE token dispatch, also introduce specific
     requirements, including high dynamics and membership sparseness.

     This document identifies the key requirements for multicast in AIDCs
     and analyzes the limitations of existing multicast technologies in
     meeting these requirements.

  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.

  2.  Multicast Requirements

  2.1.  Bidirectional Interactivity

     AI workloads are highly sensitive to packet loss.  In LLM training,
     packet loss without a reliability acknowledgment mechanism can
     corrupt model parameters, leading to degraded model quality or even
     training failures.  Moreover, congestion control is required to
     actively avoid congestion and packet loss.  Therefore, networks in
     AIDCs are required to support closed-loop control, such
     acknowledgment and congestion control, to meet the high-performance
     and high-reliability requirements of AI workloads.

     Traditional IP multicast only supports best-effort P2MP data
     delivery, while multicast in AIDCs should support bidirectional
     interaction, including both efficient P2MP data forwarding and
     multipoint-to-point (MP2P) feedback forwarding.  The core
     interactivity demands are as follows:



  Zhang & Cheng           Expires 3 September 2026                [Page 3]


  Internet-Draft              Abbreviated Title                 March 2026


     *  P2MP forwarding: Multicast should support efficient P2MP
        forwarding, which is the fundamental requirement of multicast.

     *  MP2P forwarding: Multicast in AIDCs should natively support
        efficient MP2P forwarding, particularly for feedback signals
        generated from receivers to senders such as acknowledgments (ACKs)
        to confirm successful data reception and negative acknowledgments
        (NACKs) to report packet loss, as well as congestion notification
        signals.

     *  MP2P packet aggregation: In large-scale AIDCs with numerous
        receivers, if each receiver sends feedback packets to a sender
        independently, it can lead to excessive reverse traffic to the
        sender, resulting in network congestion, increased latency, and
        amplified jitter.  To address this issue, multicast in AIDCs
        should support MP2P packet aggregation.  Network devices serving
        as rendezvous points should aggregate multiple feedback packets
        from different receivers into a single packet and send it to the
        sender.

  2.2.  High Reliability

     Maintaining uninterrupted tasks for long periods is crucial for LLM
     training.  However, hardware is prone to failures, and as the scale
     of training networks increases, the likelihood of network failures
     rises due to an increasing number of switches, network interface
     cards, and optical modules
     [I-D.cheng-rtgwg-ai-network-reliability-problem].  Therefore,
     multicast in AIDCs should provide high reliability to ensure service
     continuity.  The specific requirements are as follows:

     *  Fast failure detection: The multicast should support fast
        detection of link failures and node failures and efficient
        detection of gray failures, which are the prerequisite for any
        subsequent recovery action.

     *  Fast failure recovery: Upon failure detection, the multicast
        should support fast recovery mechanisms to restore multicast
        traffic rapidly.  It is unacceptable to rely solely on global
        control-plane convergence and multicast tree reconstruction for
        slow recovery time.

     *  Minimized failure domain: The recovery mechanism should confine
        the impact of a failure to the smallest possible set of receivers.
        Local link or node failures should only affect the faulty segment,
        without spreading to the entire multicast tree or other service
        branches.




  Zhang & Cheng           Expires 3 September 2026                [Page 4]


  Internet-Draft              Abbreviated Title                 March 2026


  2.3.  High Dynamics

     AI workloads, especially those using sparse architectures like MoE,
     have highly dynamic communication patterns.  MoE-based AI training
     and inference uses token dispatch, where gating networks select
     expert nodes per token at microsecond timescales, dynamically
     determining real-time multicast receiver sets with no fixed groups.
     This ultra-fast selection leaves no time for traditional multicast to
     establish, update, or tear down trees, leading to delays, packet
     loss, or AI task failure [I-D.zhang-rtgwg-llmmoe-multicast].
     Therefore, multicast in AIDC should meet high dynamics requirements,
     and the key points are as follows:

     *  Fast change of multicast members: Multicast should be able to
        adapt to the dynamic change of multicast members in microsecond
        timescales.

     *  Low overhead for dynamic change: The dynamic change of multicast
        members should generate minimal overhead in both the control plane
        and data plane.  Excessive signaling or processing overhead during
        dynamic change will increase transmission latency and reduce the
        efficiency of AI workloads.

  2.4.  Sparseness

     Multicast in AIDCs frequently involves multicast groups where only a
     small fraction of the total nodes in the cluster are multicast
     members, a characteristic closely tied to the sparse activation
     mechanism of modern AI models such as MoE.  For example, DeepSeekV3
     uses 256 experts and activates 9 experts at a time.  Multicast
     technologies that are designed for dense groups are inefficient for
     this sparse mode.  The multicast should be efficient when the group
     size is small relative to the network size, and meet the following
     sparseness requirements:

     *  Efficient sparse member identification: Multicast technologies
        should support efficient identification of sparse multicast
        members.  The methods for identifying multicast members should
        avoid unnecessary scanning or signaling of non-member nodes, and
        be efficient for forwarding.

     *  Low overhead for sparse state maintenance: The maintenance of
        multicast member state should be lightweight and low-overhead,
        adapting to the sparse characteristics of AIDC multicast groups.
        It should avoid maintaining redundant state information for non-
        member nodes, reducing state maintenance burden and ensuring that
        state updates do not introduce additional latency that affects AI
        task efficiency.



  Zhang & Cheng           Expires 3 September 2026                [Page 5]


  Internet-Draft              Abbreviated Title                 March 2026


  2.5.  Simplicity

     Simplicity is a foundational architectural principle for multicast in
     AIDCs, directly enabling the microsecond-timescale low-latency
     transmission in large-scale AIDC networks.  Complexity in the control
     or data plane manifests as variable latency, unpredictable jitter,
     and an inability to meet the strict performance bounds of AI
     workloads.  Therefore, multicast in AIDCs should be governed by the
     following overarching simplicity requirements:

     *  Control plane simplicity: The multicast control plane should be
        architecturally simple to maintain core functions like multicast
        routing, minimizing signaling interaction overhead and control
        processes.  It should avoid complex state synchronization and
        protocol negotiation processes, to reduce network operation and
        maintenance complexity.

     *  Data plane simplicity: The multicast data plane needs to be highly
        efficient and simple, including efficient member identification
        and forwarding adapting to sparse and dynamic multicast
        characteristics, and optimized packet processing mechanisms.
        These ensure minimal forwarding and processing overhead, meeting
        the low-latency transmission requirements of AI workloads.

  3.  Gap Analysis

     To address the gaps between multicast requirements in AIDCs and
     existing technologies, typical multicast technologies are first
     introduced, followed by an analysis of their capabilities against key
     requirements.

  3.1.  Typical Multicast Technologies

     Protocol Independent Multicast (PIM) is a widely deployed multicast
     routing protocol that operates independently of underlying unicast
     routing protocols.  It supports dense mode (PIM-DM) [RFC3973] and
     sparse mode (PIM-SM) [RFC7761].  PIM-SM builds unidirectional shared
     trees rooted at a Rendezvous Point per group and it optionally
     creates shortest-path trees per source.

     Multipoint extensions for Label Distribution Protocol (mLDP)
     [RFC6388] constructs the P2MP or multipoint-to-multipoint (MP2MP)
     Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)
     networks without interacting with or relying upon any other multicast
     tree construction protocol.






  Zhang & Cheng           Expires 3 September 2026                [Page 6]


  Internet-Draft              Abbreviated Title                 March 2026


     Segment Routing Point-to-Multipoint (SR-P2MP)
     [I-D.ietf-pim-sr-p2mp-policy] enables creation of P2MP trees for
     efficient multi-point packet delivery in a Segment Routing (SR)
     domain.  It requires the routing module of the controller or ingress
     node to calculate and determine the path of the multicast traffic,
     and the data plane can reuse existing SR unicast forwarding
     mechanisms.

     Bit Indexed Explicit Replication (BIER) [RFC8279] is a stateless
     multicast technology that eliminates the need for explicit tree
     construction.  Instead, the set of intended receivers is encoded as a
     BitString within the packet header.  Intermediate BIER Forwarding
     Routers (BFRs) replicate packets based on the BitString, without
     maintaining any per-flow or per-tree state.

  3.2.  Gap Analysis Against Requirements

     The support of typical multicast technologies for multicast
     requirements in AIDCs is summarized in Table 1.

     +==========+=============+===========+========+==========+==========+
     |Technology|Interactivity|Reliability|Dynamics|Sparseness|Simplicity|
     +==========+=============+===========+========+==========+==========+
     |   PIM    |      No     |    Poor   |  Poor  |   Good   |   Poor   |
     +----------+-------------+-----------+--------+----------+----------+
     |   mLDP   |      No     |    Poor   |  Poor  |   Good   |   Poor   |
     +----------+-------------+-----------+--------+----------+----------+
     | SR-P2MP  |      No     |    Good   |Moderate|   Good   | Moderate |
     +----------+-------------+-----------+--------+----------+----------+
     |   BIER   |      No     |    Good   |  Good  |   Poor   |   Good   |
     +----------+-------------+-----------+--------+----------+----------+

                             Table 1: Gap Analysis

     Interactivity: Traditional multicast technologies can support best-
     effort P2MP data delivery, but none of them can natively support the
     reverse MP2P forwarding or aggregation to achieve bidirectional
     interactivity.

     Reliability: The reliability of PIM and mLDP basically relies on
     routing convergence and multicast tree reconstruction.  Although some
     fast detection and recovery mechanisms [RFC9186][RFC9860][RFC7715]
     can be adopted to accelerate failure recovery, their tree-based
     architectures often keep the failure impact domain tree-level.  In
     contrast, BIER and SR-P2MP can effectively reuse unicast’s
     reliability capabilities such as Fast ReRouting, and control the
     failure domain within the damaged receivers, demonstrating good
     reliability.



  Zhang & Cheng           Expires 3 September 2026                [Page 7]


  Internet-Draft              Abbreviated Title                 March 2026


     Dynamics: PIM and mLDP adjust multicast trees via control signals,
     leading to slow convergence that struggles to handle high-frequency
     member changes.  SR-P2MP dynamically recalculates forwarding trees
     via a controller, which need global recalculating and result
     distribution.  BIER only requires updating the BitString in packets,
     enabling faster responses to member changes and exhibiting good
     dynamics.

     Sparseness: PIM, mLDP, and SR-P2MP can all adapt well to sparse
     scenarios, as they establish multicast trees or tunnels on demand,
     and multicast member identification is based on IP or other non-
     contiguous labels.  In contrast, BIER encodes the receiver set as a
     BitString, whose length is proportional to the number of nodes in the
     domain.  Even with sparse members, the full BitString must still be
     carried, leading to significant degradation in bandwidth overhead and
     forwarding efficiency.  This limits BIER’s applicability in AIDC
     sparse multicast scenarios.

     Simplicity: PIM and mLDP require the maintenance of complex multicast
     tree states and signaling mechanisms, resulting in high operational
     complexity and poor simplicity.  SR-P2MP reuses the SR unicast
     forwarding plane, with the control plane relying on a controller,
     leading to moderate complexity but still requiring additional tree
     management logic.  BIER, on the other hand, eliminates the need for
     explicit multicast tree construction, with no per-flow state at
     intermediate nodes, resulting in better simplicity.  Moreover,
     simplicity still needs further optimization to meet the ultra-high
     performance requirements of AI networks.

     In summary, the most critical common gap is the lack of native
     support for efficient, scalable bidirectional interactivity, which is
     the cornerstone for implementing closed-loop acknowledgement and
     congestion control.  Furthermore, no single multicast technology
     excels in all dimensions: some lack reliability, dynamics or
     simplicity (PIM, mLDP, SR-P2MP), others are inefficient for sparse
     groups (BIER).  Consequently, merely deploying or combining these
     existing technologies is insufficient to meet the stringent demands
     of AIDC workloads.  This gap analysis underscores the need for either
     a new architecture designed from the ground up for AIDCs or
     significant extensions to existing technologies.

  4.  IANA Considerations

     TBD.







  Zhang & Cheng           Expires 3 September 2026                [Page 8]


  Internet-Draft              Abbreviated Title                 March 2026


  5.  Security Considerations

     TBD.

  6.  References

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

  6.2.  Informative References

     [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
                Independent Multicast - Dense Mode (PIM-DM): Protocol
                Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
                January 2005, <https://www.rfc-editor.org/info/rfc3973>.

     [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
                Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
                Multicast - Sparse Mode (PIM-SM): Protocol Specification
                (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
                2016, <https://www.rfc-editor.org/info/rfc7761>.

     [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
                Thomas, "Label Distribution Protocol Extensions for Point-
                to-Multipoint and Multipoint-to-Multipoint Label Switched
                Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
                <https://www.rfc-editor.org/info/rfc6388>.

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

     [RFC9186]  Mirsky, G. and X. Ji, "Fast Failover in Protocol
                Independent Multicast - Sparse Mode (PIM-SM) Using
                Bidirectional Forwarding Detection (BFD) for Multipoint
                Networks", RFC 9186, DOI 10.17487/RFC9186, January 2022,
                <https://www.rfc-editor.org/info/rfc9186>.




  Zhang & Cheng           Expires 3 September 2026                [Page 9]


  Internet-Draft              Abbreviated Title                 March 2026


     [RFC9860]  Liu, Y., McBride, M., Zhang, Z., Xie, J., and C. Lin,
                "Multicast-Only Fast Reroute (MoFRR) Based on Topology
                Independent Loop-Free Alternate (TI-LFA) Fast Reroute",
                RFC 9860, DOI 10.17487/RFC9860, October 2025,
                <https://www.rfc-editor.org/info/rfc9860>.

     [RFC7715]  Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and
                Q. Zhao, "Multipoint LDP (mLDP) Node Protection",
                RFC 7715, DOI 10.17487/RFC7715, January 2016,
                <https://www.rfc-editor.org/info/rfc7715>.

     [I-D.ietf-pim-sr-p2mp-policy]
                Parekh, R., Voyer, D., Filsfils, C., Bidgoli, H., and Z.
                J. Zhang, "Segment Routing Point-to-Multipoint Policy",
                Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
                policy-22, 4 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
                p2mp-policy-22>.

     [I-D.zzhang-bier-optimized-use-in-aidc]
                Zhang, Z. J., Xu, X., Zhang, Z., Tantsura, J., and A.
                Mahale, "Optimized Use of BIER in AIML Data Centers", Work
                in Progress, Internet-Draft, draft-zzhang-bier-optimized-
                use-in-aidc-00, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-zzhang-bier-
                optimized-use-in-aidc-00>.

     [I-D.zhang-rtgwg-llmmoe-multicast]
                Zhang, Z., Duan, W., and X. Xu, "Multicast usage in LLM
                MoE", Work in Progress, Internet-Draft, draft-zhang-rtgwg-
                llmmoe-multicast-01, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-zhang-rtgwg-
                llmmoe-multicast-01>.

     [I-D.liu-multicast-for-computing-storage]
                Liu, Y. and X. Geng, "Multicast for Computing and
                Storage", Work in Progress, Internet-Draft, draft-liu-
                multicast-for-computing-storage-00, 10 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-liu-
                multicast-for-computing-storage-00>.

     [I-D.cheng-rtgwg-ai-network-reliability-problem]
                Cheng, W., Lin, C., wangwenxuan, and B. Xu, "Reliability
                in AI Networks Gap Analysis, Problem Statement, and
                Requirements", Work in Progress, Internet-Draft, draft-
                cheng-rtgwg-ai-network-reliability-problem-03, 6 June
                2025, <https://datatracker.ietf.org/doc/html/draft-cheng-
                rtgwg-ai-network-reliability-problem-03>.



  Zhang & Cheng           Expires 3 September 2026               [Page 10]


  Internet-Draft              Abbreviated Title                 March 2026


  Authors' Addresses

     Junye Zhang
     China Mobile
     China
     Email: zhangjunye@chinamobile.com


     Weiqiang Cheng
     China Mobile
     China
     Email: chengweiqiang@chinamobile.com







































  Zhang & Cheng           Expires 3 September 2026               [Page 11]


name: draft-hu-neotec-usecases-notc
rev: 00
title: Use cases in network operations in telco cloud
time: 2026-01-07T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-07T07:50:36Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.805969+00:00
source: ietf
source_id: 146833
source_url: https://datatracker.ietf.org/doc/draft-hu-neotec-usecases-notc/
doc_status: active
abstract:
  This document presents two network operations in telco cloud
     orchestration use case for AI-based video recognition in smart city
     management and dynamic high-bandwidth transport.  Key innovations
     include dynamic resource scheduling across heterogeneous computing
     (GPU/NPU) and network domains, centralized training with distributed
     inference, and low-latency data transmission compliant with data
     sovereignty requirements.  Additionally, the use case demonstrates
     elastic bandwidth provisioning and failover mechanisms to ensure
     reliability.  The framework highlights the need for standardized
     interfaces between cloud and network controllers to optimize
     performance, resource utilization, and QoS in telecom cloud
     environments.

full_text:
  NeoTec                                                  Jiayuan. Hu, Ed.
  Internet-Draft                                             F. Zhang, Ed.
  Intended status: Informational                               Y. Zhu, Ed.
  Expires: 7 January 2026                                           C. Xie
                                                             China Telecom
                                                               6 July 2025


               Use cases in network operations in telco cloud
                      draft-hu-neotec-usecases-notc-00

  Abstract

     This document presents two network operations in telco cloud
     orchestration use case for AI-based video recognition in smart city
     management and dynamic high-bandwidth transport.  Key innovations
     include dynamic resource scheduling across heterogeneous computing
     (GPU/NPU) and network domains, centralized training with distributed
     inference, and low-latency data transmission compliant with data
     sovereignty requirements.  Additionally, the use case demonstrates
     elastic bandwidth provisioning and failover mechanisms to ensure
     reliability.  The framework highlights the need for standardized
     interfaces between cloud and network controllers to optimize
     performance, resource utilization, and QoS in telecom cloud
     environments.

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

  Copyright Notice

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




  Hu, et al.               Expires 7 January 2026                 [Page 1]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Example 1: AI-based Video Recognition for City
             Management  . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.  Example 2: dynamic high-bandwidth transport . . . . . . .   6
     5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     This document presents two network operations in telco cloud
     scheduling use case including AI-based video recognition in smart
     city management and dynamic high-bandwidth transport.  The AI-based
     video use case addresses critical urban governance challenges
     including illegal street vending, unauthorized parking, garbage
     disposal, and waste classification through intelligent video
     analysis.

     dynamic high-bandwidth transport is an innovative network solution to
     address the challenges of large-scale, cross-regional data migration
     for high-performance computing (HPC), AI training, scientific
     research, and enterprise applications.  It provides on-demand,
     elastic, and secure high-bandwidth connectivity tailored for
     temporary or periodic bulk data transfers, significantly reducing
     costs and improving efficiency compared to traditional methods like
     physical hard disk shipping or fixed-bandwidth dedicated lines.  It
     enables instant setup and teardown of connections, allowing users to
     request bandwidth (1G-100G) only when needed (e.g., for scheduled



  Hu, et al.               Expires 7 January 2026                 [Page 2]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     nighttime transfers).  Supports multi-dimensional billing (bandwidth,
     duration, distance, traffic volume, or usage frequency).  Moreover,
     dynamic high-bandwidth transport can dynamically adjust bandwidth
     (e.g., from 30M to 10G in seconds) to match data transfer demands and
     implements network slicing (FlexE/IPv6+), SRv6 tunneling, and
     encryption to ensure data isolation and integrity.

     One of the example of dynamic high-bandwidth transport is LHAASO
     cosmic ray observatory, it transfers 11PB data from Sichuan to
     Beijing for processing per year.  Reduced a 1.6TB transfer over 2,000
     km to 40 minutes (vs. days via hard disks).  In AI/ML training area,
     dynamic high-bandwidth transport supports large-scale dataset
     migration to GPU clusters for distributed training.  Moreover, PB-
     scale video rendering can be uploaded to cloud-based post-production
     studios in hours (e.g., 2TB/day via 10Gbps) in media production
     scenario.

  2.  Conventions Used in This Document

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

  2.2.  Abbreviations

     LHAASO: Large High Altitude Air Shower Observatory

     UCMP: Unequal-Cost Multi-Path routing

  3.  Problem Statement

     Telecom Clouds integrate compute, storage, and networking resources
     to deliver low-latency, high-bandwidth services such as 5G, AI/ML
     workloads, and real-time media processing.  Unlike public clouds that
     depend on third-party networks, Telecom Clouds are operated under a
     single administrative domain, enabling tight coupling between cloud
     infrastructure and network operations.  However, existing network
     management systems lack real-time visibility into dynamic cloud
     resource states, resulting in suboptimal performance, inefficient
     resource utilization, and SLA violations.  Key challenges include:







  Hu, et al.               Expires 7 January 2026                 [Page 3]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     1.  Network controllers remain unaware of cloud-side scaling events
     (e.g., VM/container orchestration, GPU resource allocation),
     preventing dynamic adjustments to load balancing, UCMP routing, or
     QoS policies.

     2.  While cloud platforms (e.g., AWS CloudWatch, Azure Monitor)
     expose resource metrics, no standardized APIs or data models exist
     for network controllers to ingest and act on this telemetry in real
     time.

     3.  AI/ML pipelines, 5G network slicing, and inter-cloud traffic
     exhibit highly variable patterns.  Without real-time coordination
     between cloud resource availability and network state, traffic
     engineering becomes reactive, leading to congestion, unbalanced
     resource usage, and degraded QoE.

     4. standardized interface for informing routing decisions like UCMP
     weight adjustments, flow steering, or bandwidth
     allocation.[draft-li-unco-framework]

     5.  Traditional network orchestrators often pre-allocate resources
     statically or based on historical models, but modern applications
     demand rapid provisioning and adjustment of both compute and network
     resources.  Real-Time and dynamic resource scheduling ability is
     needed.[draft-li-unco-framework]

     To solving the problem is critical to achieving true cloud-network
     convergence, where dynamic cloud workloads and network resources are
     orchestrated as a unified system.

  4.  Use Cases

  4.1.  Example 1: AI-based Video Recognition for City Management

     This use cases leverages cloud-network-computing integration to
     enable intelligent urban governance through real-time video
     analytics.  Key Applications include

     1.  Illegal Street Vending Detection: Identifies static objects
     (e.g., tables, chairs) left in restricted zones for prolonged
     periods, indicating unauthorized vending activities.

     2.  Unauthorized Parking Monitoring: Detects vehicles parked in no-
     parking areas by analyzing predefined zones in video feeds.

     3.  Litter and Waste Management: Flags scattered waste (bottles,
     paper, bags) on streets and overflowing/uncovered trash bins.




  Hu, et al.               Expires 7 January 2026                 [Page 4]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     4.  Public Space Compliance: Monitors violations like disorderly
     wiring and shopfront obstructions.

     For the cameras used in urban management, the main network structure
     is shown in the following figure:

                                +---------------------+
                                |     Street Cameras  |
                                +---------------------+
                                    /             \
                                   /               \
                   (Cellular Access)           (WiFi Access)
                                 /                 \
                           +--------+         +-------------+
                           |  eNB   |         |  WiFi AP   |
                           +--------+         +-------------+
                                 |                   |
                                 |                   |
                   +----------------------+    +----------------------+
                   |        UPF           |    |    Access PE Router  |
                   +----------------------+    +----------------------+
                           |                             |
                           |                             |
                           |                             |
                          +-------------------------------+
                          |        Provider Transport     |
                          |            Network (TE)       |
                          +-------------------------------+
                                         |
                                         |
                                         v
                           +---------------------------+
                           |  Edge PE Router (per site)|
                           +---------------------------+
                                         |
                                         |
                                         v
                               +--------------------+
                               |  Edge Cloud Gateway|
                               |  + AI Model Module |
                               +--------------------+

         Figure 1: The framework of AI-based video recognition for city
                                   management

     In the cloud-network convergence architecture, AI cameras transmit
     data via cellular networks (e.g., through eNBs/gNBs and User Plane
     Functions (UPFs)) or WiFi Access Points.For cellular access, data is



  Hu, et al.               Expires 7 January 2026                 [Page 5]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     forwarded via GTP-U tunnels from eNBs to UPFs, which are often co-
     located with Edge Cloud sites.  Data traverses the provider's
     transport network between the access point (PE router) and the Edge
     Cloud PE router.  The Edge PE router connects to the Edge Cloud
     Gateway or compute node hosting the AI workload (e.g., real-time
     inference modules).  A Cloud Manager evaluates end-to-end paths
     (bandwidth, latency, topology) between cameras and Edge Cloud sites
     to select optimal deployment locations for AI models.Network
     controllers dynamically adjust UCMP (Unequal Cost Multipath) load-
     balancing algorithms to meet performance constraints (e.g., XX Gbps
     bandwidth, YY ms delay) for inter-site data exchange.
     [draft-dunbar-neotec-ac-te-applicability]

     This architecture ensures low-latency, high-throughput data
     transmission for real-time AI processing while enabling dynamic
     resource allocation based on network-aware metrics.  The solution
     leverages edge computing infrastructure to deploy AI inference models
     closer to data sources, enabling real-time processing of high-
     resolution video streams with millisecond-level response times.  Key
     technical components include:

     1.Centralized training at the group data center with distributed edge
     inference

     2.Dynamic resource orchestration across heterogeneous computing
     facilities (GPU/NPU-enabled edge nodes)

     3.Cloud-aware network optimization ensuring low-latency data
     transmission

     4.Data sovereignty compliance through localized processing

  4.2.  Example 2: dynamic high-bandwidth transport

     The dynamic high-bandwidth transport is an innovative network
     solution designed to address the challenges of large-scale, high-
     efficiency data migration for scenarios such as scientific computing,
     AI training, and cross-regional data transfers.  Typical Use Cases
     like East-to-West Data Storage: Low-cost cold/backup data transfers
     to western data centers.  Scientific Computing: Supports projects
     like the LHAASO cosmic ray observatory (11PB/year data) with high-
     speed links to supercomputing centers.  AI/Media Production:
     Accelerates raw footage (e.g., 2TB/day) or AI model training data
     transfers.

     The network architecture of thedynamic high-bandwidth transport line
     service comprises three layers: the service enabling layer, the
     service core layer, and the business carrying layer.  It can provide



  Hu, et al.               Expires 7 January 2026                 [Page 6]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     services for various data transmission businesses such as gene
     sequencing, scientific computing, cloud-to-cloud storage, film and
     television production, artificial intelligence, and more.  The
     service enabling layer, through user-oriented unified APIs, SDKs, or
     service platforms, invokes network capabilities and allocates network
     resources on demand based on the business requirements transmitted by
     various applications, generating a combination of network
     capabilities and business capabilities.  The service provides users
     with network capabilities such as elastic bandwidth, security
     isolation, flexible networking, deterministic resource assurance, and
     flexible billing based on usage, according to the business requests
     transmitted by the service enabling layer.  The business carrying
     layer, as the physical carrier providing data transportation, builds
     on-demand, deterministic, secure, and reliable network channels
     between communicating parties, including network functional entities
     such as access terminals, super business gateways, and routers.  The
     specific network architecture is shown in Figure 2.


































  Hu, et al.               Expires 7 January 2026                 [Page 7]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


                              +---------------------+
                              |     Applications    |
                              +---------------------+
                                        ^
                                        |
                           API/service-oriented interfaces
                                        |
                                        v
                  +--------------------------------------------+
                  |  service enabling layer                    |
                  |   +---------------------+   +----------+   |
                  |   | resources on demand |   | security |   |
                  |   +---------------------+   +----------+   |
                  +--------------------------------------------+
                                        ^
                                        |
           combination of network capabilities and business capabilities
                                        |
                                        v
                  +--------------------------------------------+
                  |  service core layer                       |
                  | +-------------------+ +-----------------+  |
                  | | elastic bandwidth | |flexible billing |  |
                  | +-------------------+ +-----------------+  |
                  | +----------------------------------+       |
                  | | deterministic resource assurance |       |
                  | +----------------------------------+       |
                  +--------------------------------------------+
                         |                             ^
                         |                             |
                 control signal        business information collection
                         |                             |
                         v                             |
            +--------------------------------------------------------+
            |  business carrying layer                               |
            |  +---------------------+ +---------------------------+ |
            |  | data transportation | | reliable network channels | |
            |  +---------------------+ +---------------------------+ |
            |  +-------------------------+                           |
            |  | super business gateways |                           |
            |  +-------------------------+                           |
            +--------------------------------------------------------+

          Figure 2: The framework of dynamic high-bandwidth transport







  Hu, et al.               Expires 7 January 2026                 [Page 8]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     Overall, dynamic high-bandwidth transport can significantly reducing
     costs and improving efficiency compared to traditional methods like
     physical hard disk shipping or fixed-bandwidth dedicated lines.
     Here's an overview of its key aspects:

     1.  Task-Based On-Demand Service: Supports instant setup and teardown
     of connections (1G-100G bandwidth) for temporary or scheduled data
     transfers (e.g., nighttime off-peak usage).

     2.  Elastic Bandwidth: Allows dynamic adjustment of bandwidth (e.g.,
     from 100M to 10G) to meet burst demands while maintaining cost
     efficiency.

     3.High-Bandwidth and Low-Latency: Optimizes protocols (e.g., TCP/
     UDP), leverages wide-area RDMA for lossless transmission, and uses
     load balancing (e.g., SRv6 UCMP) to maximize throughput.

     4.  Security and Reliability: Ensures end-to-end isolation via FlexE
     slicing and VPNs, with built-in encryption (IPSec) and route
     authentication (RPKI).

     5.  Cross-Domain Coordination: Enables multi-domain/operator
     collaboration through centralized or distributed control planes for
     seamless resource scheduling.

  5.  Requirements

     To enable seamless cloud-network integration across edge, core, and
     transport environments, cloud-network integration framework
     establishes a set of functional requirements that drive its
     architecture and interface design.  These requirements prioritize:

     1.  To achieve dynamic resource scheduling, the system MUST support
     real-time elastic scaling of computing resources (e.g., GPU
     containers) and network bandwidth based on AI workload fluctuations.

     2.  Upon detecting GPU node failures or BGP route oscillations, the
     system SHOULD automatically migrate services to back up nodes and
     activate OTN protection rings within 60 seconds.

     These requirements emphasize responsiveness, reliability, and
     compatibility in multi-domain environments ensures cloud-native
     applications (e.g., AI/ML, XR) achieve deterministic performance
     while maintaining operational efficiency in cloud-network fused
     environments.






  Hu, et al.               Expires 7 January 2026                 [Page 9]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


  6.  IANA Considerations

     TBC

  7.  Security Considerations

     TBC

  8.  References

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

     [draft-li-unco-framework]
                "Unified Network and Cloud Orchestration Framework".

     [draft-dunbar-neotec-ac-te-applicability]
                "Applying Attachmet Circuit and Traffic Engineering YANG
                Data Model to Edge AI Use Case".

  Contributors

     Thanks to all of the contributors.

  Authors' Addresses

     Jiayuan Hu (editor)
     China Telecom
     109, West Zhongshan Road, Tianhe District
     Guangzhou
     Guangdong, 510000
     China
     Email: hujy5@chinatelecom.cn










  Hu, et al.               Expires 7 January 2026                [Page 10]


  Internet-Draft      draft-hu-neotec-usecases-notc-00           July 2025


     Fan Zhang (editor)
     China Telecom
     109, West Zhongshan Road, Tianhe District
     Guangzhou
     Guangdong, 510000
     China
     Email: zhangf52@chinatelecom.cn


     Yongqing Zhu (editor)
     China Telecom
     109, West Zhongshan Road, Tianhe District
     Guangzhou
     Guangdong, 510000
     China
     Email: zhuyq8@chinatelecom.cn


     Chongfeng Xie
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     102209
     China
     Email: xiechf@chinatelecom.cn


























  Hu, et al.               Expires 7 January 2026                [Page 11]


name: draft-williams-netmod-lm-hierarchy-topology
rev: 02
title: Hierarchical Topology for Language Model Coordination
time: 2026-02-11T21:29:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-15T21:29:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.816070+00:00
source: ietf
source_id: 146935
source_url: https://datatracker.ietf.org/doc/draft-williams-netmod-lm-hierarchy-topology/
doc_status: active
abstract:
  This document defines a YANG data model and reference architecture
     for a hierarchical topology of language models (LMs), where tiny,
     small, and large LMs cooperate to perform distributed inference,
     summarization, and decision-making.  The model supports secure
     inter-node messaging, request escalation, token-based authorization,
     and decentralized validation using pluggable trust models.  This
     architecture is designed for deployments where computational
     capabilities vary across nodes, such as edge-to-cloud environments
     or multi-tier AI systems.  The goal is to provide a standards-based
     mechanism for orchestrating scalable, secure LM interactions across
     heterogeneous systems.

full_text:
  Network Working Group                                        K. Williams
  Internet-Draft                                    Independent Researcher
  Intended status: Standards Track                        11 February 2026
  Expires: 11 August 2026


             Hierarchical Topology for Language Model Coordination
                draft-williams-netmod-lm-hierarchy-topology-02

  Abstract

     This document defines a YANG data model and reference architecture
     for a hierarchical topology of language models (LMs), where tiny,
     small, and large LMs cooperate to perform distributed inference,
     summarization, and decision-making.  The model supports secure
     inter-node messaging, request escalation, token-based authorization,
     and decentralized validation using pluggable trust models.  This
     architecture is designed for deployments where computational
     capabilities vary across nodes, such as edge-to-cloud environments
     or multi-tier AI systems.  The goal is to provide a standards-based
     mechanism for orchestrating scalable, secure LM interactions across
     heterogeneous systems.

  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), its areas, and its working groups.  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/.

  The list of current Internet-Drafts can be accessed at
  https://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  https://www.ietf.org/shadow.html

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

  Copyright Notice

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

     This document is subject to BCP 78 and the  Trust's Legal
     Provisions Relating to  Documents
     (https://trustee..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


  Williams                Expires 11 August 2026                 [Page 1]

  Internet-Draft         LM Hierarchy YANG Model              February 2026


     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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Model Overview  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Use Case Flow . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Data Model Summary and Usage  . . . . . . . . . . . . . . . .  10
     6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  11
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     Appendix A.  YANG Module  . . . . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     Recent advancements in machine learning have enabled powerful
     language models (LMs) to perform complex inference, summarization,
     and contextual reasoning.  However, most production deployments
     assume centralized access to a single large LM, which is unsuitable
     for many constrained or distributed environments.

     This document proposes a hierarchical model for distributed language
     model (LM) deployments.  In this architecture, lightweight "tiny"
     LMs operate on constrained devices or at the edge, mid-tier "small"
     LMs act as aggregators or context enhancers, and a central "large"
     LM provides global reasoning and escalation handling.

     Communication between nodes is structured using a YANG data model
     that supports:

     *  Node roles and LM types

     *  Secure, token-based authorization

     *  Inter-node RPCs for inference, escalation, and validation

     *  Notifications for heartbeat and liveliness reporting

     This topology enables a more scalable, privacy-preserving, and
     resilient LM deployment strategy by allowing computation and trust
     decisions to occur closer to data sources.  It also provides a
     foundation for future interoperability between language model
     runtimes and network control systems.


  Williams                Expires 11 August 2026                 [Page 2]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


     The model is inspired by hierarchical network topologies such as
     those defined in [RFC8345] and extends similar principles to LM-
     based processing pipelines.

  2.  Terminology

     This document uses the following terminology:

     Tiny LM:  A lightweight, constrained language model running on edge
        devices, microcontrollers, or embedded environments.  Capable of
        basic classification, keyword spotting, or template-based NLP
        tasks.

     Small LM:  A mid-tier model with enhanced summarization or contextual
        capabilities.  Often deployed in local gateways, routers, or fog
        compute nodes.  Serves as an aggregator and intermediary between
        Tiny and Large LMs.

     Large LM:  A centralized, full-scale language model capable of
        complex inference, reasoning, multi-hop retrieval, and escalation
        handling.  Typically deployed in cloud environments or
        centralized data centers.

     Escalation:  The process by which a lower-tier LM defers processing
        to a higher-tier LM when its local capabilities are insufficient.

     Auth Token:  A signed token (e.g., JWT or CWT) used to authenticate
        and authorize requests between nodes.  Contains claims such as
        `iss`, `sub`, `scope`, `iat`, and optionally a `nonce`.

     Validate-Token:  A YANG-defined `action` that allows a node to
        verify the authenticity and authorization scope of a token
        received from a peer.

     Pluggable Token Validation:  A YANG `feature` that indicates support
        for extensible trust mechanisms (e.g., JWT verification, CBOR/
        COSE decoding, external introspection endpoints).

     Heartbeat:  A periodic `notification` sent by a Tiny LM to indicate
        liveness and continued operation.

     Hierarchy Topology:  A tree-like structure in which Tiny LMs connect
        to Small LMs, and Small LMs connect to a Large LM, forming a
        vertical path for data and escalation flow.







  Williams                Expires 11 August 2026                 [Page 3]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


  3.  Model Overview

     The data model defined in this document represents a multi-tier
     topology of language model (LM) nodes, organized hierarchically into
     three layers: Tiny, Small, and Large.  Each node type serves a
     specific role in the processing pipeline and communicates using a
     set of well-defined YANG-based interfaces.

     The core components of the model include:

     *  A topology container that describes nodes and their relationships

     *  RPCs for handling inference requests (`lm-request`) and escalation
        (`model-escalation`)

     *  An `action` for validating authentication tokens (`validate-
        token`)

     *  A `notification` stream for liveness and heartbeat (`lm-
        heartbeat`)

     *  Features such as `pluggable-token-validation` to support
        extensible security implementations

     Tiny LMs typically initiate requests but may escalate to a Small LM
     if the request exceeds local capacity.  Small LMs may respond
     directly, or further escalate to a Large LM.  All communication is
     authenticated using signed tokens, and authorization is enforced
     based on node roles, token scopes, and topology position.

     The model is inspired by the YANG network topology architecture
     defined in [RFC8345], but adapted to reflect the unique needs of
     language model interaction across a distributed system.  It is
     designed to support:

     *  Flexible security policy enforcement

     *  Modular trust and validation strategies

     *  Constrained environments with limited resources

     *  Scalable coordination of inference and summarization workloads

  4.  Use Case Flow

     This section illustrates key operational behaviors of a hierarchical
     language model (LM) system using the data model defined in this
     document.  Three common interaction patterns are described:
     inference escalation, heartbeat reporting, and summary aggregation.


  Williams                Expires 11 August 2026                 [Page 4]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


  4.1.  Inference Request Escalation: Tiny LM > Small LM > Large LM

     Actors:

     *  tiny-lm-089: A constrained edge LM deployed in a local sensor

     *  small-lm-042: An intermediate aggregator LM with limited inference
        ability

     *  large-lm-001: A central high-capacity LM responsible for complex
        reasoning

     Scenario:

     A user inputs a query via a constrained device running tiny-lm-089.
     The device is unable to resolve the meaning of the input and
     escalates the request through its hierarchy.

     Step-by-Step Flow:

     1.  Tiny LM Initiates Request

         Calls lm-request RPC to small-lm-042

         Includes: auth-token, source-node, request-type, payload

     2.  Small LM Attempts to Resolve

         Verifies auth-token via validate-token

         If unable to respond, it prepares an escalation

     3.  Small LM Escalates to Large LM

         Calls model-escalation RPC to large-lm-001

         Includes original-payload, reason, and its own auth-token

     4.  Large LM Responds

         Performs inference and returns enriched result

     5.  Small LM Relays Result

         Responds to the original lm-request

     6.  Tiny LM Displays Output

         Presents the result to the user


  Williams                Expires 11 August 2026                 [Page 5]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


     Security:

     *  Token validation at each hop

     *  Token scopes enforced (e.g., only small LMs can escalate)

  4.2.  Heartbeat Broadcast: Tiny LM > Topology

     Actors:

     *  tiny-lm-089: An edge device LM

     *  small-lm-042: Its supervising node

     Scenario:

     To maintain system health, each tiny LM emits a periodic heartbeat
     signal to its parent.

     Step-by-Step Flow:

     1.  Tiny LM Sends Heartbeat

         Emits lm-heartbeat notification with timestamp and status

     2.  Small LM Receives Notification

         Subscribed to lm-heartbeat stream

         Updates health status table or triggers alert on timeout

     Security:

     Not signed by default, but implementations MAY correlate with recent
     authenticated activity

  4.3.  Summary Aggregation: Small LM > Large LM

     Actors:

     *  tiny-lm-089, tiny-lm-090, tiny-lm-091: Sensor LMs

     *  small-lm-042: Aggregator

     *  large-lm-001: Reasoning LM

     Scenario:

     Multiple tiny LMs submit observations.  The small LM combines and
     escalates them.


  Williams                Expires 11 August 2026                 [Page 6]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


     Step-by-Step Flow:

     1.  Tiny LMs Submit Observations

         Each sends lm-request to small-lm-042 with its own auth-token

     2.  Small LM Aggregates Input

         Locally summarizes data from tiny LMs

     3.  Optional Escalation

         Sends model-escalation RPC to large-lm-001 with the summary

     4.  Large LM Enhances Result

         Returns executive-level context or response

     5.  Small LM Caches + Responds

         Updates cache and optionally forwards summary or alert

     Security:

     *  All requests must carry valid, scoped auth-tokens

     *  Escalation privileges restricted to authorized node types

  5.  Data Model Summary and Usage

     The data model defined by this document describes a hierarchical
     topology of language model (LM) nodes and the interfaces through
     which they communicate, authorize, and escalate inference
     operations.  It is expressed using the YANG 1.1 data modeling
     language [RFC7950].

     The model includes the following key elements:

     *  A `lm-node` container with identity-based classification (`tiny`,
        `small`, `large`)

     *  RPCs:

        -  `lm-request`: Initiates an inference or summarization task

        -  `model-escalation`: Forwards requests upward in the LM
           hierarchy

     *  Actions:


  Williams                Expires 11 August 2026                 [Page 7]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


        -  `validate-token`: Verifies token authenticity and scope

     *  Notifications:

        -  `lm-heartbeat`: Indicates node liveness and status

     *  Groupings for `auth-token`, trust metadata, and request payloads

     *  A `feature` flag (`pluggable-token-validation`) to support
        modular trust infrastructure

     All inter-node requests include a signed `auth-token`, which may be
     validated locally via `validate-token` or externally if the feature
     is supported.

     The full YANG module is provided in Appendix A.

  6.  Implementation Status

     NOTE TO RFC EDITOR: This section is to be removed before
     publication.

     This section documents the current implementation efforts related to
     the YANG model and architecture described in this draft.  It is
     included to inform reviewers and working group participants of the
     maturity and deployment experience of this specification.

     Title: UniLoRa Mesh LM Hierarchy Prototype
     Authors: Keenan Williams
     Maturity Level: Early Prototype
     Development Status: Active

     Description:

     A functional prototype of the hierarchical LM topology described in
     this document has been implemented as part of the UniLoRa Mesh
     project.  The prototype demonstrates communication between Tiny,
     Small, and Large LM nodes using the defined YANG data model over a
     LoRa-based mesh transport layer.

     Key features supported:

     *  `lm-request`: Implemented on Tiny and Small LMs to initiate and
        forward inference requests

     *  `model-escalation`: Fully implemented for upward delegation to a
        central reasoning engine




  Williams                Expires 11 August 2026                 [Page 8]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


     *  `validate-token`: Implemented on Small and Large LMs using JWT-
        based verification with public key validation

     *  `lm-heartbeat`: Actively used to track the liveliness of edge
        nodes

     *  `pluggable-token-validation`: Enabled; token verification can be
        swapped between local crypto module or cloud introspection
        service

     *  YANG model validated with `pyang` and integrated with a prototype
        RESTCONF endpoint

     Deployment:

     *  Tiny LM: ESP32-based TTGO T-Beam devices running lightweight
        keyword spotting and rule-based summarization

     *  Small LM: Raspberry Pi 5 devices running a lightweight Python LM
        with summarization and caching logic

     *  Large LM: Central node hosted on a cloud container, running GPT-
        style inference with trust policy enforcement

     The system supports real-time inference routing from edge to core,
     token-authenticated message passing, and topology-driven trust
     enforcement as defined in this draft.  The goal is to refine this
     prototype into a reference implementation that can be used for
     interoperability testing and NETCONF/RESTCONF YANG validation
     tooling.

     Source Code Repository: [to be published]
     License: Apache 2.0

     Feedback and collaboration are welcomed to further validate this
     model across constrained and distributed environments.

  7.  IANA Considerations

     This document registers one URI in the " XML Registry" [RFC3688]
     and one YANG module name in the "YANG Module Names" registry
     [RFC6020].

  7.1.  XML Namespace Registration

     URI: urn:ietf:params:xml:ns:yang:ietf-lm-hierarchy
     Registrant Contact:  NETMOD Working Group
     XML:

     <namespace>

       urn:ietf:params:xml:ns:yang:ietf-lm-hierarchy
     </namespace>

  7.2.  YANG Module Name Registration

     Name: ietf-lm-hierarchy
     Namespace: urn:ietf:params:xml:ns:yang:ietf-lm-hierarchy
     Prefix: lm
     Reference: This document (draft-williams-netmod-lm-hierarchy-
     topology)

  8.  Security Considerations

     This document defines a hierarchical topology model for distributed
     language models (LMs), where communication occurs between nodes of
     differing capabilities and privileges (Tiny LMs, Small LMs, and a
     central Large LM).  To maintain the integrity, trustworthiness, and
     isolation of operations within such a topology, security is
     critical.

  8.1.  Authentication and Authorization

     All inter-node communication is required to include an `auth-token`,
     as defined in the data model.  These tokens may be bearer tokens,
     CBOR Web Tokens (CWTs), or JWTs signed by trusted issuers (e.g.,
     Large LMs or centralized authorities).  The model assumes a shared
     trust infrastructure wherein Large LMs issue or delegate trust
     tokens to downstream nodes.

     To support flexible, decentralized validation, this YANG module
     defines a node-level `validate-token` action.  This action enables
     nodes to verify the authenticity and scope of received tokens at
     runtime.  While token fields alone do not enforce authorization,
     this action provides a behavioral interface for systems to verify
     and act on trust decisions.

     This approach avoids reliance on centralized introspection services,
     which may not be suitable for bandwidth-constrained or delay-
     sensitive environments (e.g., when Tiny LMs operate at the edge).

  8.2.  Pluggable Trust Model

     A YANG `feature`, `pluggable-token-validation`, is defined to
     indicate support for extensible validation backends (e.g.,
     certificate chains, OAuth2 introspection endpoints, COSE/CBOR
     decoders, etc.).  This allows implementations to declare advanced
     trust handling capabilities without forcing them into minimal
     deployments.


  Williams                Expires 11 August 2026                [Page 10]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


  8.3.  Replay and Scope Protection

     Tokens should include `exp` (expiration) and `iat` (issued at)
     claims to protect against replay.  Where possible, `nonce` or one-
     time identifiers should be used to detect message duplication.
     Token `scope` claims (e.g., `inference`, `summarization`) should be
     enforced by recipient nodes to prevent privilege escalation across
     the hierarchy.

  8.4.  Topological Access Controls

     Nodes should reject incoming requests from unauthorized peers based
     on:

     *  Node type (e.g., a Tiny LM may not issue requests to another Tiny
        LM),

     *  Issuer identity,

     *  Token scope.

     Large LMs SHOULD enforce policies on which nodes may act as
     intermediaries (e.g., only trusted Small LMs may escalate).

     This layered security model ensures each node in the hierarchy
     enforces local trust decisions, minimizing blast radius in the event
     of compromise and allowing granular control over inter-node
     permissions.

  8.5.  Token Format (Informative)

     This document assumes the use of signed tokens to authorize inter-
     node communication.  While the token format is implementation-
     specific, systems are RECOMMENDED to use existing standards such as:

     *  JSON Web Tokens (JWT) [RFC7519]

     *  CBOR Web Tokens (CWT) [RFC8392]

     Example minimal JWT claims:

     {
       "iss": "large-lm-001",
       "sub": "tiny-lm-089",
       "scope": ["inference", "summarization"],
       "exp": "2026-02-11T16:00:00Z",
       "iat": "2026-02-11T15:00:00Z",
       "nonce": "3e8f5b5b-c21e-47a0-92a2-1f6ad919ef55"
     }


  Williams                Expires 11 August 2026                [Page 11]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


     Tokens MAY be passed in cleartext (if signed) or encrypted (if
     confidentiality is required).  Nonce tracking, token expiration, and
     scope enforcement SHOULD be implemented at all receiving nodes.

  9.  References

  9.1.  Normative References

     [RFC3688]  Mealling, M., "The  XML Registry", BCP 81, RFC 3688,
                DOI 10.17487/RFC3688, January 2004,
                <https://www.rfc-editor.org/info/rfc3688>.

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/info/rfc6020>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling
                Language", RFC 7950, DOI 10.17487/RFC7950, August 2016,
                <https://www.rfc-editor.org/info/rfc7950>.

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

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/info/rfc8392>.

  9.2.  Informative References

     This document has no informative references.






  Williams                Expires 11 August 2026                [Page 12]

  Internet-Draft         LM Hierarchy YANG Model                February 2026


  Appendix A.  YANG Module

     <CODE BEGINS> file "ietf-lm-hierarchy@2026-02-11.yang"

     module ietf-lm-hierarchy {
       yang-version 1.1;
       namespace "urn:ietf:params:xml:ns:yang:ietf-lm-hierarchy";
       prefix lm;

       import ietf-yang-types { prefix yang; }
       // NOTE: Removed unused import of ietf-inet-types

       organization
         "IETF NETMOD (Network Modeling) Working Group";

       contact
         "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
          WG List:  <mailto:netmod@ietf.org>

          Author: Kevin Williams
                  <mailto:telesis001@icloud.com>";

       description
         "This module defines a YANG data model for hierarchical Language
  Model (LM) nodes that coordinate inference, summarization and
  escalation across tiny/small/large LM tiers.

  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.

  This version of this YANG module is part of draft-williams-netmod-lm-hierarchy-topology-02;
  see the Internet-Draft itself for full legal notices.";
       reference
         "RFC 7950: The YANG 1.1 Data Modeling Language
          RFC 8407: Guidelines for Authors and Reviewers of YANG Data Model Documents";

       revision 2026-02-11 {
         description
           "Initial revision for I-D draft-williams-netmod-lm-hierarchy-topology-02.";
         reference
           "I-D: draft-williams-netmod-lm-hierarchy-topology-02";
       }

       feature pluggable-token-validation {
         description
           "Indicates support for a pluggable token validation mechanism for
            requests handled by LM nodes.";
       }

       identity lm-node-type {
         description "Base identity for LM node types.";
       }

       identity tiny-lm {
         base lm-node-type;
         description "A lightweight edge-deployed language model.";
       }

       identity small-lm {
         base lm-node-type;
         description "A mid-tier aggregator or summarizer.";
       }

       identity large-lm {
         base lm-node-type;
         description "A central reasoning or escalation endpoint.";
       }

       grouping auth-token-grouping {
         description "Reusable auth-token structure.";
         leaf auth-token {
           type string;
           description "A signed authentication/authorization token.";
         }
       }

       // Top-level configuration for LM hierarchy
       container lm {
         presence
           "Enable LM hierarchy configuration on this device.";
         description
           "Presence of this container enables configuration and state for
            the Language Model (LM) hierarchy on the device.";

         container node {
           description
             "Attributes describing this node within the LM hierarchy.";

           leaf node-id {
             type string;
             description
               "Implementation-specific identifier for this LM node.";
           }

           leaf node-type {
             type identityref { base lm-node-type; }
             description
               "Classification of this node (tiny, small, large).";
           }
         }

         container trust {
           if-feature pluggable-token-validation;
           description
             "Configuration for token validation used to authorize LM
              requests and actions.";

           leaf trust-anchor {
             type string;
             description "Root or public key used for token validation.";
           }

           leaf token-scope-enforced {
             type boolean;
             default true;
             description "Whether to enforce scope claims in tokens.";
           }

           action validate-token {
             description
               "Validate a presented token against the active trust policy.";
             input {
               leaf token {
                 type string;
                 description
                   "Opaque bearer or structured token presented by a caller.";
               }
             }
             output {
               leaf valid {
                 type boolean;
                 description
                   "True if the token is valid per current trust policy.";
               }
               leaf reason {
                 type string;
                 description
                   "Human-readable reason when validation fails, or an
                    implementation-specific note when it succeeds.";
               }
             }
           }
         }
       }

       rpc lm-request {
         description
           "Submit an LM request for processing within the hierarchy.";

         input {
           uses auth-token-grouping;
           leaf source-node {
             type string;
             description
               "Identifier of the node submitting the request.";
           }
           leaf target-node {
             type string;
             description
               "Desired target node identifier; implementations may ignore
                and route based on policy and availability.";
           }
           leaf request-type {
             type enumeration {
               enum inference {
                 description "Perform inference over provided payload.";
               }
               enum summarization {
                 description "Summarize the provided payload.";
               }
             }
             description
               "The kind of operation requested.";
           }
           leaf payload {
             type string;
             description
               "The operation payload. Encoding is implementation-specific
                (e.g., JSON).";
           }
         }
         output {
           leaf result {
             type string;
             description
               "The result produced by the LM operation (implementation-
                specific encoding, e.g., JSON).";
           }
           leaf status {
             type enumeration {
               enum ok {
                 description "The request completed successfully.";
               }
               enum error {
                 description "The request failed; see result for details.";
               }
             }
             description
               "Status of the processed request.";
           }
         }
       }

       rpc model-escalation {
         description
           "Request an escalation to a different LM tier (e.g., from tiny to
            small/large) with rationale.";

         input {
           uses auth-token-grouping;
           leaf original-payload {
             type string;
             description
               "Original payload requiring escalation.";
           }
           leaf reason {
             type string;
             description
               "Reason for escalation (e.g., insufficient context, model
                limitations, or policy).";
           }
         }
         output {
           leaf resolution {
             type string;
             description
               "Resolution or answer produced after escalation.";
           }
           leaf downstream-directive {
             type string;
             description
               "Optional directive for downstream workers/coordinators.";
           }
         }
       }

       notification lm-heartbeat {
         description
           "Periodic heartbeat emitted by LM nodes to advertise presence and
            health.";

         leaf sender-node {
           type string;
           description
             "Identifier of the node emitting the heartbeat.";
         }
         leaf status {
           type enumeration {
             enum alive {
               description "Node is reachable and operating nominally.";
             }
             enum degraded {
               description "Node is reachable but operating with reduced capacity.";
             }
             enum unreachable {
               description "Node is currently unreachable.";
             }
           }
           description
             "Operational status reported by the node.";
         }
         leaf timestamp {
           type yang:date-and-time;
           description
             "Timestamp for the emitted heartbeat.";
         }
       }
     }

     <CODE ENDS>
  Author's Address

     Keenan Williams
     Independent Researcher
     Email: telesis001@icloud.com


  Williams                Expires 11 August 2026                [Page 17]


name: draft-silver-aipref-vocab-substitutive
rev: 00
title: Vocabulary For Expressing AI Substitutive Usage
time: 2025-09-09T05:44:49Z
group_uri: /api/v1/group/group/2440/
expires: 2026-03-12T21:05:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.821338+00:00
source: ietf
source_id: 149492
source_url: https://datatracker.ietf.org/doc/draft-silver-aipref-vocab-substitutive/
doc_status: active
abstract:
  This Internet Draft proposes a category entitled "AI Substitutive
     Use" which would enable parties to express a preference regarding how
     digital assets are used by automated processing systems, with a focus
     on post-training (inference-time) uses that are likely to result in
     the creation of AI-generated outputs that substitute for the original
     asset.  The proposal is for this category to nest within the larger
     category of Automated Processing, currently envisaged in the working
     group draft [AIPREF-VOCAB] (21 July 2025).

full_text:
  AI Preferences                                                 B. Silver
  Internet-Draft                                                   Advance
  Intended status: Experimental                           8 September 2025
  Expires: 12 March 2026


              Vocabulary For Expressing AI Substitutive Usage
                 draft-silver-aipref-vocab-substitutive-00

  Abstract

     This Internet Draft proposes a category entitled "AI Substitutive
     Use" which would enable parties to express a preference regarding how
     digital assets are used by automated processing systems, with a focus
     on post-training (inference-time) uses that are likely to result in
     the creation of AI-generated outputs that substitute for the original
     asset.  The proposal is for this category to nest within the larger
     category of Automated Processing, currently envisaged in the working
     group draft [AIPREF-VOCAB] (21 July 2025).

  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://datatracker.ietf.org/doc/draft-silver-aipref-vocab-
     substitutive/.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-silver-aipref-vocab-
     substitutive/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

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







  Silver                    Expires 12 March 2026                 [Page 1]


  Internet-Draft               aipref-autoctl               September 2025


     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 12 March 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.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Vocabulary Definition . . . . . . . . . . . . . . . . . . . .   4
       3.1.  AI Substitutive Use Category (New)  . . . . . . . . . . .   4
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     5.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
     6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Rationale

     Existing mechanisms for expressing preferences, including those under
     consideration by the AI Preferences WG do not address concerns which
     have been strongly articulated about the practice of using digital
     assets as input to AI models to generate outputs which substitute for
     or undermine the value of the original assets.  This gap leaves a
     broad group of stakeholders (including creators, journalists and
     publishers) without a means to express a preference regarding a type
     of use which is already having a material adverse impact on their
     rights.  Developers and deployers of AI systems are also left without
     a clear, standardized preference signal regarding such uses, which
     results in "blunt" approaches to gathering such content - exposing
     them to legal risk.  This proposal intends to define a tailored
     preference category to address the specific need, improve visibility
     across the board and support continued broad access to information



  Silver                    Expires 12 March 2026                 [Page 2]


  Internet-Draft               aipref-autoctl               September 2025


     and content.

     The use of digital assets for inferencing "in real time" is
     widespread as a means of improving the accuracy and contextual
     relevance of outputs, such as through the use of techniques such as
     Retrieval-Augmented Generation (RAG) [RAG2020].  The flipside of that
     value is that such outputs are inclined to substitute for or dilute
     the value of the original asset, which decreases user engagement with
     the original asset.  This harms revenue opportunities and undermines
     the ability of the owner or distributor of the original asset to
     connect directly with their intended audience.  For example, the use
     of journalistic material to create AI-generated summaries which have
     resulted in the substantial reduction of internet traffic to online
     publications.  In the longer term, this jeopardises the
     sustainability of those enterprises and the underlying incentives to
     create and publish such material.  To mitigate this, some are moving
     content behind paywalls and deploying other means of limiting open
     access - diminishing access to information and content.

     Should incentives to create diminish, AI innovation will also suffer
     as a result of less quality content on which to build a distribution
     funnel.  This would also undermine the sustainability and
     verifiability of news and information services relied upon by the
     public and government institutions.  Where the AI model or platform
     takes on the role of information gatekeeper and shaper, connections
     between the public and original sources can be severed (or warped),
     which undermines the ability and willingness of internet users to
     ensure what they are reading, hearing or watching matches the
     original source(s), allowing factual misrepresentations to propagate
     and go unchecked.

     Creators have also justifiably expressed the need for a preference
     that addresses the use of their assets to create derivative works "in
     the style of" such original assets.  Creators are harmed by the
     unfettered use of their works as inputs to AI Models to create
     outputs which dilute the market for their works, adopting distinctive
     elements and styles established by the creators themselves - which
     also harms their moral rights and interests to protect the integrity
     of their works and ensure attribution.

  2.  Conventions and Definitions

     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.




  Silver                    Expires 12 March 2026                 [Page 3]


  Internet-Draft               aipref-autoctl               September 2025


     For the purposes of this document, the following terms are used:

     *  *Post-training (inference-time)*: Uses of an AI/ML model that
        occur after the model has been trained and frozen, typically when
        generating outputs in response to inputs at runtime.

     *  *Retrieval-Augmented Generation (RAG)*: A technique where external
        content is retrieved at query time and supplied to a model to
        condition the generated output.  This document references RAG as a
        common mechanism by which substitutive outputs may be produced
        [RAG2020].

  3.  Vocabulary Definition

  3.1.  AI Substitutive Use Category (New)

     The Act of using one or more assets as input to a trained AI/ML model
     (as opposed to the training of the model) which results in an output
     which incorporates, summarizes, aggregates or reproduces the assets,
     including stylistic elements thereof; provided, however that this
     category does not cover the use of a lawfully acquired digital asset
     where carried out directly by an end user (as opposed to a search
     application or bot) as input to a trained model to create a summary
     of such digital asset.

     The use of assets for AI Substitutive Use is a proper subset of
     Automated Processing usage [AIPREF-VOCAB].

     This category is distinct from AI Training or Generative AI Training,
     as it addresses uses that occur after a model has been trained,
     during inference.  It is also distinct from Search, which covers uses
     that direct users back to the original asset.  Substitutive Use, by
     contrast, describes outputs that replace, reduce the utility of, or
     make the source asset redundant to users by summarizing, reproducing,
     or restyling its contents.

     Consistent with that objective, this category would not apply where
     end users are summarising digital assets which they have already
     acquired, outside of the context of search or retrieving such assets
     from online locations in summarized form.

  4.  IANA Considerations

     This document has no IANA actions.

  5.  Normative References





  Silver                    Expires 12 March 2026                 [Page 4]


  Internet-Draft               aipref-autoctl               September 2025


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

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

     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/info/rfc9309>.

  6.  Informative References

     [AIPREF-VOCAB]
                IETF AI Preferences Working Group, "AI Preferences
                Vocabulary", Work in Progress, Internet-Draft, draft-ietf-
                aipref-vocab, 21 July 2025,
                <https://datatracker.ietf.org/doc/draft-ietf-aipref-
                vocab/>.

     [RAG2020]  Facebook AI Research, University College London, and New
                York University, "Retrieval-Augmented Generation for
                Knowledge-Intensive NLP Tasks", NeurIPS 2020, 2020,
                <https://proceedings.neurips.cc/paper/2020/
                hash/6b493230205f780e1bc26945df7481e5-Abstract.html>.

  Author's Address

     Bradley Silver
     Advance
     United States of America
     Email: bsilver@advance.com
















  Silver                    Expires 12 March 2026                 [Page 5]


name: draft-wang-cats-innetwork-infer
rev: 01
title: An Open, Decentralized, and Scalable Framework for Large Language Model Inference
time: 2026-03-02T09:35:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T09:35:42Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.830327+00:00
source: ietf
source_id: 149568
source_url: https://datatracker.ietf.org/doc/draft-wang-cats-innetwork-infer/
doc_status: active
abstract:
  Large Language Model (LLM) inference is increasingly deployed as a
     networked service, yet existing deployments rely primarily on
     centralized infrastructure and trusted operators.  Such designs limit
     openness, concentrate resource ownership, and constrain scalability
     to the capacity of individual providers.  At the same time, LLM
     inference introduces execution characteristics (e.g., strict
     sequential dependencies, large intermediate activations, and tight
     latency requirements) that are not well supported by existing
     network, transport, or coordination mechanisms in open environments.

     This document specifies an open, decentralized, and scalable
     framework for executing LLM inference across independently operated
     and mutually untrusted participants.  The framework treats inference
     as a distributed, layer-wise execution process subject to explicit
     deadlines, rather than as a monolithic computation or best-effort
     service.  It combines layer-aware activation transport and routing,
     decentralized coordination among heterogeneous compute resources, and
     security mechanisms that provide accountability and correctness
     without assuming trusted execution.

     This document focuses on the architectural framework, design
     rationale, problem definition, challenges, and solution space of the
     Open, Decentralized, and Scalable Inference framework (ODSI).  It
     does not specify concrete wire protocols, message formats, or
     protocol state machines.  Such protocol-level specifications are to
     be defined in separate documents that build upon the framework
     described herein.

full_text:
  Computing-Aware Traffic Steering                                 H. Wang
  Internet-Draft                                                     Q. Li
  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


  An Open, Decentralized, and Scalable Framework for Large Language Model
                                 Inference
                     draft-wang-cats-innetwork-infer-01

  Abstract

     Large Language Model (LLM) inference is increasingly deployed as a
     networked service, yet existing deployments rely primarily on
     centralized infrastructure and trusted operators.  Such designs limit
     openness, concentrate resource ownership, and constrain scalability
     to the capacity of individual providers.  At the same time, LLM
     inference introduces execution characteristics (e.g., strict
     sequential dependencies, large intermediate activations, and tight
     latency requirements) that are not well supported by existing
     network, transport, or coordination mechanisms in open environments.

     This document specifies an open, decentralized, and scalable
     framework for executing LLM inference across independently operated
     and mutually untrusted participants.  The framework treats inference
     as a distributed, layer-wise execution process subject to explicit
     deadlines, rather than as a monolithic computation or best-effort
     service.  It combines layer-aware activation transport and routing,
     decentralized coordination among heterogeneous compute resources, and
     security mechanisms that provide accountability and correctness
     without assuming trusted execution.

     This document focuses on the architectural framework, design
     rationale, problem definition, challenges, and solution space of the
     Open, Decentralized, and Scalable Inference framework (ODSI).  It
     does not specify concrete wire protocols, message formats, or
     protocol state machines.  Such protocol-level specifications are to
     be defined in separate documents that build upon the framework
     described herein.

  About This Document

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




  Wang, et al.            Expires 3 September 2026                [Page 1]


  Internet-Draft                    ODSI                        March 2026


     The latest revision of this draft can be found at
     https://kongyanye.github.io/draft-wang-cats-innetwork-infer/draft-
     wang-cats-innetwork-infer.html.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-wang-cats-
     innetwork-infer/.

     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-wang-cats-innetwork-infer.

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



  Wang, et al.            Expires 3 September 2026                [Page 2]


  Internet-Draft                    ODSI                        March 2026


       1.1.  Motivation for Open and Decentralized Inference . . . . .   4
       1.2.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . .   6
       1.3.  Design Principles . . . . . . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Problem Definition  . . . . . . . . . . . . . . . . . . . . .   9
       3.1.  Layer-Dependent Execution Pattern . . . . . . . . . . . .   9
       3.2.  Stateful Token-by-Token Progression . . . . . . . . . . .   9
       3.3.  Activation Delivery with Timing Constraints . . . . . . .  10
       3.4.  Open Participation and Adversarial Behavior . . . . . . .  10
       3.5.  Limitations of Existing Execution and Transport
             Methods . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.  System and Threat Assumptions . . . . . . . . . . . . . . . .  11
       4.1.  Participants and Roles  . . . . . . . . . . . . . . . . .  11
       4.2.  Network and Execution Assumptions . . . . . . . . . . . .  12
       4.3.  Adversary and Failure Model . . . . . . . . . . . . . . .  12
     5.  ODSI Framework Overview . . . . . . . . . . . . . . . . . . .  13
       5.1.  High-Level Architecture . . . . . . . . . . . . . . . . .  13
       5.2.  Layer-Wise Distributed Execution Model  . . . . . . . . .  15
       5.3.  Open Participation and Resource Contribution  . . . . . .  15
       5.4.  Scalability Considerations  . . . . . . . . . . . . . . .  16
     6.  Execution and Coordination Mechanism  . . . . . . . . . . . .  16
       6.1.  Layer Assignment and Path Affinity  . . . . . . . . . . .  16
       6.2.  Handling Stateful Inference and KV Cache  . . . . . . . .  17
       6.3.  Heterogeneous Compute Coordination  . . . . . . . . . . .  17
       6.4.  Failure Handling and Recovery . . . . . . . . . . . . . .  18
     7.  Deadline-Driven Execution and Performance Considerations  . .  18
       7.1.  Deadline Semantics and Slack  . . . . . . . . . . . . . .  18
       7.2.  Latency Sources and Bottlenecks . . . . . . . . . . . . .  19
       7.3.  Routing and Scheduling Considerations . . . . . . . . . .  19
       7.4.  Trade-offs Between Flexibility and Timeliness . . . . . .  20
     8.  Security and Accountability Framework . . . . . . . . . . . .  20
       8.1.  Cryptographic Identity  . . . . . . . . . . . . . . . . .  20
       8.2.  Verifiable Execution Actions  . . . . . . . . . . . . . .  21
       8.3.  Stake-Based Participation and Accountability  . . . . . .  21
       8.4.  Accountability Without Trusted Parties  . . . . . . . . .  22
     9.  Incentives and Economic Considerations  . . . . . . . . . . .  22
       9.1.  Motivation for Incentive Mechanisms . . . . . . . . . . .  22
       9.2.  Costly Misbehavior and Deterrence . . . . . . . . . . . .  23
       9.3.  Reputation and Long-Term Participation  . . . . . . . . .  23
     10. Inference Path and Control Path Separation  . . . . . . . . .  24
       10.1.  Design Rationale . . . . . . . . . . . . . . . . . . . .  24
       10.2.  Inference Path Execution Properties  . . . . . . . . . .  25
       10.3.  Control Path Functions and Enforcement . . . . . . . . .  25
       10.4.  Bounded Risk and Practical Correctness . . . . . . . . .  26
     11. Scalability and Deployment Considerations . . . . . . . . . .  26
       11.1.  Open Membership and Sybil Resistance . . . . . . . . . .  27
       11.2.  Growth and Churn . . . . . . . . . . . . . . . . . . . .  27
       11.3.  Interoperability and Extensibility . . . . . . . . . . .  28



  Wang, et al.            Expires 3 September 2026                [Page 3]


  Internet-Draft                    ODSI                        March 2026


     12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  28
     13. Relationship to Existing Work . . . . . . . . . . . . . . . .  29
     14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  29
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  29
       15.2.  Informative References . . . . . . . . . . . . . . . . .  30
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

  1.  Introduction

     Large Language Models (LLMs) have become a foundational component of
     modern networked applications, supporting tasks such as natural
     language understanding, code generation, and interactive assistants.
     Inference for these models is typically delivered as an online
     service, where user requests are transmitted to remote servers and
     processed incrementally to generate output tokens.  Unlike
     traditional network services or offline model training workloads, LLM
     inference exhibits strict sequential dependencies, maintains per-
     request execution state, and imposes tight latency constraints on
     model response.

     Today, most large-scale LLM inference deployments rely on centralized
     infrastructure operated by a small number of providers.
     Centralization simplifies coordination, scheduling, and state
     management, but it also concentrates control, limits participation,
     and couples scalability to the capacity, geography, and policies of
     individual operators.  As model sizes and inference demand continue
     to grow, these structural limitations motivate the exploration of
     alternative execution paradigms that can support broader
     participation and more elastic scaling.

     This document introduces the Open, Decentralized, and Scalable
     Inference framework (ODSI), an architectural framework for executing
     LLM inference across independently operated and heterogeneous compute
     resources.  ODSI considers environments in which participants are
     mutually untrusted and connected only through the public Internet.
     The framework focuses on how inference execution can be coordinated,
     secured, and scaled under such conditions, without assuming
     centralized control or trusted execution environments.

  1.1.  Motivation for Open and Decentralized Inference

     Centralized inference architectures assume that compute resources,
     network paths, and execution environments are under common
     administrative control.  While these assumptions enable tight
     optimization and simplified coordination, they impose structural
     constraints that become increasingly pronounced as model sizes
     continue to grow.  Modern LLMs require substantial compute throughput



  Wang, et al.            Expires 3 September 2026                [Page 4]


  Internet-Draft                    ODSI                        March 2026


     and memory capacity, and deploying a single model instance often
     exceeds the capabilities of an individual server.  As a result,
     inference deployments increasingly rely on multiple servers to host
     and execute a single model, raising operational complexity and cost.

     At the same time, a large volume of distributed compute resources
     remains underutilized.  Many devices and servers possess limited
     memory capacity or modest compute performance, preventing them from
     hosting complete model instances despite having available compute
     resources.  These constraints lead to fragmented and wasted capacity,
     particularly at the network edge or within smaller organizations,
     where individual nodes cannot independently support large models even
     though aggregate resources may be sufficient.

     Centralized cloud-based inference also introduces data movement and
     privacy concerns.  User inputs must be transmitted to remote data
     centers for processing, increasing exposure to data leakage and
     raising privacy risks in sensitive applications.  In addition,
     aggregating large volumes of inference traffic at centralized
     endpoints places sustained pressure on network bandwidth, increases
     transmission and queuing delays, and creates service bottlenecks that
     limit horizontal scalability.  As demand grows, scaling inference
     capacity requires proportional expansion of centralized
     infrastructure and network provisioning, which may not be
     economically or operationally sustainable.

     An open and decentralized inference model seeks to address these
     limitations by allowing independently operated participants to
     contribute partial compute resources without requiring prior trust
     relationships or centralized admission.  By distributing inference
     execution across many nodes, including resource-constrained and edge
     devices, this paradigm enables inference capacity to scale
     elastically with participation.  Placing computation closer to data
     sources can also reduce data movement, mitigate bandwidth
     bottlenecks, and improve responsiveness in certain deployment
     scenarios.

     However, decentralization fundamentally changes the inference
     execution environment.  Participants may vary widely in compute
     performance, memory capacity, network connectivity, and availability,
     and some participants may behave maliciously or rationally rather
     than altruistically.  Moreover, LLM inference is inherently stateful,
     i.e., the generation of each output token depends on all previous
     tokens, commonly represented through cached intermediate values such
     as key–value (KV) caches.  These characteristics make inference
     sensitive to delays, failures, and inconsistencies, and prevent it
     from being treated as a stateless or best-effort distributed task.




  Wang, et al.            Expires 3 September 2026                [Page 5]


  Internet-Draft                    ODSI                        March 2026


     ODSI is motivated by the need to support open participation and
     elastic scaling while preserving the correctness, timeliness, and
     reliability required for practical LLM inference.  The framework
     addresses how inference can be executed across decentralized and
     heterogeneous resources while remaining usable as an interactive
     network service.

  1.2.  Scope and Non-Goals

     This document defines the architectural framework, problem
     formulation, and design considerations for decentralized LLM
     inference under open participation.  It identifies the key challenges
     introduced by decentralization, including state management, latency
     constraints, heterogeneity, and adversarial behavior, and describes
     the high-level mechanisms used to address these challenges within the
     ODSI framework.

     This document does not specify concrete network protocols, wire
     formats, message encodings, or protocol state machines.  It also does
     not mandate specific model architectures, execution platforms,
     hardware accelerators, or economic systems.  Where cryptographic,
     incentive, or coordination mechanisms are discussed, they are
     described at an abstract level to illustrate design intent rather
     than to prescribe particular implementations.

     Protocol-level specifications, interoperability requirements, and
     implementation details are to be defined in other documents that
     build upon the framework presented here.

  1.3.  Design Principles

     The ODSI framework is guided by the following design principles:

     *  Open Participation: Any independently operated participant may
        contribute compute resources without requiring centralized
        admission or prior trust, subject to mechanisms that provide
        accountability and abuse resistance.

     *  Decentralized Coordination: Inference execution is coordinated
        without assuming a single trusted controller, relying instead on
        distributed mechanisms that tolerate heterogeneity, failures, and
        adversarial behavior.

     *  State-Aware Execution: The framework explicitly accounts for the
        stateful and sequential nature of LLM inference, including the
        management of intermediate execution state across tokens and
        layers.




  Wang, et al.            Expires 3 September 2026                [Page 6]


  Internet-Draft                    ODSI                        March 2026


     *  Deadline Sensitivity: Inference execution is treated as a latency-
        sensitive process, where intermediate steps are subject to
        explicit timing constraints rather than best-effort delivery.

     *  Scalability Through Composition: The framework is designed to
        scale by composing many independent contributors, allowing overall
        inference capacity to grow with participation rather than
        centralized provisioning.

     These principles inform the architectural choices and mechanisms
     described in the remainder of this document.

  2.  Terminology

     This section defines the terminology used throughout this document.
     Phrases in upper-case refer to other defined terms.

     ACTIVATION

     Intermediate numerical data produced by executing a model layer
     during inference.  ACTIVATIONS are consumed by subsequent layers and
     may be transmitted across the network between participants.

     CONTROL PLANE

     The non-latency-critical path responsible for coordination,
     verification, and enforcement functions, including cryptographic
     IDENTITY registration, STAKE management, SLASHING, REWARD settlement,
     and REPUTATION updates.

     DEADLINE

     A time constraint by which a specific inference step, such as a layer
     execution or ACTIVATION delivery, must complete to preserve end-to-
     end responsiveness.

     EXECUTION COMMITMENT

     A cryptographically signed declaration by a PARTICIPANT indicating
     intent to execute a specific inference step under defined inputs and
     DEADLINES, enabling later verification.

     IDENTITY

     A persistent, self-generated identifier bound to a PARTICIPANT,
     typically realized as a public–private key pair.

     INFERENCE PLANE



  Wang, et al.            Expires 3 September 2026                [Page 7]


  Internet-Draft                    ODSI                        March 2026


     The latency-critical path responsible for performing inference-
     related work, including LAYER execution, ACTIVATION transport,
     ROUTING, RE-ROUTING, and failure signaling.

     LAYER

     A discrete computation stage within an inference pipeline.  LAYERS
     are executed sequentially for each token step and may be assigned to
     different execution participants.

     PARTICIPANT

     An independently operated entity that contributes compute, memory, or
     network resources to ODSI and participates using a cryptographic
     IDENTITY.

     REPUTATION

     A persistent performance signal associated with a PARTICIPANT,
     derived from historical correctness, DEADLINE adherence,
     availability, and throughput.  REPUTATION influences task assignment
     and reward rates.

     RE-ROUTING

     The process of dynamically changing the ROUTING or LAYER assignment
     of an ongoing inference request in response to failures, performance
     degradation, or DEADLINE pressure.

     REWARD

     An economic payment issued to a PARTICIPANT for successfully
     completing an assigned inference task.

     ROUTING

     The selection of execution participants and network paths for
     ACTIVATION transport and LAYER execution, informed by DEADLINES and
     observed performance.

     SLACK

     The difference between an allocated DEADLINE budget and the expected
     execution time for an inference step.  SLACK represents tolerance to
     variability and delay.

     SLASHING




  Wang, et al.            Expires 3 September 2026                [Page 8]


  Internet-Draft                    ODSI                        March 2026


     An enforced economic penalty applied to a PARTICIPANT when verifiable
     misbehavior is detected, such as incorrect output, missed DEADLINES,
     or commitment violations.

     STAKE

     A quantity of economic value locked by a PARTICIPANT as collateral
     for participation.  STAKE enables accountability, economic
     deterrence, and Sybil resistance

  3.  Problem Definition

     This section defines the core problem addressed by the ODSI
     framework.  The goal is to formalize the execution constraints and
     failure modes that arise when LLM inference is performed across open,
     distributed, and independently operated compute resources.  These
     constraints collectively define what it means for decentralized
     inference to be correct, timely, and usable.

  3.1.  Layer-Dependent Execution Pattern

     LLM inference executes as a fixed sequence of model layers applied
     repeatedly for each generated token.  The output of each layer
     constitutes an intermediate activation that is required as input to
     the next layer in the sequence.  Execution therefore forms a strict
     dependency chain at layer granularity.

     In a decentralized setting, different layers may be executed on
     different nodes.  This introduces an explicit requirement that
     intermediate activations be transferred between nodes in the correct
     order and without duplication or omission.  Any execution framework
     must preserve layer ordering and ensure that each layer operates on
     the correct input corresponding to a specific inference request and
     token position.

  3.2.  Stateful Token-by-Token Progression

     Inference proceeds incrementally, generating tokens one at a time.
     Each token depends on an execution state accumulated from all
     previous tokens, commonly including cached intermediate values such
     as KV caches.  This state is logically persistent over the lifetime
     of the inference request.









  Wang, et al.            Expires 3 September 2026                [Page 9]


  Internet-Draft                    ODSI                        March 2026


     As a result, inference requests exhibit execution affinity, i.e.,
     successive tokens must either be processed by nodes that already
     possess the relevant state or incur the cost of state transfer or
     reconstruction.  Failures, delays, or inconsistencies in state
     handling directly affect correctness and latency.  The problem
     therefore includes maintaining coherent per-request state across a
     sequence of distributed execution steps.

  3.3.  Activation Delivery with Timing Constraints

     For interactive applications, inference must progress under tight
     latency constraints.  Each layer execution contributes both
     computation delay and communication delay, and delays in earlier
     layers propagate to all subsequent layers within the same token
     generation step.

     This creates implicit per-layer timing constraints, i.e.,
     intermediate activations must be delivered within bounded time to
     sustain acceptable end-to-end response latency.  The problem is not
     merely reliable delivery, but timely delivery under variable network
     conditions and heterogeneous execution speeds.

     The activation delivery problem is defined as follows.  Given a
     sequence of layer-dependent computations distributed across multiple
     nodes, how can intermediate activations be delivered and processed in
     order, within time bounds, despite variability in network latency,
     compute throughput, and node availability?

  3.4.  Open Participation and Adversarial Behavior

     ODSI assumes an open execution environment in which nodes may join or
     leave without centralized admission and are operated by independent
     parties.  Participants may differ significantly in performance,
     reliability, and incentives, and some may behave maliciously or
     rationally rather than cooperatively.

     The problems to solve therefore includes:

     *  Detecting incorrect or inconsistent execution results,

     *  Attributing actions to specific participants,

     *  Preventing abuse such as equivocation, free-riding, or denial of
        service,

     *  Enabling accountability without assuming trusted execution
        environments.




  Wang, et al.            Expires 3 September 2026               [Page 10]


  Internet-Draft                    ODSI                        March 2026


     Any viable solution must address correctness and liveness under these
     conditions while remaining compatible with open participation.

  3.5.  Limitations of Existing Execution and Transport Methods

     Existing execution and transport methods do not directly address the
     problem defined above.  Best-effort networking does not account for
     execution dependencies or timing constraints.  Traditional
     distributed computation frameworks assume stable membership, trusted
     operators, or coarse-grained tasks.  Centralized schedulers do not
     extend naturally to environments without common administrative
     control.

     The problem addressed by ODSI is therefore not solved by simply
     distributing computation or improving transport performance.  It
     requires a framework that explicitly integrates execution
     dependencies, state management, timing constraints, and participant
     accountability into the design.

  4.  System and Threat Assumptions

     This section specifies the assumptions under which the ODSI framework
     operates.  It defines the participating entities, communication and
     execution conditions, and the classes of failures and adversarial
     behavior the framework is designed to tolerate.  No centralized
     trust, privileged operators, or trusted execution environments are
     assumed.

  4.1.  Participants and Roles

     The system consists of a set of independently operated nodes that
     participate in inference execution.  Nodes may assume one or more of
     the following roles:

     *  *Clients* initiate inference requests and receive generated
        outputs.  A client may or may not also participate in execution.

     *  *Execution Nodes* perform inference computation, typically
        executing one or more model layers for specific inference
        requests.  Execution nodes may differ in compute capacity, memory
        availability, and supported hardware.

     *  *Coordination Nodes* participate in control-plane functions such
        as identity management, stake accounting, verification, and
        settlement.  These roles may be co-located with execution nodes or
        operated separately.





  Wang, et al.            Expires 3 September 2026               [Page 11]


  Internet-Draft                    ODSI                        March 2026


     All participants are identified by persistent cryptographic
     identities.  No global trust relationships are assumed among
     participants, and no role is restricted to a fixed or privileged set
     of operators.

  4.2.  Network and Execution Assumptions

     Nodes communicate over the public Internet using unreliable,
     asynchronous networks.  Message delivery may experience variable
     latency, reordering, duplication, or loss.  No assumptions are made
     about bounded network delay or synchronized clocks, except where
     explicitly stated by higher-layer mechanisms.

     Execution nodes are heterogeneous.  They may differ in:

     *  Compute throughput and supported instruction sets,

     *  Available memory and storage,

     *  Network bandwidth and latency,

     *  Availability and uptime.

     Nodes may join or leave the system at arbitrary times.  Execution may
     be interrupted due to failures, preemption, or voluntary withdrawal.
     The system does not assume trusted execution environments or
     hardware-based attestation, and correctness cannot be inferred solely
     from successful message delivery.

  4.3.  Adversary and Failure Model

     The framework assumes the presence of faulty, rational, and malicious
     participants.  Nodes may deviate arbitrarily from prescribed
     behavior, including but not limited to:

     *  Returning incorrect or fabricated inference outputs,

     *  Withholding results or responding after deadlines,

     *  Equivocating by providing inconsistent results to different peers,

     *  Attempting to free-ride without performing assigned computation,

     *  Launching denial-of-service or resource exhaustion attacks.

     In addition to malicious behavior, the system must tolerate non-
     malicious failures such as crashes, network partitions, and transient
     performance degradation.



  Wang, et al.            Expires 3 September 2026               [Page 12]


  Internet-Draft                    ODSI                        March 2026


     The adversary is not assumed to control a majority of system
     resources globally, but may control multiple identities unless
     mitigated by Sybil-resistance mechanisms.  The framework does not
     assume confidentiality of intermediate activations unless explicitly
     provided by higher-layer mechanisms.

     Under these assumptions, the framework aims to provide:

     *  Safety: incorrect inference results can be detected and
        attributed,

     *  Liveness: inference can make progress despite failures and churn,

     *  Accountability: misbehavior can be penalized without relying on
        trusted authorities.

  5.  ODSI Framework Overview

     This section provides a high-level overview of the ODSI framework.
     The framework defines how large-scale inference execution can be
     coordinated across open, heterogeneous, and independently operated
     resources while preserving correctness, timeliness, and
     accountability.

     ODSI is structured as a layered framework that integrates execution,
     coordination, and incentive mechanisms.  It does not mandate a
     specific implementation or protocol stack, but instead defines
     architectural components and their interactions.

  5.1.  High-Level Architecture





















  Wang, et al.            Expires 3 September 2026               [Page 13]


  Internet-Draft                    ODSI                        March 2026


                      +----------------------+
                      |        Client        |
                      |  (Inference Request) |
                      +----------+-----------+
                                 |
                                 v
     =========================================================
     |                    INFERENCE PLANE                    |
     |   (Deadline-Critical, Peer-to-Peer Inference Path)    |
     |                                                       |
     |   +-----------+     +-----------+     +-----------+   |
     |   |  Layer i  | --> | Layer i+1 | --> | Layer i+2 |   |
     |   | Exec Node |     | Exec Node |     | Exec Node |   |
     |   +-----------+     +-----------+     +-----------+   |
     |       |                   |                   |       |
     |       |        Intermediate Activations       |       |
     |       +---------------------------------------+       |
     |                                                       |
     =========================================================
                                 |
                                 |   Execution Events
                                 |   (commit, result, timing)
                                 v
     ---------------------------------------------------------
     |                     CONTROL PLANE                     |
     |     (Asynchronous Coordination and Accountability)    |
     |                                                       |
     |   +----------------+   +--------------------------+   |
     |   | Identity and   |   | Verification and Dispute |   |
     |   | Stake Manage.  |   | Resolution               |   |
     |   +----------------+   +--------------------------+   |
     |            |                     |                    |
     |            v                     v                    |
     |   +----------------+   +--------------------------+   |
     |   | Incentives and |   | Reputation and Routing   |   |
     |   | Settlement     |   | Feedback                 |   |
     |   +----------------+   +--------------------------+   |
     |                                                       |
     ---------------------------------------------------------

     At a high level, ODSI separates inference execution into two
     logically distinct planes:

     *  Execution Plane: Responsible for performing inference computation
        and delivering intermediate results under latency constraints.

     *  Control Plane: Responsible for identity management, coordination,
        verification, accounting, and enforcement.



  Wang, et al.            Expires 3 September 2026               [Page 14]


  Internet-Draft                    ODSI                        March 2026


     The execution plane operates in a peer-to-peer fashion and is
     optimized for low-latency, deadline-sensitive computation.  The
     control plane operates asynchronously and does not block inference
     progress, allowing execution to proceed even in the presence of
     coordination delays.

     This separation enables inference to remain responsive while still
     supporting accountability and correctness in an open environment.

  5.2.  Layer-Wise Distributed Execution Model

     ODSI adopts a layer-wise execution model in which inference
     computation is decomposed into sequential stages corresponding to the
     layers of the inference graph.  Each stage may be executed by a
     different execution node, and intermediate results are transferred
     between nodes as needed.

     Execution proceeds incrementally for each inference request, with
     explicit association between:

     *  A specific inference request,

     *  A specific token generation step,

     *  A specific computation layer.

     This explicit structuring allows the framework to reason about
     execution dependencies, timing constraints, and correctness at layer
     granularity.  It also enables flexible placement of computation
     across nodes with varying capabilities, without requiring any single
     node to host the entire inference workload.

  5.3.  Open Participation and Resource Contribution

     ODSI is designed to support open participation without centralized
     admission control.  Any node may contribute resources to inference
     execution by assuming execution or coordination roles, subject to
     framework-defined requirements for identity, accountability, and
     correctness.

     Resource contribution is flexible and may include:

     *  Compute capacity for executing specific computation stages,

     *  Memory for maintaining execution state,

     *  Network capacity for transporting intermediate results.




  Wang, et al.            Expires 3 September 2026               [Page 15]


  Internet-Draft                    ODSI                        March 2026


     Nodes are not required to support complete inference execution.
     Instead, they may contribute partial resources aligned with their
     capabilities.  This allows resource-constrained or edge nodes to
     participate meaningfully, while enabling aggregate inference capacity
     to scale with the number of participants.

  5.4.  Scalability Considerations

     Scalability in ODSI is achieved through decentralization,
     decomposition, and asynchronous coordination.  By distributing
     execution across many independently operated nodes, the framework
     avoids reliance on centralized bottlenecks.

     Key scalability properties include:

     *  Horizontal scaling: Inference capacity increases with the number
        of participating nodes.

     *  Elastic participation: Nodes may join or leave without global
        reconfiguration.

     *  Local decision-making: Execution placement and routing decisions
        can be made using local observations rather than global state.

     The framework is designed to tolerate heterogeneity and churn while
     maintaining bounded coordination overhead.  As inference demand
     grows, scalability is achieved by expanding participation rather than
     by increasing the capacity of centralized infrastructure.

  6.  Execution and Coordination Mechanism

     This section describes how inference execution is coordinated across
     distributed participants in the ODSI framework.  It focuses on how
     computation is assigned, how execution state is preserved, how
     heterogeneous resources are coordinated, and how failures are handled
     during inference execution.

  6.1.  Layer Assignment and Path Affinity

     Inference execution in ODSI is organized as a sequence of layer
     executions.  For each inference request, layers are assigned to
     execution nodes based on their capabilities, availability, and
     observed performance characteristics.








  Wang, et al.            Expires 3 September 2026               [Page 16]


  Internet-Draft                    ODSI                        March 2026


     ODSI introduces the notion of execution path affinity, whereby
     successive layers and token steps of the same inference request
     preferentially follow a consistent sequence of nodes.  Path affinity
     reduces the need to transfer execution state and intermediate data,
     thereby improving latency and reducing network overhead.

     Layer assignment decisions may be adapted dynamically in response to
     changing network conditions or node availability.  However,
     reassignment is performed conservatively to avoid excessive state
     migration or disruption of ongoing inference execution.  Under
     typical operating conditions, stable execution paths are expected to
     dominate, and recovery-related latency remains within acceptable
     bounds for interactive inference.

  6.2.  Handling Stateful Inference and KV Cache

     Inference execution maintains per-request state across token
     generation steps.  This state commonly includes cached intermediate
     values such as KV caches, which are required for efficient generation
     of subsequent tokens.

     ODSI treats execution state as logically associated with an execution
     path rather than with a single node.  State may be:

     *  Retained locally by execution nodes across successive steps,

     *  Transferred explicitly when execution is reassigned,

     *  Reconstructed when transfer is infeasible or too costly.

     This document does not mandate a specific state representation or
     transfer mechanism.  Instead, it defines coordination requirements
     that ensure state consistency and correctness across execution steps.

  6.3.  Heterogeneous Compute Coordination

     Execution nodes in ODSI are heterogeneous in compute performance,
     memory capacity, and network connectivity.  Coordination mechanisms
     must account for this heterogeneity when assigning computation and
     routing intermediate results.

     Nodes may advertise capabilities and performance metrics, such as
     execution throughput or observed latency.  Coordination decisions may
     incorporate these metrics to balance load, avoid bottlenecks, and
     satisfy timing constraints.






  Wang, et al.            Expires 3 September 2026               [Page 17]


  Internet-Draft                    ODSI                        March 2026


     The framework supports partial participation, allowing nodes to
     execute only those computation stages that align with their
     capabilities.  This enables broad participation without requiring
     uniform hardware or resource provisioning.

  6.4.  Failure Handling and Recovery

     ODSI is designed to tolerate failures during inference execution,
     including node crashes, network disruptions, and missed execution
     deadlines.

     Failure handling strategies include:

     *  Detecting stalled or failed execution steps through timeout or
        absence of expected outputs,

     *  Reassigning computation to alternative nodes when failures occur,

     *  Reconstructing execution state when necessary to resume inference.

     The framework prioritizes forward progress and bounded recovery cost.
     Failures may result in degraded performance or recomputation, but
     should not compromise correctness or global system stability.

     Recovery mechanisms are coordinated without assuming centralized
     control and do not require halting unrelated inference requests.

  7.  Deadline-Driven Execution and Performance Considerations

     Interactive inference services impose strict latency requirements
     that shape execution, coordination, and resource selection decisions.
     This section describes how ODSI reasons about deadlines, identifies
     sources of latency, and manages trade-offs between flexibility and
     timely execution.

  7.1.  Deadline Semantics and Slack

     In ODSI, inference execution is associated with explicit or implicit
     deadlines derived from application-level responsiveness requirements.
     Deadlines apply not only to end-to-end inference requests but also to
     intermediate execution steps, such as individual layer computations
     within a token generation cycle.









  Wang, et al.            Expires 3 September 2026               [Page 18]


  Internet-Draft                    ODSI                        March 2026


     Each execution step may be assigned a deadline budget, representing
     the maximum allowable time from input availability to output
     production.  The difference between the allocated budget and the
     expected execution time is referred to as slack.  Slack captures
     tolerance to variability in computation and communication and serves
     as a key signal for execution planning.

     Slack is consumed as inference progresses.  Delays incurred at
     earlier steps reduce the slack available to downstream steps, making
     subsequent execution increasingly time-sensitive.  The framework
     therefore prioritizes maintaining positive slack throughout execution
     to preserve responsiveness.

  7.2.  Latency Sources and Bottlenecks

     End-to-end inference latency arises from multiple sources, including:

     *  Computation time for executing individual layers,

     *  Data transfer time for delivering intermediate results,

     *  Queuing delays caused by contention for compute or network
        resources,

     *  Coordination overhead for assignment and verification.

     In decentralized environments, these latency components are highly
     variable and may fluctuate over short time scales.  Bottlenecks may
     shift dynamically due to changes in network conditions, node
     availability, or workload distribution.

     ODSI does not assume that any single latency source dominates.
     Instead, it treats latency as a composite effect and seeks to
     minimize the risk of deadline violations by accounting for both
     computation and communication delays when coordinating execution.

  7.3.  Routing and Scheduling Considerations

     Routing and scheduling decisions in ODSI are informed by deadline
     constraints and observed performance.  Execution steps may be routed
     through nodes that offer favorable trade-offs between compute
     throughput, network latency, and reliability.

     Scheduling decisions may incorporate:

     *  Estimated computation time based on historical performance,

     *  Network round-trip latency and variability,



  Wang, et al.            Expires 3 September 2026               [Page 19]


  Internet-Draft                    ODSI                        March 2026


     *  Current queue occupancy or load,

     *  Remaining slack for the inference request.

     The framework favors execution paths that preserve slack and reduce
     the probability of deadline violations.  However, routing decisions
     are made using incomplete and potentially stale information, and must
     therefore tolerate uncertainty.

  7.4.  Trade-offs Between Flexibility and Timeliness

     ODSI balances execution flexibility against the need for timely
     completion.  Allowing frequent reassignment or dynamic
     reconfiguration can improve robustness and load balancing but may
     introduce additional coordination overhead and state transfer costs.

     Conversely, favoring stable execution paths improves predictability
     and reduces overhead but may limit the system’s ability to respond to
     failures or performance degradation.

     The framework does not prescribe a single optimal balance.  Instead,
     it defines a design space in which implementations may tune the
     degree of flexibility based on workload characteristics, deployment
     conditions, and performance objectives.  The guiding principle is to
     favor timely execution in the common case, while retaining sufficient
     adaptability to preserve progress under adverse conditions.

  8.  Security and Accountability Framework

     This section describes the security and accountability mechanisms
     assumed by the ODSI framework.  The framework operates in an open
     environment with mutually untrusted participants and therefore relies
     on cryptographic mechanisms and economic accountability rather than
     trusted operators or centralized enforcement.

  8.1.  Cryptographic Identity

     Each participant in the system is associated with a persistent
     cryptographic identity, typically represented by a public–private key
     pair [RFC6979].  This identity serves as the basis for
     authentication, attribution, and accountability across all
     interactions.

     All inference-related actions, including execution commitments,
     result submissions, and coordination messages, are bound to the
     participant’s identity through digital signatures.  This binding
     ensures that actions can be reliably attributed to specific
     participants without relying on centralized identity providers.



  Wang, et al.            Expires 3 September 2026               [Page 20]


  Internet-Draft                    ODSI                        March 2026


     Identities are self-generated and do not imply trust.  The framework
     assumes that a single entity may control multiple identities unless
     constrained by additional mechanisms such as economic bonding or
     resource-based admission.

  8.2.  Verifiable Execution Actions

     ODSI requires that execution-related actions be verifiable, meaning
     that they can be independently checked for consistency, correctness,
     or policy compliance after the fact.

     Verifiable actions may include:

     *  Commitments to execute specific computation stages,

     *  Submission of intermediate or final execution outputs,

     *  Timing assertions related to execution deadlines.

     Verification does not require continuous oversight during execution.
     Instead, it relies on cryptographic commitments, hashes, and signed
     messages that allow third parties to reconstruct and evaluate
     execution behavior when disputes arise.

     This approach enables detection of incorrect execution, equivocation,
     or deadline violations without imposing synchronous verification on
     the critical execution path [Byzantine].

  8.3.  Stake-Based Participation and Accountability

     ODSI employs stake-based participation as a foundational mechanism
     for accountability and Sybil resistance.  To serve inference
     requests, participants are required to lock a quantity of economic
     value as stake, which acts as collateral against misbehavior.

     Stake introduces a real economic cost to participation and creates
     persistent consequences for incorrect or unreliable behavior.  When
     misbehavior is verified—such as incorrect execution, commitment
     violations, or repeated deadline failures—stake may be partially or
     fully forfeited according to predefined rules.

     Stake directly enables accountability by ensuring that identities are
     bound to economic risk.  It also provides an economic basis for Sybil
     resistance: while identities are inexpensive to create, meaningful
     participation and influence require proportional stake.  As a result,
     large-scale Sybil attacks require substantial capital commitment and
     expose the adversary to high risk of loss.




  Wang, et al.            Expires 3 September 2026               [Page 21]


  Internet-Draft                    ODSI                        March 2026


     The influence and opportunities afforded to a participant may be
     proportional to both locked stake and historical performance.  This
     ensures that influence reflects sustained contribution rather than
     identity count alone.

  8.4.  Accountability Without Trusted Parties

     The framework is designed to provide accountability without assuming
     trusted coordinators, validators, or execution environments.
     Accountability is achieved by combining identity-bound actions with
     verifiable evidence and enforceable consequences.

     When misbehavior is detected, responsibility can be attributed to
     specific identities based on signed execution records.  Consequences,
     such as penalties or exclusion from future participation, can then be
     applied according to defined rules.

     This design ensures that participants are held accountable for their
     actions while preserving open participation and decentralization.
     Trust is replaced by verification and consequence, allowing the
     system to operate securely in adversarial environments.

  9.  Incentives and Economic Considerations

     ODSI operates in an open environment where participation is voluntary
     and participants are assumed to act in their own interest.  As a
     result, correct and timely execution cannot be assumed to arise from
     cooperation alone.  This section outlines the economic mechanisms
     that align participant incentives with system objectives, ensuring
     reliable execution under decentralized operation.

  9.1.  Motivation for Incentive Mechanisms

     In a decentralized inference environment, participants contribute
     compute, memory, and network resources that incur real costs.
     Without explicit incentives, participants may decline execution
     assignments, deprioritize inference workloads, or abandon execution
     paths when conditions become unfavorable.

     ODSI therefore associates inference execution with explicit economic
     rewards [Bitcoin].  Each successfully executed layer earns a payment,
     creating a direct linkage between contributed work and compensation.
     Reward levels may vary based on execution conditions, including:

     *  Tighter execution deadlines, which impose higher performance
        requirements,





  Wang, et al.            Expires 3 September 2026               [Page 22]


  Internet-Draft                    ODSI                        March 2026


     *  Placement on latency-critical or bottleneck segments of an
        execution path,

     *  Historical reliability and performance of the executing
        participant.

     By rewarding each completed execution unit, ODSI enables fine-grained
     accounting and encourages participants to contribute resources
     proportionally to their capabilities.

  9.2.  Costly Misbehavior and Deterrence

     For incentives to be effective, misbehavior must be economically
     disadvantageous.  ODSI assumes that participants may behave
     strategically, including submitting incorrect activation outputs,
     violating execution commitments, or missing assigned deadlines.

     Misbehavior triggers penalties through the control path.  Slashing
     events may occur in response to:

     *  Incorrect or invalid activation outputs,

     *  Mismatches between committed execution inputs and revealed
        results,

     *  Failure to meet agreed execution deadlines.

     Penalties are calibrated to exceed the expected gains from cheating
     or shirking, ensuring that rational participants cannot profit from
     misbehavior even if detection is probabilistic.  Slashing may involve
     forfeiture of locked stake, loss of accrued rewards, or other
     economically meaningful consequences.

     Penalties are applied only when sufficient cryptographic and
     execution evidence exists to attribute responsibility to a specific
     identity.  This ensures that deterrence is precise and does not
     require centralized trust or continuous supervision.

  9.3.  Reputation and Long-Term Participation

     While per-layer payments and penalties shape short-term behavior,
     long-term reliability is reinforced through reputation mechanisms.
     Reputation reflects a participant’s historical performance across
     multiple dimensions, including:

     *  Deadline adherence rate,

     *  Output correctness and consistency,



  Wang, et al.            Expires 3 September 2026               [Page 23]


  Internet-Draft                    ODSI                        March 2026


     *  Availability and responsiveness,

     *  Sustained execution throughput over time.

     Reputation directly influences future participation opportunities.
     Participants with strong reputations may receive higher task volumes,
     preferential assignment to latency-critical execution paths, higher
     reward rates, or access to tighter deadlines.  Conversely,
     participants with poor or unstable reputations may receive fewer
     assignments, reduced compensation, or eventual exclusion.

     Reputation complements direct economic incentives by encouraging
     sustained, honest participation across many execution sessions.
     Together, per-layer rewards, slashing-based deterrence, and
     reputation-driven coordination create a self-reinforcing environment
     in which rational participants are motivated to behave reliably,
     enabling scalable and decentralized inference execution.

  10.  Inference Path and Control Path Separation

     ODSI separates inference execution into an inference path and a
     control path in order to reconcile strict latency requirements with
     the need for security, accountability, and open participation
     (analogy to Lightning [Lightning]).  The inference path is
     responsible for latency-critical execution and data movement required
     to generate inference outputs.  The control path is responsible for
     identity management, economic coordination, verification, and
     enforcement.  Together, they form a coherent architecture that
     decouples performance-sensitive execution from governance and
     accountability functions.

  10.1.  Design Rationale

     Interactive inference requires execution progress within tight and
     predictable time bounds.  Operations such as cryptographic identity
     registration, stake management, global verification, or reward
     settlement cannot be placed directly on the critical execution path
     without violating these constraints.

     At the same time, an open and decentralized environment requires
     mechanisms to deter misbehavior, attribute responsibility, and
     enforce incentives.  These mechanisms inherently involve
     coordination, state persistence, and potentially delayed resolution.

     The separation between the inference path and the control path
     addresses this tension by allowing inference execution to proceed
     optimistically and independently, while ensuring that execution
     remains observable, attributable, and enforceable.  Lightweight



  Wang, et al.            Expires 3 September 2026               [Page 24]


  Internet-Draft                    ODSI                        March 2026


     checks on the inference path reduce the likelihood that incorrect
     results propagate to users, while the control path provides
     definitive validation, economic settlement, and long-term
     accountability.

  10.2.  Inference Path Execution Properties

     The inference path carries all latency-critical activities required
     for inference execution.  This includes:

     *  Layer-wise computation across participating nodes,

     *  Transport of intermediate activations and execution state,

     *  Routing and re-routing decisions based on network and execution
        conditions,

     *  Failure detection and signaling to enable timely recovery.

     The inference path is optimized for low latency, minimal coordination
     overhead, and predictable progress under Internet variability.

     Inference path execution is optimistic but constrained.  Participants
     are not blindly trusted, and incorrect execution is mitigated through
     the following mechanisms:

     *  Execution commitments: Participants commit to execution inputs,
        layer identifiers, and deadlines before revealing outputs,
        preventing adaptive or inconsistent behavior.

     *  Selective redundancy: For high-impact layers or execution steps,
        multiple participants may perform the same computation, allowing
        mismatches to be detected through lightweight comparison.

     *  State-local execution: Execution path affinity minimizes state
        transfer and confines errors to limited execution segments.

     These mechanisms allow many incorrect executions to be detected
     within the same token step or shortly thereafter, enabling rapid
     fallback or localized re-execution before incorrect results propagate
     to the user.

  10.3.  Control Path Functions and Enforcement

     The control path operates asynchronously and is responsible for
     system-wide coordination and accountability.  Its functions include,
     but are not limited to:




  Wang, et al.            Expires 3 September 2026               [Page 25]


  Internet-Draft                    ODSI                        March 2026


     *  Cryptographic identity registration and authentication,

     *  Stake locking, management, and release,

     *  Validation of execution commitments and revealed results,

     *  Slashing decisions for incorrect execution or missed deadlines,

     *  Reward calculation and settlement,

     *  Maintenance of long-term reputation or eligibility signals.

     Because control path operations are not latency-critical, they can
     perform thorough verification and policy enforcement without delaying
     inference execution.  Control path decisions are driven by signed
     execution records and verifiable evidence produced during inference
     path execution.

     While some violations may be detected only after inference has
     progressed or completed, economic deterrence and reputational
     consequences make sustained misbehavior irrational for participants
     seeking long-term participation.

  10.4.  Bounded Risk and Practical Correctness

     The separation between the inference path and the control path
     introduces bounded risk rather than absolute prevention of incorrect
     execution.  However, the combination of early detection on the
     inference path, rapid fallback mechanisms, and strong economic
     deterrence on the control path ensures that incorrect results are
     rare, localized, and unlikely to persist undetected.

     This design follows a well-established distributed systems principle:
     optimistic execution combined with eventual verification.  ODSI
     applies this principle to open and decentralized inference, enabling
     high-throughput, low-latency execution while preserving
     accountability and system integrity.

  11.  Scalability and Deployment Considerations

     ODSI is designed to scale across large numbers of independently
     operated participants and to operate under dynamic network and
     resource conditions.  This section discusses considerations related
     to open participation, participant churn, and long-term extensibility
     of the framework.






  Wang, et al.            Expires 3 September 2026               [Page 26]


  Internet-Draft                    ODSI                        March 2026


  11.1.  Open Membership and Sybil Resistance

     ODSI supports open membership, allowing any participant to contribute
     computational resources without requiring centralized admission or
     prior trust relationships.  This openness is essential for elastic
     scaling and for harnessing widely distributed and heterogeneous
     compute capacity.

     However, open membership introduces the risk that a single entity may
     create many identities to gain disproportionate influence or rewards.
     To mitigate this risk, ODSI relies on Sybil-resistance mechanisms
     implemented within the control plane, where Sybil resistance can only
     be achieved economically rather than administratively.  While
     identity creation is unrestricted, meaningful participation requires
     stake-backed commitment.  Stake ensures that influence, task volume,
     and rewards are proportional to economic risk and historical
     performance rather than identity count.

     This approach preserves openness while preventing adversaries from
     cheaply amplifying influence through large numbers of identities.
     Large-scale Sybil attacks require correspondingly large capital
     commitments and carry a high risk of economic loss.

  11.2.  Growth and Churn

     Participants in ODSI may join or leave the system at any time, either
     intentionally or due to failures, mobility, or network conditions.
     The framework assumes continuous churn and does not require long-
     lived availability from individual participants.

     Scalability under churn is achieved by:

     *  Decentralized participant discovery and coordination,

     *  Adaptive assignment of inference execution based on observed
        availability and performance,

     *  Conservative state migration and localized recovery when execution
        paths change.

     The inference plane prioritizes timely progress in the presence of
     transient failures, while the control plane provides longer-term
     stability by discouraging unreliable behavior through economic and
     reputational consequences.  Together, these mechanisms allow the
     system to scale with participation while remaining robust under
     dynamic conditions.





  Wang, et al.            Expires 3 September 2026               [Page 27]


  Internet-Draft                    ODSI                        March 2026


  11.3.  Interoperability and Extensibility

     ODSI is defined as an architectural framework rather than a single
     monolithic protocol.  It is intended to accommodate multiple protocol
     instantiations, execution environments, and incentive mechanisms.

     Interoperability is supported by:

     *  Clear separation between inference execution and verification
        functions,

     *  Well-defined interfaces between planes,

     *  Use of cryptographic primitives and message formats that can be
        standardized independently.

     Extensibility is a key design goal.  New execution strategies,
     verification techniques, or incentive schemes can be introduced
     without disrupting existing deployments, provided they respect the
     framework’s core principles.  This modularity allows ODSI to evolve
     alongside advances in inference techniques, hardware capabilities,
     and decentralized coordination mechanisms.

  12.  Privacy Considerations

     Inference execution in ODSI involves the transmission of user-
     provided inputs and intermediate activations across independently
     operated participants.  By default, the framework does not provide
     confidentiality guarantees for such data beyond transport-level
     protection.

     Decentralized execution may reduce the need to transmit user data to
     centralized endpoints and can enable computation to occur closer to
     data sources.  However, distributing execution across multiple
     participants may also increase the number of entities that observe
     portions of the execution state.

     Privacy risks include exposure of user inputs, partial activations,
     execution patterns, or metadata such as timing and routing
     information.  These risks vary depending on deployment context,
     participant selection policies, and execution strategies.

     ODSI is designed to be compatible with additional privacy-enhancing
     mechanisms, including data minimization, execution on trusted
     hardware, encrypted computation, or differential privacy techniques.
     Such mechanisms are considered out of scope for this document but may
     be incorporated by specific protocol instantiations or deployment
     profiles.



  Wang, et al.            Expires 3 September 2026               [Page 28]


  Internet-Draft                    ODSI                        March 2026


     Operators and users should carefully evaluate privacy requirements
     and select appropriate configurations and extensions when deploying
     ODSI in sensitive environments.

  13.  Relationship to Existing Work

     ODSI draws inspiration from multiple areas of distributed systems and
     decentralized computing, while addressing challenges that are
     specific to large-scale, interactive inference workloads.

     Centralized inference platforms provide tightly optimized execution
     but rely on trusted operators and centralized infrastructure.  ODSI
     departs from this model by enabling open participation and
     decentralized execution while preserving interactivity.

     Prior work on distributed machine learning focuses primarily on
     training or batch-oriented computation, where execution is less
     sensitive to strict per-step latency and state continuity.  In
     contrast, ODSI targets online inference with strong sequential
     dependencies and deadline constraints.

     Peer-to-peer and decentralized computation frameworks enable open
     resource contribution but typically assume best-effort execution or
     stateless tasks.  ODSI extends these ideas by incorporating stateful
     execution, deadline awareness, and economic accountability.

     Blockchain and decentralized ledger systems provide mechanisms for
     identity, verification, and incentive alignment, but are generally
     unsuitable for latency-critical execution.  ODSI adopts similar
     accountability principles while decoupling execution from
     verification to meet performance requirements.

     By integrating concepts from these domains, ODSI defines a distinct
     architectural approach for open, decentralized inference that
     complements rather than replaces existing systems.

  14.  Acknowledgments

     The authors would like to thank colleagues and reviewers in the
     community who provided feedback on the early version of this draft.

  15.  References

  15.1.  Normative References







  Wang, et al.            Expires 3 September 2026               [Page 29]


  Internet-Draft                    ODSI                        March 2026


     [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
                Algorithm (DSA) and Elliptic Curve Digital Signature
                Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
                2013, <https://www.rfc-editor.org/rfc/rfc6979>.

  15.2.  Informative References

     [Bitcoin]  Nakamoto, S., "Bitcoin: A peer-to-peer electronic cash
                system", 2008.

     [Byzantine]
                Castro, M. and B. Liskov, "Practical byzantine fault
                tolerance", OSDI, February 1999, <https://www.usenix.org/l
                egacy/publications/library/proceedings/osdi99/full_papers/
                castro/castro.ps>.

     [Lightning]
                Joseph Poon and T. Dryja, "The bitcoin lightning network:
                Scalable off-chain instant payments", 2008.

  Authors' Addresses

     Hanling Wang
     Pengcheng Laboratory
     Email: wanghl03@pcl.ac.cn


     Qing Li
     Pengcheng Laboratory
     Email: liq@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











  Wang, et al.            Expires 3 September 2026               [Page 30]


name: draft-reilly-sentinel-protocol
rev: 00
time: 2025-09-26T20:43:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-30T20:43:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.836789+00:00
source: ietf
source_id: 149747
source_url: https://datatracker.ietf.org/doc/draft-reilly-sentinel-protocol/
doc_status: active
title:
  Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI Datasets, Training, Fine-Tuning, and Inference Provenance

abstract:
  The Reilly Sentinel Protocol (RSP) specifies an interoperable,
     dual-layer method for establishing integrity, provenance, and
     auditability across the artificial intelligence (AI) lifecycle.
     RSP defines a Sentinel Evidence Package (SEP) that binds payload
     digests, provenance metadata, signatures, blockchain timestamp
     proofs, and resolvable identifiers (DOIs).  This enables
     tamper-evident, independently verifiable receipts for datasets,
     data transformations, training jobs, checkpoints, fine-tuning
     runs, evaluations, and inference outputs.

     RSP is transport-agnostic and serializable in JSON and CBOR.  It
     leverages existing IETF and industry building blocks, including
     COSE/CMS signatures, CBOR (RFC 8949), CDDL (RFC 8610), JSON
     (RFC 8259), and NTS-secured time (RFC 8915).  Anchoring is done
     via append-only blockchain receipts (e.g., OpenTimestamps-style
     proofs) and identity/lineage is stabilized with a DOI registry.
     The result is an evidence-grade audit trail for regulated and
     safety-critical AI deployments.

full_text:
  Network Working Group                                         L.J. Reilly
  Internet-Draft                                       Independent Submission
  Intended status: Informational                                 26 September 2025
  Expires: 30 March 2026


     Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI
        Datasets, Training, Fine-Tuning, and Inference Provenance
                    draft-reilly-sentinel-protocol-00


  Abstract

     The Reilly Sentinel Protocol (RSP) specifies an interoperable,
     dual-layer method for establishing integrity, provenance, and
     auditability across the artificial intelligence (AI) lifecycle.
     RSP defines a Sentinel Evidence Package (SEP) that binds payload
     digests, provenance metadata, signatures, blockchain timestamp
     proofs, and resolvable identifiers (DOIs).  This enables
     tamper-evident, independently verifiable receipts for datasets,
     data transformations, training jobs, checkpoints, fine-tuning
     runs, evaluations, and inference outputs.

     RSP is transport-agnostic and serializable in JSON and CBOR.  It
     leverages existing IETF and industry building blocks, including
     COSE/CMS signatures, CBOR (RFC 8949), CDDL (RFC 8610), JSON
     (RFC 8259), and NTS-secured time (RFC 8915).  Anchoring is done
     via append-only blockchain receipts (e.g., OpenTimestamps-style
     proofs) and identity/lineage is stabilized with a DOI registry.
     The result is an evidence-grade audit trail for regulated and
     safety-critical AI deployments.


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


  Table of Contents

     1.  Introduction
     2.  Conventions and Terminology
     3.  Architecture and Roles
     4.  Sentinel Evidence Package (SEP) Data Model
     5.  Serialization and Media Types
     6.  Anchoring and Proofs
     7.  DOI Registration and Metadata
     8.  Protocol Operations
     9.  Verification Algorithm
     10. Error Handling
     11. Manageability and Telemetry
     12. Privacy Considerations
     13. Security Considerations
     14. IANA Considerations
     15. Implementation Status
     16. References
         16.1. Normative References
         16.2. Informative References
     Appendix A.  CDDL for CBOR SEP
     Appendix B.  Example JSON SEP
     Appendix C.  Verification Report (JSON)
     Appendix D.  Example OpenTimestamps Receipt
     Appendix E.  Example DOI Metadata Mapping
     Acknowledgments
     Author's Address


  1.  Introduction

     Artificial Intelligence (AI) systems are increasingly used in
     high-stakes contexts (defense, healthcare, finance, critical
     infrastructure).  Confidence in AI outcomes depends on the ability
     to show where data came from, how models were trained or adapted,
     when inferences were produced, and whether any of these artifacts
     have been altered.

     RSP addresses these needs by defining a minimal yet extensible
     evidence container -- the Sentinel Evidence Package (SEP) -- and a
     verification process that any independent party can execute without
     trusting the producer's infrastructure.  RSP is content- and model-
     agnostic: it does not dictate the model architecture or task; it
     only standardizes how integrity, time, identity, and lineage are
     recorded and verified.

     RSP combines two complementary layers of permanence:

     *  Blockchain anchoring:  an append-only proof of existence by a
        given time for payload digests and roll-up digests.

     *  DOI registration:  globally resolvable, citable identifiers with
        metadata, lineage, and retention semantics.

     This dual anchoring makes later manipulations detectable and enables
     reliable long-term discovery and citation.


  2.  Conventions and Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
     and "OPTIONAL" in this document are to be interpreted as described
     in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in
     all capitals, as shown here.

     SEP:  Sentinel Evidence Package; the container defined by this
        document.

     Artifact:  Any AI lifecycle asset -- dataset, data transform,
        training configuration, training log, model checkpoint, fine-
        tuning diff, evaluation artifact, or inference record.

     Digest:  A cryptographic hash (e.g., SHA-256) of a payload or
        Merkle root over chunked payloads.

     OTS:  OpenTimestamps-style proof object or functionally equivalent
        blockchain timestamp receipt.

     DOI:  Digital Object Identifier; a resolvable identifier (via
        DataCite/Crossref or internal Handle) providing metadata and
        lineage stability.

     COSE:  CBOR Object Signing and Encryption; RSP uses COSE signatures
        (RFC 9052, RFC 9053).

     CMS:  Cryptographic Message Syntax (RFC 5652).


  3.  Architecture and Roles

     Producer:  Creates artifacts, computes digests, collects device/
        environment attestations, signs SEPs, and requests anchoring and
        DOI registration.

     Registrar:  Provides two sub-services: (a) Anchoring Orchestrator
        that submits digests to public chains and returns proofs; (b) DOI
        Registrar that mints DOIs and stores metadata, lineage, and
        fixity.

     Verifier:  Recomputes digests, validates signatures, checks OTS
        receipts against independent nodes, and resolves DOI metadata and
        lineage without trusting Producer or Registrar beyond their
        signatures.

     Storage:  WORM (Write-Once-Read-Many) or equivalent immutable object
        storage for SEPs, proofs, and payloads under retention policy.

     Time:  Authenticated time sources (NTS, RFC 8915) and monotonic
        counters to resist back-dating and rollback.

     RSP does not mandate a specific trust relation among these roles; in
     many deployments, Producer and Registrar are separate entities.


  4.  Sentinel Evidence Package (SEP) Data Model

     An SEP is a self-describing manifest that binds digest(s), metadata,
     signatures, proofs, and identifiers.  The canonical fields are:

     *  version:  Protocol version string (e.g., "1.0").

     *  artifact.type:  "dataset", "datatransform", "training.config",
        "training.log", "training.checkpoint", "fine-tune.diff",
        "evaluation", "inference", or an extension token.

     *  payloads[]:  Optional array with entries { cid, size, mime,
        chunking }; payload storage MAY be external.  'cid' MUST encode
        algorithm and value (e.g., "sha256:HEX").

     *  digests:  Object with at least sha256 and sha3_256 members
        (hex-encoded).  For chunked payloads, digests.root is the Merkle
        root, and digests.leaves MAY be omitted.

     *  timestamps:  wallclock (RFC 3339) and monotonic counter.  The
        'source' SHOULD indicate NTS, Roughtime, or equivalent.

     *  authors[]:  Optional list of creators/operators; MAY include
        device IDs and certificate references.

     *  attestation:  Optional device/firmware/build attestation claims
        (out of scope to specify here; see RATS, RFC 9334).

     *  rem:  Anchoring and identity sub-object:
          - rem.ots_proof_ref: URN or locator to proof file.
          - rem.doi: DOI string.
          - rem.lineage: parent[], siblings[], supersedes[].

     *  class:  Optional classification/handling indicators (tokenized).

     *  policies:  Retention and access policy references.

     *  signatures[]:  One or more COSE_Sign1 or CMS signatures covering
        the manifest canonical form.  Certificate chains MUST be
        included.

     The manifest MUST be canonicalized prior to signing; canonical JSON
     (JCS, RFC 8785) or deterministic CBOR (RFC 8949 Section 4.2) MAY be
     used.


  5.  Serialization and Media Types

     RSP SEPs MAY be emitted as JSON (RFC 8259) or CBOR (RFC 8949).
     This document defines two media types for IANA registration:

     *  application/rsp-ep+json
     *  application/rsp-ep+cbor

     The "+" structured suffix follows RFC 6839.  See Section 14 for
     IANA templates.


  6.  Anchoring and Proofs

     Producers submit digests (payload or roll-up Merkle roots) to the
     Anchoring Orchestrator.  The orchestrator MUST anchor to at least
     one public append-only chain and SHOULD support multiple chains for
     diversity.  Proofs MUST be exportable and independently checkable.

     OpenTimestamps receipts are RECOMMENDED where applicable.  When
     using other schemes, a proof MUST include sufficient data for
     independent verification (e.g., chain identifier, transaction
     locator, inclusion path).

     Roll-up anchoring:  Operators SHOULD periodically compute a Merkle
     tree over all new artifact digests and anchor the root to reduce
     per-artifact anchoring cost and to provide compact audit coverage.


  7.  DOI Registration and Metadata

     After anchoring, the Registrar mints a DOI and stores a metadata
     record containing at least: title or short label, creators,
     creation time, fixity (digests), lineage links, and policy URIs.
     DOIs for classified material MAY be internal Handles resolvable on
     private networks; unclassified artifacts MAY use public DOIs
     (e.g., DataCite).

     A DOI SHOULD be minted for each material evolution that changes
     fixity (e.g., new dataset version, fine-tune result, evaluation
     report).  Prior DOIs MUST NOT be deleted; instead, metadata MAY
     indicate "superseded-by".


  8.  Protocol Operations

     The following abstract operations are defined; concrete APIs are out
     of scope, but typical deployments use REST or gRPC.

     8.1  SEAL

        Inputs:  manifest draft (unsigned), digests, optional attestation.
        Action:  Canonicalize, sign (COSE/CMS), return SEP (unsigned ->
                 signed).

     8.2  ANCHOR

        Inputs:  digest(s) (payload or roll-up).  Action: Anchor to one
                 or more chains; return proof reference(s).

     8.3  REGISTER

        Inputs:  metadata (including fixity, lineage).  Action: Mint DOI,
                 bind DOI <-> SEP <-> proofs; return DOI.

     8.4  VERIFY

        Inputs:  DOI or SEP URI (plus payload, if accessible).  Action:
                 Recompute digests; validate signatures; check time
                 discipline; verify proofs; emit Verification Report.


  9.  Verification Algorithm

     Given a DOI or SEP:

     1.  Resolve DOI (if provided) to retrieve minimal metadata including
         fixity, lineage, and pointers to SEP and payload (subject to
         policy).

     2.  Fetch SEP.  Parse and canonicalize the manifest according to its
         serialization; verify that the 'digests' field matches the
         payload (if accessible).

     3.  Validate signatures (COSE/CMS).  Check certificate validity and
         revocation (OCSP/CRL).  Attestation claims MAY be evaluated via
         a verifier (cf. RATS, RFC 9334).

     4.  Validate time: ensure wallclock is plausible (NTS/secure time)
         and monotonic counter continuity holds relative to adjacent
         SEPs.

     5.  Validate anchoring proofs independently using public chain data.

     6.  Emit a Verification Report with fields: hash_ok, sig_ok,
         attestation_ok, ots_ok, time_ok, doi_ok, and overall verdict.
         The report SHOULD itself be signed.


  10.  Error Handling

     RSP defines abstract error conditions with suggested codes/strings:

       ERR_PARSE          - malformed SEP or encoding
       ERR_DIGEST_MISMATCH- recomputed digest != manifest
       ERR_SIG_INVALID    - signature or chain invalid
       ERR_TIME_INVALID   - unauthenticated or non-monotonic time
       ERR_PROOF_INVALID  - proof not verifiable on stated chain
       ERR_DOI_RESOLVE    - DOI metadata unavailable/inconsistent
       ERR_POLICY_DENIED  - access denied by policy

     Implementations SHOULD map these to transport-specific error
     responses.


  11.  Manageability and Telemetry

     Deployments SHOULD monitor:
       - Anchoring SLA (time to first chain inclusion).
       - Coverage (% artifacts with valid SEPs and DOIs).
       - Verification pass rate and dominant failure reasons.
       - Key health (expiration, revocation events).
       - Time-source health (NTS/stratum, Roughtime reachability).

     Daily or mission-rollup Merkle roots SHOULD be recorded and
     anchored, enabling compact audits.


  12.  Privacy Considerations

     SEPs record integrity metadata; payloads MAY be withheld.  Where
     privacy is required, field-level encryption SHOULD be used for
     sensitive manifest attributes while keeping digests and proofs
     public.  DOI records for sensitive artifacts SHOULD minimize
     personally identifiable information.  Policy URIs SHOULD reflect
     access constraints.


  13.  Security Considerations

     Key compromise:  Private keys used for COSE/CMS MUST be protected in
     HSMs or equivalent.  Short-lived device certificates and revocation
     (OCSP/CRL) are RECOMMENDED.  Compromised keys MUST NOT trigger data
     deletion; instead, append revocation facts and supersede with new
     signatures.

     Time attacks:  Producers MUST use authenticated time (NTS) and
     monotonic counters.  Multiple time sources are RECOMMENDED.  Large
     backward jumps MUST be flagged.

     Proof stability:  Anchoring to multiple independent chains
     (heterogeneous consensus) reduces correlation risk.  Re-anchoring of
     historical Merkle roots over time is RECOMMENDED for longevity.

     Replay/substitution:  Bind signatures to digests and policy context;
     DOIs provide stable identity to detect swaps.

     Supply chain:  Model and dataset supply chain attestations (e.g.,
     SBOM-like metadata, RATS evidence) are RECOMMENDED but out of scope
     to normatively specify here.

     Security considerations follow RFC 3552 guidance.


  14.  IANA Considerations

     IANA is requested to register the following media types:

     14.1  application/rsp-ep+json

       Type name:           application
       Subtype name:        rsp-ep+json
       Required parameters: none
       Optional parameters: charset (per RFC 6838)
       Encoding considerations:  binary; JSON (RFC 8259)
       Security considerations:  see Section 13
       Interoperability considerations:  none
       Published specification:  this document
       Applications that use this media type:  AI provenance systems
       Fragment identifier considerations:  per RFC 7303
       Additional information:
         Magic number(s):  n/a
         File extension(s):  .rsp.json
         Macintosh file type code(s):  n/a
       Person & email address to contact for further information:
         Lawrence John Reilly Jr. <lawrencejohnreilly@gmail.com>
       Intended usage:  COMMON
       Restrictions on usage:  none
       Author:  IETF
       Change controller:  IESG

     14.2  application/rsp-ep+cbor

       Type name:           application
       Subtype name:        rsp-ep+cbor
       Required parameters: none
       Optional parameters: none
       Encoding considerations:  binary; CBOR (RFC 8949)
       Security considerations:  see Section 13
       Interoperability considerations:  none
       Published specification:  this document
       Applications that use this media type:  AI provenance systems
       Fragment identifier considerations:  none
       Additional information:
         Magic number(s):  n/a
         File extension(s):  .rsp.cbor
         Macintosh file type code(s):  n/a
       Person & email address to contact for further information:
         Lawrence John Reilly Jr. <lawrencejohnreilly@gmail.com>
       Intended usage:  COMMON
       Restrictions on usage:  none
       Author:  IETF
       Change controller:  IESG


  15.  Implementation Status

     A background report describing RSP's intent and design is archived at
     Zenodo (doi:10.5281/zenodo.17103522).  Reference implementations for
     SEP creation, anchoring integration, and verification are planned for
     public release.

  16.  References

  16.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, May 2017.

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", RFC 8259, December 2017.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express CBOR and JSON Data Structures", RFC 8610, June 2019.

     [RFC8785]  rfc-editor.org, "JSON Canonicalization Scheme (JCS)",
                RFC 8785, June 2020.

     [RFC8915]  Franke, D., "Network Time Security for the Network Time
                Protocol", RFC 8915, September 2020.

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949, December 2020.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", RFC 9052, August 2022.

     [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Algorithms", RFC 9053, August 2022.

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, July 2002.

  16.2.  Informative References

     [RSP]      Reilly, L. J., "Reilly Sentinel Protocol", Zenodo,
                doi:10.5281/zenodo.17103522.

     [REM]      Reilly, L. J., "Reilly EternaMark (REM) Protocol",
                Zenodo, doi:10.5281/zenodo.17129012.

     [RATS]     Birkholz, H., et al., "Remote Attestation Procedures
                Architecture", RFC 9334, November 2022.

     [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)",
                RFC 5652, September 2009.

     [SCITT]    IETF, "Supply Chain Integrity, Transparency, and Trust
                (SCITT) Working Group Charter", IETF Datatracker.

     [C2PA]     Coalition for Content Provenance and Authenticity, "C2PA
                Specification", 2023.

     [OTS]      OpenTimestamps community, "OpenTimestamps: Scalable
                Timestamping", online documentation.

     [DATACITE] DataCite Metadata Schema 4.x, DataCite.


  Appendix A.  CDDL for CBOR SEP

     sep = {
       version: tstr,
       artifact: {
         type: tstr
       },
       ? payloads: [* payload],
       digests: {
         sha256: tstr,        ; lowercase hex
         sha3_256: tstr,
         ? root: tstr
       },
       timestamps: {
         wallclock: tstr,     ; RFC3339
         ? monotonic: uint,
         ? source: tstr
       },
       ? authors: [* { name: tstr, ? id: tstr }],
       ? attestation: any,
       rem: {
         ots_proof_ref: tstr,
         doi: tstr,
         lineage: {
           ? parent: [* tstr],
           ? siblings: [* tstr],
           ? supersedes: [* tstr]
         }
       },
       ? class: any,
       ? policies: any,
       signatures: [* any]    ; COSE_Sign1 or CMS
     }

     payload = { cid: tstr, size: uint, ? mime: tstr, ? chunking: tstr }


  Appendix B.  Example JSON SEP

     {
       "version": "1.0",
       "artifact": {"type": "training.checkpoint"},
       "digests": {"sha256": "ab..", "sha3_256": "cd.."},
       "timestamps": {"wallclock": "2025-09-26T12:34:56Z", "source": "NTS"},
       "rem": {
         "ots_proof_ref": "urn:ots:btc:txid:...",
         "doi": "doi:10.rsp/abc123",
         "lineage": {"parent": ["doi:10.rsp/dataset456"]}
       },
       "signatures": [{"...": "COSE_Sign1 bytes (base64url)"}]
     }


  Appendix C.  Verification Report (JSON)

     {
       "doi": "doi:10.rsp/abc123",
       "hash_ok": true,
       "sig_ok": true,
       "attestation_ok": true,
       "ots_ok": true,
       "time_ok": true,
       "doi_ok": true,
       "verified_at": "2025-09-26T20:10:22Z"
     }


  Appendix D.  Example OpenTimestamps Receipt

     (Non-normative) An OTS receipt includes commitment operations and
     attestations that enable independent reconstruction of inclusion
     in a public chain.  See [OTS].


  Appendix E.  Example DOI Metadata Mapping

     title: "Model Checkpoint R1 (ResNet-50 finetune)"
     creators: [{"name": "Org Unit 7"}]
     created: "2025-09-26T12:34:56Z"
     fixity: {"sha256": "...", "sha3_256": "..."}
     lineage.parent: ["doi:10.rsp/dataset456"]
     policy_uri: "abac://policy/default/retention/75y"


  Acknowledgments

     The author thanks reviewers and implementers who provided feedback on
     RSP design and alignment with REM and SCITT efforts.


  Author's Address

     Lawrence John Reilly Jr.
     Independent Submission
     Email: lawrencejohnreilly@gmail.com


  Expires: 30 March 2026


name: draft-dunbar-onions-ac-te-applicability
rev: 00
title: Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case
time: 2025-10-03T19:24:52Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-06T19:24:52Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.841614+00:00
source: ietf
source_id: 149861
source_url: https://datatracker.ietf.org/doc/draft-dunbar-onions-ac-te-applicability/
doc_status: active
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: 6 April 2026                                      China Telecom
                                                                B. Wu, Ed.
                                                                    Huawei
                                                  L. CONTRERASMURILLO, Ed.
                                                               Telefornica
                                                                    C. Xie
                                                             China Telecom
                                                            3 October 2025


   Applying Attachmet Circuit and Traffic Engineering YANG Data Model to
                              Edge AI Use Case
                 draft-dunbar-onions-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 6 April 2026.



  Dunbar, et al.            Expires 6 April 2026                  [Page 1]


  Internet-Draft                 onions API                   October 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 . . . . . . . . . . . . . .   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 6 April 2026                  [Page 2]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                  [Page 3]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                  [Page 4]


  Internet-Draft                 onions API                   October 2025


  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 6 April 2026                  [Page 5]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                  [Page 6]


  Internet-Draft                 onions API                   October 2025


                              +---------------------+
                              |     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 6 April 2026                  [Page 7]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                  [Page 8]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                  [Page 9]


  Internet-Draft                 onions API                   October 2025


     {
       "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 6 April 2026                 [Page 10]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                 [Page 11]


  Internet-Draft                 onions API                   October 2025


     {
       "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 6 April 2026                 [Page 12]


  Internet-Draft                 onions API                   October 2025


  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 6 April 2026                 [Page 13]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                 [Page 14]


  Internet-Draft                 onions API                   October 2025


  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 6 April 2026                 [Page 15]


  Internet-Draft                 onions API                   October 2025


                             +-----------------------------+
                         |      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 6 April 2026                 [Page 16]


  Internet-Draft                 onions API                   October 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 6 April 2026                 [Page 17]


  Internet-Draft                 onions API                   October 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 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 6 April 2026                 [Page 18]


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

  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 6 April 2026                 [Page 19]


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

  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 6 April 2026                 [Page 20]


  Internet-Draft                 onions API                   October 2025


  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 6 April 2026                 [Page 21]


  Internet-Draft                 onions API                   October 2025


  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 6 April 2026                 [Page 22]


  Internet-Draft                 onions API                   October 2025


  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 6 April 2026                 [Page 23]


  Internet-Draft                 onions API                   October 2025


     [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 6 April 2026                 [Page 24]


  Internet-Draft                 onions API                   October 2025


     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 6 April 2026                 [Page 25]


name: draft-shi-moq-kvcache
rev: 01
title: KVCache over MoQT
time: 2025-10-11T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-12T06:52:40Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.847317+00:00
source: ietf
source_id: 143431
source_url: https://datatracker.ietf.org/doc/draft-shi-moq-kvcache/
doc_status: active
abstract:
  Large language model (LLM) inference involves two stages: prefill and
     decode.  The prefill phase processes the prompt in parallel,
     generating the KVCache, which is then used by the decode phase to
     produce tokens sequentially.  KVCache can be reused if the model and
     prompt is the same, reducing computing cost of the prefill.  However,
     its large size makes efficient transfer challenging.  Delivering
     these over architectures enabled by publish/subscribe transport like
     MoQT, allows local nodes to cache the KVCache to be later retrieved
     via new subscriptions, saving the bandwidth.  This document specifies
     the transmission of KVCache over MoQT.

full_text:
  Media Over QUIC                                                   H. Shi
  Internet-Draft                                       Huawei Technologies
  Intended status: Informational                                    S. Yue
  Expires: 12 October 2025                                    China Mobile
                                                             10 April 2025


                             KVCache over MoQT
                          draft-shi-moq-kvcache-01

  Abstract

     Large language model (LLM) inference involves two stages: prefill and
     decode.  The prefill phase processes the prompt in parallel,
     generating the KVCache, which is then used by the decode phase to
     produce tokens sequentially.  KVCache can be reused if the model and
     prompt is the same, reducing computing cost of the prefill.  However,
     its large size makes efficient transfer challenging.  Delivering
     these over architectures enabled by publish/subscribe transport like
     MoQT, allows local nodes to cache the KVCache to be later retrieved
     via new subscriptions, saving the bandwidth.  This document specifies
     the transmission of KVCache over MoQT.

  Discussion Venues

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

     Discussion of this document takes place on the Media Over QUIC
     mailing list (moq@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/moq/.

     Source for this draft and an issue tracker can be found at
     https://github.com/VMatrix1900/draft-moq-kvcache.

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



  Shi & Yue                Expires 12 October 2025                [Page 1]


  Internet-Draft                   KVCache                      April 2025


     This Internet-Draft will expire on 12 October 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: KVCache in LLM inference  . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  KVCache Data Model  . . . . . . . . . . . . . . . . . . . . .   4
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction: KVCache in LLM inference

     The inference process of large language models is typically divided
     into two distinct stages: prefill and decode.  The prefill phase
     processes the input prompt in parallel, generating a KVCache, which
     serves as an essential input for the decode phase.  The decode phase
     then utilizes the KVCache to generate output tokens sequentially, one
     at a time.  Prefill is a computationally intensive process, whereas
     decoding is constrained by memory bandwidth.  Due to their differing
     resource requirements, prefill and decode processes are often
     deployed on separate computing clusters using different hardware
     chips optimized for computational performance in prefill nodes and
     memory bandwidth efficiency in decode nodes, with KVCache transferred
     between them.









  Shi & Yue                Expires 12 October 2025                [Page 2]


  Internet-Draft                   KVCache                      April 2025


                    +--------------------+
                    |    Prompt Input    |
                    |  (System + User)   |
                    +--------------------+
                 Tokenization |
                     ---------------------
                     |                   |
                     v                   |
         +--------------------+          |
         |   Prefill Nodes    |          |
         | (Generate KVCache) |          |
         +--------------------+          |
                     |                   |
                     v                   |
         +--------------------+          |
         |      KVCache       |<---------+
         | (Stored & Reused)  |
         +--------------------+
                     |
           -----------------------------
           |              |            |
           v              v            v
     +----------------+       +----------------+
     |  Decode Node 1 |  ...  |  Decode Node N |
     | (Use KVCache)  |       | (Use KVCache)  |
     +----------------+       +----------------+

                        Figure 1: LLM inference process

     KVCache is significantly large, with a single token requiring 160KB
     for a 70B model(8bit quantization).  For a prompt of 1000 tokens, the
     KVCache size reaches 160MB.  To reduce the size of KVCache, various
     quantization and compression algorithm are proposed such as
     [CacheGen].  Furthermore, KVCache can be reused across sessions if
     derived from the same prompt and model, as shown in Figure 1.  The
     most basic reuse strategy is prefix caching, where KVCache is shared
     among prompts with a common prefix.  More advanced methods, such as
     [CacheBlend], improve reuse efficiency by selectively reusing KVCache
     beyond prefix matching.  To minimize transmission costs, a publish/
     subscribe architecture is required to distribute KVCache.  This
     document defines how to send KVCache over
     MoQT[I-D.ietf-moq-transport].









  Shi & Yue                Expires 12 October 2025                [Page 3]


  Internet-Draft                   KVCache                      April 2025


  2.  Conventions and Definitions

     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.

     This document uses the following terms:

     *  LLM: A large language model (LLM) that utilizes the attention
        mechanism to process and generate text efficiently by capturing
        long-range dependencies within input sequences.

     *  KVCache: A key-value cache storing intermediate representations
        used in LLM inference.

     *  Prompt: A prompt consists of two parts: the system prompt and the
        user prompt.  The system prompt is predefined by the LLM model
        developer to guide the model's behavior, while the user prompt is
        provided dynamically by the user to specify the task or request.

     *  Token: The smallest unit of processing in LLM inference, typically
        representing a word or subword.

  3.  KVCache Data Model

     The KVCache data model is structured as follows.

     *Naming*: The Track Namespace consisting of following tuples 
     (moq://kvcache.moq.arpa/v1/),(modelName), (prompt) is defined in
     this specification.  The track name identifies the compression level
     for the KVCache.  Thus, a track name can be identified with the tuple
     (<compression>) and the full track name having the following format
     (when represented as a string):

     moq://kvcache.moq.arpa/v1/<modelName>/<compression>

     Following compressions are defined in this specification, along with
     their size:











  Shi & Yue                Expires 12 October 2025                [Page 4]


  Internet-Draft                   KVCache                      April 2025


        +=============+=============================+=================+
        | Compression | Description                 | Size per Weight |
        +=============+=============================+=================+
        | FP16        | Quantized using FP16        | 2 bytes         |
        +-------------+-----------------------------+-----------------+
        | BF16        | Quantized using BF16        | 2 bytes         |
        +-------------+-----------------------------+-----------------+
        | FP8         | Quantized using FP8         | 1 byte          |
        +-------------+-----------------------------+-----------------+
        | Int8        | Quantized using Int8        | 1 byte          |
        +-------------+-----------------------------+-----------------+
        | FP4         | Quantized using FP4         | 0.5 byte        |
        +-------------+-----------------------------+-----------------+
        | Int4        | Quantized using Int4        | 0.5 byte        |
        +-------------+-----------------------------+-----------------+
        | AC (5x)     | Compressed using Arithmetic | Variable        |
        |             | Coding (5x ratio)           |                 |
        +-------------+-----------------------------+-----------------+

                        Table 1: Compression of KVCache

     *Group ID*: Normally the tokens are split into chunks of uniform
     length(typical value is 128).  The KVCache are organized into groups
     corresponding into token chunks.  The ID of the group represents the
     index of a token group within the KVCache.

     *Object ID*: An identifier for a specific token within a group.

     *Object Payload*: The content of the KVCache, which varies based on
     the compression algorithm used for storage and transmission.

  4.  Security Considerations

     TBD

  5.  IANA Considerations

     TBD

  6.  References

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




  Shi & Yue                Expires 12 October 2025                [Page 5]


  Internet-Draft                   KVCache                      April 2025


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

  6.2.  Informative References

     [CacheBlend]
                "CacheBlend: Fast Large Language Model Serving for RAG
                with Cached Knowledge Fusion", 2024,
                <https://arxiv.org/abs/2405.16444>.

     [CacheGen] "CacheGen: Fast Context Loading for Language Model
                Applications via KV Cache Streaming (SIGCOMM24)", 2024,
                <https://github.com/UChi-JCL/CacheGen>.

     [I-D.ietf-moq-transport]
                Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
                I. Swett, "Media over QUIC Transport", Work in Progress,
                Internet-Draft, draft-ietf-moq-transport-10, 3 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
                transport-10>.

  Authors' Addresses

     Hang Shi
     Huawei Technologies
     China
     Email: shihang9@huawei.com


     Shengnan Yue
     China Mobile
     China
     Email: yueshengnan@chinamobile.com

















  Shi & Yue                Expires 12 October 2025                [Page 6]


name: draft-song-rtgwg-din-usecases-requirements
rev: 01
title: Distributed Inference Network (DIN) Problem Statement, Use Cases, and Requirements
time: 2026-02-28T06:42:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T06:42:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.851509+00:00
source: ietf
source_id: 150276
source_url: https://datatracker.ietf.org/doc/draft-song-rtgwg-din-usecases-requirements/
doc_status: active
abstract:
  This document describes the problem statement, use cases, and
     requirements for a "Distributed Inference Network" (DIN) in the era
     of pervasive AI.  As AI inference services become widely deployed and
     accessed by billions of users, applications and devices, traditional
     centralized cloud-based inference architectures face challenges in
     scalability, latency, security, and efficiency.  DIN aims to address
     these challenges by leveraging distributed edge-cloud collaboration,
     intelligent scheduling, and enhanced network security to support low-
     latency, high-concurrency, and secure AI inference services.

full_text:
  rtgwg                                                            S. Jian
  Internet-Draft                                                  W. Cheng
  Intended status: Informational                              China Mobile
  Expires: 31 August 2026                                 27 February 2026


   Distributed Inference Network (DIN) Problem Statement, Use Cases, and
                                Requirements
               draft-song-rtgwg-din-usecases-requirements-01

  Abstract

     This document describes the problem statement, use cases, and
     requirements for a "Distributed Inference Network" (DIN) in the era
     of pervasive AI.  As AI inference services become widely deployed and
     accessed by billions of users, applications and devices, traditional
     centralized cloud-based inference architectures face challenges in
     scalability, latency, security, and efficiency.  DIN aims to address
     these challenges by leveraging distributed edge-cloud collaboration,
     intelligent scheduling, and enhanced network security to support low-
     latency, high-concurrency, and secure AI inference services.

  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



  Jian & Cheng             Expires 31 August 2026                 [Page 1]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Enterprise Secure Inference Services  . . . . . . . . . .   5
       4.2.  Edge-Cloud Collaborative Model Training . . . . . . . . .   5
       4.3.  Dynamic Model Selection and Coordination  . . . . . . . .   6
       4.4.  Adaptive Inference Resource Scheduling and
             Coordination  . . . . . . . . . . . . . . . . . . . . . .   6
       4.5.  Privacy-Preserving Split Inference  . . . . . . . . . . .   7
       4.6.  AI Agent Inference Services . . . . . . . . . . . . . . .   7
     5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  Scalability and Elasticity Requirements . . . . . . . . .   8
       5.2.  Performance and Determinism Requirements  . . . . . . . .   8
       5.3.  Security and Privacy Requirements . . . . . . . . . . . .   9
       5.4.  Identification and Scheduling Requirements  . . . . . . .   9
       5.5.  Management and Observability Requirements . . . . . . . .   9
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     AI inference is rapidly evolving into a fundamental service accessed
     by billions of users, applications, IoT devices, and AI agents.

     The rapid advancement and widespread adoption of large AI models are
     introducing significant changes to internet usage patterns and
     service requirements.  These changes present new challenges that
     existing network need to address to effectively support the growing
     demands of AI inference services.

     First, internet usage patterns are shifting from primarily content
     access to increasingly include AI model access.








  Jian & Cheng             Expires 31 August 2026                 [Page 2]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     Users and applications are interacting more frequently with AI
     models, generating distinct traffic patterns that differ from
     traditional web browsing or streaming.  This shift requires networks
     to better support model inference as an important service type
     alongside conventional content delivery.

     Second, the interaction modalities are diversifying from simple
     human-to-model conversations to include complex multi-modal
     interactions.

     As AI inference costs decrease dramatically, applications, IoT
     devices, and autonomous systems are increasingly integrating AI
     capabilities through API calls and embedded model access.  This
     expansion creates unprecedented demands for high-concurrency
     processing and predictable low-latency responses, as these systems
     often require real-time inference for critical functions including
     autonomous operations, industrial control, and interactive services.

     Third, AI inference workloads introduce distinct traffic
     characteristics that impact network design.

     Both north-south traffic between users and AI services, and east-west
     traffic among distributed AI components, are growing significantly.
     Moreover, the nature of AI inference communication, often organized
     around token generation and processing, introduces new considerations
     for traffic management, quality of service measurement, and resource
     optimization that complement traditional bit-oriented network
     metrics.

     In addition, AI agents are autonomous, goal-driven entities that can
     perceive their environment, make decisions, and execute actions.  AI
     agents communicate with each other and with models/tools, requiring
     not only inference but also coordination, state management, and
     dynamic discovery.  This further stresses the network infrastructure
     and is considered within the scope of this document.

     These developments collectively challenge current network
     infrastructures to adapt to the unique characteristics of AI
     inference workloads.  Centralized approaches face limitations in
     supporting the distributed, latency-sensitive, and concurrent nature
     of modern AI services, particularly in scenarios requiring real-time
     performance, data privacy, and reliable service delivery.

     This document outlines the problem statement, use cases, and
     functional requirements for a Distributed Inference Network (DIN) to
     enable scalable, efficient, and secure AI inference services that can
     address these emerging challenges.




  Jian & Cheng             Expires 31 August 2026                 [Page 3]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


  2.  Conventions and Definitions

     DIN:  Distributed Inference Network

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

     The proliferation of AI inference services has exposed fundamental
     limitations in traditional centralized AI inference architectures.

     Centralized inference deployments face severe scalability challenges
     when handling concurrent requests from the rapidly expanding
     ecosystem of users, applications, IoT devices, and AI agents.
     Service providers have experienced recurrent outages and performance
     degradation during peak loads, with concurrent inference requests
     projected to grow from millions to billions.  The fundamental
     constraint of concentrating computational resources in limited
     geographical locations creates inherent bottlenecks that lead to
     service disruptions and degraded user experience under massive
     concurrent access.

     While human-to-model conversations may tolerate moderate network
     latency, the emergence of diverse interaction patterns including
     application-to-model, device-to-model, and machine-to-model
     communications imposes stringent low-latency requirements that
     centralized architectures cannot meet.

     Applications including industrial robots, autonomous systems, and
     real-time control platforms require low-latency responses that are
     fundamentally constrained by the unavoidable geographical dispersion
     between end devices and centralized inference facilities.  This
     architectural limitation creates critical barriers for delay-
     sensitive operations across manufacturing, healthcare,
     transportation, and other domains where millisecond to sub-
     millisecond-level response times are essential.

     Enterprise and industrial AI inference scenarios present unique
     security and compliance requirements.  Centralized architectures
     introduce risks such as single points of failure (e.g., vulnerable to
     DDoS/APT attacks) and raise data sovereignty concerns when sensitive
     data must traverse long distances to centralized inference pools.
     Sectors including finance, healthcare, and public services often
     mandate localized processing to comply with regulations.  However,



  Jian & Cheng             Expires 31 August 2026                 [Page 4]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     distributed architectures also introduce their own security
     challenges: a larger attack surface, potential for model extraction
     or data leakage from intermediate nodes, and the need for trust among
     distributed components.  The Distributed Inference Network (DIN) aims
     to address these by providing mechanisms for secure, verifiable
     inference within a trusted perimeter while enabling the benefits of
     distribution.

     The rise of AI agents adds new dimensions: agents may be created,
     migrated, or terminated dynamically, requiring the network to support
     agent identity, discovery, and stateful communication across
     distributed nodes.  Current networks lack the necessary abstractions
     to handle agent-scale dynamics.

  4.  Use Cases

  4.1.  Enterprise Secure Inference Services

     Enterprises in regulated sectors such as finance, healthcare,
     industrial and public services require strict data governance while
     leveraging advanced AI capabilities.  In this use case, inference
     servers are deployed at enterprise headquarters or private cloud
     environments, with branch offices and field devices accessing these
     services through heterogeneous network paths including dedicated
     lines, VPNs, and public internet connections.

     The scenario encompasses various enterprise applications such as AIoT
     equipment inspection, intelligent manufacturing, and real-time
     monitoring systems that demand low-latency, high-reliability, and
     high-security inference services.  Different network paths should
     provide appropriate levels of cryptographic assurance and quality of
     service while accommodating varying bandwidth and latency
     characteristics across the enterprise network topology.

     The primary challenge involves maintaining data sovereignty and
     security across diverse network access scenarios while ensuring
     consistent low-latency performance for delay-sensitive industrial
     applications.

  4.2.  Edge-Cloud Collaborative Model Training

     Small and medium enterprises often need to dynamically procure
     additional AI inference capacity while facing capital constraints for
     full-scale inference infrastructure deployment.  This use case
     enables flexible resource allocation where businesses maintain core
     computational resources on-premises while dynamically procuring
     additional inference capacity from AI inference providers during
     demand peaks.



  Jian & Cheng             Expires 31 August 2026                 [Page 5]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     The hybrid deployment model allows sensitive data to remain within
     enterprise boundaries while leveraging elastic cloud resources for
     computationally intensive operations.  As enterprise business
     requirements fluctuate, the ability to seamlessly integrate local and
     cloud-based inference resources becomes crucial for maintaining
     service quality while controlling operational costs.

     The network should support efficient coordination between distributed
     computational nodes, ensuring stable performance during resource
     scaling operations and maintaining inference pipeline continuity
     despite variations in network conditions across different service
     providers.

  4.3.  Dynamic Model Selection and Coordination

     The transition from content access to model inference access
     necessitates intelligent model selection mechanisms that dynamically
     route requests to optimal computational resources.  This use case
     addresses scenarios where applications should automatically select
     between different model sizes, specialized accelerators, and
     geographic locations based on real-time factors including network
     conditions, computational requirements, accuracy needs, and cost
     considerations.

     The inference infrastructure should support real-time assessment of
     available resources, intelligent traffic steering based on
     application characteristics, and graceful degradation during resource
     constraints.

     Key requirements include maintaining service continuity during model
     switching, optimizing the balance between response time and inference
     quality, and ensuring consistent user experience across varying
     operational conditions.  This capability is particularly important
     for applications serving diverse user bases with fluctuating demand
     patterns and heterogeneous device capabilities.

  4.4.  Adaptive Inference Resource Scheduling and Coordination

     The evolution from content access to model inference necessitates
     intelligent resource coordination across different computational
     paradigms.  This use case addresses scenarios where inference
     workloads require adaptive resource allocation strategies to balance
     performance, cost, and efficiency across distributed environments.

     Large-small model collaboration represents a key approach for
     balancing inference accuracy and response latency.  In this pattern,
     large models handle complex reasoning tasks while small models
     provide efficient specialized processing, requiring the network to



  Jian & Cheng             Expires 31 August 2026                 [Page 6]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     deliver low-latency connectivity and dynamic traffic steering between
     distributed model instances.  The network should ensure efficient
     synchronization and coherent data exchange to maintain service
     quality across the collaborative ecosystem.

     Prefill-decode separation architecture provides an optimized
     framework for streaming inference tasks.  This pattern distributes
     computational stages across specialized nodes, with prefilling and
     decoding phases executing on optimized resources.  The network should
     provide high-bandwidth connections for intermediate data transfer and
     reliable transport mechanisms to maintain processing pipeline
     continuity, enabling scalable handling of concurrent sessions while
     meeting real-time latency requirements.

     The network infrastructure should support dynamic workload
     distribution, intelligent traffic steering, and efficient
     synchronization across distributed nodes.  This comprehensive
     approach ensures optimal user experience while maximizing resource
     utilization efficiency across the inference ecosystem.

  4.5.  Privacy-Preserving Split Inference

     For applications requiring strict data privacy compliance, model
     partitioning techniques enable sensitive computational layers to
     execute on-premises while utilizing cloud resources for non-sensitive
     operations.  This approach is particularly relevant for applications
     processing personal identifiable information, healthcare records,
     financial data, or proprietary business information subject to
     regulatory constraints.

     The network should support efficient transmission of intermediate
     computational results between edge and cloud with predictable
     performance characteristics to maintain inference pipeline
     continuity.  Challenges include maintaining inference quality despite
     network variations, managing computational dependencies across
     distributed nodes, and ensuring end-to-end security while maximizing
     resource utilization efficiency across the partitioned model
     architecture.

  4.6.  AI Agent Inference Services

     AI agents are autonomous software entities that combine AI inference
     with decision-making and inter-agent communication.  They can be
     deployed in various forms, including software agents running on user
     devices (e.g., smartphones, PCs), or embedded agents in IoT devices
     and robots.  These agents interact not only with each other in multi-
     agent systems, but also with various tools, APIs, existing
     applications, web services, and software through function calling or



  Jian & Cheng             Expires 31 August 2026                 [Page 7]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     other mechanisms.  Additionally, human-agent interaction remains
     essential, particularly when agents require human confirmation for
     critical decisions.  This diverse interaction landscape spans a wide
     range of applications, including personal scheduling, smart home
     automation, industrial process control, and real-time monitoring.

     Unlike human-AI conversations, which may tolerate moderate latency,
     the communication between agents and tools or between agents
     themselves often demands extremely low latency to ensure timely
     execution of tasks.  The network should therefore provide
     deterministic, low-latency connectivity for these machine-to-machine
     interactions, while also supporting dynamic agent discovery, seamless
     migration of agents across locations (e.g., from a mobile device to
     edge), and efficient coordination among distributed agents with
     reliable and secure interactions.  Furthermore, as agents may be
     ephemeral or long-lived, the network needs to handle rapid creation
     and termination of agent sessions without impacting ongoing services.

  5.  Requirements

  5.1.  Scalability and Elasticity Requirements

     Distributed Inference Network should support seamless scaling to
     accommodate billions of concurrent inference sessions while
     maintaining consistent performance levels.  The network should
     provide mechanisms for dynamic discovery and integration of new
     inference nodes, with automatic load distribution across available
     resources.  Elastic scaling should respond to diurnal patterns and
     sudden demand spikes without service disruption.

  5.2.  Performance and Determinism Requirements

     AI inference workloads require consistent and predictable network
     performance to ensure reliable service delivery.  The network should
     provide strict Service Level Agreement (SLA) guarantees for latency,
     jitter, and packet loss to support various distributed inference
     scenarios.  Bandwidth provisioning should accommodate bursty traffic
     patterns characteristic of model parameter exchanges and intermediate
     data synchronization, with performance isolation between different
     inference workloads.











  Jian & Cheng             Expires 31 August 2026                 [Page 8]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


  5.3.  Security and Privacy Requirements

     Comprehensive security mechanisms should protect AI models,
     parameters, and data throughout their transmission across network
     links.  Cryptographic protection should be applied at appropriate
     layers (e.g., network, transport, or application) depending on the
     deployment scenario, with key management and authentication
     integrated.  Privacy-preserving techniques should prevent leakage of
     sensitive information through intermediate representations while
     supporting efficient distributed inference.

  5.4.  Identification and Scheduling Requirements

     The network should support fine-grained identification of inference
     workloads to enable appropriate resource allocation and path
     selection.  Application-aware networking capabilities should allow
     inference requests to be steered to optimal endpoints based on
     current load, network conditions, and computational requirements.
     These identifiers, such as agent ID, workflow ID, or job ID, are
     typically defined by the application.  Similar to DNS maps URL to IP
     address, the network may need to map applicaiton layer name or id to
     network-layer addresses or labels, and to enable efficient resource
     routing and orchestration.  The network should also support agent
     registration, discovery, and stateful handover across distributed
     nodes.  Both centralized and distributed scheduling approaches should
     be supported to accommodate different deployment scenarios and
     organizational preferences.

  5.5.  Management and Observability Requirements

     The network should provide comprehensive telemetry for performance
     monitoring, fault detection, and capacity planning.  Metrics should
     include inference-specific measurements such as token latency,
     throughput, and computational efficiency in addition to traditional
     network performance indicators.  Management interfaces should support
     automated optimization and troubleshooting across the combined
     compute-network infrastructure.

  6.  Security Considerations

     This document highlights security as a fundamental requirement for
     DIN.  The distributed nature of inference workloads creates new
     attack vectors including model extraction, data reconstruction from
     intermediate outputs, and adversarial manipulation of inference
     results.  Security mechanisms should operate at multiple layers while
     maintaining the performance characteristics necessary for efficient
     inference.




  Jian & Cheng             Expires 31 August 2026                 [Page 9]


  Internet-Draft    DIN: Problem, Use Cases, Requirements    February 2026


     Compared to centralized architectures, distributed inference
     increases the attack surface but also enables localized processing
     that can reduce data exposure.  The DIN should provide mechanisms to
     establish trust among nodes, such as attestation and secure key
     distribution.

  7.  IANA Considerations

     This document has no IANA actions.

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

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

  Acknowledgments

     The authors would like to thank the contributors from China Mobile
     Research Institute for their valuable inputs and discussions.

  Authors' Addresses

     Song Jian
     China Mobile
     China
     Email: songjianyjy@chinamobile.com


     Weiqiang Cheng
     China Mobile
     China
     Email: chengweiqiang@chinamobile.com













  Jian & Cheng             Expires 31 August 2026                [Page 10]


name: draft-tan-ccamp-uonaco-problem-statement
rev: 02
time: 2026-03-02T09:48:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T09:48:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.856441+00:00
source: ietf
source_id: 150332
source_url: https://datatracker.ietf.org/doc/draft-tan-ccamp-uonaco-problem-statement/
doc_status: active
title:
  Unified Optical Networks and AI Computing Orchestration (UONACO) Problem Statement, Use Cases and Requirements

abstract:
  Distributed artificial intelligence (AI) computing is increasingly
     deployed across geographically dispersed AI data centers (AIDCs) to
     meet the scale and performance demands of modern AI workloads.  In
     such environments, the efficiency of distributed training, inference,
     and remote service access depends critically on tight coordination
     between optical transport networks and compute orchestration systems.
     However, today's infrastructure operates with isolated control
     planes: optical networks lack awareness of dynamic compute
     requirements, while compute schedulers have no visibility into real-
     time network conditions such as latency, bandwidth, or congestion.
     This decoupling leads to suboptimal resource utilization, degraded
     job performance, and inefficient scaling.

     This document presents the problem statement, outlines three
     representative use cases—distributed AI training, distributed AI
     inference, and remote AI service access—and specifies the
     requirements for Unified Optical Networks and AI Computing
     Orchestration (UONACO).  The goal is to enable bidirectional
     awareness, joint resource abstraction, and synchronized control
     across the compute-optical boundary, thereby supporting intent-
     driven, end-to-end provisioning of AI services over wide-area optical
     infrastructures.

full_text:
  ccamp                                                        Y. Tan, Ed.
  Internet-Draft                                                  Y. Zheng
  Intended status: Informational                              China Unicom
  Expires: 3 September 2026                                     Q. Hu, Ed.
                                                                    Z. Han
                                                                   W. Wang
                                                                  J. Zhang
                                                                   Y. Zhao
                        Beijing University of Posts and Telecommunications
                                                              2 March 2026


  Unified Optical Networks and AI Computing Orchestration (UONACO) Problem
                   Statement, Use Cases and Requirements
                draft-tan-ccamp-uonaco-problem-statement-02

  Abstract

     Distributed artificial intelligence (AI) computing is increasingly
     deployed across geographically dispersed AI data centers (AIDCs) to
     meet the scale and performance demands of modern AI workloads.  In
     such environments, the efficiency of distributed training, inference,
     and remote service access depends critically on tight coordination
     between optical transport networks and compute orchestration systems.
     However, today's infrastructure operates with isolated control
     planes: optical networks lack awareness of dynamic compute
     requirements, while compute schedulers have no visibility into real-
     time network conditions such as latency, bandwidth, or congestion.
     This decoupling leads to suboptimal resource utilization, degraded
     job performance, and inefficient scaling.

     This document presents the problem statement, outlines three
     representative use cases—distributed AI training, distributed AI
     inference, and remote AI service access—and specifies the
     requirements for Unified Optical Networks and AI Computing
     Orchestration (UONACO).  The goal is to enable bidirectional
     awareness, joint resource abstraction, and synchronized control
     across the compute-optical boundary, thereby supporting intent-
     driven, end-to-end provisioning of AI services over wide-area optical
     infrastructures.

  Status of This Memo

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






  Tan, et al.             Expires 3 September 2026                [Page 1]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     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
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Isolated Control and Management . . . . . . . . . . . . .   4
       2.2.  Independent Resource Efficiency Evaluation  . . . . . . .   5
       2.3.  Limitations of Existing Computing-Aware Frameworks  . . .   5
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Distributed AI Training . . . . . . . . . . . . . . . . .   6
       3.2.  Distributed AI Inference  . . . . . . . . . . . . . . . .   6
       3.3.  Accessing Remote AI Service . . . . . . . . . . . . . . .   7
     4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Integrated Control and Management Architecture  . . . . .   7
       4.2.  Unified Abstraction of Computing and Network Resources  .   8
       4.3.  Joint Orchestration of Computing and Network Resources  .   8
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9



  Tan, et al.             Expires 3 September 2026                [Page 2]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


  1.  Introduction

     The rapid proliferation of large-scale AI applications, particularly
     those involving distributed training and inference across
     geographically dispersed AIDCs, has exposed a critical gap in today's
     infrastructure: the lack of coordination between optical transport
     networks and compute orchestration systems.  While optical networks
     provide the high-bandwidth, low-latency, and deterministic
     connectivity required for wide-area AI computing collaboration, their
     control planes remain largely agnostic to the dynamic, heterogeneous
     demands of AI workloads.  Conversely, compute schedulers operate
     without visibility into the underlying network's real-time state,
     such as path latency, available bandwidth, or congestion levels.

     This decoupling leads to suboptimal resource utilization, degraded
     job performance, and inefficient scaling of distributed AI jobs.  For
     instance, a training job may be scheduled across distant AIDCs with
     abundant GPU capacity but poor optical connectivity, resulting in
     prolonged synchronization phases and significant compute efficiency
     loss.  Similarly, inference services with strict latency requirements
     may be routed through paths that meet compute criteria but violate
     network service-level objectives.

     To address these challenges, UONACO enables bidirectional awareness,
     joint resource abstraction, and synchronized control across the
     compute-optical boundary.  This document describes sample usage
     scenarios that drive UONACO requirements and will help to identify
     candidate solution architectures and solutions.

  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.

  2.  Problem Statement













  Tan, et al.             Expires 3 September 2026                [Page 3]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     +------------------------------------------+
     |        AI Compute Service Request        |
     |    (e.g., Distributed Training Job)      |
     +--------------------+---------------------+
                          |
               +----------v----------+
               |                     |
               v                     v
     +------------------+   +---------------------+
     | Compute          |   | Transport Network   |
     | Scheduler        |   | Controller          |
     +------------------+   +---------------------+
               |                        |
               |                        |
               v                        v
     +------------------+            +-----------------+
     |     AIDC-A       |<--Low-BW-->|     AIDC-B      |
     | GPU: High        |(e.g., 100G)| GPU: High       |
     | Load: Low        |            | Load: Low       |
     +--------+---------+            +---------+-------+
             |                                |
             |                                |
             |    High-BW (e.g., 400G)        |
             +<------------------------------>+
             |                                |
             |                                |
             |    High-BW (e.g., 400G)        |
             +<------------------------------>+
             |                                |
     +--------v---------+                     |
     |     AIDC-C       |<--------------------+
     | GPU: Low         |
     | Load: High       |
     +------------------+

        Figure 1: Suboptimal Resource Allocation under Decoupled Control

  2.1.  Isolated Control and Management

     The primary challenge lies in the management and control isolation
     between the computing domain (e.g., AI training clusters, cloud
     pools) and the optical transport network.  This separation creates a
     "chasm" that prevents holistic resource optimization.

     The optical network control plane operates without awareness of the
     real-time characteristics and requirements of the compute jobs it
     carries.  It cannot perceive critical parameters such as the
     bandwidth intensity of a distributed training job, the strict latency



  Tan, et al.             Expires 3 September 2026                [Page 4]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     budget of an inference request, or the fluctuating resource demands
     of a compute job.  Consequently, it is unable to proactively
     establish, adjust, or tear down optical paths (e.g., OTN circuits,
     OXC switched paths) to optimally serve the compute workload, leading
     to suboptimal network configurations and underutilized bandwidth.

     Conversely, the compute orchestration layer (e.g., Kubernetes
     schedulers, AI job managers) makes resource allocation and job
     placement decisions based primarily on local compute and storage
     metrics (e.g., GPU availability, memory).  It lacks visibility into
     the underlying network's state, including path latency, available
     bandwidth, or congestion levels between candidate data centers.  This
     results in compute jobs being scheduled across locations with poor
     network connectivity, causing significant communication bottlenecks
     and degraded overall job performance (i.e., "compute efficiency
     loss").

     This bidirectional lack of awareness creates a fundamental mismatch,
     where neither domain can adapt to the needs of the other, severely
     limiting the potential of wide-area collaborative computing.

  2.2.  Independent Resource Efficiency Evaluation

     Compounding the control isolation is the absence of a unified
     framework for evaluating the joint efficiency of compute and network
     resources.  Today, network performance is evaluated using traditional
     metrics like bandwidth utilization, latency, and packet loss.
     Compute performance is assessed through metrics like FLOPS (Floating
     Point Operations Per Second), job completion time, and resource
     utilization (CPU/GPU/memory).  These evaluation systems operate in
     silos.  There is no standardized method to quantify the combined cost
     and benefit of a joint compute-and-network resource allocation
     decision.  For instance, as shown in Figure 1, it is difficult to
     answer whether allocating a more powerful but distant GPU (with
     higher network latency) is more efficient than a less powerful but
     local one for a specific AI job.  This lack of a common evaluation
     language prevents the development of truly optimal co-scheduling
     algorithms that balance compute power against network quality.

  2.3.  Limitations of Existing Computing-Aware Frameworks

     Existing frameworks, such as Computing-Aware Traffic Steering
     (CATS)[I-D.ietf-cats-framework]
     [I-D.ietf-cats-usecases-requirements], have initiated efforts to
     integrate computing metrics into network routing decisions.  However,
     these approaches are primarily designed for traffic steering at the
     network layer and fall short of the orchestration requirements for AI
     workloads over optical infrastructures.



  Tan, et al.             Expires 3 September 2026                [Page 5]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     Inability to provision optical links: CATS focus on selecting an
     optimal path among already existing and established network routes.
     They lack the capability to interact with the optical control plane
     to provision new physical or logical links (e.g., establishing new
     OTN circuits, ODUk containers, or OXC switched paths) on demand.  For
     AI workloads requiring massive, dedicated bandwidth, simply steering
     traffic over existing shared pipes is often insufficient.

     Inability to reserve/release compute resource: Current frameworks are
     generally limited to scheduling service requests to compute resources
     that are already available.  They do not support the full lifecycle
     orchestration of computing resources, such as the explicit
     reservation, locking, and subsequent release of high-performance
     resources (like GPU clusters).  AI training jobs, in particular,
     require guaranteed resource availability for extended periods,
     necessitating a framework that can manage compute occupancy rather
     than just performing best-effort steering to available nodes.

  3.  Use Cases

     The growing scale and distribution of artificial intelligence
     workloads have created new demands on wide-area optical
     infrastructure, particularly in scenarios that span multiple
     artificial intelligence data centers (AIDCs).  Three representative
     use cases illustrate the need for tighter integration between optical
     transport networks and compute orchestration systems.

  3.1.  Distributed AI Training

     In distributed AI training, large models are increasingly trained
     across geographically separated AIDCs due to physical and operational
     constraints within any single site.  This requires frequent
     synchronization of model parameters over long-haul optical links,
     where performance is highly sensitive to network latency, bandwidth
     availability, and packet loss.  Without awareness of the underlying
     compute job characteristics, optical networks cannot provision
     connections that match the dynamic communication patterns of training
     iterations, leading to significant inefficiencies in GPU utilization
     and extended training times.

  3.2.  Distributed AI Inference

     Distributed AI inference presents a complementary challenge, where
     workloads exhibit diverse service-level requirements ranging from
     strict latency bounds for interactive applications to high-throughput
     processing for batch analytics.  To meet these varied objectives,
     inference jobs are often deployed across a hierarchical compute
     fabric that includes cloud, regional, and edge AIDCs.  Effective



  Tan, et al.             Expires 3 September 2026                [Page 6]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     placement of these jobs depends not only on local compute capacity
     but also on the quality of optical connectivity to the user or
     upstream service.  However, current inference orchestrators lack
     visibility into optical path conditions such as available bandwidth
     or propagation delay, while optical networks remain oblivious to the
     latency and throughput expectations of the inference jobs they carry.
     This disconnect can result in suboptimal job placement and violations
     of service-level agreements, highlighting the need for bidirectional
     signaling between compute and network control planes.

  3.3.  Accessing Remote AI Service

     The third use case, accessing remote AI inference services reflects
     the growing trend of enterprises and end users consuming AI
     capabilities on demand via APIs.  In this scenario, users request
     access to remote inference or training resources through high-level
     APIs, expecting predictable performance and reliability.  Traditional
     best-effort Internet transport is inadequate for such services, which
     instead require deterministic, isolated, and dynamically adjustable
     optical channels.  Fulfilling these requests demands an integrated
     control framework capable of jointly evaluating compute availability
     and optical path feasibility, then orchestrating end-to-end resource
     allocation across both domains.  This scenario underscores the need
     for standardized protocols that can carry both compute intent and
     network constraints, enabling automated, intent-driven provisioning
     of cross-domain AI services.

  4.  Requirements


  4.1.  Integrated Control and Management Architecture

     A new, integrated control architecture is required to break down the
     management silos.  This architecture must facilitate bidirectional
     fusion between the compute and network control planes.

     It should allow the optical network to dynamically create, adjust,
     and tear down connections (e.g., leveraging OXC, ODUk, and fgOTN
     flexible scheduling mechanisms) based on explicit instructions or
     implicit signals derived from compute job requirements.  Conversely,
     it should enable the compute orchestration system to perform resource
     planning and online tuning based on the real-time quality and state
     of the underlying optical network.  The goal is to compress the
     response time for provisioning a compute-and-network service (e.g.,
     "dynamic compute entry") from the current hour-level down to the
     minute-level.





  Tan, et al.             Expires 3 September 2026                [Page 7]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


  4.2.  Unified Abstraction of Computing and Network Resources

     A common language is needed for both domains to understand each
     other's capabilities and state.  This requires a unified resource
     abstraction model.

     The optical network's heterogeneous resources (e.g., at the OTN,
     optical, and Ethernet layers; or physical ports, spectrum, time
     slots) must be abstracted into a model that can be understood by the
     compute orchestrator.  This model should expose key attributes like
     available bandwidth, latency, and reliability.

     Similarly, heterogeneous compute resources (CPU, GPU, memory,
     storage) must be abstracted into a model that conveys their real-time
     capabilities (e.g., FLOPS, available memory/VRAM) and state to the
     network controller.  This unified abstraction is the foundation for
     any joint decision-making process.

  4.3.  Joint Orchestration of Computing and Network Resources

     Building on the integrated architecture and unified abstraction, a
     joint orchestration mechanism is required to make intelligent, end-
     to-end resource allocation decisions.  This mechanism should include
     compute-aware optical network dynamic adjustment algorithms that can
     perform application-driven optical path reconfiguration and adaptive
     bandwidth allocation.  It should also include network-aware compute
     joint orchestration algorithms that can perform dynamic compute
     resource optimization and contention-aware job scheduling.

     The orchestration should be driven by a unified evaluation system
     that can assess the joint efficiency of a scheduling decision by
     considering both compute performance metrics (e.g., job completion
     time) and network performance metrics (e.g., bandwidth cost, latency)
     in a single, cohesive framework.

  5.  IANA Considerations

     TBD

  6.  Security Considerations

     TBD

  7.  References

  7.1.  Normative References





  Tan, et al.             Expires 3 September 2026                [Page 8]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  7.2.  Informative References

     [I-D.ietf-cats-framework]
                Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
                Drake, "A Framework for Computing-Aware Traffic Steering
                (CATS)", Work in Progress, Internet-Draft, draft-ietf-
                cats-framework-16, 16 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cats-
                framework-16>.

     [I-D.ietf-cats-usecases-requirements]
                Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
                "Computing-Aware Traffic Steering (CATS) Problem
                Statement, Use Cases, and Requirements", Work in Progress,
                Internet-Draft, draft-ietf-cats-usecases-requirements-08,
                12 October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-cats-usecases-requirements-08>.

  Authors' Addresses

     Yanxia Tan (editor)
     China Unicom
     Email: tanyx11@chinaunicom.cn


     Yanlei Zheng
     China Unicom
     Email: zhengyanlei@chinaunicom.cn


     Qiaojun Hu (editor)
     Beijing University of Posts and Telecommunications
     Email: qiaoj475@bupt.edu.cn


     Zheng Han
     Beijing University of Posts and Telecommunications
     Email: 2025010255@bupt.cn




  Tan, et al.             Expires 3 September 2026                [Page 9]


  Internet-Draft  UONACO: Problem, Use Cases, Requirements      March 2026


     Wei Wang
     Beijing University of Posts and Telecommunications
     Email: weiw@bupt.edu.cn


     Jie Zhang
     Beijing University of Posts and Telecommunications
     Email: jie.zhang@bupt.edu.cn


     Yongli Zhao
     Beijing University of Posts and Telecommunications
     Email: yonglizhao@bupt.edu.cn






































  Tan, et al.             Expires 3 September 2026               [Page 10]


name: draft-ramadan-mboned-sonar
rev: 01
title: SONAR: Statistical Observation Network for Attestation and Reach
time: 2025-11-04T21:40:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-08T21:40:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.861301+00:00
source: ietf
source_id: 151152
source_url: https://datatracker.ietf.org/doc/draft-ramadan-mboned-sonar/
doc_status: active
abstract:
  This document specifies SONAR (Statistical Observation Network for
     Attestation and Reach), a protocol for verifiable multicast delivery
     claims without trusted intermediaries.  SONAR combines: (1) O(1) IP
     multicast efficiency versus O(N) unicast to detect cheating, (2)
     cryptoeconomic accountability via on-chain stake deposits, VRF-based
     unpredictable sampling, and blockchain attestations, and (3) ALTA-
     based real-time multicast authentication.  SONAR separates content
     authentication from coverage verification: ALTA authenticates all
     packets with ~6% bandwidth overhead, while statistical coverage
     verification adds minimal overhead (320 KB challenge messages per
     15-60 minute test period, 0.7-2.8 Kbps).  Coverage estimation samples
     0.1% of receivers using German Tank Problem inference.  For privacy
     and cost efficiency at scale, zkSNARK proof aggregation (recommended
     for >1,000 sampled users) maintains O(1) on-chain verification cost,
     enabling populations exceeding 10^8 receivers.

full_text:
  mboned                                                        O. Ramadan
  Internet-Draft                                             Blockcast Inc
  Intended status: Informational                           2 November 2025
  Expires: 6 May 2026


      SONAR: Statistical Observation Network for Attestation and Reach
                       draft-ramadan-mboned-sonar-01

  Abstract

     This document specifies SONAR (Statistical Observation Network for
     Attestation and Reach), a protocol for verifiable multicast delivery
     claims without trusted intermediaries.  SONAR combines: (1) O(1) IP
     multicast efficiency versus O(N) unicast to detect cheating, (2)
     cryptoeconomic accountability via on-chain stake deposits, VRF-based
     unpredictable sampling, and blockchain attestations, and (3) ALTA-
     based real-time multicast authentication.  SONAR separates content
     authentication from coverage verification: ALTA authenticates all
     packets with ~6% bandwidth overhead, while statistical coverage
     verification adds minimal overhead (320 KB challenge messages per
     15-60 minute test period, 0.7-2.8 Kbps).  Coverage estimation samples
     0.1% of receivers using German Tank Problem inference.  For privacy
     and cost efficiency at scale, zkSNARK proof aggregation (recommended
     for >1,000 sampled users) maintains O(1) on-chain verification cost,
     enabling populations exceeding 10^8 receivers.

  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 6 May 2026.

  Copyright Notice

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



  Ramadan                    Expires 6 May 2026                   [Page 1]


  Internet-Draft                    SONAR                    November 2025


     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 Notation . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Protocol Layers . . . . . . . . . . . . . . . . . . . . .   4
         3.2.1.  Layer 1: Content Authentication . . . . . . . . . . .   4
         3.2.2.  Layer 2: Statistical Coverage Verification  . . . . .   5
         3.2.3.  Layer 3: Zero-Knowledge Aggregation (Recommended for m
                 > 1,000)  . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Content Authentication  . . . . . . . . . . . . . . . . . . .   6
       4.1.  ALTA Protocol Configuration . . . . . . . . . . . . . . .   6
       4.2.  Packet Format . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Verification Procedure  . . . . . . . . . . . . . . . . .   8
     5.  Statistical Coverage Verification . . . . . . . . . . . . . .   8
       5.1.  Sample Selection Protocol . . . . . . . . . . . . . . . .   8
         5.1.1.  VRF-Based Random Selection  . . . . . . . . . . . . .   9
         5.1.2.  Challenge Message Format  . . . . . . . . . . . . . .   9
       5.2.  User Attestation Protocol . . . . . . . . . . . . . . . .  11
         5.2.1.  Attestation Message Format  . . . . . . . . . . . . .  11
         5.2.2.  Submission Methods  . . . . . . . . . . . . . . . . .  12
       5.3.  Coverage Estimation . . . . . . . . . . . . . . . . . . .  13
         5.3.1.  German Tank Problem Estimator . . . . . . . . . . . .  13
         5.3.2.  Confidence Intervals  . . . . . . . . . . . . . . . .  13
     6.  Zero-Knowledge Proof Aggregation  . . . . . . . . . . . . . .  14
       6.1.  Merkle Tree Construction  . . . . . . . . . . . . . . . .  14
       6.2.  zkSNARK Proof Generation  . . . . . . . . . . . . . . . .  15
       6.3.  On-Chain Verification . . . . . . . . . . . . . . . . . .  15
       6.4.  Challenge Protocol  . . . . . . . . . . . . . . . . . . .  15
     7.  Test Period Optimization  . . . . . . . . . . . . . . . . . .  16
       7.1.  Unicast Replication Detection . . . . . . . . . . . . . .  16
       7.2.  Recommended Test Periods  . . . . . . . . . . . . . . . .  16
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
       8.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  17
       8.2.  Economic Security . . . . . . . . . . . . . . . . . . . .  18
       8.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  18
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19



  Ramadan                    Expires 6 May 2026                   [Page 2]


  Internet-Draft                    SONAR                    November 2025


     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
       10.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Appendix A.  Example Deployment . . . . . . . . . . . . . . . . .  20
       A.1.  NYC Television Station Scenario . . . . . . . . . . . . .  20
         A.1.1.  Network Configuration . . . . . . . . . . . . . . . .  20
         A.1.2.  SONAR Configuration . . . . . . . . . . . . . . . . .  20
         A.1.3.  Cost-Benefit Analysis . . . . . . . . . . . . . . . .  21
         A.1.4.  Performance Metrics . . . . . . . . . . . . . . . . .  22
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     Multicast distribution offers significant efficiency advantages over
     unicast for large-scale content delivery, reducing bandwidth costs by
     99.99% or more.  However, the lack of verifiable delivery mechanisms
     prevents widespread commercial adoption.  Content providers cannot
     verify that infrastructure operators actually delivered content to
     claimed receivers, while infrastructure operators cannot prove
     delivery to enable billing.  This bilateral trust deficit blocks the
     formation of liquid markets for multicast capacity.

     Existing multicast authentication schemes ([RFC4082],
     [I-D.ietf-mboned-ambi], [I-D.krose-mboned-alta]) address content
     authentication but do not provide per-receiver coverage proof.  Per-
     receiver encryption defeats multicast efficiency by requiring O(N)
     bandwidth where N is the number of receivers.

     SONAR solves this problem through statistical sampling: rather than
     proving delivery to every receiver, SONAR proves delivery to a random
     sample with known statistical confidence.  This enables verification
     of populations exceeding 10^7 receivers with constant bandwidth
     overhead.

  1.1.  Requirements Notation

     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:

     Coverage Group:  A set of receivers that can be addressed with a



  Ramadan                    Expires 6 May 2026                   [Page 3]


  Internet-Draft                    SONAR                    November 2025


        single multicast transmission, typically defined by geographic
        location or network topology.

     Attestation:  A cryptographically signed statement by a receiver
        asserting successful reception of specific content with packet
        statistics.

     Sample Size:  The number of receivers randomly selected to provide
        attestations in a given test window.  Denoted as m.

     Population Size:  The total number of receivers in the coverage
        group.  Denoted as N.

     German Tank Estimate:  A statistical estimator for population size
        based on maximum observation in a sampled sequence.

     Test Window:  A time period during which packet reception is tracked
        for coverage verification.  Duration denoted as P.

     zkSNARK:  Zero-Knowledge Succinct Non-Interactive Argument of
        Knowledge.  A cryptographic proof system enabling verification of
        aggregate statements with constant-size proofs.

  3.  Architecture Overview

  3.1.  Design Principles

     SONAR is designed around the following principles:

     *  Content authentication is independent of coverage verification

     *  Statistical sampling provides O(1) verification cost regardless of
        population size

     *  Broadcast bandwidth overhead MUST be <10% to preserve multicast
        efficiency

     *  Return path (user attestations) uses existing internet
        infrastructure

     *  Cryptographic security complemented by economic incentives

  3.2.  Protocol Layers

  3.2.1.  Layer 1: Content Authentication

     All receivers verify content authenticity using ALTA protocol
     [I-D.krose-mboned-alta].  This provides:



  Ramadan                    Expires 6 May 2026                   [Page 4]


  Internet-Draft                    SONAR                    November 2025


     *  Non-repudiation: Content provider cannot deny transmission

     *  Source authentication: Receivers verify authorized origin

     *  Integrity: Content not modified in transit

     *  Low latency: 1-10ms authentication delay

     ALTA is chosen over alternatives (TESLA, AMBI) because:

     *  No time synchronization required (vs TESLA)

     *  Real-time authentication (vs TESLA 100-6000ms delay)

     *  Broadcast-only (vs AMBI unicast manifests)

     *  Strong non-repudiation (periodic Ed25519 signatures)

     Bandwidth overhead: Approximately 6% for typical configurations.

  3.2.2.  Layer 2: Statistical Coverage Verification

     Random sample of m receivers (typically 0.1% of population) provide
     attestations via internet return path.  Statistical inference
     provides population coverage estimate with confidence interval.

     Sample selection uses Verifiable Random Function (VRF) to prevent
     adversarial selection.  Attestations include packet statistics
     enabling loss rate estimation and fraud detection.

     Broadcast overhead: Only sample selection message (320 KB per test).

     Return path overhead: Distributed across m users (128 bps per
     selected user).

  3.2.3.  Layer 3: Zero-Knowledge Aggregation (Recommended for m > 1,000)

     zkSNARK proofs SHOULD be employed when sample size m exceeds 1,000
     users, primarily for privacy protection.  Individual viewing patterns
     become correlatable on-chain, enabling de-anonymization attacks.
     zkSNARKs provide aggregated proof of coverage statistics while hiding
     individual user attestations.

     Additional benefits: 80-90% cost reduction via off-chain storage,
     constant-size verification (328 bytes regardless of m), and
     scalability to populations exceeding 10^8.





  Ramadan                    Expires 6 May 2026                   [Page 5]


  Internet-Draft                    SONAR                    November 2025


     Challenge protocol enables spot-checking of individual attestations
     via Merkle proof while maintaining aggregate privacy.

  4.  Content Authentication

  4.1.  ALTA Protocol Configuration

     SONAR employs ALTA with the following parameters:

     Scheme Parameters:
        *  a = 3 (backward reference interval)

        *  p = 5 (redundancy factor)

        *  K = 50 (signature interval)

     Algorithms:
        *  MAC: HMAC-SHA256 truncated to 128 bits

        *  Signature: Ed25519 (64 bytes)

  4.2.  Packet Format

     Each multicast packet MUST include ALTA authentication data:



























  Ramadan                    Expires 6 May 2026                   [Page 6]


  Internet-Draft                    SONAR                    November 2025


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Sequence Number (32 bits)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S| Reserved  |  MAC Count    |                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     +                   Previous Packet Hash (256 bits)            +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   MAC 1 (128 bits)                           +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   MAC 2 (128 bits)                           +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   ... (additional MACs)                       ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                   Ed25519 Signature (512 bits)                |
     +                   (present if S=1, every Kth packet)          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                   Content Payload                             ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Sequence Number:  Monotonically increasing packet identifier

     S (Signature Present):  1-bit flag indicating Ed25519 signature
        included

     Reserved:  7 bits reserved for future use, MUST be zero

     MAC Count:  Number of MACs included (typically 3-5)

     Previous Packet Hash:  SHA-256 hash of previous packet for chain
        verification




  Ramadan                    Expires 6 May 2026                   [Page 7]


  Internet-Draft                    SONAR                    November 2025


     MAC n:  HMAC-SHA256 of packet at offset (i - n*a) truncated to 128
        bits

     Ed25519 Signature:  Signature of packets i through i-K+1 (when S=1,
        every Kth packet)

     Content Payload:  Application data

     Total overhead calculation:

     *  Base: 4 + 32 = 36 bytes

     *  MACs: 16 * MAC_Count bytes

     *  Signature (amortized): 64 / K bytes

     *  For MAC_Count=4, K=50: 36 + 64 + 1.28 = 101.28 bytes

     *  Percentage for 1500-byte packets: 6.75%

  4.3.  Verification Procedure

     Upon receiving packet i, receiver performs the following steps:

     1.  Verify sequence number is monotonically increasing

     2.  Compute SHA-256(packet_{i-1}) and compare with Previous Packet
         Hash field

     3.  For each MAC_j in packet, retrieve stored packet at offset (i -
         j*a)

     4.  Recompute HMAC-SHA256 for each referenced packet and compare

     5.  If S=1, verify Ed25519 signature over packets [i-K+1, i]

     6.  If all verifications pass, accept packet as authentic

     Receiver MUST buffer packets until sufficient MACs received for
     verification (depth = p packets).

  5.  Statistical Coverage Verification

  5.1.  Sample Selection Protocol







  Ramadan                    Expires 6 May 2026                   [Page 8]


  Internet-Draft                    SONAR                    November 2025


  5.1.1.  VRF-Based Random Selection

     Content provider generates verifiable random sample using VRF to
     prevent adversarial selection:

     1.  Obtain blockchain randomness source (e.g., block hash at height
         H)

     2.  Apply VRF with content provider private key: seed = VRF_prove(sk,
         blockhash || session_id)

     3.  Use seed for Fisher-Yates shuffle of registered user public keys

     4.  Select first m users from shuffled list

     VRF properties ensure:

     *  Unpredictability: Adversary cannot predict selection before
        blockhash revealed

     *  Verifiability: Anyone can verify selection was computed correctly

     *  Uniqueness: Only one valid output for given input

  5.1.2.  Challenge Message Format


























  Ramadan                    Expires 6 May 2026                   [Page 9]


  Internet-Draft                    SONAR                    November 2025


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Message Type = 0x01         |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Session ID (64 bits)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Test Window Start (32 bits)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Test Window End (32 bits)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Number of Selected Users (32 bits)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   VRF Proof (80 bytes)                        +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~      Selected User Public Keys (32 bytes each, m total)      ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                   Ed25519 Signature (512 bits)                |
     +                   (signs entire message)                     +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Size calculation for m=10,000 users:

     *  Header: 24 bytes

     *  VRF Proof: 80 bytes

     *  User pubkeys: 32 * 10,000 = 320,000 bytes

     *  Signature: 64 bytes

     *  Total: 320,168 bytes ≈ 320 KB

     Broadcast frequency: Once per test period P (recommended: P =
     900-7200 seconds)

     Bandwidth: 320 KB / P seconds

     *  P = 900s (15 min): 356 bytes/s = 2.8 Kbps



  Ramadan                    Expires 6 May 2026                  [Page 10]


  Internet-Draft                    SONAR                    November 2025


     *  P = 3600s (1 hour): 89 bytes/s = 0.7 Kbps

  5.2.  User Attestation Protocol

  5.2.1.  Attestation Message Format

     Selected users MUST respond within response window T_response
     (recommended: 60 seconds):

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Message Type = 0x02         |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   User Public Key (256 bits)                 +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Session ID (64 bits)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Packet Min Observed (32 bits)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Packet Max Observed (32 bits)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Packets Received (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   Sample Content Hash (256 bits)             +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Response Timesonar (64 bits)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                   Ed25519 Signature (512 bits)                |
     +                   (signs entire message)                     +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Packet Min/Max Observed:  First and last sequence numbers received in
        test window

     Packets Received:  Total count of packets successfully received and
        authenticated

     Sample Content Hash:  SHA-256 hash of concatenated payload from



  Ramadan                    Expires 6 May 2026                  [Page 11]


  Internet-Draft                    SONAR                    November 2025


        sampled packets (e.g., every 100th packet) to prove actual content
        reception

     Response Timesonar:  Unix timesonar when attestation created

     Total size: 160 bytes per attestation

  5.2.2.  Submission Methods

  5.2.2.1.  Direct Blockchain Submission

     Each selected user submits attestation as blockchain transaction:

     *  Attestation payload: 160 bytes

     *  Transaction overhead: ~40 bytes

     *  Total: ~200 bytes per user

     *  For m=10,000: 2 MB per test

     *  Cost at $0.0001/tx: $1.00 per test

     Advantages: Simple, immediate verification

     Disadvantages: High on-chain cost for large m

  5.2.2.2.  Aggregated Submission via zkSNARK

     Users submit to off-chain aggregator that creates zkSNARK proof:

     1.  Users submit 160-byte attestations to off-chain storage

     2.  Aggregator collects m attestations

     3.  Aggregator builds Merkle tree with root R

     4.  Aggregator computes aggregate statistics

     5.  Aggregator generates zkSNARK proof π

     6.  Aggregator submits {R, statistics, π} on-chain

     On-chain size: 328 bytes (constant regardless of m)

     Cost reduction: 99.998% vs direct submission for m=10,000





  Ramadan                    Expires 6 May 2026                  [Page 12]


  Internet-Draft                    SONAR                    November 2025


  5.3.  Coverage Estimation

  5.3.1.  German Tank Problem Estimator

     Given sender transmitted N packets and user j reports packet_max_j,
     population size estimate:

     N_hat = max(packet_max_1, ..., packet_max_m)
             + max(...) / m - 1

     Loss rate estimate for user j:

     span_j = packet_max_j - packet_min_j + 1
     loss_j = 1 - (packets_received_j / span_j)

     Aggregate loss rate:

     loss_avg = (1/m) * sum(loss_j for j in sample)

     If packet_max_j ≈ N, user kept pace with real-time stream (multicast
     reception).  If packet_max_j << N, user lagged significantly
     (potential unicast forwarding).

  5.3.2.  Confidence Intervals

     For sample size m from population N, coverage estimate has confidence
     interval:

     Standard error: SE = sqrt(p_hat * (1 - p_hat) / m)
     95% confidence: CI_95 = p_hat ± 1.96 * SE
     Population coverage: Coverage = N * p_hat
                          Coverage_CI = N * (p_hat ± 1.96 * SE)

     Example: N = 10,000,000 users, m = 10,000 sample, p_hat = 0.95:

     SE = sqrt(0.95 * 0.05 / 10000) = 0.00218
     CI_95 = 0.95 ± 0.00427 = [0.946, 0.954]
     Coverage = 9,500,000 ± 42,700 users

     Minimum sample size for desired margin of error E:

     m_min = (1.96^2 * p_hat * (1 - p_hat)) / E^2

     For E = 0.001 (0.1% margin) with p_hat = 0.95:

     m_min = (3.84 * 0.95 * 0.05) / 0.000001 = 18,240 samples





  Ramadan                    Expires 6 May 2026                  [Page 13]


  Internet-Draft                    SONAR                    November 2025


  6.  Zero-Knowledge Proof Aggregation

     Zero-knowledge proof aggregation via zkSNARKs SHOULD be employed when
     sample size m exceeds 1,000 users.  This threshold is determined by
     three factors:

     1.  Privacy Protection: Individual attestations become correlatable
         on-chain, enabling de-anonymization attacks.  For small
         communities (N < 100,000), users are more easily identifiable,
         making privacy protection critical.

     2.  Cost Efficiency: Off-chain storage via Data Anchor costs $0.00001
         per attestation versus $0.0001 for direct on-chain submission.
         For m=1,000, this represents 80-90% cost reduction: $0.02
         (zkSNARK aggregated) versus $0.10 (direct).

     3.  Constant Verification: zkSNARK proofs maintain 200-byte size and
         O(1) verification cost regardless of m, enabling scalability to
         populations exceeding 10^8.

     Implementation:

     *  User attestations sent to aggregator (off-chain)

     *  zkSNARK proof generated in Trusted Execution Environment (TEE)

     *  Proof verified on-chain via smart contract

     *  Challenge protocol enables spot-checking via Merkle proofs

  6.1.  Merkle Tree Construction

     Aggregator constructs binary Merkle tree from attestations:

     1.  Collect m attestations: A_1, A_2, ..., A_m

     2.  Compute leaf hashes: L_j = SHA256(A_j)

     3.  Build tree bottom-up: H_parent = SHA256(H_left || H_right)

     4.  Compute root: R

     Merkle proof for attestation A_j:

     *  Path: Sibling hashes from leaf to root

     *  Length: ceil(log2(m)) hashes




  Ramadan                    Expires 6 May 2026                  [Page 14]


  Internet-Draft                    SONAR                    November 2025


     *  For m=10,000: 14 hashes * 32 bytes = 448 bytes

  6.2.  zkSNARK Proof Generation

     Aggregator generates proof π for statement S:

     Statement S:
       "I know m attestations {A_1, ..., A_m} such that:
        1. MerkleRoot({SHA256(A_j)}) = R
        2. Each A_j contains valid Ed25519 signature
        3. Aggregate loss rate < threshold (e.g., 0.05)
        4. Median(packet_max) > threshold (e.g., 0.95 * N)"

     Public inputs: {R, m, aggregate_stats, thresholds}

     Witness: {A_1, ..., A_m, Merkle_paths, signatures}

     Proof size: Approximately 200 bytes (constant regardless of m)

  6.3.  On-Chain Verification

     Smart contract verifies zkSNARK proof:

     1.  Extract public inputs: {R, m, statistics, π}

     2.  Verify proof: valid = Verify(vk, public_inputs, π)

     3.  If valid: Accept coverage claim for m users

     4.  If invalid: Reject and slash aggregator stake

     Verification cost: ~100,000 gas (constant regardless of m)

  6.4.  Challenge Protocol

     Any party may challenge aggregator by requesting Merkle proof for
     specific user:

     1.  Challenger submits challenge: "Prove user_j is in tree R"

     2.  Aggregator MUST respond within T_challenge (recommended: 24
         hours)

     3.  Aggregator provides: {A_j, merkle_path}

     4.  Challenger verifies: MerkleVerify(A_j, path, R) and signature
         validity




  Ramadan                    Expires 6 May 2026                  [Page 15]


  Internet-Draft                    SONAR                    November 2025


     5.  If verification fails: Aggregator stake slashed, challenger
         rewarded

     6.  If verification succeeds: Challenge bond returned to challenger

  7.  Test Period Optimization

  7.1.  Unicast Replication Detection

     A malicious relay might receive content via unicast forwarding and
     claim multicast reception.  Detection relies on bandwidth
     constraints:

     For unicast replication to B recipients:

     Required bandwidth: B * R_content
     If B * R_content > R_relay, relay must lag
     Lag accumulates at rate: (B * R_content - R_relay)

     Minimum test period for detection:

     P_min = L / (alpha - 1)
     where alpha = (B * R_content) / R_relay
           L = acceptable loss rate

     Example: B=1M recipients, R_content=25 Mbps, R_relay=10 Gbps, L=0.05:

     alpha = (1,000,000 * 25) / 10,000 = 2,500
     P_min = 0.05 / (2,500 - 1) ≈ 0.00002 seconds

     Conclusion: For typical broadcast scenarios, any test period P > 1
     second provides overwhelming detection certainty.  Optimal P is
     determined by cost-benefit tradeoff, not detection requirements.

  7.2.  Recommended Test Periods

     Test period selection based on use case:














  Ramadan                    Expires 6 May 2026                  [Page 16]


  Internet-Draft                    SONAR                    November 2025


      +===========+===============+============+============+===========+
      | Use Case  | Test Period P | Tests/Hour | Cost/Hour* | Detection |
      |           |               |            |            | Latency   |
      +===========+===============+============+============+===========+
      | Live      | 300s (5 min)  | 12         | $12        | <5 min    |
      | Events    |               |            |            |           |
      +-----------+---------------+------------+------------+-----------+
      | Prime     | 900s (15 min) | 4          | $4         | <15 min   |
      | Time TV   |               |            |            |           |
      +-----------+---------------+------------+------------+-----------+
      | Off-Peak  | 3600s (1      | 1          | $1         | <1 hour   |
      | Content   | hour)         |            |            |           |
      +-----------+---------------+------------+------------+-----------+
      | ISP SLA   | 7200s (2      | 0.5        | $0.50      | <2 hours  |
      | Reporting | hours)        |            |            |           |
      +-----------+---------------+------------+------------+-----------+

                                    Table 1

     *Assumes m=10,000 users, $0.0001 per transaction

     Maximum recommended P: 7200 seconds (2 hours)

     Rationale: Beyond 2 hours, network state staleness reduces actionable
     value of coverage data.

  8.  Security Considerations

  8.1.  Threat Model

     SONAR must resist the following adversarial behaviors:

     Sybil Attacks:  Attacker creates multiple fake receiver identities to
        inflate coverage claims.  Mitigated by stake requirements and VRF-
        based random sampling.

     Replay Attacks:  Adversary captures authenticated content and replays
        to different receivers.  Mitigated by sequence numbers,
        timesonars, and hash chaining.

     Man-in-the-Middle:  Intermediate node modifies content while
        maintaining valid authentication.  Prevented by ALTA MAC chains
        and periodic signatures.

     DoS Attacks:  Attacker floods network with fake packets to exhaust
        receiver buffers.  Mitigated by instant ALTA authentication
        enabling immediate rejection.




  Ramadan                    Expires 6 May 2026                  [Page 17]


  Internet-Draft                    SONAR                    November 2025


     Sample Manipulation:  Adversary attempts to influence which users are
        selected for sampling.  Prevented by VRF unpredictability.

  8.2.  Economic Security

     Cryptographic security is complemented by economic incentives:

     *  Stake requirements: $10-$100K deposits create accountability

     *  Slashing penalties: Fraudulent attestations result in stake loss

     *  Fraud detection rewards: 5-10x multiplier encourages honest
        reporting

     *  Rational behavior: Cost of fraud exceeds expected benefit

     Game-theoretic analysis shows honest participation is Nash
     equilibrium when fraud detection probability exceeds 0.001% (easily
     achieved through random spot checks).

  8.3.  Privacy Considerations

     SONAR reveals the following information:

     *  Which users are registered for coverage verification (public keys
        on-chain)

     *  Which users were selected for sampling (challenge message)

     *  Aggregate statistics about selected users (loss rates, packet
        counts)

     SONAR does NOT reveal:

     *  Content of multicast stream (encrypted separately if needed)

     *  Individual user consumption patterns (when zkSNARK aggregation
        used)

     *  Non-selected users' reception status

     Privacy Attack Vector for Small Communities:

     Without zkSNARK aggregation, direct on-chain attestations enable
     correlation attacks.  For small communities (N < 100,000), attackers
     can:

     *  Link public keys to known wallet addresses



  Ramadan                    Expires 6 May 2026                  [Page 18]


  Internet-Draft                    SONAR                    November 2025


     *  Correlate viewing times with other on-chain activity

     *  Cross-reference with geographic or demographic data

     Privacy decreases inversely with community size.  For N=5,000,
     individual identification probability exceeds 75% through cross-
     referencing.  For N=10,000,000, crowd anonymity provides natural
     protection.

     RECOMMENDATION: zkSNARK aggregation MUST be used when sample size m >
     1,000, SHOULD be used when m > 100.  This protects small community
     viewers from de-anonymization while maintaining cryptographic
     coverage proof.

  9.  IANA Considerations

     This document requests IANA to create a new registry for SONAR
     message types:

     Registry Name: SONAR Message Types

     Registration Procedure: IETF Review

     Reference: This document

     Initial allocations:

             +=======+==========================+===============+
             | Value | Description              | Reference     |
             +=======+==========================+===============+
             | 0x01  | Sample Challenge         | Section 5.1.2 |
             +-------+--------------------------+---------------+
             | 0x02  | User Attestation         | Section 5.2.1 |
             +-------+--------------------------+---------------+
             | 0x03  | zkSNARK Aggregated Proof | Section 6.3   |
             +-------+--------------------------+---------------+

                                   Table 2

  10.  References

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




  Ramadan                    Expires 6 May 2026                  [Page 19]


  Internet-Draft                    SONAR                    November 2025


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

     [I-D.krose-mboned-alta]
                Rose, K. and J. Holland, "Asymmetric Loss-Tolerant
                Authentication", July 2019,
                <https://datatracker.ietf.org/doc/html/draft-krose-mboned-
                alta-01>.

  10.2.  Informative References

     [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J. D., and B.
                Briscoe, "Timed Efficient Stream Loss-Tolerant
                Authentication (TESLA): Multicast Source Authentication
                Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
                June 2005, <https://www.rfc-editor.org/info/rfc4082>.

     [I-D.ietf-mboned-ambi]
                Holland, J., Rose, K., and M. Franke, "Asymmetric Manifest
                Based Integrity", March 2022,
                <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-
                ambi-04>.

  Appendix A.  Example Deployment

  A.1.  NYC Television Station Scenario

     This appendix provides a concrete deployment example for a New York
     City television station broadcasting to 10 million concurrent
     viewers.

  A.1.1.  Network Configuration

     *  Content Provider: NBC New York

     *  Content: Live sports broadcast

     *  Bitrate: 25 Mbps H.265 video

     *  Target Coverage: 10,000,000 concurrent viewers

     *  Geographic Area: NYC metropolitan area

  A.1.2.  SONAR Configuration

     Content Authentication (ALTA):




  Ramadan                    Expires 6 May 2026                  [Page 20]


  Internet-Draft                    SONAR                    November 2025


     *  MAC algorithm: HMAC-SHA256 (128-bit)

     *  Signature: Ed25519 every 50th packet

     *  Overhead: 6.75% (1.69 Mbps)

     Statistical Sampling:

     *  Sample size: m = 10,000 users (0.1%)

     *  Test period: P = 900 seconds (15 minutes)

     *  Confidence: 95%

     *  Margin of error: ±0.3%

     Broadcast Overhead:

     *  ALTA: 1.69 Mbps

     *  Challenge message: 320 KB / 900s = 2.8 Kbps

     *  Total: 1.69 Mbps (6.76%)

  A.1.3.  Cost-Benefit Analysis

     Per-Hour Costs:

     *  User sampling: 10,000 users × 4 tests/hour × $0.0001 = $4.00

     *  zkSNARK aggregation: 4 tests/hour × $0.0001 = $0.0004

     *  Total: $4.00 per hour

     Revenue Impact:

     *  Traditional CPM (unverified): $10 per 1000 impressions

     *  Verified CPM: $15 per 1000 impressions (50% premium)

     *  Traditional revenue: 10M × $10/1000 = $100,000/hour

     *  Verified revenue: 10M × $15/1000 = $150,000/hour

     *  Additional revenue: $50,000/hour

     *  Net benefit: $50,000 - $4 = $49,996/hour




  Ramadan                    Expires 6 May 2026                  [Page 21]


  Internet-Draft                    SONAR                    November 2025


     *  ROI: 1,249,900%

  A.1.4.  Performance Metrics

     *  Broadcast bandwidth: 25 Mbps + 1.69 Mbps = 26.69 Mbps

     *  Overhead: 6.76%

     *  Authentication latency: 1-10ms (ALTA)

     *  Detection latency: <15 minutes

     *  Coverage confidence: 95% (9,458,000 - 9,542,000 users)

     *  Blockchain TPS: 0.011 (well below capacity)

  Acknowledgments

     The author thanks Jake Holland and Kyle Rose (Akamai) for the ALTA
     protocol specification and insights on multicast authentication.  A
     special thanks to Lenny Giuliano (Juniper Networks), Chris Lenart
     (Verizon), Neil Chatterjee (DAWN Internet) for real-world deployment
     experience with decentralized multicast networks and feedback on
     earlier revisions of this work.

  Author's Address

     Omar Ramadan
     Blockcast Inc
     Berkeley, CA
     United States of America
     Email: omar@blockcast.network
     URI:   https://blockcast.network


















  Ramadan                    Expires 6 May 2026                  [Page 22]


name: draft-xu-rtgwg-fare-in-sun
rev: 02
title: Fully Adaptive Routing Ethernet in Scale-Up Networks
time: 2026-02-27T06:56:11Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T06:56:11Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.866365+00:00
source: ietf
source_id: 146007
source_url: https://datatracker.ietf.org/doc/draft-xu-rtgwg-fare-in-sun/
doc_status: active
abstract:
  The Mixture of Experts (MoE) has become a dominant paradigm in
     transformer-based artificial intelligence (AI) large language models
     (LLMs).  It is widely adopted in both distributed training and
     distributed inference.  To enable efficient expert parallelization
     and even tensor parallelization across dozens or even hundreds of
     Graphics Processing Units (GPUs) in MoE architectures, an ultra-high-
     throughput, ultra-low-latency AI scale-up network (SUN) is critical.
     This document describes how to extend the Weighted Equal-Cost Multi-
     Path (WECMP) load-balancing mechanism, referred to as Fully Adaptive
     Routing Ethernet (FARE), which was originally designed for scale-out
     networks, to scale-up networks.

full_text:
  Network Working Group                                              X. Xu
  Internet-Draft                                              China Mobile
  Intended status: Standards Track                                   Z. He
  Expires: 30 August 2026                                         Broadcom
                                                                   N. Wang
                                                                     Intel
                                                                   N. Wang
                                                                     Hygon
                                                                   H. Wang
                                                             Moore Threads
                                                                    J. Guo
                                                          Biren Technology
                                                                     X. Li
                                                        Enflame Technology
                                                                   T. Zhou
                                                        Resnics Technology
                                                                   Y. Yang
                                                                    Centec
                                                                    Y. Xia
                                                                  W. Zhang
                                                                   Tencent
                                                                   P. Wang
                                                                     Baidu
                                                                 Y. Zhuang
                                                       Huawei Technologies
                                                                   F. Yang
                                        Cloudnine Information Technologies
                                                                     C. Li
                                             Metanet Networking Technology
                                                                   X. Wang
                                                           Ruijie Networks
                                                          26 February 2026


            Fully Adaptive Routing Ethernet in Scale-Up Networks
                       draft-xu-rtgwg-fare-in-sun-02

  Abstract













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


  Internet-Draft                 FARE in SUN                 February 2026


     The Mixture of Experts (MoE) has become a dominant paradigm in
     transformer-based artificial intelligence (AI) large language models
     (LLMs).  It is widely adopted in both distributed training and
     distributed inference.  To enable efficient expert parallelization
     and even tensor parallelization across dozens or even hundreds of
     Graphics Processing Units (GPUs) in MoE architectures, an ultra-high-
     throughput, ultra-low-latency AI scale-up network (SUN) is critical.
     This document describes how to extend the Weighted Equal-Cost Multi-
     Path (WECMP) load-balancing mechanism, referred to as Fully Adaptive
     Routing Ethernet (FARE), which was originally designed for scale-out
     networks, to scale-up networks.

  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 RFC 2119 [RFC2119].

  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.



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


  Internet-Draft                 FARE in SUN                 February 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Solution Description  . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Per-Flow Weighted Load Balancing  . . . . . . . . . . . .   5
       3.2.  Per-Packet Weighted Load Balancing  . . . . . . . . . . .   5
     4.  Considerations on Memory Semantic Operations  . . . . . . . .   6
     5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     The Mixture of Experts (MoE) has become a dominant paradigm in
     transformer-based artificial intelligence (AI) large language models
     (LLMs).  It is widely adopted in both distributed training and
     distributed inference.  To enable efficient expert parallelization
     and even tensor parallelization across dozens or even hundreds of
     Graphics Processing Units (GPUs) in MoE architectures, an ultra-high-
     throughput, ultra-low-latency AI scale-up network (SUN) is
     indispensable.  This network serves as the interconnection fabric,
     allowing GPUs to function as a unified super GPU, referred to as
     a SuperPoD.  The scale-up network is fundamental for efficiently
     transporting substantial volumes of communication traffic within the
     SuperPoD.  It includes but not limited to：1) all-to-all traffic for
     Expert Parallelism (EP) communication, and 2) all-reduce traffic for
     Tensor Parallelism (TP) communication, ensuring consistent tensor
     values across GPUs during training and inference.


           +----+ +----+ +----+ +----+
           | L1 | | L2 | | L3 | | L4 |  (Leaf)
           +----+ +----+ +----+ +----+

           +----+ +----+ +----+ +----+ +----+ +----+      +----+
           | G1 | | G2 | | G3 | | G4 | | G5 | | G6 | ...  |G64 |  (GPU)
           +----+ +----+ +----+ +----+ +----+ +----+      +----+


                                      Figure 1






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


  Internet-Draft                 FARE in SUN                 February 2026


     (Note that the diagram above does not include the connections between
     GPUs and leaf switches.  However, it can be assumed that GPUs are
     connected to every leaf switch in the above scale-up network
     topology.)

     As shown in Figure 1, it's a 64-GPU SuperPoD that consists of 64 GPUs
     and four leaf switches with high radix (e.g., 128 400G ports).  To
     achieve inter-GPU bandwidths of several terabits per second (Tbps) or
     higher, each GPU is typically equipped with multiple scale-up network
     ports (e.g., four 800 Gbps ports).  Each port connects to a separate
     scale-up leaf switch via a Y-cable, forming four distinct network
     planes.

     In such multi-plane scale-up networks, achieving ultra-high bandwidth
     and ultra-low latency requires two key strategies.  First,
     efficiently distributing data across all network planes is critical.
     For instance, if an 800G port on a GPU fails, traffic destined for
     that GPU over the faulty plane must immediately cease.  If only one
     400G sub-cable of a given 800G Y-cable malfunctions, halving the
     bandwidth of the affected network plane, traffic on that network
     plane between the relevant GPU pair should be proportionally reduced.
     Second, incast traffic patterns inherent to all-to-all communication
     may cause congestion on the egress ports of a last-hop switch;
     therefore, a more efficient congestion management mechanism is
     required.

     This document describes how to extend the Fully Adaptive Routing
     Ethernet (FARE) using BGP (FARE-BGP in short) as described in
     [I-D.xu-idr-fare], which was originally designed for scale-out
     netowrks, to scale-up networks.

  2.  Terminology

     This memo makes use of the terms defined in [RFC2119].

  3.  Solution Description

     Each pair of GPUs establishes multiple Remote Direct Memory Access
     (RDMA) Queue Pairs (QPs) for data transmission using the loopback
     addresses of the GPU servers.  It is recommended that each loopback
     address be bound to a single GPU.  While the use of port-level or
     sub-port-level physical addresses for QP establishment is technically
     supported, this approach is not recommended.

     Additionally, upper-layer adaptations (e.g., transaction layer) can
     facilitate memory semantic operations (load/store/atomic) based on
     RDMA message semantics.  However, implementation details are beyond
     the scope of this document.



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


  Internet-Draft                 FARE in SUN                 February 2026


     Acting as stub BGP speakers, servers exchange BGP routes with
     connected switches across different planes, advertising the
     reachability of their loopback addresses and learning the
     reachability of remote GPUs.  Additionally, by extending FARE-BGP
     from switches to servers, they can obtain path bandwidth information
     related to ECMP routes for other GPUs.  This capability enables GPUs
     to perform WECMP load balancing across all available network planes
     of a scale-up network.

     When the path bandwidth of a route through a specific network plane
     to a destination GPU degrades due to events such as network plane
     failures or partial link outages, existing Queue Pairs (QPs)
     traversing unaffected planes maintain their established forwarding
     paths.  Meanwhile, the source GPU must adjust the traffic load
     allocated to the affected network plane based on updated weight
     values.  Conversely, when the path bandwidth through a previously
     degraded network plane recovers—such as after failed links or planes
     are restored—the source GPU should increase the traffic load
     allocated to that plane.  This approach ensures optimal traffic
     distribution across all operational network planes.

  3.1.  Per-Flow Weighted Load Balancing

     Per-flow weighted load balancing is recommended when ordered packet
     delivery is essential.

     For per-flow weighted load balancing, at least one Queue Pair (QP)
     per sub-port must be established between a pair of GPUs.  When QPs
     are configured using the loopback address assigned to each GPU, each
     QP should be assigned a unique UDP source port to differentiate
     traffic flows across all network planes between the GPU pair.  If QPs
     are configured using the physical addresses assigned to ports, each
     QP should be assigned a unique UDP source port to differentiate
     traffic flows across the same network plane.  If QPs are configured
     using the physical addresses assigned to sub-ports, there is no need
     for assigning unique UDP source port for each QP anymore.

     The traffic allocated to a given network plane is evenly distributed
     among all available QPs traversing that plane.

     The switch within each network plane SHOULD perform per-flow load
     balancing as well to ensure ordered packet delivery for all QPs.

  3.2.  Per-Packet Weighted Load Balancing

     Rer-packet weighted load balancing is recommended in the case where
     disordered packet delivery is acceptable.




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


  Internet-Draft                 FARE in SUN                 February 2026


     For per-packet weighted load balancing, all QPs established between a
     pair of GPUs must support disordered packet delivery (e.g., through
     the Direct Data Placement mechanism [RFC7306]).  In this mode, a
     single QP per network plane between a given GPU pair is sufficient,
     with the traffic of that QP evenly distributed across all available
     routes within that network plane.

     The switch within each network plane SHOULD perform per-packet
     weighted load balancing since disordered packet delivery is
     acceptable for all QPs.

  4.  Considerations on Memory Semantic Operations

     When implementing memory semantics, the ordering guarantees for
     network transmission can be categorized as follows:

     a.  Weak Ordering Guarantee for Network Transmission: The network
     adopts full packet spraying, and the GPUs rely entirely on the
     Reorder Buffer (ROB) to maintain ordering.  This results in a
     significant increase in implementation complexity on the GPU side.

     b.  Partial Ordering Constraint for Network Transmission: For
     transactions with strict ordering requirements (e.g., fence and
     barrier operations), sequential execution is mandatory.  These
     transactions are marked with a "strong ordering" flag, and the
     endpoint side uses a blocking mechanism to wait and satisfy the
     ordering requirement.  For transactions that allow out-of-order
     transmission, the network provides a baseline hash-based ordering
     guarantee mechanism.  When the GPU generates transactions with the
     same hash key, in-order delivery is enforced between these
     transactions.  This approach grants the GPU ample flexibility while
     enabling fine-grained local control over ordering.

     c.  Strong Ordering Guarantee for Network Transmission: To simplify
     the implementation of memory semantic transactions, some GPUs require
     that the same transaction stream be transmitted strictly in order
     along the entire network path, with out-of-order transmission
     completely prohibited.  This achieves a highly simplified
     implementation on the GPU side.

     When implementing native Load/Store memory semantics directly on top
     of RDMA QPs, additional purpose-built mechanisms are required to
     guarantee the sequential consistency of memory
     transactions—particularly for GPUs built on weak-order memory models.
     Specifically, for weak-order memory models, transactions of the same
     type targeting the same memory address must maintain consistent
     ordering throughout their entire network transmission and transaction
     processing pipeline.  To achieve this, transactions should be routed



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


  Internet-Draft                 FARE in SUN                 February 2026


     to the same QP via a hash-based strategy: all transactions targeting
     the same memory address are hashed to the same QP.  Furthermore, each
     QP enforces strict in-order transmission and completion along its
     dedicated network path when operating in per-flow weighted load-
     balancing mode.

  5.  Acknowledgements

     TBD.

  6.  IANA Considerations

     TBD.

  7.  Security Considerations

     TBD.

  8.  References

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

  8.2.  Informative References

     [I-D.xu-idr-fare]
                Xu, X., Hegde, S., Patel, K., He, Z., Wang, J., Huang, H.,
                Zhang, Q., Wu, H., Liu, Y., Xia, Y., Wang, P., and
                Tiezheng, "Fully Adaptive Routing Ethernet using BGP",
                Work in Progress, Internet-Draft, draft-xu-idr-fare-04, 18
                December 2025, <https://datatracker.ietf.org/doc/html/
                draft-xu-idr-fare-04>.

     [RFC7306]  Shah, H., Marti, F., Noureddine, W., Eiriksson, A., and R.
                Sharp, "Remote Direct Memory Access (RDMA) Protocol
                Extensions", RFC 7306, DOI 10.17487/RFC7306, June 2014,
                <https://www.rfc-editor.org/info/rfc7306>.

  Authors' Addresses

     Xiaohu Xu
     China Mobile
     Email: xuxiaohu_ietf@hotmail.com




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


  Internet-Draft                 FARE in SUN                 February 2026


     Zongying He
     Broadcom
     Email: zongying.he@broadcom.com


     Nan Wang
     Intel
     Email: nan.wang@intel.com


     Nan Wang
     Hygon
     Email: wangn@hygon.cn


     Hua Wang
     Moore Threads
     Email: wh@mthreads.com


     Jian Guo
     Biren Technology
     Email: jguo@birentech.com


     Xiang Li
     Enflame Technology
     Email: xiang.li@enflame-tech.com


     Tianyou Zhou
     Resnics Technology
     Email: tzhou@resnics.com


     Yongtao Yang
     Centec
     Email: yangyt@centec.com


     Yinben Xia
     Tencent
     Email: forestxia@tencent.com


     Weifeng Zhang
     Tencent
     Email: wikkizhang@tencent.com



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


  Internet-Draft                 FARE in SUN                 February 2026


     Peilong Wang
     Baidu
     Email: wangpeilong01@baidu.com


     Yan Zhuang
     Huawei Technologies
     Email: zhuangyan.zhuang@huawei.com


     Fajie Yang
     Cloudnine Information Technologies
     Email: yangfajie@cloudnineinfo.com


     Chao Li
     Metanet Networking Technology
     Email: lichao22@ieisystem.com


     Wang Xiaojun
     Ruijie Networks
     Email: wxj@ruijie.com.cn




























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


