| Internet-Draft | CATS-MUP Service Segmentation | October 2026 |
| Bui, et al. | Expires 16 April 2027 | [Page] |
Service segmentation introduces an emerging deployment paradigm in which a service is composed of multiple distributed subtasks forming a service pipeline. This document discusses architectural considerations for steering sessions across multiple subtask instances in sequential, parallel, and iterative service pipelines, including a MUP Sequence Session Transform to support ordered traversal, and for maintaining service continuity during pipeline updates, particularly when stateful subtasks are involved.¶
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 16 April 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 document [I-D.draft-dcn-dmm-cats-mup] describes how to integrate Computing-Aware Traffic Steering (CATS) capabilities into the Mobile User Plane (MUP) architecture. In that design, when multiple candidate service instances are deployed at different locations, the MUP Controller (MUP-C), as the core component of the architecture, selects the optimal service instance by considering computing and network information. The MUP-C receives user mobility session information from the control plane entity and converts such session information into IPv6 dataplane routing information. Instead of relying on traditional anchoring mechanisms or intermediate user plane forwarding nodes, the session is directly mapped into SRv6-based routing instructions in the underlay network. The Type 2 Session Transformed Route (T2ST) and Type 1 Session Transformed Route (T1ST) are used to convert session information into SRv6-based routing paths toward the selected service endpoint. As a result, traffic steering is realized at the IP routing level without requiring dedicated anchor or intermediate nodes in the mobile user plane.¶
However, emerging 6G applications introduce a new deployment paradigm, where a service is decomposed into multiple subtasks that are distributed across different edge locations. These subtasks can be organized as a sequential service pipeline, where traffic must traverse service instances in a predefined sequence, as a parallel service pipeline, where traffic is distributed to multiple service instances and later merged, or as an iterative service pipeline, where two subtasks exchange intermediate results repeatedly before a result is returned. Distributed AI Inference gives examples of all three: an ML model inference service can be segmented by model structure (parallel), by inference phase as in prefill-decode disaggregation (sequential), or by model role as in speculative decoding (iterative), in which one of the subtasks may be located at a remote site outside the CATS domain. Such service segmentation scenarios are discussed in [I-D.draft-dcn-cats-req-service-segmentation].¶
The existing T1ST and T2ST mechanisms are defined for mapping a session to a selected service instance, where traffic is steered toward a specific execution endpoint. While this model is suitable when a session is directed to one optimal service instance, service segmentation introduces scenarios in which a sequential service pipeline spans multiple service instances as part of a single service execution. In such cases, the session-to-route transformation must not only select appropriate service instances, but also support ordered traversal across them and preserve overall service continuity, particularly when the pipeline includes stateful subtasks.¶
The existing CATS-MUP architecture focuses on mapping a session to a selected service instance. This document discusses scenarios where a service execution consists of multiple distributed subtasks forming a pipeline. It discusses extensions to session transformation behavior to enable ordered traversal across multiple subtask instances and to support service continuity during pipeline updates, particularly when stateful subtasks are involved.¶
This document uses the terminology defined in [I-D.draft-dcn-dmm-cats-mup] and [I-D.draft-dcn-cats-req-service-segmentation].¶
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].¶
This document does not define mechanisms for constructing or orchestrating service pipelines. Pipeline composition, subtask placement, and lifecycle management are considered out of scope. Furthermore, it does not modify or redefine existing SRv6 behavior definitions and relies on procedures specified in existing SRv6 and SFC specifications.¶
+----------------+
| Mobility |
| Management |
| System |
+----------------+
|
Session Information
|
STR +--------v-------+
+------| CATS-MUP-C |
+--|------| +------+ |----------+
| | | | C-PS | | |
| | +----------------+ | +-----------------+
UE- | v | | C-SMA |
\+---+ +------+ DSD +------+ |-----------------|
UE--|RAN|---| PE |<----------------------| PE |----| Service Site A |
+---+ +------+<-----------\ +------+ | Subtask 1 |
UE-/ |Buffer| \ |Buffer| | Subtask 3 |
+------+ \ +------+ +-----------------+
| \ |
| MUP network \ +------+ +-----------------+
| +-------+ \-----| PE |----| C-SMA |
| | C-NMA | +------+ |-----------------|
| +-------+ |Buffer| | Service Site B |
+------------------------------+------+ | Subtask 1 |
| Subtask 2 |
+-----------------+
Figure 1 illustrates the high-level architecture for supporting service segmentation in the CATS-MUP environment, where an application is decomposed into multiple subtasks deployed across different edge sites. Depending on deployment and execution logic, these subtasks may form sequential chains, parallel branches, or iterative exchanges between two subtasks, requiring traffic steering to evolve from single-instance selection toward pipeline-aware steering across distributed subtasks.¶
For sequential pipelines, existing Session Transform Routes, including T1ST and T2ST, require the C-PS to configure traffic steering independently for each MUP-PE along the execution chain. As a result, the completion time of the CATS-MUP-C operation increases proportionally with the number of subtasks composing the pipeline. The situation becomes more complex when the active pipeline must be updated or replaced due to mobility events or changing resource conditions, since multiple steering configurations must be recomputed and consistently applied across all participating nodes. To address this limitation, this document proposes a new Session Transform Route referred to as the MUP Sequence Session Transform, enabling pipeline-level traffic steering for sequential service execution. The detailed design is presented in Section 4.¶
For parallel pipelines, existing T1ST and T2ST mechanisms remain applicable because traffic distribution and result aggregation can be handled by split and merge functions. User requests may be distributed across parallel subtasks, and intermediate results are combined before delivering the final outcome to the UE. However, each parallel branch may itself consist of a sequential chain of subtasks, in which case the same scalability and steering reconfiguration issues as observed in sequential pipelines arise. Therefore, the proposed MUP Sequence Session Transform can also be applied within such branches to enable pipeline-level traffic steering.¶
For iterative pipelines, a segment list installed when the session is established encodes a fixed, ordered traversal, whereas the number of exchanges between the two subtasks of an iterative pipeline depends on the processed data and is not known in advance. Moreover, these exchanges are generated by the subtask instances themselves rather than carried in the uplink traffic of the session, and, in the case considered in this document, one of the two subtasks is a remote service subtask outside the CATS domain. The session is therefore steered to the selected subtask instance in the CATS domain by a T2ST, as for a single service instance, and the iterative exchange with the remote service subtask takes place outside the MUP, as described in Section 5.¶
Service segmentation may involve stateful subtasks, making subtask migration necessary when an existing pipeline no longer satisfies QoS requirements. Maintaining service continuity during pipeline transitions requires preventing packet loss while new subtask instances are activated and traffic steering is updated. One approach to enabling such transitions is the use of SRv6-based buffering, which temporarily stores packets during path updates and releases them once the new execution pipeline becomes operational.¶
Furthermore, a single subtask type may have multiple instances deployed across different MEC sites. Selecting an optimal pipeline based solely on per-instance evaluation may introduce significant decision overhead as deployment scale increases. To address this challenge, Service Pipeline Metrics are introduced to evaluate pipelines as unified entities rather than independent instances, enabling efficient pipeline selection as described in [I-D.draft-dcn-cats-req-service-segmentation].¶
The MUP Sequence Session Transform defines how the Mobile User Plane steers packets across an ordered set of service stages using a single session transformation operation. Under this mechanism, the execution sequence of a service pipeline is encoded directly into packet forwarding behavior at MUP-PE nodes.¶
+-----------+ +-----------+
| Subtask 1 | | Subtask 2 |
+-----------+ +-----------+
| |
+-----------+ +-----------+
| SFC Proxy | | SFC Proxy |
+-----------+ +-----------+
^ ^
+----------+ | +----------+ +----------+ | +----------+
|NSH(X,255)| | |Inner Pkt | |NSH(X,254)| | |Inner Pkt |
+----------+ | +----------+ +----------+ | +----------+
|Inner Pkt | | |NSH(X,254)| |Inner Pkt | | |NSH(X,253)|
+----------+ v +----------+ +----------+ v +----------+
+--+ +------+ +--------+ +--------+
|UE|->|RAN PE|---------->|MUP PE 1|------------------>|MUP PE 2|
+--+ +------+ +--------+ +--------+
+-------------+ +-------------+
| SRH | | SRH |
|[0]: MUP PE 2| |[0]: MUP PE 2|
|[1]: MUP PE 1| |[1]: MUP PE 1|
| SL: 2 | | SL: 1 |
+-------------+ +-------------+
| NSH(X,255) | | NSH(X,254) |
+-------------+ +-------------+
| Inner Pkt | | Inner Pkt |
+-------------+ +-------------+
The execution order of a service pipeline is encoded directly into packet forwarding state. Specifically, the SRv6 segment list carried in the SRH defines the traversal sequence across MUP-PE nodes, while service processing context is maintained within the packet using SRv6 Service Function Chaining (SFC) mechanisms, as specified in [RFC9491]. As illustrated in Figure 2, packets advance along the pipeline as each MUP-PE processes its local segment and updates the associated service context.¶
When traffic is steered according to the SRv6 segment list, each MUP-PE performs the following processing steps:¶
By embedding pipeline progression into dataplane processing, the MUP Sequence Session Transform enables ordered service execution across multiple edge locations.¶
+----------------------------------------+
| MUP network +-----------+ +-----------+
| +---------+ | Subtask A |=L1=>| |
| |MUP PE 1 |<-->| (draft) |<L2==| |
| +---------+ |Edge site 1| | |
+--+ | +---------+ ^ +-----------+ | Subtask B |
|UE|<-->| RAN PE |-----------+ | | (target) |
| | | |(ingress)| +-----------+ |Remote site|
+--+ | +---------+ +---------+ | Subtask A |=L1=>| |
| |MUP PE 2 |<-->| (draft) |<L2==| |
| +---------+ |Edge site 2| | |
| +-----------+ +-----------+
| session steered by T2ST |
+----------------------------------------+
L1 (spec) / L2 (verdict): exchanged once per iteration between an
edge site and the remote site, outside the MUP network. In this
example, the session is steered to the draft model at Edge site 1.
Figure 3 illustrates the speculative decoding example of [I-D.draft-dcn-cats-req-service-segmentation]. Draft model instances (Subtask A) are hosted at Edge site 1 and Edge site 2, which are located at the edge of the MUP network and attached to it through MUP PE 1 and MUP PE 2. The target model (Subtask B) is located at a remote site outside the MUP network and the CATS domain, and can be reached from both edge sites.¶
In practical deployments, service segmentation often involves stateful service instances, where execution state must be preserved across service instance relocation or pipeline reconfiguration. In such scenarios, immediate redirection of traffic to a newly selected service pipeline may result in service disruption if the target instances are not yet ready to process incoming requests or if state migration is still in progress.¶
For example, consider a sequential service pipeline composed of five subtasks executed in order. The first four subtasks are stateless, while the fifth subtask is a stateful application. When the stateful subtask is migrated due to mobility events or computing resource degradation, packets processed by the upstream stateless subtasks (i.e., Subtasks 1 through 4) may reach at the stateful subtask before migration is completed. As a result, these packets may be dropped or fail to be processed correctly, leading to wasted computing resources and unnecessary consumption of network bandwidth.¶
To preserve service continuity during pipeline transition, this document considers new use behaviors [future-SRv6-service-continuity], such as End.M.GTP6.D.Buffer, an extension of the End.M.GTP6.D function, integrated into all MUP Session Transform Routes. These behaviors enable traffic to be temporarily held while stateful service instances are being migrated.¶
This memo includes no request to IANA.¶