| Internet-Draft | ONCO Control Framework | July 2026 |
| Tan, et al. | Expires 7 January 2027 | [Page] |
This document defines the control framework for Optical Networks and AI Computing Orchestration (ONCO). The framework is designed to achieve synergistic management of optical network (e.g., fgOTN, OXC) and computing resources for high-performance AI workloads. It specifies a multi-stakeholder service model, a layered architecture across management, control, and data planes, and a set of functional components. The ONCO framework supports both centralized and distributed orchestration models to enable proactive resource reservation and deterministic optical circuit provisioning.¶
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 2027.¶
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.¶
The rapid evolution of Artificial Intelligence (AI), characterized by large-scale model training and distributed inference, has shifted the requirements for wide-area infrastructure from simple connectivity to deterministic optical-compute orchestration. High-performance AI workloads, particularly compute-to-compute interactions among geographically distributed AI Data Centers (AIDCs), demand deterministic low latency, stable high bandwidth, bounded jitter, strict isolation, and explicit resource guarantees that go beyond traditional best-effort transport. The key technical distinction of the Optical Networks and AI Computing Orchestration (ONCO) framework is a shift from an IP-overlay traffic steering model to an optical-underlay resource orchestration model.¶
The Computing-Aware Traffic Steering (CATS) framework [I-D.ietf-cats-framework] provides an overlay architecture to dynamic selection of service instances based on joint network and computing awareness. While CATS excels at steering service-specific traffic toward existing instances over available network pipes, it is primarily a traffic-triggered mechanism that operates on a "selection" and "awareness" basis. In a traditional IP or IP-overlay environment, the underlay transport resources may still be statistically multiplexed and affected by queueing, congestion, packet-layer path changes, and contention with other services. As a result, an overlay mechanism alone is not sufficient to guarantee the fixed latency, low jitter, hard isolation, and congestion-loss-free behavior required by emerging AI scenarios such as geographically distributed training. These scenarios require a more proactive approach centered on admission control, advance resource reservation, and deterministic path provisioning in the underlay network.¶
ONCO therefore extends the core principles of compute-aware networking into the optical transport domain and uses fine-grained Optical Transport Network (fgOTN) and Optical Cross-Connect (OXC) technologies as the underlying optical network capabilities. fgOTN supports small-granularity bandwidth allocation, deterministic transport containers, predictable latency, low jitter, and service-level hard isolation, making it suitable for reserving optical resources for AI flows with different bandwidth and timing requirements. OXC enables optical-layer cross-connect and circuit-level path provisioning, reducing packet-layer processing and supporting stable high-capacity optical paths. The combination of fgOTN and OXC provides a deterministic optical underlay that can support fixed or predictable delay, bounded jitter, and elimination of congestion-induced packet loss under normal fault-free operation, which demonstrates its suitability and advantages over a purely traditional IP-based transport approach for AI optical-compute services.¶
Unlike pure traffic-steering approaches that react to packets arriving at the ingress, ONCO focuses on the end-to-end orchestration of resource lifecycles before traffic is admitted. It enables the reservation of compute resources and the provisioning of new deterministic optical circuits triggered by service intents or API requests prior to traffic flow. Through coordination among the AI Service Orchestrator (ASO), Joint Optical-Compute Orchestrator (JOCO), Compute Power Controller (CPC), and Provisioning Network Controller (PNC), ONCO can align compute placement with optical path setup, resource locking, SLA assurance, and resource release across the full service lifecycle.¶
The rest of this document is organized as follows:¶
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.¶
The terms defined in the CATS framework [I-D.ietf-cats-framework] and the ACTN framework [RFC8453] are used in this document. To support the joint orchestration of AI computing and deterministic optical networks, the following terms are introduced or redefined. Detailed architectural descriptions of these functional components are provided in Section 4.2.¶
The deployment of wide-area AI services over optical infrastructure involves multiple stakeholders, each playing a distinct role in the end-to-end service delivery chain. To clarify responsibilities and interactions, this document defines a service model comprising the Customer, Service Provider, Network Provider, and Computing Power Provider.¶
The Customer is the end user or enterprise that consumes AI capabilities. Three primary service patterns are observed:¶
In AI training, the customer delegates the training of large-scale AI models to service providers, typically specifying performance, scale, and data privacy requirements.¶
In AI inference, the customer leases computing resources to deploy and operate inference models, often serving downstream internet users with real-time or batch inference services.¶
The Service Provider acts as the business orchestrator, interfacing directly with the Customer to translate high-level service intents—such as SLAs, geographic constraints, or performance targets—into concrete resource demands. It coordinates with both the Network Provider and the Computing Power Provider to fulfill these demands, and is responsible for service lifecycle management, billing, and customer support.¶
The Network Provider operates and manages the underlying optical transport infrastructure. It delivers high-bandwidth, low-latency, and deterministic connectivity services, including inter-AIDC backbone links and user-to-AIDC dedicated access circuits. The Network Provider exposes network capabilities—such as available bandwidth, path latency, and reliability—through standardized control interfaces to enable coordinated service provisioning.¶
The Computing Power Provider owns and operates one or more Artificial Intelligence Data Centers (AIDCs). It offers compute, memory, and accelerator resources (e.g., GPUs, TPUs) for AI training and inference workloads. The Computing Power Provider reports real-time resource availability and performance metrics to the Service Provider and supports dynamic task placement and scaling based on orchestration instructions.¶
The ONCO framework defines a layered architecture to achieve synergistic orchestration of AI computing and optical transport. This chapter details the functional entities and their roles in both centralized and distributed orchestration models.¶
The ONCO architecture consists of three functional planes: the Management Plane for intent translation, the Control Plane for joint resource orchestration and metric distribution, and the Data Plane for deterministic forwarding. The centralized JOCO model and the distributed Edge JOCO model are alternative deployment modes and are not used simultaneously for the same ONCO service. Unlike CATS, ONCO does not assume that traffic is steered only toward already deployed service instances. Instead, ONCO coordinates AI compute resource reservation in AIDCs with deterministic optical path provisioning. The two deployment modes are illustrated in Figure 1 and Figure 2.¶
+-------------------------------------------------------------+
| ONCO Management Plane |
| +---------------------------------------+ |
| | AI Service Orchestrator (Enhanced CNC)| |
| +---------------------+-----------------+ |
+------------------------------|------------------------------+
|AJI
+------------------------------|------------------------------+
| ONCO Control Plane | |
| +-----------v-----------+ |
| | JOCO (Enhanced MDSC) | |
| +-----------+-----------+ |
| +----------+ | +----------+ |
| | JCI | MPI | JCI |
| | | | |
| +---v---+ +--v--+ +---v---+ |
| | CPC A | | PNC | | CPC Z | |
| +---+---+ +--+--+ +---+---+ |
+---------------|--------------|--------------|---------------+
| | |
| | |
+---------------|--------------|--------------|---------------+
|ONCO Data Plane| | | |
| | | | |
| +---v----+ | +----v---+ |
| | AIDC A | | | AIDC Z | |
| +---+----+ | +----+---+ |
| | | | |
| +--------|--------------v--------------|--------+ |
| | +------v-----------+ +-----------v------+ | |
| | | C-TC A | | C-TC Z | | |
| | |------------------| |------------------| | |
| | | CATS-Forwarder A | | CATS-Forwarder Z | | |
| | +------+-----------+ +-----------+------+ | |
| | | | | |
| | | +----------------+ | | |
| | +====> | Deterministic |<====+ | |
| | | Optical Path | | |
| | | over fgOTN/OXC | | |
| | +----------------+ | |
| +-----------------------------------------------+ |
+-------------------------------------------------------------+
+-----------------------------------------------------------------------+
|ONCO Management Plane |
| +---------------------------------------+ |
| | AI Service Orchestrator (Enhanced CNC)| |
| +--------------------+------------------+ |
+-----------------------------|-----------------------------------------+
|
+-----------------------------|-----------------------------------------+
|ONCO Control Plane | |
| +-------------v--------+ |
| | JOCO (Enhanced MDSC) | |
| +-------------+--------+ |
| | |
| +-------+ NETCONF +---v---+ +-------+ NETCONF +-------+ |
| |OC-GW A|<---------| CPC A | | CPC Z |-------->|OC-GW Z| |
| +---+---+ +---+---+ +---+---+ +---+---+ |
| | | | | |
| +---v---+ | | +---v---+ |
| | Edge | | | | Edge | |
| |JOCO A |<====== Routing/Signaling Mechanisms =====>|JOCO Z | |
| +---+---+ | (e.g., ASON/GMPLS) +---+---+ |
| | | | | |
+----------|------------------|--------------|-----------------|--------+
| | | |
v v v v
+----------|------------------|--------------|-----------------|--------+
| | +---v----+ +----v---+ | |
| +-------v--------+ | AIDC A | | AIDC Z | +----------v-----+ |
| | C-TC A |<----+--------+ +--------+->| C-TC Z | |
| +----------------+ +----------------+ |
| |CATS-Forwarder A| |CATS-Forwarder Z| |
| +--------+-------+ +---------+------+ |
| | +----------------------------+ | |
| +========>| Deterministic Optical Path |<=======+ |
| | over fgOTN/OXC | |
| ONCO Data Plane +----------------------------+ |
+-----------------------------------------------------------------------+
Description: Responsible for interfacing with customers to receive high-level AI service intents (e.g., "geographically distributed training with 10ms sync latency"). It translates these intents into specific resource requirements—such as compute capacity, memory footprint, and deterministic network bandwidth. It also handles service lifecycle management, including billing, SLA enforcement, and user authentication. It does not manage physical resources directly but instead communicates abstracted demands to the control plane via the AJI.¶
Relationship to CATS: Acts as the high-level service management entity.¶
Relationship to ACTN: This component conceptually maps to the Customer Network Controller (CNC) defined in [RFC8453]. However, instead of merely passing traditional Virtual Network Service (VNS) requirements, it translates and communicates overarching AI service intents (encompassing both computing demands and deterministic network demands) to the control plane via the AJI. Accordingly, the AJI can be regarded as an enhanced CNC-MDSC Interface (CMI) for AI-oriented optical-compute orchestration.¶
The control plane supports two independent orchestration models (Centralized and Distributed). The ONCO architecture uses ONCO-specific names for new or enhanced optical-compute orchestration functions and uses ACTN and CATS terminology where ACTN or CATS functions are directly reused. These entities describe logical functions; depending on implementation and deployment, a function may be realized as a standalone component or hosted by, co-located with, or located adjacent to another network or compute-domain component.¶
Description: The centralized decision-making engine for the ONCO framework. It manages the entire lifecycle of resources, performing joint reservation of compute resources and initiating the provisioning of new deterministic optical circuits. It coordinates across both the Compute Domain and the Optical Domain to establish synergistic end-to-end services.¶
Relationship to CATS: Inherited from the CATS Path Selector (C-PS). However, while the standard C-PS focuses on path selection and traffic steering for existing routes, the JOCO proactively reserves compute resources and provisions new deterministic optical circuits.¶
Relationship to ACTN: This component acts as an Enhanced Multi-Domain Service Coordinator (Enhanced MDSC). Unlike the standard ACTN MDSC that solely coordinates network domains, this enhanced entity natively incorporates computing power. It coordinates across both the Compute Domain and the Optical Domain to establish synergistic end-to-end services.¶
Description: Monitors the optical underlay in the centralized orchestration model. It tracks parameters such as wavelength availability, fgOTN timeslot utilization, and physical layer latency, and executes the setup of optical channels based on orchestration decisions. The PNC may be deployed as a standalone optical controller or hosted in, or located adjacent to, an operator control platform or the nearest AIDC.¶
ONCO reuses the ACTN PNC for the optical transport domain.¶
The PNC abstracts the optical topology and exposes it to the JOCO via the MPI, and receives provisioning commands to configure optical nodes.¶
Description: Monitors the AI compute pool, collecting real-time telemetry such as GPU utilization, VRAM availability and task queue status. It executes task placement and compute resource locking commands within the Artificial Intelligence Data Center (AIDC). The CPC may be deployed as a standalone compute control component or hosted in, or located adjacent to, the AIDC whose compute resources it controls. It abstracts non-network compute resources (e.g., GPU clusters) and exposes them to the JOCO via the dedicated JCI.¶
Relationship to CATS: Inherited from the CATS Service Metric Agent (C-SMA). It is enhanced from simple service state awareness to supporting active, stateful compute resource reservation and locking.¶
Relationship to ACTN: This component conceptually maps to the Provisioning Network Controller (PNC) defined in [RFC8453]. However, rather than managing network elements, this entity introduces the novel concept of a Compute Provisioning Controller. Architecturally, its interface with the JOCO holds an equivalent hierarchical status to the MPI. However, a strict domain separation is maintained: while the optical network domain is controlled via the MPI, the compute domain is governed through the dedicated JCI.¶
Description: An independent, distributed control-plane entity deployed at an edge optical network node. It may be hosted by, or co-located with, the same edge optical network node that supports the C-TC and CATS-Forwarder functions, while remaining logically separate from those data-plane functions. It performs rapid resource reservation and optical path provisioning based on locally collected metrics.¶
For any specific ONCO service, the Edge JOCO and the centralized JOCO orchestration functions are mutually exclusive. This avoids having two independent orchestration authorities issue resource reservation, path computation, or signaling decisions for the same service. The deployment choice determines whether the service is controlled by a centralized orchestration loop or by a distributed orchestration loop.¶
In the distributed model, the JOCO does not perform the centralized joint resource computation or optical provisioning role. It only relays the AI service resource demand from the AI Service Orchestrator to the local CPC, which then drives the distributed control chain.¶
Relationship to CATS: Derived from the distributed deployment model of the CATS C-PS.¶
Description: A protocol mediation gateway deployed at the AIDC edge in the distributed orchestration model. It retrieves AI compute metrics from the CPC, translates them into network-layer TE attributes, and makes them available to the distributed optical control plane through routing, signaling, controller-mediated, or other resource advertisement mechanisms. Extended OSPF-TE Opaque LSAs and extended RSVP-TE signaling are possible examples for carrying metric advertisements or service requirements; they are not mandatory protocol choices for ONCO.¶
Relationship to CATS: A new component specific to the ONCO distributed orchestration model to bridge compute metrics into the optical control plane.¶
The data plane focuses on the high-speed, deterministic delivery of AI traffic according to control-plane decisions. The definitions of data plane entities are extended from [I-D.zhao-cats-otn-applicability] to support hard-isolation optical transport.¶
Description: Functions as the entry (Ingress) or exit (Egress) point for deterministic optical containers at an edge optical network node. In this framework, it plays a role similar to a Provider Edge (PE) node in an optical transport network, where service traffic is admitted into, or released from, the provider-controlled optical underlay. Unlike a packet-only edge function, the ONCO CATS-Forwarder relies on fgOTN and OXC capabilities to bind service flows to deterministic optical resources, including fine-grained time slots, ODUk containers, wavelengths, or optical cross-connect paths. Based on forwarding instructions from the JOCO or Edge JOCO, the Ingress CATS-Forwarder encapsulates and maps client AI signals into hard-isolation optical pipes (e.g., ODUk or fgOTN timeslots). Conversely, the Egress CATS-Forwarder decapsulates and de-maps the signals back to their original client format for delivery to the AIDC.¶
Relationship to CATS: Extends the standard CATS-Forwarder from traffic forwarding over existing paths to optical-edge adaptation and provisioning support. By enabling mapping to fgOTN containers and OXC-based optical paths, it provides the hard isolation, predictable latency, bounded jitter, and high-capacity deterministic transport that cannot be guaranteed by an IP-overlay forwarding function alone.¶
Description: A data-plane functional entity typically hosted in, or located adjacent to, the Ingress CATS-Forwarder at an edge optical network node. It is responsible for identifying incoming AI service traffic through physical ports, VLAN tags, or specific Service IDs (CS-ID). It ensures that identified flows are correctly mapped and encapsulated into the appropriate pre-provisioned optical containers (e.g., fgOTN) as directed by the JOCO or Edge JOCO.¶
Relationship to CATS: Aligns with the standard CATS C-TC but is strictly tied to optical container mapping rules in the OTN data plane.¶
Editor's note: This section describes the scenarios where distributed and centralized orchestration architectures are most applicable.¶
This section details the end-to-end operational workflows for AI service deployment over optical networks. It covers the full lifecycle—resource provisioning, utilization, flexible adjustment, and release—across both centralized and distributed orchestration models. In both models, the user's high-level intent (e.g., AI training or inference model deployment) is ingested via the AI Service Orchestrator.¶
In the centralized model, the JOCO is responsible for all metric collection, global optimization, and top-down command dispatch for both compute and network resources.¶
+----+ +---------+ +-------------+ +--------------+ +-------------+ |User| | AI Orch | | JOCO | | CPC | | PNC | +----+ +---------+ +-------------+ +--------------+ +-------------+ | | | | | |[Phase 1: Resource Provisioning] | | | | | | | |1. Intent | | | | |--------->| 2. Translate | | | | |---Demands--->| 3. Periodic Metric Collection | | | |<---Compute-----| | | | |<-------Network------------------| | | | | | | | |---+ 4. Calculate Joint | | | |<--+ Resource Allocation | | | | | | | | | 5a. Provision Optical Path | | | |-------------------------------->| | | | 5b. Lock Compute Resources | | Deployed| Deployed |--------------->| | |<---------|<-------------| | | | | | | | |[Phase 2: Utilization and Flexible Adjustment] | | | | | | | 6. User -driven | 7. State-driven| | |--------->|------------->|<---Alert-------| | | | |<-------Alert--------------------| | | |-Re-calculate-->| | | | |-Re-calculate------------------->| | | | | | |[Phase 3: Resource Release] | | | | | | | | 8. Terminate | | | |--------->|--Release---->|--Release------>| | | | |--------Teardown---------------->|
In the distributed model, orchestration is decentralized. Compute and service availability is advertised across the distributed control plane so that edge nodes can maintain an abstract view of optical and compute resource states. The AI Service Orchestrator translates an AI service intent into resource demands and sends them to the JOCO. In this model, the JOCO does not perform centralized joint resource computation; it relays the demand to the local CPC, which then drives the distributed optical-compute control chain. The edge optical nodes in the sequence below are PE nodes that host the Edge JOCO control-plane function and support the C-TC and CATS-Forwarder data-plane functions. The detailed protocol procedures used to advertise resources, provision paths, or release reservations are outside the scope of this framework and may be specified in separate protocol extension documents.¶
+-----+ +-------+ +--------+ +--------+ +-------+ +-----+ |CPC A| |OC-GW A| | PE-A | | PE-Z | |OC-GW Z| |CPC Z| +-----+ +-------+ +--------+ +--------+ +-------+ +-----+ | | | | | | | | [Phase 1: Resource Awareness] | | |--Metric->| | | |<-Metric--| | |--Metric->| |<---Metric---| | | | |<--Res view-->| | | | | | | | | | [Phase 2: Endpoint Selection and Link Establishment] | |--Demand->| | | | | | |-Forward->| | | | | | |---+ selects | | | | | |<--+ endpoint | | | |<---ACK---|<---ACK---| | | | | |------------------Path---------------->| | | |<---------------ACK--------------------| | | | | | | | | [Phase 3: Service Initialization and Execution] | | |------Initialization Service---------->| | | | | | |--Init--->| | | | | |<---ACK---| | |<---------------ACK--------------------| | | | | | |-Service->| | | | | |<-Result--| | |<--------------Result------------------| | |<-Result--| | | | | | | | | | | | [Phase 4: Adjustment, Recovery, or Release] | |--Update->|<--Alert--| | | | | |<-----------------Alert----------------|<--Alert--| | |--Adjust->| | | | | | |---+ Re-calculate | | | | |<--+ | | | | |<-Result--| | | | | |------------Adjust Path--------------->| | | | | | |--Adjust->| | | | | |<---ACK---| |<---ACK---|<-----------------ACK------------------| | | | | | | | |-Release->|-------------------------------------->| | | | | | |-Release->| | |<-----------------ACK------------------|<---ACK---| | |----------------Teardown-------------->| | |<---ACK---| | |
This document makes no request for IANA action.¶
The ONCO framework introduces a deeply integrated orchestration mechanism across compute and optical network domains. Because this framework handles high-value AI workloads, sensitive compute metrics, and core optical transport resources, securing the control, management, and data planes is critical. The security considerations are divided into system-level security and interface-level security.¶
System security focuses on the robustness, isolation, and availability of the end-to-end ONCO architecture.¶
The ONCO architecture relies on multiple standardized interfaces to bridge the management, control, and functional agents. Data transmitted over these interfaces MUST be protected against eavesdropping, spoofing, and man-in-the-middle (MitM) attacks.¶
The following people contributed significantly to this document:¶