Skip to main content

Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture
draft-dcn-dmm-cats-mup-00

Document Type Active Internet-Draft (individual)
Authors Trần Minh Ngọc , Younghan Kim
Last updated 2024-03-04
Replaces draft-duongph-dmm-computing-aware-ts-mup-sr
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dcn-dmm-cats-mup-00
Distributed Mobility Management                                  N. Tran
Internet-Draft                                                    Y. Kim
Intended status: Informational                       Soongsil University
Expires: 5 September 2024                                   4 March 2024

  Computing Aware Traffic Steering Consideration for Mobile User Plane
                              Architecture
                       draft-dcn-dmm-cats-mup-00

Abstract

   The document [I-D.draft-mhkk-dmm-srv6mup-architecture] describes the
   Mobile User Plane (MUP) architecture for Distributed Mobility
   Management.  The proposed architecture converts the user mobility
   session information from the control plane entity to an optimal IPv6
   dataplane routing information.  However, when anycast address is used
   for service in data network (DN), this solution can be enhanced to
   dynamically set up the dataplane to the optimal service instance.

   This document discusses a solution to integrate computing-aware
   traffic steering capabilities to the mentioned MUP architecture.  The
   target applied use-case is the anycast IP services scenario, where
   different instances that share the same anycast address of the
   service can serve the user request.  For each session request, based
   on the up-to-date collected computing and network information, the
   MUP controller can convert the session information to the dataplane
   routing information to the optimal service instance.

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.

Tran & Kim              Expires 5 September 2024                [Page 1]
Internet-Draft                  CATS-MUP                      March 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology used in this draft  . . . . . . . . . . . . . . .   3
   3.  Proposed Architecture . . . . . . . . . . . . . . . . . . . .   4
   4.  Possible Procedure and MUP Route Types changes  . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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.

Tran & Kim              Expires 5 September 2024                [Page 2]
Internet-Draft                  CATS-MUP                      March 2024

   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.

Tran & Kim              Expires 5 September 2024                [Page 3]
Internet-Draft                  CATS-MUP                      March 2024

   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

Tran & Kim              Expires 5 September 2024                [Page 4]
Internet-Draft                  CATS-MUP                      March 2024

                       +----------------+
                       |    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: CATS MUP Architecture using Segment Routing

   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

Tran & Kim              Expires 5 September 2024                [Page 5]
Internet-Draft                  CATS-MUP                      March 2024

   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.

7.  References

7.1.  Informative References

   [I-D.draft-ietf-cats-usecases-requirements]
              Yao, K., Trossen, D., Boucadair, M., Contreras, LM., Shi,
              H., Li, Y., Zhang, S., and Q. An, "Mobile User Plane
              Architecture using Segment Routing for Distributed
              Mobility Management", 2 January 2024,
              <https://datatracker.ietf.org/doc/draft-ietf-cats-
              usecases-requirements/>.

   [I-D.draft-ldbc-cats-framework]
              Li, C., Du, Z., Boucadair, M., Contreras, L. M., Drake,
              J., Huang, D., and G. S. Mishra, "A Framework for
              Computing-Aware Traffic Steering (CATS)", Work in

Tran & Kim              Expires 5 September 2024                [Page 6]
Internet-Draft                  CATS-MUP                      March 2024

              Progress, Internet-Draft, draft-ldbc-cats-framework-03, 22
              June 2023, <https://datatracker.ietf.org/doc/html/draft-
              ldbc-cats-framework-03>.

   [I-D.draft-mhkk-dmm-srv6mup-architecture]
              Matsushima, S., Horiba, K., Khan, A., Kawakami, Y.,
              Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo,
              P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal,
              A., and K. Perumal, "Mobile User Plane Architecture using
              Segment Routing for Distributed Mobility Management", Work
              in Progress, Internet-Draft, mhkk-dmm-srv6mup-
              architecture, 23 October 2023,
              <https://datatracker.ietf.org/doc/draft-mhkk-dmm-srv6mup-
              architecture/>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", December 2006,
              <https://datatracker.ietf.org/doc/rfc4786/>.

   [RFC7333]  Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management", August
              2014, <https://datatracker.ietf.org/doc/rfc7333/>.

   [TS23501]  "System architecture for the 5G System (5GS)", December
              2023,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144>.

Authors' Addresses

   Minh-Ngoc Tran
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul
   06978
   Republic of Korea
   Email: mipearlska1307@dcn.ssu.ac.kr

   Younghan Kim
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul
   06978
   Republic of Korea
   Phone: +82 10 2691 0904
   Email: younghak@ssu.ac.kr

Tran & Kim              Expires 5 September 2024                [Page 7]