| Internet-Draft | CATS terminal mobility IP addr anchoring | March 2025 |
| Bernardos & Mourad | Expires 4 September 2025 | [Page] |
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity).¶
This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent mobility management adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered.¶
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 4 September 2025.¶
Copyright (c) 2025 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.¶
Let's consider a possible use case scenario, just for the sake of illustrating the scenario. Several nodes (UEs in this example) are acting as sensors in an Integrated Sensing and Communications (ISAC) case. The sensors generate/collect sensing data that needs to be processed timely and appropriately to generate an accurate sensing result. Part of this service is executed in the network infrastructure, posing some requirements on the connectivity (e.g., delay between the terminals and the node where the service is executed on the network infrastructure) and computing resources (e.g., capabilities to render the XR video within a certain latency budget). Within the network domain where the terminals are connected to there are multiple sites capable of hosting the service, each with potentially different connectivity and computing characteristics. Figure 1 shows an exemplary scenario. Considering the connectivity and computing latencies (just as an example of metrics), the best service site is #n-1 in the example used in the Figure.¶
Note that this is just an example, other services would also benefit from compute and connectivity traffic steering. For the sake of having a simpler service, we can also consider an AR/VR/XR service where a terminal connected to the network needs to instantiate a service in the network to aid in the AR/VR/XR service by providing computing capabilities with latency constraints.¶
Note on terminology. In this document we use the old terminology in which by ICR we mean Ingress CATS-Forwarder [I-D.ietf-cats-framework], and by ECR we mean Egress CATS-Forwarder.¶
________________
( ---------- )
( | | )
( ---------- | )
________________ ( | | | ) _______________
( ---------- ) ( ---------- | | ) ( ---------- )
( | | ) ( |service | |- ) ( | | )
( ---------- | ) ( |contact | | ) ( ---------- | )
( | | | ) ( |instance|-- ) ( | | | )
( ---------- | | ) ( ---------- ) ( ---------- | | )
( |service | |- ) ( Serv. site #N-1 ) ( |service | |- )
( |contact | | ) -------+---------- ( |contact | | )
( |instance|-- ) Computing \ ( |instance|-- )
( ---------- ) delay:4ms \ ( ---------- )
( Serv. site #1 ) --------+-- ( Serv. site #N )
-------+-------- ----| ECR#N-1 |---- ---------+-----
\ Computing -- ----------- -- Computing /
\ delay:10ms Networking delay:5ms /
---+----- delay:7ms ------+--
( | ECR#1 | // | ECR#N | )
( --------- // --------- )
( Networking // Networking )
( delay:5ms // delay:15ms )
( // )
( // )
( // )
( // )
( // )
( --------- --------- )
-------| ICR#1 |---------------------| ICR#2 |--------
--------- __ ---------
(·) (·) / ( ) (·)
(·) ------- - ( ) (·)
(·) | UE2 | / (__) \ (·)
(·) ------- / - -------
(·) / (sensing \ | UE3 |
------- --------- -------
| UE1 | /
-------
The main problem that this document tries to address is the following. Networking systems do not have mechanisms yet with capabilities to support to dynamically change of point of attachement of a node which is consuming a service instantiated in the network, with the traffic being steered in accordance with the dynamically changing connectivity and computing conditions.¶
Based on the former, this document proposes solutions to enable the network to react and adapt to the change in connectivity and computing conditions caused by a terminal change of point of attachment, which might also trigger optimal service migration based on service-specific IP anchor mobility. In particular, this document addresses the following questions: (i) what mechanisms does the network need to implement to facilitate CATS-enabled terminal mobility, leveraging the architecture defined in [I-D.bernardos-cats-ip-address-anchoring], so the requirements of the service in terms of computing and networking are simultaneously fulfilled?, (ii) how to steer traffic between sensing terminals and the sensing service computing site, after sensor’s mobility, and how to re-evaluate --upon sensor’s mobility-- if service relocation is also needed, in a transparent manner to the sensor, by using IP anchor mobility?¶
The following terms used in this document are defined by the IETF:¶
ECR: Egress CATS router. This refers to the Egress CATS-Forwarder as defined in [I-D.ietf-cats-framework].¶
ICR: Ingress CATS router. This refers to the Ingress CATS-Forwarder as defined in [I-D.ietf-cats-framework].¶
We describe next an example of operation and signaling for the network to perform terminal mobility. Three different options are described next, for variations (OPTIONS) of the procedures: terminal initiated, ECR-initiated and CATS-controller initiated. In addition to the functionality defined in [I-D.bernardos-cats-ip-address-anchoring] and [I-D.bernardos-cats-anchoring-service-mobility], this documents defines a new functionality:¶
Next, we assume terminal mobility is triggered by a CATS-aware terminal. By having a CATS agent running on the terminal, it can perform different monitoring actions to predict or detect the need to move from one point of attachment or another, and also the potential need to migrate a service from one site to another. This CATS agent might, for example, interact with other CATS agents deployed on ICRs, ECRs and service sites.¶
In the following we describe a terminal mobility procedure for CATS, initiated by a CATS-aware terminal. Using the sensing terminal support, the network infrastructure is capable of steering the traffic to the new location of the sensing terminal, and, if required, select a target service instance meeting the connectivity and computing requirements of the service. Both the mobility of the sensing terminal, and the potential service migration, are performed with signaling procedures transparent for the sensing terminal. Extensions and new behavior are highlighted. Note that variations are possible over this exemplary signaling diagram.¶
+----+ +-----+ +-----+ +-------------+ +---------------+ +-------------+ +----+ | | | | | | | site #1 | | site #N-1 | | site #N | |CATS| |term| |ICR#1| |ICR#2| |ECR#1 ag. SCI| |ECR#N-1 ag. SCI| |ECR#N ag. SCI| |ctrl| +----+ +-----+ +-----+ +--+----+---+-+ +----+----+---+-+ +--+----+---+-+ +----+ | | | | | | | | | | | | | | O. Terminal attached to ICR#1. Service instance running at site #n-1. | | Tunnel established between ICR#1 and ECR#N-1| | | | | | | | | | | | | | | | | | | 1. Terminal moves and attaches to ICR#2 | | | | | | | | | | | | | | | | | | | |2. CATS agent at terminal includes information of service and current ECR |·············>| | | | | | | | | | | | | | | | | | | | | | | | | | 3. Current ICR decides whether to migrate the service or not | SERVICE NEEDS TO BE MIGRATED: | | | | | | | | | | | 4. CATS query(service ID, terminal ID, ICR ID, CATS reqs.) | | | |······>|<··>| | | | | | | | | | | |········································>|<··>| | | | | | | | | | | | | | | | | | 5. CATS response(service ID, terminal ID, ECR ID, CATS cond.) | | | |<······| | | | | | | | | | | | |<········································| | | | | | | | | | | | | | | | | | | 6. Service anchor/ECR @ site n is selected as best | | | | | | | | | | | | | | | | 7. CATS request(service ID, terminal ID, ICR ID, CATS reqs., cur. IP pref.) | | |········································>| | | | | | 8. CATS ACK(service ID, terminal ID, ECR ID, CATS cond., IP pref.) | | |<········································| | | | | | | | | | | | | | | | | 9. A new IP tunnel for the IP prefix in use set up between new ICR and new ECR | | | | | | | | | | | | | 10. ICR sends a CATS request with zero lifetime to old ECR and receives ACK | | |<·······················>| | | | | | | | | | | | | | | | | | | | 11. Old ECR sends unsolicited CATS response to the old ICR with zero lifetime | |<································| | | | | | | | | | | | | | | | | | | | | | 12. Service migration (from site #n-1 to site #n) | | | | | | | | | | | | | | | | | | | 13. Service specifc traffic | | | | |<------------>|<=======================================>|<------>| | | | | | | | | | | | | | | SERVICE NEEDS TO BE MIGRATED: | | | | | | | | | 14. CATS request(service ID, terminal ID, ICR ID, CATS reqs., cur. IP pref.)| | | |························>| | | | | | | | | | | | | | | | | | | | | 14. CATS ACK(service ID, terminal ID, ECR ID, CATS cond., IP pref.)| | | |<·······················>| | | | | | | | | | | | | | | | | | | | | 15. IP tunnel is updated, endpoint moved from old to new ICR | | | | | | | | | | | | | | 16. ECR sends unsolicited CATS response to the old ICR with zero lifetime | |<································| | | | | | | | | | | | | | | | | | | | | | | 17. Service specifc traffic | | | | |<------------>|<========================|<------>| | | | | | | | | | | | | | | | | |
Figure 2 shows the message sequence chart of terminal mobility for CATS, initiated by a CATS-aware terminal (OPTION A), which is explained next:¶
(SERVICE NEEDS TO BE MIGRATED:) The ICR sends a query to all (but currently used) ECRs of the domain, or a subset selected based on the location of the ICR. This query may include the following parameters:¶
Each ECR, possibly after checking with the CATS agent of the site(s) it provides connectivity, responds, including the following information:¶
A CATS agent at a site might be collocated with the ECR. Examples of a CATS agent at a site are network controllers or orchestrators at the site. Note that the way a CATS agent at an ECR may interact with the CATS agent of the site is out of the scope of this document. Examples include using monitoring and telemetry interfaces with an orchestrator managing the site.¶
(SERVICE DOES NOT NEED TO BE MIGRATED:) The ICR requests the proposed/selected ECR to establish a traffic steering session with it, sending a CATS request. This request includes the same information that was included in the CATS query (to facilitate stateless operation of the ECRs while being queried), plus the following additional parameters:¶
The selected ECR responds back with an acknowledgement, including the following information:¶
TBD.¶
TBD.¶
The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe MultiX (Grant 101192521), DISCO6G-CM (TEC-2024/COM-360) and UNICO I+D 6G-DATADRIVEN projects.¶