CATS Working Group Jaehwoon Lee Internet-Draft Dongguk University Intended status: Informational May 11, 2026 Expires: November 10, 2026 Network-based mobility management in CATS network environment draft-jaehwoon-cats-mobility-04 Abstract Computing-Aware Traffic Steering (CATS) network architecture is to choose the best edge computing server by considering both the network environment and available computing/storage resources of the edge computing server. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress CATS-Router by using the PMIPv6-based mobility management method in the CATS-based edge computing networking environment. 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 November 10, 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. Jaehwoon Lee Expires Nov. 10, 2026 [Page 1] Internet-Draft Mobility management in CATS network May 11, 2026 Table of Contents 1. Introduction.................................................2 2. Conventions and Terminology..................................4 2.1. Conventions used in this document........................4 2.2. Terminology..............................................4 3. Protocol Operation...........................................4 4. Message Formats..............................................8 4.1. CATS mobility notification and request messages..........8 4.2 CATS mobility indications message........................9 4.3 Mobile node address and CATS address options............10 5. Security Considerations.....................................10 6. IANA Considerations.........................................10 7. References...................................................11 Author's Address................................................11 1. Introduction Cloud computing provides powerful computing and nearly unlimited storage resources to client devices connected over the Internet. However, if the number of clients such as Internet of Things (IoT) devices is quite large, the amount of traffic exchanged between clients and the cloud computing server is also high and it can cause congestion over the Internet. When congestion occurs on the path between a client and the cloud computing server, the client transmitting service request may experience long response time in receiving the result of the service request, or the service request itself may be lost. In edge computing, even though edge computing server provides smaller computing and storage resources compared to the cloud computing server, multiple number of edge computing servers can be located near client devices and the client sending service request can benefit from shorter response time. In the edge computing environment, one way for a client to find a suitable edge computing server is to choose the nearest edge server based on the location of the client inferred from the client's source IP address. Another way is to choose one of the several edge servers by using the round- robin method. However, in such cases, either the available resource in the chosen server can be insufficient or poor network condition between the client and the chosen edge server may result in long response time for the service request of the client. IETF CATS working group tries to standardize the mechanism to choose the best edge computing server by considering both the networking environment and available computing/storage resources of the edge computing server[1]. Here, a service is represented by an CATS Service ID (CS-ID). Assume that there is a client trying to Jaehwoon Lee Expires Nov. 10, 2026 [Page 2] Internet-Draft Mobility management in CATS network May 11, 2026 receive a service provided by a specific service instance. In this case, ingress CATS-Forwarder acts as a gateway for the client. In addition, egress CATS-Forwarder is connected to the edge computing server in which specific service instance is installed. Assume that there are N edge servers providing the same specific service. Moreover, we assume that different edge servers are connected to different egress CATS-Forwarders. The client transmits a service request message with CS-ID as a destination IP address. Ingress CATS-Forwarder chooses the best egress CATS-Forwarder by using the combination of the network metric such as delay, and computing metric such as available computing/storage resource of edge servers. The ingress CATS-Forwarder transmits the service request sent by the client to the chosen egress CATS-Forwarder. After which egress CATS- Forwarder transmits the service request to the service instance in the edge computing server. The result of the service request is in turn transmitted from the edge server to the client through the egress CATS-Forwarder and the ingress CATS-Forwarder. When a client transmits a service request and then moves to another network before receiving the service result, the client can no longer receive the result of the service request. When the client moves and connects to a new ingress CATS-Forwarder, host-based mobility management method such as Mobile IPv6 (MIPv6) can be used to maintain end-to-end connectivity[2]. In this case, the destination IP address of the service request message sent by the client is the CS-ID. This means that the new ingress CATS-Forwarder cannot know the address of the egress CATS-Forwarder connected to the edge server providing service to the client. Therefore, host- based mobility management cannot be used in the CATS networking environment. Network-based mobility management mechanism such as Proxy MIPv6 (PMIPv6) can be used in the CATS networking environment if the new ingress CATS-Forwarder knows the address of the egress CATS-Forwarder connected to the edge server providing service to the client[3]. In this case, service continuity is ensured for the client. However, new ingress CATS-Forwarder cannot know the IP address of the egress CATS-Forwarder only using the address information of the IP packet sent by the client. The reason is that the destination address of the IP packet indicates not the same egress CATS-Forwarder that the client are connected but the same specific service. As mentioned above, when moving from one network to another while the connection between the client and the edge server is established, if the transaction between the client and the edge server needs to continue for a considerable period of time, the current edge server to which the client is connected may not be the optimal server when considering both network resources and computing resources. In this case, the new ingress CATS-Forwarder to which the client is connected needs to select a new optimal edge server considering both network resources and computing resources, and Jaehwoon Lee Expires Nov. 10, 2026 [Page 3] Internet-Draft Mobility management in CATS network May 11, 2026 transmit the client's current state information from the existing edge server to the new edge server, so that the client can continue to receive computing service from the new optimal edge server. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress CATS-Forwarder by using the PMIPv6-based mobility management method in the CATS-based edge computing networking environment. Moreover, This draft also describes a technique to enable a new ingress CATS- Forwarder to select a new edge server suitable for the client's service request when a client moves while establishing a connection with an edge server and receiving service responses, and to enable the client to continuously receive services from the new edge server. 2. Conventions and Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. 2.2 Terminology TBD. 3. Protocol Operation When a client moves from an ingress CATS-Forwarder to another ingress CATS-Forwarder before receiving all the service results, either proactive method of reactive method can be utilized to provide service continuity. Fig. 1 shows the message exchange procedure to provide service continuity proactively when a client moves to another network in CATS networking environment. If the client transmits service request message with CS-ID as a destination IP address, an ingress CATS-Forwarder (that is, old ingress CATS-Forwarder) chooses the best egress CATS-Forwarder by using the combination of the network metric and computing metric. The old ingress CATS-Forwarder transmits the service request to the chosen egress CATS-Forwarder. The egress CATS-Forwarder transmits the service request message to the corresponding service instance in the edge computing server. When the old ingress CATS-Forwarder detects the movement of the client before completing transmission of all service results, it transmits the CATS mobility notification message including the addresses of the client and the chosen egress CATS-Forwarder to one or more candidate new ingress CATS-Forwarders that client may Jaehwoon Lee Expires Nov. 10, 2026 [Page 4] Internet-Draft Mobility management in CATS network May 11, 2026 connect to. How the old ingress CATS-Forwarder can know the movement of the client is TBD. One example is to utilize the warping the edge [5]. The format of the CATS mobility notification message is defined in Section 4.1. Here, how the old ingress CATS-Forwarder can know the movement of the client is out of scope. One method is to use the signal strength of the client. Moreover, how the old ingress CATS-Forwarder can know which is the new ingress CATS-Forwarder that the client moves and connects to is TBD. One method is for the old ingress CATS-Forwarder to broadcast the CATS mobility notification message to neighbor ingress CATS-Forwarders. Another method is to find some candidate ingress CATS-Forwarders by using the GPS information of the client. When the client moves and connects to a new ingress CATS-Forwarder, the new ingress CATS-Forwarder transmits the CATS mobility indication message having the IP address of the client to the old ingress CATS-Forwarder and establishes the tunnnel with the old ingress CATS-Forwarder. The format of the CATS mobility indication message is defined in Section 4.2. The old ingress CATS- Forwarder having received the CATS mobility indication message also establishes the tunnel with the new ingress CATS-Forwarder. Client old ingress new ingress egress Forwarder Edge Forwarder Forwarder server | | | | | |<--connect -->| | | | |-service req->| | | | | |------ service request --------->| | | | | |-service req ->| (movement) | | | | | (client move detection) | | | | |- notify msg ->| | | |<----- connect ---------->| | | | |<-- ind. msg --| | | | |<=est. tunnel=>| | | | | | |<- svc result--| | |<---- service result -----| | | |- svc result ->| | | |<--- svc result ----| | | | | |--- ind. msg --->| | | | | |<- svc result--| | | |<-- svc result --| | |<--- svc result ----| | | Figure 1: Message exchange procecure - proactive method Moreover, the new ingress CATS-Forwarder transmits the CATS mobility indication message having the client's IP address and the IP address of the old ingress CATS-Forwarder to the egress CATS-Forwarder. From now on, the old ingress CATS-Forwarder and the egress CATS-Forwarder can transmit all services results to the client through the new ingress CATS-Forwarder. Jaehwoon Lee Expires Nov. 10, 2026 [Page 5] Internet-Draft Mobility management in CATS network May 11, 2026 Fig. 2 shows the message exchange procedure to provide service continuity reactively to the client. If the client moves and connects to a new ingress CATS-Forwarder, the new ingress CATS- Forwarder transmits the CATS mobility request message including the IP address of the client to the old ingress CATS-Forwarder. The format of the CATS mobility request message is defined in Section 4.1. Here, how the new ingress CATS-Forwarder can know the address information of the old ingress CATS-Forwarder is TBD. One method is to use a location server. When a client connects to an old ingres CATS-Forwarder, the old CATS-Forwarder store the IP and link layer addresses of the client and the IP address information of the egress CATS-Forwarder that the service request of the client is transmitted in the location server. The information regarding the client can be removed just after all service results are transmitted to the client. When a client moves to a new ingress CATS-Forwarder, then the new ingress CATS-Forwarder can know whether the client is a new client or the client requiring service continuity by quering the information stored in the server. Client old ingress new ingress egress Forwarder Edge Forwarder Forwarder server | | | | | |<--connect -->| | | | |-service req->| | | | | |------ service request --------->| | | | | |-service req ->| (movement) | | | | |<----- connect ---------->| | | | |<-- req. msg --| | | | |- notify msg ->| | |<=est. tunnel=>| | | | | | |<- svc result--| | |<---- service result -----| | | |- svc result ->| | | |<--- svc result ----| | | | | |--- ind. msg --->| | | | | |<- svc result--| | | |<-- svc result --| | |<--- svc result ----| | | Figure 2: Message exchange procecure - reactive method Another method is to assign a network address to CAT domain but different sub-network address is assigned to different ingress CATS- Forwarder. For example, assume that 10.0.0.0/8 network address is assigned to a CATS domain. Here, 10.0.0.0/16 sub-network address is assigned to the old ingress CATS-Forwarder and 10.0.1.0/16 sub- network address is assigned to the new ingress CATS-Forwarder. Moreover, 10.0.0.1 IP address is assigned to the old ingress CATS- Forwarder and 10.0.1.1 IP address is assigned to the new ingress Jaehwoon Lee Expires Nov. 10, 2026 [Page 6] Internet-Draft Mobility management in CATS network May 11, 2026 CATS-Forwarder. Whena client connects to the old ingress CATS- Forwarder, the router advertises 10.0.0.0 network address by using the Router Advertisement message. If the client transmits DHCP request message requesting a new IP address, the router assigns one of the IP addresses belonging to 10.0.0.0/16 sub-network address. When the client moves and connects to the new ingress CATS- Forwarder, the Forwarder advertises 10.0.0.0/8 network address by using the Router advertisement message. If the client transmits DHCP request message, then the Forwarder considers that the client is the newly connected client. Otherwise, the router can deduce the IP address of the old ingress CATS-Forwarder by using the source IP address of the packet transmitted by the client. The old ingress CATS-Forwarder having received CATS mobility request message transmits the CATS mobility notification message including the IP address of the egress CATS-Forwarder to the new ingress CATS- Forwarder and establishes the tunnel with the new ingress CATS- Forwarder. Moreover the old ingress CATS-Forwarder can inform the new ingress CATS-Forwarder whether the client needs service continuity or not by using the notification message. The new ingress CATS-Forwarder transmits the CATS mobility indication message to the old ingress CATS-Forwarder and establishes the tunnel with old ingress CATS-Forwarder. Moveover, it transmits the CATS mobility indication message to the egress CATS-Forwarder. From now on, the old ingress CATS-Forwarder and the egress CATS-Forwarder can transmit all service results to the client through the new ingress CATS-Forwarder. Figure 3 shows the message exchange procedure related to seamless service migration between edge servers. When a client requiring service continuity moves from an old ingress CATS-forwarder to a new ingress CATS forwarder, the new ingress CATS forwarder searches for a new optimal edge server for the client while continuing to receive service results through the old egress CATS-forwarder. The new ingress CATS-forwarder requests to find a new edge server connected to the optimal service instance for the client to the cats path selector (C-PS). Upon receiving information from the C-PS regarding the new edge server and the new egress CATS-forwarder to which the new edge server is connected, the new ingress CATS-forwarder transmits a request message to the old egress CATS forwarder to transfer the service status information for the client to the new edge server connected to the new egress CATS-forwarder. Additionally, the new ingress CATS-forwarder transmits a notification message to the new egress CATS-forwarder indicating that the current service status information for the client will be transferred from the old egress CATS-forwarder. Upon receiving a transfer request message from the new ingress CATS-forwarder, the old egress CATS-forwarder transfers the service status information for the client received from the old edge server to the new edge server connected to the new egress CATS-forwarder, transmits a confirmation message to the new ingress CATS-forwarder indicating that the transfer of service status information is complete, and Jaehwoon Lee Expires Nov. 10, 2026 [Page 7] Internet-Draft Mobility management in CATS network May 11, 2026 then closes the tunnel with the old ingress CATS-forwarder. Upon receiving a service status transfer message for the client from the old egress CATS-forwarder, the new egress CATS forwarder transmits a notification message to the new ingress CATS-forwarder containing information that a service transfer message for the client has been received. From now on, the new egress CATS-forwarder transmits the remaining service result information for the client to the new ingress CATS forwarder. new ingress C-PS old egress new egress new edge Forwarder Forwarder Forwarder Forwarder server | | | | | |--- query --->| | | | |<- response ->| | | | | | | | | |---- transaction transfer --->| | | | request message | | | |(with transaction information)| | | |-------- notification message -------------->| | | |(with transaction information)| | | | |=transaction=>| | | | | information | | |<--- confirmation message --->| | | | and close tunnel | | | |<------------- notification message ---------| | | | | |-- transaction--->| | | | | information | | | | |<--- switching ---| | | | | completed and | | | | | resume service | |<=============== resume service transaction ====================| Figure 3: Transaction switching procecure 4. Message Formats 4.1 CATS mobility notification and request messages In this draft, the proxy binding update message defined in the Proxy Mobile IPv6 protocol is used to define the CATS mobility notification and request messages [3]. The message format is as follows: Jaehwoon Lee Expires Nov. 10, 2026 [Page 8] Internet-Draft Mobility management in CATS network May 11, 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|C|N| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C: CATS flag. This bit must be set to 1 in the CATS environment. N: The flag must be set to 0 for CATS mobility notification message must be set to 1 for CATS mobility request message. The mobility option of the CATS notification message contains client node address option and CATS address option defined in Section 4.3. In this case, the address contained in the CATS address option is the egress CATS-Router address. Moreover, the mobility option of the CATS request message contains the client node address option. 4.2 CATS mobility indication message In this draft, the proxy binding acknowledgment message defined in the Proxy Mobile IPv6 protocol is used to define the CATS mobility indication message [3]. The message format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|C|Resrved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C: CATS flag. This bit must be set to 1 in the CATS environment. Jaehwoon Lee Expires Nov. 10, 2026 [Page 9] Internet-Draft Mobility management in CATS network May 11, 2026 When the message is transmitted from the new ingress CATS-Router to the old ingress CATS-Router, the client node address option is included in the mobility option. Moreover, when the message is transmitted from the new ingress CATS-Router the the egress CATS-Router, the client node address and CATS address options are included in the mobility options. In this case, the address included in the CATS address option is the old ingress CATS-Router. 4.3 Mobile node address and CATS address options In this draft, the mobility option defined in the Mobile IPv6 protocol is used to define the client node address and CATS address options [2]. The option format is as follow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Client node address option: - Type : TBD - The mobile node address is included in the Address field. CATS address option: - Type : TBD - The CATS address is included in the address field. 5. Security Considerations TBD 6. IANA Considerations TBD Jaehwoon Lee Expires Nov. 10, 2026 [Page 10] Internet-Draft Mobility management in CATS network May 11, 2026 7. References [1] C. Li, Z. Du, M, Boucadair, L. M. Contreras and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", draft-ietf-cats-framework-07 (work in progress), Apr. 30, 2025. [2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", IETF RFC 6275, July 2011. [3] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] M. Ahmad, et al., "Warping the Edge: Where Instant Mobility in 5G Meets Stateful Applications", SEC'25: Proceedings of the Tenth ACM/IEEE Symposium on Edge Computing, no. 25, pp. 1-18, https://doi.org/10.1145/3769102.3770610. Author's Address Jaehwoon Lee Dongguk University 30, Pildong-ro 1 gil, Jung-gu Seoul 04620, KOREA Email: jaehwoon@dongguk.edu Jaehwoon Lee Expires Nov. 10, 2026 [Page 11]