A Control Framework for Optical Networks and AI Computing Orchestration (ONCO)
draft-tan-ccamp-onco-control-framework-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yanxia Tan , Zheng HAN , LiXiao , 10099490 , XingZhao | ||
| Last updated | 2026-07-06 | ||
| Replaces | draft-hu-ccamp-uonaco-control-framework | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tan-ccamp-onco-control-framework-00
ccamp Y. Tan
Internet-Draft China Unicom
Intended status: Informational Z. Han
Expires: 7 January 2027Beijing University of Posts and Telecommunications
X. Li
Huawei Technologies
S. Yang
ZTE Corporation
X. Zhao
CAICT
6 July 2026
A Control Framework for Optical Networks and AI Computing Orchestration
(ONCO)
draft-tan-ccamp-onco-control-framework-00
Abstract
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.
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 2027.
Tan, et al. Expires 7 January 2027 [Page 1]
Internet-Draft ONCO Control Framework July 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 . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Service Model for AI Computing over Optical Network . . . . . 6
3.1. Customer . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Service Provider . . . . . . . . . . . . . . . . . . . . 6
3.3. Network Provider . . . . . . . . . . . . . . . . . . . . 7
3.4. Computing Power Provider . . . . . . . . . . . . . . . . 7
4. ONCO Control and Management Architecture . . . . . . . . . . 7
4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 7
4.2. Functional Component Descriptions . . . . . . . . . . . . 9
4.2.1. Management Plane Entities . . . . . . . . . . . . . . 9
4.2.2. Control Plane Entities . . . . . . . . . . . . . . . 10
4.2.3. Data Plane Entities . . . . . . . . . . . . . . . . . 12
5. Applicable scenarios of Distributed and Centralized
Architectures . . . . . . . . . . . . . . . . . . . . . . 13
6. ONCO Operational Workflows . . . . . . . . . . . . . . . . . 14
6.1. Centralized Orchestration Workflow . . . . . . . . . . . 14
6.2. Distributed Orchestration Workflow . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. System Security . . . . . . . . . . . . . . . . . . . . . 19
8.2. Interface Security . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Tan, et al. Expires 7 January 2027 [Page 2]
Internet-Draft ONCO Control Framework July 2026
1. Introduction
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.
Tan, et al. Expires 7 January 2027 [Page 3]
Internet-Draft ONCO Control Framework July 2026
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:
* Section 3 defines the service model for AI computing over optical
networks, clarifying the roles and responsibilities of Customers,
Service Providers, Network Providers, and Computing Power
Providers.
* Section 4 describes the ONCO layered architecture and details the
specific functional entities across the management, control, and
data planes.
* Section 5 specifies the interaction procedures between these
functional components to achieve joint resource reservation and
provisioning in both centralized and distributed orchestration
scenarios.
Tan, et al. Expires 7 January 2027 [Page 4]
Internet-Draft ONCO Control Framework July 2026
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
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.
AI Service Orchestrator (ASO)
A management-plane entity that accepts high-level AI service
intents and translates them into structured resource demands.
Joint Optical-Compute Orchestrator (JOCO)
The centralized control-plane entity responsible for end-to-end
joint optical-compute orchestration.
Edge JOCO
A distributed control-plane entity deployed at an edge optical
network node, capable of autonomous remote AIDC selection and
optical path provisioning based on the extended joint traffic
engineering database (TED) that contains computing power
information.
Compute Power Controller (CPC)
A control-plane agent that monitors and locks resources within the
AI compute pool.
Provisioning Network Controller (PNC)
The ACTN transport-domain controller reused by ONCO for the
optical underlay. The PNC monitors optical network states,
abstracts optical topology, and executes deterministic optical
circuit provisioning.
ASO-JOCO Interface (AJI)
The northbound management interface between the ASO and the JOCO
for conveying high-level AI service intents and resource demands.
It can be viewed as an enhanced ACTN CMI for AI service intents.
Tan, et al. Expires 7 January 2027 [Page 5]
Internet-Draft ONCO Control Framework July 2026
JOCO-CPC Interface (JCI)
The southbound interface between the JOCO and the CPC for
monitoring and reserving of compute resources.
MDSC-PNC Interface (MPI)
The ACTN interface defined in [RFC8453] between the JOCO, acting
as an enhanced MDSC, and the PNC for monitoring and provisioning
of optical networks. ONCO does not define a separate optical-
controller interface.
Optical-Compute Gateway (OC-GW)
A protocol mediation gateway deployed at the AIDC edge,
facilitating the exchange of compute metrics between the compute
domain and the optical network. It can translate compute metrics
into network-layer TE attributes and trigger distributed routing
or signaling mechanisms; extended OSPF-TE [RFC3630] and extended
RSVP-TE [RFC3209] are possible examples.
3. Service Model for AI Computing over Optical Network
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.
3.1. Customer
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.
3.2. Service Provider
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,
Tan, et al. Expires 7 January 2027 [Page 6]
Internet-Draft ONCO Control Framework July 2026
billing, and customer support.
3.3. Network Provider
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.
3.4. Computing Power Provider
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.
4. ONCO Control and Management Architecture
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.
4.1. Architecture Overview
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.
Tan, et al. Expires 7 January 2027 [Page 7]
Internet-Draft ONCO Control Framework July 2026
+-------------------------------------------------------------+
| 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 | | |
| | +----------------+ | |
| +-----------------------------------------------+ |
+-------------------------------------------------------------+
Figure 1: Centralized ONCO Architecture
Tan, et al. Expires 7 January 2027 [Page 8]
Internet-Draft ONCO Control Framework July 2026
+-----------------------------------------------------------------------+
|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 +----------------------------+ |
+-----------------------------------------------------------------------+
Figure 2: Distributed ONCO Architecture
4.2. Functional Component Descriptions
4.2.1. Management Plane Entities
AI Service Orchestrator
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
Tan, et al. Expires 7 January 2027 [Page 9]
Internet-Draft ONCO Control Framework July 2026
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.
4.2.2. Control Plane Entities
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.
Joint Optical-Compute Orchestrator (JOCO)
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.
Tan, et al. Expires 7 January 2027 [Page 10]
Internet-Draft ONCO Control Framework July 2026
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.
Provisioning Network Controller (PNC)
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.
Compute Power Controller (CPC)
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.
Tan, et al. Expires 7 January 2027 [Page 11]
Internet-Draft ONCO Control Framework July 2026
Edge JOCO
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.
Optical-Compute Gateway (OC-GW)
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.
4.2.3. Data Plane Entities
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.
Tan, et al. Expires 7 January 2027 [Page 12]
Internet-Draft ONCO Control Framework July 2026
CATS-Forwarder
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.
CATS Traffic Classifier (C-TC)
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.
5. Applicable scenarios of Distributed and Centralized Architectures
Editor's note: This section describes the scenarios where distributed
and centralized orchestration architectures are most applicable.
Tan, et al. Expires 7 January 2027 [Page 13]
Internet-Draft ONCO Control Framework July 2026
6. ONCO Operational Workflows
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.
6.1. Centralized Orchestration Workflow
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.
Tan, et al. Expires 7 January 2027 [Page 14]
Internet-Draft ONCO Control Framework July 2026
+----+ +---------+ +-------------+ +--------------+ +-------------+
|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---------------->|
Figure 3: Centralized Orchestration Sequence
Phase 1: Resource Provisioning
The user submits an AI task intent to the AI Service Orchestrator
(Step 1), which translates it into specific compute and network
demands and forwards them to the JOCO (Step 2). Utilizing its
global view gathered via both the dedicated JCI for compute
metrics and the MPI for network states (Step 3), the JOCO
calculates the optimal joint allocation for both compute and
optical resources (Step 4). It then dispatches commands to the
PNC to provision the deterministic optical circuit (Step 5a) and
the CPC to lock the compute resources (Step 5b).
Tan, et al. Expires 7 January 2027 [Page 15]
Internet-Draft ONCO Control Framework July 2026
Phase 2: Utilization and Flexible Adjustment
During task execution, adjustments can be triggered by two
sources. User-driven adjustments occur when the customer updates
the SLA (e.g., scaling up compute resources) via the AI Service
Orchestrator (Step 6). State-driven adjustments occur when the
CPC or PNC detects threshold crossings (e.g., GPU memory
exhaustion or optical degradation) and alerts the JOCO (Step 7).
In both cases, the JOCO re-computes and dispatches update
instructions to dynamically scale resources without interrupting
the service.
Phase 3: Resource Release
Upon completion of the AI task, the AI Service Orchestrator
triggers a termination signal. The JOCO releases the compute
instances via the CPC and tears down the optical connections via
the PNC (Step 8).
6.2. Distributed Orchestration Workflow
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.
Tan, et al. Expires 7 January 2027 [Page 16]
Internet-Draft ONCO Control Framework July 2026
+-----+ +-------+ +--------+ +--------+ +-------+ +-----+
|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---| | |
Figure 4: Distributed Orchestration Sequence
Tan, et al. Expires 7 January 2027 [Page 17]
Internet-Draft ONCO Control Framework July 2026
Phase 1: Resource Awareness
The distributed orchestration process relies on an abstract
resource view that reflects both compute availability and optical
network state. CPC A and CPC Z collect compute pool status from
their respective AIDCs and make this information available to PE-A
and PE-Z through the corresponding OC-GWs. PE-A and PE-Z are edge
optical network nodes that host the Edge JOCO control-plane
function and support the C-TC and CATS-Forwarder data-plane
functions. Resource advertisements are exchanged across the
distributed optical control plane so that the Edge JOCO functions
can maintain an abstract resource view for subsequent endpoint
selection and resource coordination. The advertisement function
may be supported by distributed resource advertisement mechanisms,
for example extensions to OSPF-TE, but the ONCO framework does not
mandate a specific protocol realization.
Phase 2: Endpoint Selection and Link Establishment
After the AI service demand has been relayed to the local CPC, CPC
A checks local compute feasibility and, when local compute
resources are insufficient or remote compute resources are
explicitly required, delegates the remote service request to OC-GW
A. OC-GW A forwards the demand to the local PE-A edge node, where
the Edge JOCO function selects a suitable remote compute/service
endpoint, such as the PE-Z edge node and its associated AIDC,
based on the abstract resource view. After the endpoint is
selected, PE-A establishes deterministic connectivity toward PE-Z
through the distributed optical-compute control chain. The
deterministic connectivity establishment function may be supported
by distributed signaling, controller-based provisioning, or other
path provisioning mechanisms; the sequence shown here only
describes the architectural function.
Phase 3: Service Initialization and Execution
After the deterministic link has been established, the distributed
control chain triggers service initialization on the selected
remote side. The remote side prepares the service runtime,
initializes the requested AI service instance, and confirms
readiness back to the requesting side. Once the service
initialization is acknowledged, the C-TC identifies the relevant
AI service flow, and the CATS-Forwarder maps the classified flow
into the selected deterministic optical resource. Inference or
other AI service results are returned through the distributed
control chain to the AI Service Orchestrator as needed by the
service lifecycle.
Phase 4: Adjustment, Recovery, or Release
During service execution, the distributed control chain may handle
service adjustment, recovery, or release. A top-down service
Tan, et al. Expires 7 January 2027 [Page 18]
Internet-Draft ONCO Control Framework July 2026
update may modify the AI service requirement while retaining the
existing compute and optical connectivity resources, or may
trigger endpoint reselection and connectivity adjustment. A
bottom-up condition, such as compute load change, resource
conflict, or optical path failure, may trigger recovery procedures
including endpoint reselection, establishment of an alternative
deterministic optical connection, and release or teardown of the
affected optical connection. Upon service suspension, the AI
service may be stopped while associated compute and optical
connectivity resources are retained according to policy. Upon
service deletion, the same distributed control chain releases both
compute and optical connectivity resources according to the
requested service policy.
7. IANA Considerations
This document makes no request for IANA action.
8. Security Considerations
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.
8.1. System Security
System security focuses on the robustness, isolation, and
availability of the end-to-end ONCO architecture.
* *Resource Isolation and Multi-tenancy:* AI training and inference
tasks from different customers MUST be strictly isolated. In the
data plane, the optical underlay SHOULD utilize hard-isolation
technologies (e.g., fgOTN timeslots, ODUk) to prevent cross-talk
and side-channel attacks between tenants. In the compute domain,
robust virtualization or bare-metal isolation is required.
* *Denial of Service (DoS) Protection:* Malicious actors might
attempt to exhaust valuable compute (GPU) or deterministic optical
resources by flooding the AI Service Orchestrator with fake intent
requests. The system SHOULD implement strict rate-limiting,
resource quotas, and admission control at the AI Service
Orchestrator and JOCO levels.
Tan, et al. Expires 7 January 2027 [Page 19]
Internet-Draft ONCO Control Framework July 2026
* *Topology and Compute State Confidentiality:* The CPC collects
detailed compute pool metrics (e.g., GPU utilization, task
queues). If exposed, this data could reveal a Computing Power
Provider's business scale or operational status. Abstraction and
topology-hiding mechanisms (similar to ACTN Grey/Black topologies)
MUST be applied before exposing intra-domain states to a multi-
domain JOCO.
* *High Availability and Single Point of Failure:* In the
centralized orchestration model, the JOCO acts as a single
decision-making engine. It SHOULD be deployed with high
availability, state synchronization, and geographic redundancy to
prevent catastrophic failures caused by targeted attacks.
8.2. Interface Security
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.
* *Northbound Interface (AJI):* The interface between the AI Service
Orchestrator (ASO) and the JOCO handles customer SLA and AI
intents. It MUST support robust Authentication, Authorization,
and Accounting (AAA). Secure transport protocols (e.g., TLS/
HTTPS) and Role-Based Access Control (RBAC) are REQUIRED to ensure
that only authorized entities can request or modify resources.
* *Southbound Interfaces (MPI, JCI & NETCONF):* The JOCO
communicates with the PNC via the MPI and with the CPC via the
dedicated JCI. Similarly, in the distributed model, the local CPC
communicates with the OC-GW via NETCONF. These interfaces
transmit precise telemetry and provisioning directives. They MUST
utilize mutual authentication (e.g., mTLS) and data encryption to
prevent the malicious injection of false compute metrics or
unauthorized optical cross-connect teardowns.
* *Control Plane Protocols:* In the distributed workflow, resource
advertisement and deterministic connectivity establishment may be
supported by extensions to routing or signaling protocols, for
example OSPF-TE and RSVP-TE. When such protocols are used,
standard routing and signaling protocol security mechanisms MUST
be enabled. For example, cryptographic authentication for OSPFv2
[RFC5709] and RSVP [RFC2747] SHOULD be deployed to prevent rogue
nodes from injecting false compute/network states or tearing down
deterministic paths maliciously.
9. References
Tan, et al. Expires 7 January 2027 [Page 20]
Internet-Draft ONCO Control Framework July 2026
9.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>.
9.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-24, 2 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
framework-24>.
[I-D.zhao-cats-otn-applicability]
Zhao, Y., Han, L., LiXiao, Zheng, H., and D. King,
"Framework and Applicability of Computation-aware Traffic
Steering (CATS) in Optical Transport Networks (OTN)", Work
in Progress, Internet-Draft, draft-zhao-cats-otn-
applicability-01, 3 July 2026,
<https://datatracker.ietf.org/doc/html/draft-zhao-cats-
otn-applicability-01>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, October 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/info/rfc2747>.
Tan, et al. Expires 7 January 2027 [Page 21]
Internet-Draft ONCO Control Framework July 2026
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>.
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
Zheng Han
Beijing University of Posts and Telecommunications
Email: 2025010255@bupt.cn
Xiao Li
Huawei Technologies
Tan, et al. Expires 7 January 2027 [Page 22]
Internet-Draft ONCO Control Framework July 2026
Email: lixiao33@huawei.com
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 23]