Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture

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 5 September 2024.¶

Copyright Notice

Copyright (c) 2024 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.¶

Table of Contents

1. Introduction

The document [I-D.draft-mhkk-dmm-srv6mup-architecture] describes the Mobile User Plane architecture for Distributed Mobility Management. The MUP controller (MUP-C) is the core component of this architecture. It converts the user mobility session information from the upper mobility management system (e.g. 5G control plane) to IPv6 dataplane routing information. Therefore, mobile user plane specific nodes for the anchor or intermediate points are no longer required.¶

This document discusses a potential enhancement to this architecture capabilities in terms of supporting for anycast IP services. To support high reliability and low latency services, multiple computing instances of the same service can be often geographically distributed to multiple nodes. A single anycast address can be used to represent different instances of the same service. Once the User Equipment (UE) device sends a service request, the control plane entity of the mobile network establishes an user session. Based on the architecture procedure in the document [I-D.draft-mhkk-dmm-srv6mup-architecture], the session information is then sent to the MUP-C. The MUP-C converts the session information to the dataplane routing information between the two MUP Provider Edges (MUP-PE) that connect to the UE connecting RAN and the chosen service instance's location.¶

To support anycast IP service, the control plane should choose the suitable service instance's location for the requested service. However, without application server's computing and underlay network information, the service instance's location might be simply selected based on the closest geographical location to the user. However, it might not be the optimal service instance's location as pointed out in the problem statement document of IETF Computing-Aware Traffic Steering (CATS) working group [I-D.draft-ietf-cats-usecases-requirements].¶

Therefore, a solution to integrate CATS capabilities into the mentioned MUP architecture is presented in this document. It can provide the anycast address support for the mentioned MUP architecture's distributed mobility management abilities.¶

Regarding the Distributed Mobility Management requirements described in [RFC7333], this document addresses the "Multicast considerations" requirement for the mentioned MUP architecture. As described in [RFC4786], anycast is the practice of making a particular service address available in multiple locations. Anycast support could be in the scope of multicast support for distributed mobility management. Besides, anycast address is one of the possible implementation methods of CATS Service ID (CS-ID) as described in [I-D.draft-ldbc-cats-framework]. Hence, the mentioned MUP architecture can support anycast service by integrating CATS capabilities.¶

2. Terminology used in this draft

CATS-MUP-C: Computing-aware traffic steering MUP-C which integrates CATS path selection and MUP-C features.¶

Besides, this document uses the following terminologies which has been defined in [I-D.draft-ldbc-cats-framework]¶

CATS: Computing-Aware Traffic Steering takes into account the dynamic nature of computing resource metrics and network state metrics to steer service traffic to a service instance.¶

Service: An offering that is made available by a provider by orchestrating a set of resources (networking, compute, storage, etc.). The same service can be provided in many locations; each of them constitutes a service instance.¶

Service instance: An instance of running resources according to a given service logic.¶

Service contact instance: A client-facing service function instance that is responsible for receiving requests in the context of a given service. A single service can be represented and accessed via several contact instances that run in different regions of a network.¶

CATS Path Selector (C-PS): A functional entity that computes and selects paths towards service locations and instances and which accommodates the requirements of service requests. Such a path computation engine takes into account the service and network status information.¶

CATS Service Metric Agent (C-SMA): A functional entity that is responsible for collecting service capabilities and status, and for reporting them to a C-PS.¶

CATS Network Metric Agent (C-NMA): functional entity that is responsible for collecting network capabilities and status, and for reporting them to a C-PS.¶

3. Proposed Architecture

                       +----------------+
                       |    Mobility    |
                       |   Management   |
                       |     System     |
                       +----------------+
                                |
        UE Location, Session Info, Service Anycast Address
                                |
                       +--------v-------+
                       |   CATS-MUP-C   |
            +----------|    +------+    |---------+
            |          |    | C-PS |    |         |                Service1
            |          +----------------+         |   +----------+ Contact
UE-         |                                     |   |   C-SMA  |/Instance
   \+---+   +------+        +-----+        +------+   |----------|\
UE--|RAN|---|  PE  |        |C-NMA|        |  PE  |---|  Service | Service2
    +---+   +------+        +-----+        +------+   |   Site 1 | Contact
UE-/        |                                     |   +----------+ Instance
            |                                     |
            |                MUP                  |                Service1
UE-         |              Network                |                Contact
   \+---+   +------+                       +------+   +----------+ Instance
UE--|RAN|---|  PE  |                       |  PE  |---|  Service |/
    +---+   +------+                       +------+   |   Site 2 |\Service2
UE-/        |                                     |   |----------| Contact
            +-------------------------------------+   |   C-SMA  | Instance
                                                      +----------+

Figure 1 describes the CATS-MUP architecture.¶

Regarding the information sent from the mobility management system, besides session information, UE location and the requested service anycast address of the session are also required.¶

The controller MUP-C in previous mentioned document is enhanced with CATS capabilities and renamed to CATS-MUP-C. Besides converting session information into underaly routing information function, the CATS-MUP-C can also decide the optimal service instance's location for the requested service in the session information. Application servers computing and underlay network information are collected by C-SMA and C-NMA respectively. The sub-component C-PS inside the CATS-MUP-C is responsible for select optimal service instance's location to serve the requested anycast service and the routing path to it. The decision is based on the collected CATS metrics from C-NMA and C-SMA, and UE location. Based on this decision, the CATS-MUP-C convert the session information into the SRv6 routing path via the transform routes defined in [I-D.draft-mhkk-dmm-srv6mup-architecture].¶

This architecture separates the CATS-based service instance's location selection from the upper control plane and integrates to the MUP-C. Hence, for the same requested anycast IP-based service, different UEs can be dynamically routes to service instances at different location if necessary based on the CATS information and UE location.¶

This document only discusses the possible architecture and design to the previous defined MUP architecture in [I-D.draft-mhkk-dmm-srv6mup-architecture] when integrating CATS capabilities. The CATS measurement data collection, data delivery mechansim, and CATS optimal path selection algorithm are in the scope of CATS, not in this document.¶

4. Possible Procedure and MUP Route Types changes

TBD¶

5. Security Considerations

TBD¶

6. IANA Considerations

This document makes no requests for IANA action.¶

Authors' Addresses