Internet-Draft CATS Service mobility IP addr anchoring September 2024
Bernardos & Mourad Expires 7 March 2025 [Page]
Workgroup:
CATS WG
Internet-Draft:
draft-bernardos-cats-anchoring-service-mobility-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
CJ. Bernardos
UC3M
A. Mourad
InterDigital

Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring

Abstract

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 service migration 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. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined.

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 7 March 2025.

Table of Contents

1. Introduction and Problem Statement

1.1. Use case scenario

Let's consider a possible use case scenario, just for the sake of illustrating the scenario. A terminal is running an AR/VR/XR application (note that this is just an example, other services would also benefit from compute and connectivity traffic steering). Part of this service is executed in the network infrastructure, posing some requirements on the connectivity (e.g., delay between the terminal 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 terminal is 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.

                             ________________
                            (     ---------- )
                           (      |        |  )
                         (     ---------- |   )
   ________________     (     |        | |    )     ________________
  (     ---------- )    (   ---------- | |    )    (    ---------- )
 (      |        |  )   (   |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 |--------
                ---------                     ---------
                  (·)
                 (·)
               ------
               | UE |
               ------
Figure 1: Exemplary scenario

1.2. Problem statement

The main problem that this document tries to address is the following. Networking systems do not have mechanisms yet to service mobility mechanisms optimized for connectivity and computing-aware traffic steering, which consider both connectivity and computing status to dynamically select where a service runs for a given terminal.

Based on the former, this document proposes solutions to enable the network to react and adapt to connectivity and computing conditions, triggering 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 the migration of a service so its requirements in terms of computing and networking are maintained?; and, (ii) how to steer traffic to a new service instance location after moving the service, in a transparent manner to the terminal, by using IP anchor mobility?

2. Terminology

The following terms used in this document are defined by the IETF:

3. Enabling service continuity with IP anchor mobility for CATS

We describe next an example of operation and signaling for the network to perform service mobility. Three different embodiments 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], this documents defines a new functionality:

3.1. OPTION A: terminal-initiated

Next, we assume service 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 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 service anchor mobility procedure for CATS, initiated by a CATS-aware terminal. Following the terminal initiation, the network infrastructure is capable to select a target service instance meeting the connectivity and computing requirements of the service, with signaling procedures defined to perform a transparent anchor migration to a new site, facilitating the service migration in a transparent way for the 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| |ECR#1 ag. SCI| |ECR#N-1 ag. SCI| |ECR#N ag. SCI| |ctrl|
+----+ +-----+ +--+----+---+-+ +----+----+---+-+ +--+----+---+-+ +----+
   |      |       |    |   |        |    |   |      |    |   |      |
   |      |  O. Service instance running at site #n-1.   |   |      |
   |      |     Tunnel established between ICR#1 and ECR#N-1 |      |
   |      |       |    |   |        |    |   |      |    |   |      |
   |   1. An external or internal trigger is received regarding     |
   |       a change in the compute or networking conditions         |
   |      |       |    |   |        |    |   |      |    |   |      |
   |1a. CATS agent at terminal reports a perceived change on service|
   |·····>|       |    |   |        |    |   |      |    |   |      |
   |      |       |    |   |        |    |   |      |    |   |      |
   |      |2a.CATS query(service ID, terminal ID, ICR ID, CATS reqs.)
   |      |······>|<··>|   |        |    |   |      |    |   |      |
   |      |········································>|<··>|   |      |
   |     3a.CATS response(service ID, terminal ID, ECR ID, CATS cond.)
   |      |<······|    |   |        |    |   |      |    |   |      |
   |      |<········································|    |   |      |
   |      |       |    |   |        |    |   |      |    |   |      |
   |      4a. Service anchor/ECR@site#n is selected as best  |      |
   |      |       |    |   |        |    |   |      |    |   |      |
5a.CATS request(service ID, terminal ID, ICR ID, CATS reqs., IP pref.)
   |···············································>|    |   |      |
   |      |       |    |   |        |    |   |      |    |   |      |
   |6.CATS ACK(service ID, terminal ID, ECR ID, CATS cond., IP prefix)
   |<···············································|    |   |      |
   |      |       |    |   |        |    |   |      |    |   |      |
   | 7.New tunnel for IP pref. established beetween ICR#1 and ECR#N |
   |      |       |    |   |        |    |   |      |    |   |      |
   |      | 8.Service migration from site#N-1 to site#N  |   |      |
   |      |       |    |   |        |    |   |      |    |   |      |
   |     9. Service specific traffic|    |   |      |    |   |      |
   |<---->|<--------------------------------------->|<------>|      |
   |      |       |    |   |        |    |   |      |    |   |      |
Figure 2: Exemplary signaling

Figure 2 shows the message sequence chart of the IP anchor mobility for CATS, initiated by a CATS-aware terminal (OPTION A), which is explained next:

  1. A service/app has been already instantiated on a service site (for example, by using the mechanisms specified in [I-D.bernardos-cats-ip-address-anchoring]). In this example, the site where the service/app consumed by the terminal is currently instantiated is site #n-1. The terminal is connected to ICR #1 and there is a service tunnel between ICR#1 and ECR#N-1. This service/app requires some functionality to be run on the network infrastructure (e.g., an AR/VR/XR service). This service has specific requirements in terms of both connectivity and computing (CATS requirements).
  2. An internal or external trigger is generated regarding a change in the computing of networking conditions, making the current selected service site not feasible for the running service (i.e., CATS requirements cannot be met). In this OPTION A, the terminal is CATS-aware, and it the node that detects the change in the conditions (how this is made is outside the scope of this document, but possible mechanisms include: monitoring at service/app level, in-situ monitoring by the terminal, etc.) and sends a trigger to the ICR.
  3. 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:

    1. Service ID: an identifier of the service requested by the terminal. This allows to check if the service can be instantiated or it is already instantiated.
    2. Terminal ID: an identifier of the terminal requesting the service. This is useful for example for affinity purposes. It might not include information that can be used to identify the user.
    3. ICR ID: identifier of the requesting ICR.
    4. CATS requirements: list of requirements, e.g., connectivity and computing requirements.
  4. Each ECR, possibly after checking with the CATS agent of the site(s) it provides connectivity, responds, including the following information:

    1. The ICR sends a query to all ECRs of the domain, or a subset selected based on the location of the ICR. This query may include the following parameters:

      1. Service ID.
      2. Terminal ID.
      3. ECR ID: identifier of the ECR sending the response.
      4. CATS conditions: how the site meets each of the requirements included in the request.
      5. (Optional): URI to get to the service instance.

      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.

    2. Based on the received responses, and considering both networking and computing metrics and policies, the ICR selects an ECR (#n).
    3. 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:

      • ECR prefix: currently in use IP prefix IP to the terminal to reach the service instance.
      • Lifetime: requested duration for the association between the ICR and the ECR.
    4. The selected ECR responds back with an acknowledgement, including the following information:

      1. Service ID.
      2. Terminal ID.
      3. ECR ID: identifier of the ECR sending the response.
      4. CATS conditions: how the site meets each of the requirements included in the request.
      5. IP prefix assigned for the terminal to use to reach the service instance. It should match the one included in the request.
      6. Lifetime: granted duration of the association between the ICR and the ECR.
    5. An IP tunnel is established between the ICR and the new ECR. Optionally (not shown in the figure), the ICR might send a CATS request with cero lifetime to the old ECR to remove the old tunnel.
    6. The previous message triggers the service migration (from site #n to site #n-1). The specific mechanism is out of the scope of this document. Note that some preparation/migration steps might be conducted in parallel (e.g., after messages #1 and #3) to accelerate the process, making this step just the final trigger for the service migration. At site #n, the prefix used by the terminal for accessing the service is configured to be used by migrated instance. This might requires routing updates to be perfomed in the site, potentially controlled by a CATS agent running in the site.
    7. Traffic of the service for this terminal is steered using the IP tunnel.

4. Proxy Mobile IPv6 signaling extensions to enable service mobility with IP address service-specific anchoring for CATS

The control plane extensions introduced in the previous section can be implemented over different protocols. This section specifies extensions to Proxy Mobile IPv6. Only new options additional to what is defined in [I-D.bernardos-cats-ip-address-anchoring] are included.

4.1. New ECR mobility option

The new ECR option has the following format:

 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      |   Reserved    | Addr. Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                     New ECR IP address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message fields:

  • Option Type: TBA by IANA.
  • Option Length: 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields.
  • Addr. Length: 8-bit unsigned integer. Length of the New ECR IP address field, in octets.
  • New ECR IP address: variable length field that includes IP address of the new ECR.

5. IANA Considerations

TBD.

6. Security Considerations

TBD.

7. Acknowledgments

The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe PREDICT-6G (Grant 101095890), DESIRE6G (Grant 101096466) and UNICO I+D 6G-DATADRIVEN project.

8. Informative References

[I-D.bernardos-cats-ip-address-anchoring]
Bernardos, C. J. and A. Mourad, "Computing Aware Traffic Steering using IP address anchoring", Work in Progress, Internet-Draft, draft-bernardos-cats-ip-address-anchoring-02, , <https://datatracker.ietf.org/doc/html/draft-bernardos-cats-ip-address-anchoring-02>.

Authors' Addresses

Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Alain Mourad
InterDigital Europe