| Internet-Draft | MUP Architecture | March 2023 |
| Matsushima, et al. | Expires 14 September 2023 | [Page] |
This document defines the Mobile User Plane (MUP) architecture using Segment Routing (SR) for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion.¶
Mobile services are deployed over several parts of IP networks. An SR network can accommodate a part of those networks, or all those networks. IPv6 dataplane option (SRv6) is suitable for both cases especially for the latter case thanks to the large address space, so this document illustrates the MUP deployment cases with IPv6 dataplane.¶
MUP Architecture can incorporate existing session based mobile networks. By leveraging Segment Routing, mobile user plane can be integrated into the dataplane. In that routing paradigm, session information between the entities of the mobile user plane is turned to routing information.¶
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 14 September 2023.¶
Copyright (c) 2023 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.¶
Mobile services require IP connectivity for communication between the entities of mobile service architecture [RFC5213][TS.23501]. To provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a candidate solution.¶
In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be provided over SR networks, as well as LMA and Internet. In 3GPP 5G [TS.23501], IP connectivity for N3 interface between gNodeB(es) and UPFs can also be provided by SR, as well as for N6 interface between UPFs and DNs (Data Network).¶
These IP connectivities may be covered by multiple SR networks, or just one SR network, depending on the size of the deployment. In the latter case, it is expected that the address space of the SR network should be large enough to cover a vast number of nodes, such as millions of base stations. For this reason, use of IPv6 for the SR dataplane looks sufficiently suitable.¶
SRv6 is an instantiation of SR over IPv6 dataplane in which a single network can accommodate all entities of mobile services thanks to the huge available address space and network programming capability described in [RFC8986].¶
Meanwhile, SRv6 network programmability enhances SRv6 dataplane to be integrated with mobile user plane [I-D.ietf-dmm-srv6-mobile-uplane]. It will make an entire SRv6 network support the user plane in a very efficient distributed routing fashion.¶
On the other hand, the requirements for Distributed Mobility Management (DMM) described in [RFC7333] can be satisfied by session management based solutions. [RFC8885] defines protocol extension to PMIPv6 for the DMM requirements. 3GPP 5G defines an architecture in which multiple session anchors can be added to one mobility session by the session management.¶
As a reminder, the user plane related requirements in [RFC7333] are reproduced here:¶
This document defines the Mobile User Plane (MUP) architecture using Segment Routing for Distributed Mobility Management. MUP is not a mobility management system itself, but an architecture enables the SR dataplanes to integrate mobile user plane into it for the IP networks.¶
In this routing paradigm, session information from a mobility management system will be transformed to routing information. It means that mobile user plane specific nodes for the anchor or intermediate points are no longer required. The user plane anchor and intermediate functions can be supported by SR throughout an SR domain (REQ1), not to mention that MUP will naturally be deployed over IPv6 networks (REQ3).¶
MUP architecture is independent from the mobility management system. For the requirements (REQ4, 5), MUP architecture is designed to be pluggable user plane part of existing mobile service architectures. Those existing architectures are for example defined in [RFC5213], [TS.23501], or if any.¶
The level of MUP integration for mobile networks running based on the existing architecture will be varied and depending on the level of SR awareness of the control and user plane entities.¶
Specifying how to modify the existing architecture to integrate MUP is out of scope of this document. What this document provides for the existing architecture is an interface for MUP which the existing or future architectures can easily integrate.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
MUP architecture defined in this document introduces new segment types of MUP segment called "Direct segment", and "Interwork Segment". An SR node of PE accommodates an Interwork Segment and/or a Direct Segment. Figure 1 depicts the overview.¶
* Mobility *
* Management *
* System *
*........*
|
Session Information
|
______________v______________
_______ / |MUP-C| \ _______
/ \ / +-----+ \ / \
/Interwork\__ | | __/ Direct \
\ Segment / \ |----+ +----| / \ Segment /
\_______/ \| PE | SR | PE |/ \_______/
_______ /|----+ Network +----|\ _______
/ \ / | | \ / \
/ Direct \_/ \ / \_/Interwork\
\ Segment / \____________________________/ \ Segment /
\_______/ \_______/
This document also defines new routing information called "Segment Discovery route" and "Session Transformed route". To carry these new routing information, this architecture requires extending the existing routing protocols. Any routing protocol can be used to carry this information but this document recommends using BGP. Thus, this document describes extensions on BGP as an example.¶
This document defines two new types of Mobile User Plane (MUP) segment. A MUP segment represents a network segment consisting of a mobile service. The MUP segment can be created by a PE which provides connectivity for the mobile user plane.¶
Direct Segment is a type of MUP segment that provides connectivity between MUP segments through the SR network. Interwork Segment is another type of MUP segment. It provides connectivity between a user plane protocol of existing or future mobile service architecture and other MUP segments through the SR networks.¶
An SRv6 SID (Segment Identifier) can represent a MUP segment. The SID can be any behavior defined in [RFC8986], [I-D.ietf-dmm-srv6-mobile-uplane], or any other extensions for further use cases. The behavior of the MUP segment will be chosen by the role of the representing MUP segment.¶
For example, in case of a PE interfaces to 5G user plane on the access side defined as "N3" in [TS.23501], the PE accommodates the N3 network as Interwork Segment in a routing instance and then the behavior of created segment SID by the PE will be "End.M.GTP4.E", or "End.M.GTP6.E". In this case, the PE may associate the SID to the routing instance for the N3 access network (N3RAN).¶
Another example here is that a PE interfaces to 5G DN on the core side defined as "N6" in [TS.23501], the PE accommodates the N6 network in a routing instance as Direct Segment and then the behavior of the created segment SID by the PE will be "End.DT4", "End.DT6", or "End.DT2". In this case, the PE may associate the SID to the routing instance for the N6 data network (N6DN).¶
Distribution of MUP segment information can be done by advertising routing information with the MUP segment for mobile service. A PE distributes MUP segment information when a MUP segment is connected to the PE.¶
A MUP Segment Discovery route is routing information that associates the MUP segment with network reachability. This document defines the basic discovery route types, Direct Segment Discovery route, and Interwork Segment Discovery route. Other types of segment discovery route may be mobile service architecture specific. Defining the architecture specific network reachability is out of scope of this document and it will be specified in another document.¶
When a PE accommodates a network through an interface or a routing instance as a Direct Segment, the PE advertises the corresponding Direct Segment Discovery route for the interface or the routing instance to the SR domain. The Direct Segment Discovery route includes an address of the PE in the network reachability information with an extended community indicating the corresponding Direct Segment, and the SID for the segment.¶
For example in 3GPP 5G specific case, an PE may connect to N6 interface on a DN side, an MUP Segment Discovery route for the DN will be advertised with an address of the PE, corresponding SID and Direct Segment extended community to the routing instance for the DN from the PE.¶
When a PE receives a Direct Segment Discovery route from other PEs, the PE keeps the received Direct Segment Discovery route in the RIB. The PE uses the received Direct Segment Discovery route to resolve Type 2 session transformed routes reachability, described in Section 6.2. If the Direct Segment Discovery route resolves reachability for the endpoints, and match the Direct Segment extended community of the Type 2 session transformed routes, the PE updates the FIB entry for the Type 2 session transformed route with the SID of the matched Direct Segment Discovery route.¶
When a PE accommodates a network through an interface or a routing instance for the user plane protocol of the mobile service architecture as an Interwork Segment, the PE advertises the corresponding Interwork Segment Discovery route with the prefixes of the Interwork Segment and the corresponding SID of the prefixes to the SR domain.¶
For example in 3GPP 5G specific case, an Interwork Segment Discovery route for N3 network accommodating RAN will be incorporated in an N3RAN segment discovery route associated with a RAN segment SID.¶
When a PE receives a Interwork Segment Discovery route, the PE keeps the received Interwork Segment Discovery routes in the RIB. The PE uses the received Interwork Segment Discovery routes to resolve the reachability for remote endpoint of Type 1 session transformed routes, described in Section 6.1. If the Interwork Segment Discovery route resolves the reachability for Type 1 session transformed routes, the PE updates the FIB entry for the prefix of Type 1 session transformed route with the SID of the matched MUP segment discovery route.¶
The received Interwork Segment Discovery routes MUST be used to resolve reachability for the remote endpoints of Type 1 session transformed routes. The connectivity among the routing instances for Interwork Segments may be advertised as VPN routes. This is to avoid forwarding entries to the prefixes of Interwork Segment mingled in the other type of routing instance. A PE may discard the received Interwork segment discovery route if the Route Target extended communities of the route does not meet the PE's import policy.¶
MUP architecture defines two types of session transformed route.¶
First type route, called Type 1 Session Transformed route, encodes IP prefix(es) for a UE or MN in a BGP MP-NLRI attribute with associated session information of the tunnel endpoint identifier on the access side. The MUP controller advertises the Type 1 Session Transformed route with the Route Target extended communities for the UE or MN to the SR domain.¶
A PE may receive the Type 1 Session Transformed routes from the MUP Controller in the SR domain. The PE may keep the received Type 1 Session Transformed routes advertised from the MUP Controller. The receiving PE will perform the importing of the received Type 1 Session Transformed routes in the configured routing instances based on the Route Target extended communities. A PE may discard the received Type 1 Session Transformed route if the PE fails to import the route based on the Route Target extended communities.¶
Second type route, called Type 2 Session Transformed route, encodes the tunnel endpoint identifier of the session on the core side in a BGP MP-NLRI attribute with the nature of tunnel decapsulation. Longest match algorithm for the prefix in this type of session transformed route should be applicable to aggregate the routes for scale. The MUP controller advertises the Type 2 Session Transformed route with the Route Target and Direct Segment extended communities for the endpoint to the SR domain.¶
A PE may receive the Type 2 Session Transformed routes from the MUP Controller in the SR domain. The PE may keep the received Type 2 Session Transformed routes advertised from the MUP Controller. The receiving PE will perform the importing of the received Type 2 Session Transformed routes in the configured routing instances based on the Route Target extended communities. A PE may discard the received Type 2 Session Transformed route if the PE fails to import the route based on the Route Target extended communities.¶
A MUP controller provides an API. A consumer of the API inputs session information for a UE or a MN from mobility management system. The MUP controller transforms the received session information to routing information and will advertise the session transformed routes with the corresponding extended communities to the SR domain.¶
The received session information is expected to include the UE or MN IP prefix(es), tunnel endpoint identifiers for both ends, and any other attributes for the mobile networks. For example in a 3GPP 5G specific case, the tunnel endpoint identifier will be a pair of the F-TEIDs on both the N3 access side (RAN) and core side (UPF).¶
This section illustrates possible MUP deployments with IPv6 dataplane. 3GPP 5G is an example mobile service for the deployment cases in this section.¶
Figure 2 shows how SR networks can accommodate existing mobile network service before enabling MUP. The PEs S1, S2, and S3 compose an SR network. A routing instance is configured to each network of the mobile service. N6DN in S1 and S2 are providing connectivity to edge servers and the Internet respectively.¶
VRF (Virtual Routing Forwarding) is the routing instance to accommodate MUP segments in this section. All example cases in this section follow the typical routing policy control using the BGP extended community described in [RFC4360] and [RFC4684]¶
__ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \
/ V/v\_ | +-----+ | N6 __
\ / \ |----+ +----| DN / \
\__/ \| S1 | | S2 |----/W/w \
__ /|----+ +----| \ /
/ \__/ | +----+ | \__/
/ E/e\N6 \ | S3 | /
\ /DN \------------+----+------------/
\__/ N3UPF /\ N6UPF
X/x / \ Y/y
+-----+
| UPF |
+-----+
The following routing instances are configured:¶
Here, the PEs S1, S2 and S3 are configured to enable MUP as follows:¶
S1 adopts the local N6DN to prioritize the closer segment for the same Direct Segment. Another PE may adopt D1 from S2, if the PE has no local N6DN for D1 and closer to S2 than S1.¶
U1
|
U/u v
\__ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \
/ V/v\_ | +-----+ | N6 __
\ / \ |----+ +----| DN / \
\__/ \| S1 | | S2 |----/W/w \
__ /|----+ +----| \ /
/ \__/ | +----+ | \__/
/ E/e\N6 \ | S3 | /
\ /DN \------------+----+------------/
\__/ N3UPF /\ N6UPF
X/x / \ Y/y
+-----+
| UPF |
+-----+
Now, session information U1 is put to a MUP Controller, MUP-C, and MUP-C is configured to transform U1 to the routes as follows:¶
Then N3RAN and N6DN import route X and U/u respectively. S1 and S2 resolves U/u's remote endpoint with V/v and then install SID S1:: for U/u in FIB. S1:: will not appear in the packet from E/e to U/u over the wire.¶
As S1 adopts local N6DN for D1, N3RAN in S1 decapsulates GTP-U packets from V/v to X and then lookup the inner packets from U/u in N6DN after the decapsulation.¶
Another case shown in Figure 4 is that S4 joins the SR network and accommodates edge servers in the N6DN in S4.¶
U1
|
U/u v __
\__ N3 /-----------+-----+------------\ / \
/ \RAN / |MUP-C| \ __/W/w \
/ V/v\_ | +-----+ +----|_/N6\ /
\ / \ |----+ | S2 | DN \__/
\__/ \| S1 | +----| __
__ /|----+ +----|_ / \
/ \__/ | +----+ | S4 | \__/E/e \
/ \N6 \ | S3 | +----/ N6\ /
\ /DN \------------+----+------------/ DN \__/
\__/ N3UPF /\ N6UPF
X/x / \ Y/y
+-----+
| UPF |
+-----+
The following routing instances are configured:¶
Here, the PEs are configured to enable MUP as following:¶
As in the previous case, S1 adopts the local N6DN for D1 as long as S1 prioritizes the closer segment for the same MUP Direct Segment. The Direct type route from S4 for D2 with SID S4:: will be kept in S1.¶
Then N3RAN and N6DN import route X and U/u respectively. S2 and S4 resolve U/u's remote endpoint with V/v and then install SID S1:: for U/u in FIB.¶
As in the previous case, S1 adopts local N6DN for D1, N3RAN in S1 decapsulates GTP-U packets from V/v to X and then lookup the inner packets from U/u in N6DN after the decapsulation.¶
For D2 on the other hand, no corresponding N6DN existed in S1. However, E/e with RT C4 from S4 is imported into N6DN in S1 as a VPN route, E/e is reachable from U/u via N6DN for D1 in S1.¶
If a session U1' includes the DN corresponding to D2, MUP-C advertises Type 2 session transformed route X' with MUP Direct Segment community D2, and then N3RAN in S1 instantiates H.M.GTP4.D or End.M.GTP6.D for X with S4:: as the last SID in the received Direct type route from S4.¶
In this case only S1 enables MUP in a collapsed fashion. S2 and S3 are L3VPN PEs without MUP capability. In this section, S2 and S3 are illustrated as SRv6 nodes. But they can be non-SR nodes if S1 provides SR independent connectivity to S2 and S3.¶
U1
|
U/u v
\__ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \
/ V/v\_ | +-----+ | N6 __
\ / \ |----+ +----| DN / \
\__/ \| S1 | | S2 |----/W/w \
__ /|----+ +----| \ /
/ \__/ | +----+ | \__/
/ E/e\N6 \ | S3 | /
\ /DN \------------+----+------------/
\__/ N3UPF /\ N6UPF
X/x / \ Y/y
+-----+
| UPF |
+-----+
The difference between the previous case in Section 7.1 for the routing instance configuration is following:¶
Here, S1 is configured to enable MUP and S2 as an L3VPN PE is configured as follows:¶
Now, session information U1 is added to the MUP Controller, MUP-C, and MUP-C and S1 is configured to transform U1 to the routes as follows:¶
Then the N3RAN and N6DN import route X and U/u respectively. S1 resolves U/u's remote endpoint with V/v and then create the corresponding GTP encap entry for U/u into the N3RAN FIB. S2 will create a regular L3VPN routing entry for U/u with SID S1:1:: in the N6DN when S2 imports the L3VPN route with RT C4 for U/u advertised from S1.¶
As S1 adopts local N6DN for D1, N3RAN in S1 decapsulates GTP-U packets from V/v to X and then lookup the inner packets from U/u in N6DN after the decapsulation.¶
This memo includes no request to IANA.¶
The authors would like to thank Jeffrey Zhang for his review and discussions with the authors.¶