Optical Networks and AI Computing Orchestration (ONCO) Problem Statement, Use Cases and Requirements
draft-tan-ccamp-onco-problem-statement-00

ccamp                                                             Y. Tan
Internet-Draft                                              China Unicom
Intended status: Informational                                    Z. Han
Expires: 7 January 2027Beijing University of Posts and Telecommunications
                                                                 S. Yang
                                                         ZTE Corporation
                                                                 X. Zhao
                                                                   CAICT
                                                             6 July 2026

     Optical Networks and AI Computing Orchestration (ONCO) Problem
                 Statement, Use Cases and Requirements
               draft-tan-ccamp-onco-problem-statement-00

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 and
   inference 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 draft presents the problem statement, outlines two
   representative use cases: distributed AI training and distributed AI
   inference, and specifies the requirements for Optical Networks and AI
   Computing Orchestration (ONCO).  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.

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

Tan, et al.              Expires 7 January 2027                 [Page 1]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

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

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Isolated Control and Management . . . . . . . . . . . . .   5
     3.2.  Independent Resource Efficiency Evaluation  . . . . . . .   7
     3.3.  Limitations of Existing Computing-Aware Frameworks  . . .   7
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Distributed AI Training . . . . . . . . . . . . . . . . .   8
     4.2.  Distributed AI Inference  . . . . . . . . . . . . . . . .   9
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Integrated Control and Management Architecture  . . . . .  10
     5.2.  Unified Abstraction of Computing and Network Resources  .  11
     5.3.  Joint Orchestration of Computing and Network Resources  .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Tan, et al.              Expires 7 January 2027                 [Page 2]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

1.  Introduction

   The rapid development 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
   example, a training job may be scheduled across distant AIDCs with
   abundant GPU resources but poor optical connectivity, resulting in
   prolonged synchronization phases and significant compute efficiency
   loss.  Similarly, latency-sensitive inference services may be routed
   through paths that meet compute criteria but violate network service-
   level objectives.

   To address these challenges, ONCO enables bidirectional awareness,
   joint resource abstraction, and synchronized control across the
   compute-optical boundary.  This draft describes sample usage
   scenarios that drive ONCO 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.  Terminology

   This document uses the following terms:

   Hard-Isolated:  A transport channel that is physically separated from
      other traffic at the optical layer (e.g., dedicated wavelength or
      time-slot), ensuring zero interference, zero jitter, and
      guaranteed bandwidth.  Unlike soft isolation (e.g., queue-based or
      priority-based mechanisms), hard isolation provides deterministic
      performance regardless of background traffic load.

Tan, et al.              Expires 7 January 2027                 [Page 3]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   Compute Efficiency Loss:  The degradation of compute resource
      utilization caused by communication bottlenecks, synchronization
      delays, or resource contention.  In distributed AI workloads, this
      typically manifests as GPU idle cycles waiting for parameter
      synchronization or data transfer, resulting in reduced effective
      FLOPS and prolonged job completion times.

   Key-Value (KV) Cache:  A data structure used in autoregressive
      language model inference that stores the key and value tensors
      from the attention mechanism for previously processed tokens.  The
      KV Cache enables efficient generation by avoiding recomputation of
      attention states, but can grow to hundreds of gigabytes for long
      context windows and large batch sizes, necessitating efficient
      migration mechanisms across distributed inference nodes.

   Time-to-First-Token (TTFT):  The latency measured from the moment an
      inference request is submitted to the moment the first output
      token is generated.  TTFT is a critical user-perceived latency
      metric for interactive AI services, particularly in conversational
      and real-time applications.

   Time-Per-Output-Token (TPOT):  The average time required to generate
      each subsequent output token after the first token.  TPOT
      characterizes the sustained generation throughput of an inference
      service and directly impacts the responsiveness of interactive AI
      applications.

3.  Problem Statement

Tan, et al.              Expires 7 January 2027                 [Page 4]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   +------------------------------------------+
   |        AI Compute Service Request        |
   |    (e.g., Distributed Training Job)      |
   +--------------------+---------------------+
                        |
             +----------v----------+
             |                     |
             v                     v
   +------------------+   +---------------------+
   | Compute          |   | Optical 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

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

Tan, et al.              Expires 7 January 2027                 [Page 5]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   The optical network control plane operates without awareness of the
   real-time characteristics and requirements of the compute jobs it
   carries.  Crucially, the physical layer properties of the optical
   infrastructure directly determine the feasibility and efficiency of
   AI workloads.

   The physical distance between geographically distributed AIDCs
   imposes a fundamental propagation delay (roughly 5 microseconds per
   kilometer).  For large-scale distributed training, this inherent
   latency directly impacts the time of global synchronization
   operations (e.g., All-Reduce).  Furthermore, traditional packet-
   switched networks may introduce variable jitter, queuing delays, and
   potential packet loss.  These can lead to frequent retransmissions
   and high synchronization penalties, causing massive GPU idle cycles
   and severely degrading compute efficiency.

   The optical underlay possesses unique physical-layer capabilities,
   such as wavelength or time-slot switching, which can provision hard-
   isolated and deterministic circuits.  These circuits eliminate jitter
   and guarantee a stable, latency-bounded channel.  This is a critical
   differentiator for synchronizing massive GPU clusters across long
   distances.  Without this physical-layer awareness, the control plane
   cannot leverage these unique deterministic features to support high-
   performance AI workloads.

   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 physical state, including the end-to-end
   propagation delay and whether the available optical paths can provide
   the required deterministic performance.  This results in compute jobs
   being scheduled across locations with poor physical connectivity
   (e.g., long-distance links with excessive latency or shared channels
   lacking isolation).  Such scheduling causes significant communication
   bottlenecks and degraded overall job performance (i.e., compute
   efficiency loss).

   This bidirectional lack of awareness creates a fundamental mismatch.
   While the optical network possesses the physical-layer capabilities
   (deterministic latency, hard-isolation) to act as the ideal transport
   for wide-area AI workloads, these capabilities are not exposed to or
   understood by the compute domain.  Consequently, neither domain can
   adapt to the needs of the other, severely limiting the potential of
   wide-area collaborative computing.

Tan, et al.              Expires 7 January 2027                 [Page 6]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

3.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 each operate
   independently.

   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.

3.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.  Specifically, two
   fundamental limitations exist.

   First, existing frameworks cannot provision optical links on demand.
   CATS focuses on selecting an optimal path among already existing and
   established network routes.  It lacks the capability to interact with
   the optical control plane to create new physical or logical links.
   This limitation becomes critical in cross-regional AI scheduling
   scenarios.

   For example, a distributed training job spanning Beijing and Shanghai
   (1000 km apart) requires a high-bandwidth, low-latency, and
   deterministic optical channel to synchronize model parameters
   efficiently.  The physical propagation delay over 1000 kilometers is
   a hard constraint, but the more unpredictable issue lies in packet
   jitter and queuing delays introduced by traditional IP-based

Tan, et al.              Expires 7 January 2027                 [Page 7]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   forwarding.  CATS-based traffic steering over existing shared pipes
   cannot guarantee the required deterministic performance, leaving the
   training job vulnerable to synchronization stalls and severe GPU
   utilization degradation.

   In contrast, the optical physical layer can establish hard-isolated
   channels through dedicated wavelength or time-slot circuits (e.g.,
   OXC or fgOTN).  These channels offer deterministic latency, zero
   jitter, and guaranteed bandwidth, which are essential for efficient
   all-reduce operations over long distances.  The existing framework
   cannot trigger this on-demand optical provisioning, which represents
   a fundamental gap.

   Second, existing frameworks do not support full lifecycle
   orchestration of computing resources.  They are generally limited to
   steering service requests to service instances that are already
   available.  They cannot perform explicit reservation, locking, and
   subsequent release of high-performance resources (like GPU clusters).

   In the Beijing-Shanghai scenario, effective orchestration cannot
   merely "steer" traffic.  It must first jointly reserve compute
   resources at both AIDCs and then trigger the optical layer to
   provision a end-to-end deterministic optical containers to deliver
   the training job.  Without this joint capability, both networks and
   computing remain in isolated silos, which prevents the consistent,
   high-performance execution of distributed AI workloads.

4.  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).  Two representative use
   cases illustrate the need for tighter integration between optical
   transport networks and compute orchestration systems.

4.1.  Distributed AI Training

   In distributed training of large language models (LLMs), state-of-
   the-art techniques like 3D parallelism (data, pipeline, and tensor
   parallelism) coordinate thousands of GPUs across geographically
   dispersed AIDCs.  The dominant synchronization primitive, Ring All-
   Reduce, is highly sensitive to the quality of inter-AIDC connections.

   Consider a training job spanning Beijing and Shanghai (1000 km).  The
   Round-Trip Time (RTT) is physically bound to roughly 10ms by the
   speed of light in fiber.  However, standard RoCEv2 (RDMA over
   Converged Ethernet) networks rely on Priority Flow Control (PFC) to

Tan, et al.              Expires 7 January 2027                 [Page 8]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   prevent packet loss.  In a wide-area context, PFC can cause "head-of-
   line" blocking and deadlocks, leading to severe jitter and occasional
   large latency spikes.  These unpredictable fluctuations cause the
   All-Reduce operation to stall.  This results in massive GPU idle
   cycles and renders the training efficiency of GPUs, especially those
   using high-end H100 or Blackwell architectures.

   Existing computing-aware routing frameworks (such as CATS) are
   designed for "steering" traffic over pre-existing paths and cannot
   eliminate this jitter.  The core issue is the buffer-based queuing
   inherent to IP forwarding.  To achieve deterministic performance, the
   optical physical layer is a superior choice.

   An Optical Cross-Connect (OXC) can provision an ultra-low-latency,
   bufferless, and jitter-free wavelength circuit between two AIDCs.
   For a 1000km link, this provides a deterministic, hard-isolated
   channel with a fixed propagation delay (e.g., 5ms one-way) and zero
   queuing latency.  This deterministic channel ensures that intra-
   iteration synchronization (All-Reduce) completes within a predictable
   time window, significantly improving GPU utilization and training
   stability.

4.2.  Distributed AI Inference

   Distributed AI inference, specifically for LLMs, introduces unique
   data dispersal requirements.  The Key-Value (KV) Cache stores
   attention states for autoregressive generation.  For long context
   windows and large batch sizes, the KV Cache can reach hundreds of
   gigabytes.

   In a cross-regional inference scenario (e.g., an incoming request is
   processed by a central AIDC but must be offloaded to a regional edge
   node for sustained conversation), the KV Cache may need to be
   relocated or remotely accessed across the wide-area network.

   If the KV Cache is migrated over a standard IP network, congestion
   and unpredictable buffer delays can significantly degrade the Time-
   to-First-Token (TTFT) and Time-Per-Output-Token (TPOT) metrics.  For
   real-time conversational AI, even a single retransmission or queuing
   event can cause a noticeable stall or abrupt increase in latency,
   breaking the user experience.  This is a critical bottleneck for
   implementing distributed inference services across data centers.

Tan, et al.              Expires 7 January 2027                 [Page 9]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   To enable seamless KV Cache migration, the transport network must
   provide a high-bandwidth, deterministic, and low-latency channel.  An
   optical path (e.g., an fgOTN timeslot or OXC wavelength) can be
   dynamically provisioned to form a dedicated pipe specifically for the
   cache migration.  This guarantees that the KV Cache transfer is not
   impacted by other data plane traffic, ensuring predictable TTFT and
   TPOT.

   Furthermore, the optical path's guaranteed latency allows the
   inference scheduler to accurately predict the cost of remote KV Cache
   access or migration.  This enables optimal placement decisions (e.g.,
   co-locating the prompt processing and KV Cache affinity with the
   optical path quality).

5.  Requirements

   Based on the problem statements and use cases described above, the
   following functional and performance requirements are necessary to
   support Optical Networks and AI Computing Orchestration (ONCO).
   These requirements are essential for enabling joint, high-performance
   scheduling of AI workloads across wide-area optical infrastructures.

5.1.  Integrated Control and Management Architecture

   An integrated control architecture is required to break down the
   management silos.  This architecture must facilitate bidirectional
   fusion between the compute and network control planes.

   Specifically, the architecture must support the following
   _performance requirements_:

   *  *Rapid Service Provisioning:* The response time for establishing a
      cross-domain, joint compute-and-optical-path service (e.g.,
      initiating a new training job across two AIDCs) should be
      compressed from the current hour-level down to *sub-minute
      levels*.

   *  *Fast Resource Adjustment:* The control plane must support dynamic
      reconfiguration of optical bandwidth and compute resources in
      response to workload changes (e.g., scaling a training job).

   *  *Deterministic Performance Monitoring:* The architecture must
      expose real-time, end-to-end optical performance metrics to the
      joint orchestrator.  This includes, but is not limited to, *Link
      OSNR (Optical Signal-to-Noise Ratio)*, *pre-FEC BER (Bit Error
      Rate)*, and *propagation delay*.

Tan, et al.              Expires 7 January 2027                [Page 10]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   *  *Resilience and Protection:* The architecture must support rapid
      optical path protection switching in the event of OSNR degradation
      or fiber failure.  This high availability is crucial for long-
      duration training jobs, preventing massive compute wastage due to
      a single optical fault.

5.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 must be abstracted into
   a model that can be understood by the joint orchestrator.  This model
   must expose detailed and quantifiable parameters including:

   *  *Physical Layer Health:* Explicit parameters such as *Path*.
      These are necessary to assess the viability of a long-haul optical
      circuit for high-throughput, low-error-rate AI traffic.

   *  *Deterministic QoS:* Guaranteed *Available Bandwidth* (in Gbps),
      *One-way Minimum Latency*, and *Jitter Bounds*.

   *  *Topology Constraints:* Abstract topology information must be
      exposed to support multi-domain path computation.

   Similarly, heterogeneous compute resources (CPU, GPU, memory,
   storage) must be abstracted into a model that conveys their real-time
   capabilities and state to the joint orchestrator.  This model must
   include:

   *  *Compute Capabilities:* Metrics such as *GPU FLOPS* (FP16/FP8),
      *VRAM Size* (in GB), and *Available Memory Bandwidth* (in GB/s).

   *  *Job Characteristics:* The joint orchestrator must be able to
      indicate the *expected bandwidth requirement*, *latency
      sensitivity*, and *duration target* of a specific AI job (e.g.,
      training vs. inference).

   This unified, detailed abstraction is the foundation for any credible
   joint decision-making process.

5.3.  Joint Orchestration of Computing and Network Resources

   Building on the integrated architecture and unified abstraction, a
   joint orchestration mechanism is required to make end-to-end resource
   allocation decisions.  This mechanism must:

Tan, et al.              Expires 7 January 2027                [Page 11]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   *  *Optimize for a Joint Objective:* The joint orchestrator must be
      capable of simultaneously evaluating a multi-dimensional objective
      function composed of both compute performance metrics and network
      performance metrics.  It should be able to trade off compute power
      against network quality to find the overall service optimum.

   *  *Compute-Aware Optical Provisioning:* The joint orchestrator must
      be able to initiate an *end-to-end deterministic optical circuit
      setup* (e.g., OXC cross-connect, fgOTN cross-connect) to support a
      specific AI workload.

   *  *Network-Aware Compute Resource Locking:* The joint orchestrator
      must support the *reservation and locking* of compute resources
      (e.g., GPU clusters) that take into account the *underlying
      optical path*.

   *  *Cross-Domain Lifecycle Management:* The joint orchestrator must
      manage the end-to-end lifecycle of a ONCO service (e.g., from
      intent to teardown), including joint resource reservation, path
      setup, dynamic adjustment, and coordinated release across both
      compute and optical domains.

6.  IANA Considerations

   This document makes no request for IANA action.

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

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

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

Tan, et al.              Expires 7 January 2027                [Page 12]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

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

Contributors

   The following people contributed significantly to this document:

   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

   Qiaojun Hu
   Beijing University of Posts and Telecommunications
   Email: qiaoj475@bupt.edu.cn

   Yanlei Zheng
   China Unicom
   Email: zhengyanlei@chinaunicom.cn

Authors' Addresses

   Yanxia Tan
   China Unicom
   Email: tanyx11@chinaunicom.cn

Tan, et al.              Expires 7 January 2027                [Page 13]
Internet-Draft   ONCO: Problem, Use Cases, Requirements        July 2026

   Zheng Han
   Beijing University of Posts and Telecommunications
   Email: 2025010255@bupt.cn

   Sanwei Yang
   ZTE Corporation
   Email: yang.sanwei1@zte.com.cn

   Xing Zhao
   CAICT
   Email: zhaoxing@caict.ac.cn

Tan, et al.              Expires 7 January 2027                [Page 14]