| Internet-Draft | CATS-MUP | July 2024 |
| Tran & Kim | Expires 31 January 2025 | [Page] |
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 IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route.¶
This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. 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 optimal route.¶
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 31 January 2025.¶
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.¶
The document [I-D.draft-mhkk-dmm-srv6mup-architecture] describes the Mobile User Plane architecture for Distributed Mobility Management. This architecture is composed of a MUP controller and multiple MUP PEs. When applying the MUP architecture in 5G network, the MUP PEs accomodate the N3 RAN network as Interwork Segment or the N6 DN network as Direct Segment. The MUP PEs advertises the Interwork and Discovery Segment dataplane network reachability (e.g. Segment Routing IPv6 segment identifier (SRv6 SID)) to the MUP network via the interwork and direct segment Discovery routes. Meanwhile, the MUP controller transformed the received user mobility session information to the corresponding interwork and direct segment information. Then, it advertises the transformed information to MUP PEs via Session Transformed routes. The MUP PEs use the matching Discovery routes to resolve the Session Transformed routes and forward the packet through the MUP SRv6 network.¶
This document discusses the optimal route configuration problem when applying the mentioned MUP architecture in a network scenario where an user request can be served by multiple computing instances of the same service located at different locations. The closest geographical service location to users 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]. In this scenario, an optimal service instance location can be decided at the mobile control plane or data plane.¶
In the control plane case, it is possible to use an Application Function (AF) to determine the optimal service instance and influence the 5G control plane to select the DN corresponding to the chosen instance. The MUP-C only needs to transform the optimal DN information in the session information into the corresponding route. Meanwhile, in the data plane approach, the MUP-C should decide the optimal service instance location by itself and transform the unoptimal session information into the optimal route based on its decision. The data plane approach can avoid additional signalling procedure at the control plane of the other approach. It also supports IP Routing paradigm benefit of SRv6 mobile user plane as mentioned in the edge computing use case of the document [I-D.draft-ietf-dmm-srv6mob-arch].¶
Therefore, a solution to integrate CATS capabilities into the mentioned MUP architecture is presented in this document. By considering service computing and network information of all candidate service instances, the MUP controller can convert the session information into the optimal dataplane route.¶
This document is proposed to discuss a possible extension consideration of the original MUP architecture document[I-D.draft-mhkk-dmm-srv6mup-architecture]. Regarding the Distributed Mobility Management requirements described in [RFC7333], the MUP architecture can partly address the "Non-optimal routes" problem and the "Multicast considerations" requirement by integrating CATS capabilties. 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.¶
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.¶
This section presents 3 enhancement points that need to be added in MUP for selecting an optimal service instance for serving an user request.¶
First, the MUP architecture should be capable of identifying the service and its candidate service instances. These service identifiers are well defined in CATS framework document [I-D.draft-ldbc-cats-framework], CATS Service ID (CS-ID) is used to differentiate between different services. CATS Instance Selector ID (CIS-ID) is used to differentiate between different service instances of the same service.¶
Second, the MUP architecture should be capable of advertising service deployment information among its components. The egress MUP PE attaching to the MUP direct segment should gather the corresponding service and servince instance information (CS-ID and CIS-ID) and avertise to the MUP environment. Different methods can be considered for this requirement. A specific method is not considered in the scope of this document. One example solution can be referred from [I-D.draft-lin-idr-distribute-service-metric]. The egress routers can advertise the edge service deployment information via a BGP NLRI that can hold the CS-ID and CIS-ID information.¶
Third, the MUP architecture should be capable of advertising the computing and network metrics (CATS metrics) related to the each service instance. The egress MUP PE attaching to the MUP direct segment should gather the corresponding service CATS metrics and avertise to the MUP environment. Different methods can be considered for this requirement. A specific method is not considered in the scope of this document. One example solution can be referred from [I-D.draft-ietf-idr-5g-edge-service-metadata]. The egress routers can advertise the edge service CATS metrics via a metadata BGP path attribute that can hold different types of CATS metric.¶
Compared with the original route definition introduced in [I-D.draft-ldbc-cats-framework], the Direct Segment Discovery Route (DSD) and the Type 2 Session Transformed Route (T2ST) need modifications to support the centralized CATS-MUP deployment case. Another CATS Metrics Update Route (CMU) is also introduced.¶
The Direct Segment Discovery route advertises the reachability information of the direct segment. This route is advertised from the PEs attaching to the direct segments to the PEs attaching to the mobile network access side. In CATS scenario, the direct segment is a specific instance of a service. The service identifier CS-ID and service instance identifier CIS-ID information are required in this route. The CIS-ID can be used as the direct segment extended community ID. The list below shows the DSD route information in CATS-MUP centralized deployment case:¶
The Type 2 Session Transformed Route convert the session information into dataplane routing information. This route is advertised from the CATS-MUP-C to the PEs attaching to the mobile network access side. In CATS scenario, the direct segment is a specific instance of a service. This route type includes the target service identifier CS-ID and the tunnel endpoint identifier on the mobile network core side information. The optimal service instance identifier CIS-ID determined by the CATS-MUP-C is also required in this route information. The list below shows the T2ST route information in CATS-MUP centralized deployment case:¶
The CATS Metric Update route convert the session information into dataplane routing information. This route is advertised from the PEs attaching to the direct segments to the CATS-MUP-C. This route type update the CATS metrics related to the attaching service instance of each PE to the CATS-MUP-C. The list below shows the CMU route information in CATS-MUP centralized deployment case:¶
+----------------+
| Mobility |
| Management |
| System |
+----------------+
|
Session Information, CS-ID
|
T2ST +--------v-------+ CMU A
+-------| CATS-MUP-C |<-----+
+--|-------| +------+ |------|--+
| | | | C-PS | | | |
| | +----------------+ | | +----------+
UE- | v CMU B ^ | | | C-SMA |
\+---+ +------+ DSD A | +------+ |----------|-Service1
UE--|RAN|---| PE |<------------------|---| PE |---| Service | Instance
+---+ +------+<---------------\ \ +------+ | Site A | (CS-ID S1)
UE-/ | DSD B \ \ | +----------+ (CIS-ID S1A)
| \ \ |
| \ \ |
| \ \ |
| MUP network \ +------+ +----------+
| +-------+ \| PE |---| Service |
| | C-NMA | +------+ | Site B |-Service1
| +-------+ | |----------| Instance
+-------------------------------------+ | C-SMA | (CS-ID S1)
+----------+ (CIS-ID S1B)
Figure 1 describes the CATS-MUP Centralized deployment architecture. The controller MUP-C in previous mentioned document is enhanced with CATS path selection capability and renamed to CATS-MUP-C. The optimal route configuration procedure based on this architecture is described as follows:¶
Initially, when a service instance joins the MUP network, the connecting PE advertises the DSD Route with the CS-ID, CIS-ID of the service instance and the corresponding SRv6 SID of the attaching PE.¶
The PE can periodically update the CATS metrics collected from C-SMA and C-NMA that are related to each service instance by advertising the information in the CMU route to the CATS-MUP-C .¶
When an UE request a service, during the session establishment process, the mobility management system provides necessary session information and requested service CS-ID to the CATS-MUP-C. An example of this session information provisioning process can be referred from [ieee-access-cats-mup].¶
The sub-component C-PS inside the CATS-MUP-C is responsible for select optimal service instanceto serve the requested service. The decision is based on the current CATS metrics updated from all CMU routes.¶
Based on this decision, the CATS-MUP-C attaches the corresponding CIS-ID value of the chosen service instance to the T2ST route along with the session tunnel endpoint identifier. The CATS-MUP-C then advertises this Session Transformed route to the MUP PE connecting to the N3 RAN.¶
After receiving the T2ST route, the MUP PE resolve it with the DSD Route that has the matching CIS-ID value. Because this value is CIS-ID of the optimal service instance selected by the CATS-MUP-C, the UE packets will be forwarded to the optimal service instance.¶
The CATS metric collection method and CATS optimal service instance selection method are out of scope of this document.¶
Compared with the original route definition introduced in [I-D.draft-ldbc-cats-framework], the Direct Segment Discovery Route (DSD) and the Type 2 Session Transformed Route (T2ST) need modifications to support the distributed CATS-MUP deployment case.¶
The Direct Segment Discovery route advertises the reachability information of the direct segment. This route is advertised from the PEs attaching to the direct segments to the PEs attaching to the mobile network access side. For the distributed CATS-MUP deployment case, in addition to the CS-ID and the CIS-ID, the CATS metrics of the corresponding service instance of the PE is also included. The CIS-ID can be used as the direct segment extended community ID. The list below shows the DSD route information in CATS-MUP centralized deployment case:¶
The Type 2 Session Transformed Route convert the session information into dataplane routing information. This route is advertised from the CATS-MUP-C to the PEs attaching to the mobile network access side. For the distributed CATS-MUP deployment case, this route type only includes the target service identifier CS-ID and the tunnel endpoint identifier on the mobile network core side information. The list below shows the T2ST route information in CATS-MUP centralized deployment case:¶
+----------------+
| Mobility |
| Management |
| System |
+----------------+
|
Session Information, CS-ID
|
T2ST +--------v-------+
+-------| |
+--|-------| MUP-C |---------+
| | | | |
| | +----------------+ | +----------+
UE- | v | | C-SMA |
\+---+ +------+ DSD A +------+ |----------|-Service1
UE--|RAN|---| PE |<----------------------| PE |---| Service | Instance
+---+ +------+<---------------\ +------+ | Site A | (CS-ID S1)
UE-/ | C-PS | DSD B \ | +----------+ (CIS-ID S1A)
+------+ \ |
| \ |
| \ |
| MUP network \ +------+ +----------+
| +-------+ \| PE |---| Service |
| | C-NMA | +------+ | Site B |-Service1
| +-------+ | |----------| Instance
+-------------------------------------+ | C-SMA | (CS-ID S1)
+----------+ (CIS-ID S1B)
Figure 2 describes the CATS-MUP Distributed deployment architecture. The optimal route configuration procedure based on this architecture is described as follows:¶
Initially, when a service instance joins the MUP network, the connecting PE advertises the DSD Route with the CS-ID, CIS-ID and the current CATS metrics of the service instance and the corresponding SRv6 SID of the attaching PE. The DSD is re-advertised whenever new CATS metrics corresponding to the related service instance is updated.¶
When an UE request a service, during the session establishment process, the mobility management system provides necessary session information and requested service CS-ID to the MUP-C. An example of this session information provisioning process can be referred from [ieee-access-cats-mup]. The MUP-C provides session information and CS-ID of the request to the PE connecting to the N3 RAN via the T2ST route.¶
The C-PS at the PE connecting to the N3 RAN considers all candidate service instances corresponding to the CS-ID recieved from the T2ST route. Based on the current CATS metrics of all candidate service instance obtained from the DSD routes, the C-PS determines the optimal service instance. The UE packets will be forwarded to the that instance based on its corresponding PE SID in the DSD route.¶
The CATS metric collection method and CATS optimal service instance selection method are out of scope of this document.¶