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]
