Zhejiang Gongshang University

Zhejiang China chuanhuang_li@zjgsu.edu.cn

Zhejiang Gongshang University

Zhejiang China 13970967804@163.com

Zhejiang Gongshang University

Zhejiang China thq@mail.zjgsu.edu.cn

ZTE Corporation

Nanjing China miao.chuanyang@zte.com.cn

Zhejiang Gongshang University

Zhejiang China 1912190128@pop.zjgsu.edu.cn

China Mobile

China zhangshicong@cmhi.chinamobile.com

Zhejiang Gongshang University

Zhejiang China mabo@zjgsu.edu.cn

routing cats Internet-Draft This document proposes an extension to the Computing-Aware Traffic Steering (CATS) framework by introducing a task segmentation module. This extension enables the CATS framework to handle divisible computing requests by breaking them down into smaller computational units, referred to as "Task". The document focuses on two primary task segmentation modes: the distributed mode and the chain-structured Directed Acyclic Graph (DAG) model, providing detailed workflows for each.

Introduction With the growing demand for efficient and scalable network services, segmenting computational tasks for distributed processing has become increasingly important. This document extends the existing CATS framework by introducing a "Task Segmentation Module" (TSM), which collaborates with the CATS Service Metric Agent (C-SMA) and the CATS Network Metric Agent (C-NMA) to support task-aware traffic steering, including service contact instance selection and CATS-computed path selection.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document makes use of the terms defined in . In addition, the following terms are defined below:

CATS Service Metric Agent (C-SMA):

A functional entity that is responsible for collecting service capabilities and status, and for reporting them to a CATS Path Selector (C-PS). In the task segmentation scenarios described in this document, C-SMA information can be provided in a distributed manner by C-SMA functions associated with service sets or service sites, rather than by a single centralized function for all service sites. (From )

CATS Network Metric Agent (C-NMA):

A functional entity that is responsible for collecting network capabilities and status, and for reporting them to a C-PS. (From )

CATS Path Selector (C-PS):

A functional entity that selects paths towards service sites and instances, and thus towards service contact instances, in order to accommodate the requirements of service requests. The path selection engine takes into account service and network status information. (From )

Task:

In this document, a Task refers to a logical computational unit within a service request that can be processed independently or as a stage in a chain-structured DAG model. The granularity of a task is smaller than that of a service and represents specific operations executed within a service instance.

Task Identifier:

A Task Identifier is used to distinguish an original service request from the subtasks derived from it. An indivisible task uses a single task identifier. A divisible task can use suffixes to identify subtasks derived from the original task identifier, for example 2.1 and 2.2 for two subtasks derived from task 2.

Computing Power Brain (CPB):

The Computing Power Brain (CPB) is responsible for coordinating C-NMA and C-SMA information and transmitting task segmentation instructions to the C-TEA.

CATS Task Execution Agent (C-TEA):

The CATS Task Execution Agent (C-TEA) is responsible for receiving task data and determining the task segmentation method and optimal path. It receives task segmentation instructions transmitted by the CPB, transforms logical tasks into actionable task units, and interacts with the CATS Path Selector (C-PS) and the CATS-Forwarder to ensure task-related traffic is steered to the appropriate service sites. The term execution in C-TEA refers to the application of task segmentation and steering instructions in this document; it does not require CATS to execute the application computation itself.

Task Segmentation Module (TSM):

The Task Segmentation Module (TSM), primarily composed of the CPB and C-TEA, is a functional component tasked with analyzing incoming requests and segmenting them into smaller task units based on their dependencies and independence. For further details, see .

Task Segmentation Module (TSM) To enhance the utilization of computing and network resources, this document extends the CATS framework by introducing the concept of task segmentation. Task segmentation involves breaking down received service requests into smaller computational units to enable more efficient distribution and processing across network and computing resources. Tasks can be categorized into two types based on their characteristics: divisible tasks and indivisible tasks.

Divisible and Indivisible Tasks

Divisible Tasks:

These refer to computational requests that are still divisible when they are received. A divisible task can be represented as multiple subtasks. The subtasks can either be processed non-dependently or executed sequentially. A divisible task can retain the identifier of the original task and add suffixes for subtasks, for example task 2.1 and task 2.2.

Indivisible Tasks:

These are computational requests that have already reached the minimum processing granularity when they are received and cannot be broken into subtasks. An indivisible task is processed as a whole and uses a single task identifier.

Classification of Divisible Tasks Divisible tasks can be further divided into dependent tasks and Non-dependent tasks.

Dependent Tasks:

These tasks exhibit a defined sequence of execution and dependencies among subtasks. For example, the output of Task A serves as the input for Task B. Traffic steering decisions, service contact instance selection, and CATS-computed path selection must preserve these dependencies so that task-related traffic follows the required order, consistent with computational logic and data-flow requirements.

Non-dependent Tasks:

These tasks can be divided into relatively autonomous atomic tasks, each of which can be completed Non-dependently without relying on the results of other tasks. Non-dependent tasks are suitable for parallel processing, significantly improving computational efficiency.

Task Segmentation Process This section describes the task segmentation process. The C-TEA determines the task segmentation method and optimal path, while the CPB transmits the corresponding segmentation instructions.

Task Reception:

The CPB receives computational requests from clients and provides the related task data to the C-TEA.

Task Analysis:

Based on the characteristics and requirements of the request, the C-TEA determines whether the task is divisible. If the task is indivisible, it is treated as a whole and uses a single task identifier.

Task Identifier Assignment:

If the task is divisible, the C-TEA or the task segmentation logic can identify subtasks by adding suffixes to the original task identifier. For example, an original task 2 can be represented as task 2.1 and task 2.2 after segmentation.

Task Classification:

If the task is divisible, the C-TEA further analyzes whether it involves task dependencies. If the task is indivisible, the request is steered as a whole towards a suitable service contact instance, as described in I-D.ietf-cats-framework.

Traffic Steering and Service Selection:

When a task is divisible, traffic associated with dependent tasks is steered sequentially between service sites according to their dependencies. Traffic associated with non-dependent tasks can be steered to different service contact instances for parallel processing. The C-TEA determines task segmentation and CATS-computed paths using C-SMA and C-NMA information. The CPB transmits the corresponding segmentation instructions, and the C-TEA applies the task representation. Specific segmentation details, including segmentation ratio and the number of subtasks, are beyond the scope of this document.

Application Scenarios for Task Segmentation Task segmentation significantly optimizes traffic steering and resource utilization within the CATS framework. This section provides the original dependent and non-dependent categories and adds a concrete example for a chain-structured DAG model.

Applications for Dependent Tasks:

These are suitable for scenarios requiring sequential execution, such as data stream computing or complex pipeline processing, e.g., multi-step encoding and compression in video processing.

Agent-Based Enterprise AI Assistant:

A concrete example of a chain-structured DAG model is an agent-based enterprise AI assistant. For example, a user can submit a request to generate an answer based on enterprise policy documents. This service request can be represented as a sequence of dependent subtasks. The first subtask performs intent analysis and identifies the user intent, required knowledge domain, and possible tool requirements. The second subtask performs knowledge retrieval or tool selection based on the output of the intent analysis subtask. The third subtask performs reasoning and answer planning based on the retrieved information or tool results. The fourth subtask generates the final response. These subtasks form a chain-structured DAG model because each subtask depends on the output of the previous subtask. Knowledge retrieval cannot be performed correctly before the intent is identified, reasoning cannot be performed before the relevant knowledge or tool result is available, and response generation depends on the reasoning result. Therefore, the service request can be represented as Task 1 -> Task 2 -> Task 3 -> Task 4.In this scenario, the application layer can describe the logical task chain by agent names, such as an intent analysis agent, a retrieval agent, a reasoning agent, and a response generation agent. The CATS-enabled network does not execute these agents. Instead, CATS uses the task model, service status, and network status to select suitable service sites and CATS-computed paths for traffic associated with each subtask. If multiple instances of the same agent are available, the concrete instance selection can be handled by a service gateway or internal service routing policy within the service set.

Applications for Non-dependent Tasks:

These are ideal for large-scale parallel computing, such as batch image processing or distributed data analysis tasks. By representing non-dependent tasks, CATS can select suitable service contact instances and CATS-computed paths for traffic associated with parallel subtasks, based on service and network status.

The Role of Task Segmentation in the CATS Framework Tasks serve as the fundamental units for representing service requests in task-aware CATS steering. By segmenting requests into tasks, the CATS framework can optimize resource utilization and path selection in a more granular manner based on the current state of network and computing resources. The introduction of tasks enables the CATS framework to achieve the following:

Optimizing Path and Service Selection:

Through task segmentation and task representation, CATS can select suitable service contact instances and CATS-computed paths, thereby enhancing the utilization of both computing and network resources.

Supporting Parallel Steering:

For divisible non-dependent tasks, CATS can steer task-related traffic to service contact instances that support parallel processing.

Supporting Dependency Management:

In the chain-structured DAG model, inter-task dependencies can be maintained to ensure the correct order of computation.

CATS Workflow under Multi-Task Segmentation

Distributed Mode In the distributed mode, a task is represented as non-dependent subtasks, and traffic associated with those subtasks is steered to multiple service contact instances for parallel processing. This mode is suitable for tasks without dependencies. As shown in .The detailed workflow for distributed tasks is as follows:

1. The client sends a service request. The CPB receives the request and provides the related task data to the C-TEA, which determines that the task type is non-dependent.
2. The C-TEA uses service and network status information from the C-SMA and C-NMA to determine the segmentation method and CATS-computed paths. The CPB transmits the corresponding segmentation instructions.
3. The C-PS selects a CATS-computed path for each subtask. The ingress CATS-Forwarder steers each subtask along its selected path to the corresponding egress CATS-Forwarder and service site.
4. Each selected service contact instance processes its associated subtask in parallel, and the results are aggregated and returned to the client.

Distributed Framework (assumes segmentation into 3 subtasks) +-----+ +------+| +-------+ |client|+------------------------>| CPB | +---+--+ +-------+ | | ^ ^ | | | | +---+---+ | | | | C-TEA |<------------------------+ | | +---+---+ | | | | | | | | +-------------------+---------------------+ | | | | | | | | | | | | +---------+------+ +---------+------+ +-----------+----+ | | | |C-PS#1| | |C-PS#2| | |C-PS#3| | | ....| +------|..| +------|..| +------|.... | | : |CATS-Forwarder 1| |CATS-Forwarder 2| |CATS-Forwarder 3| : | | : +----------------+ +----------------+ +----------------+ : | | : : | | : : | | : Underlay +-------+ : | | : Infrastructure | C-NMA |----------+ | : +-------+ : | : : | : : | : : | : +----------------+ +----------------+ +----------------+ : | : |CATS-Forwarder 4| |CATS-Forwarder 5| |CATS-Forwarder 6| : +-------+ ....| |..| |..| |.... | C-SMA | +------+---------+ +--------+-------+ +--------+-------+ +-------+ | | | ^ ^ ^ | | | | | | | | | | | | +------------+ +------------+ +------------+ | | | +------------+ | +------------+ | +------------+ | | | | | Service | | | Service | | | Service | | | | | | Contact | |--+ | Contact | |--+ | Contact | |----+ | | | Instance |-+ | | Instance |-+ | | Instance |-+ | | +------------+ | +------------+ | +------------+ | | Service Site 1 | Service Site 2 | Service Site 3 | | | +--------------------------+ | +----------------------------------------------------+

Chain-Structured DAG Model The chain-structured DAG model is applicable for tasks with interdependencies, where each subtask depends on the output of the previous subtask and must be routed sequentially between service sites. An example is an agent-based enterprise AI assistant, where a user request is processed by a sequence of agent subtasks, such as intent analysis, knowledge retrieval or tool selection, reasoning and answer planning, and response generation. As shown in , the detailed workflow for the agent-based enterprise AI assistant under the chain-structured DAG model is as follows:

1. The client sends an enterprise AI assistant request. The CPB receives the service request and represents it as a chain of dependent subtasks, for example Task 1 for intent analysis, Task 2 for knowledge retrieval or tool selection, Task 3 for reasoning and answer planning, and Task 4 for response generation.
2. The C-TEA receives the data and determines the segmentation method and optimal path. The CPB uses the network status and service status provided by the C-SMA and C-NMA to transmit the segmentation instructions.
3. The C-TEA receives the instructions and represents the agent subtasks as task units that can be used for CATS traffic steering.
4. The traffic associated with Task 1 is steered to the selected service contact instance for intent analysis. After Task 1 is completed, its output is used as the input of Task 2. The same process is then applied, in the dependency order of the chain-structured DAG model, to knowledge retrieval or tool selection, reasoning and answer planning, and response generation.
5. After the response generation subtask is completed, the final result is returned to the client.

Chain-Structured DAG Framework (assumes segmentation into 4 subtasks) +-----+ +------+| +-------+<-------------------------------------------------+ |client|+------------------------>| CPB | | +---+--+ +-------+<-----------------------------------------------+ | | | ^ | | | | | | | +---+---+<------------------------+ | | | | C-TEA | | | | +---+---+---------------------------------+ | | | +-----------+ +---------+ +---------+ | | | | | | | | | | | +---------+------+ | +-------+--------+ | +-----+----------+ | +-----+----------+ | | | |C-PS#1| | | |C-PS#2| | | |C-PS#3| | | |C-PS#4| | | ..| +------|.. | ..| +------|.. | ..| +------|.. | ..| +------|.. | | : |CATS-Forwarder 1| : | : |CATS-Forwarder 2| : | : |CATS-Forwarder 3| : | : |CATS-Forwarder 4| : | | : +----------------+ : | : +----------------+ : | : +----------------+ : | : +----------------+ : | | : Underlay : | : Underlay : | : Underlay : | : Underlay : | | : Infrastructure : | : Infrastructure : | : Infrastructure : | : Infrastructure : | | : : | : : | : : | : : | | : +-------+ : | : +-------+ : | : +-------+ : | : +-------+ : | | : | C-NMA | : | : | C-NMA | : | : | C-NMA | : | : | C-NMA | : | | : +---+---+ : | : +---+---+ : | : +---+---+ : | : +---+---+ : | | : | : | : | : | : | : | : | : | | : +----------:-|-:---------+----------:-|-:---------+----------:-|-:---------+----------:--|-+ : +----------------+ : | : +----------------+ : | : +----------------+ : | : +----------------+ : | : |CATS-Forwarder 5| : | : |CATS-Forwarder 6| : | : |CATS-Forwarder 7| : | : |CATS-Forwarder 8| : | ..| |.. | ..| |.. | ..| |.. | ..| |.. | +----------------+ | +----------------+ | +----------------+ | +----------------+ | | | | | | | | | | | | | | | | | +------------+ | +------------+ | +------------+ | +------------+ | +------------+ | | +------------+ | | +------------+ | | +------------+ | | | Service | |------+ | Service | |-------+ | Service | |-------+ | Service | | | | Contact | |--+ | Contact | |--+ | Contact | |--+ | Contact | |--+ | | Instance |-+ | | Instance |-+ | | Instance |-+ | | Instance |-+ | | +------------+ | +------------+ | +------------+ | +------------+ | | Service Site 1 | Service Site 2 | Service Site 3 | Service Site 4 | | | | | | | | | | | | +-------+<-+ +-------+<-+ +-------+<-+ +-------+<-+ | | C-SMA | | C-SMA | | C-SMA | | C-SMA | | +---+---+ +---+---+ +---+---+ +---+---+ | | | | | | +-----------------------+------------------------+------------------------+------------+

Security Considerations TBD

IANA Considerations TBD

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Huawei Technologies China Mobile Orange Telefonica Independent This document describes a framework for Computing-Aware Traffic Steering (CATS). Particularly, the document identifies a set of CATS components, describes their interactions, and exemplifies the workflow of the control and data planes.

Acknowledgements TBD