Segment Routing IPv6 Mobile User Plane Architecture for Distributed Mobility Management

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 8 September 2022.¶

Copyright Notice

Copyright (c) 2022 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

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:¶

REQ1: Distributed mobility management

IP mobility, network access solutions, and forwarding solutions provided by DMM MUST enable traffic to avoid traversing a single mobility anchor far from the optimal route. It is noted that the requirement on distribution applies to the data plane only.¶

REQ3: IPv6 deployment

DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, particularly in situations where private IPv4 addresses and/or NATs are used.¶

REQ4: Existing mobility protocols

A DMM solution MUST first consider reusing and extending IETF standard protocols before specifying new protocols.¶

REQ5: Coexistence with deployed networks/hosts and operability across different networks

A DMM solution may require loose, tight, or no integration into existing mobility protocols and host IP stacks. Regardless of the integration level, DMM implementations MUST be able to coexist with existing network deployments, end hosts, and routers that may or may not implement existing mobility protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when the needed mobility management signaling, forwarding, and network access are allowed by the trust relationship between them.¶

This document defines the Segment Routing IPv6 Mobile User Plane (SRv6 MUP) architecture for Distributed Mobility Management. SRv6 MUP is not a mobility management system itself, but an architecture to integrate mobile user plane into the SRv6 data plane.¶

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 SRv6 MUP will naturally be deployed over IPv6 networks (REQ3).¶

SRv6 MUP architecture is independent from the mobility management system. For the requirements (REQ4, 5), SRv6 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 SRv6 MUP integration for mobile networks running based on the existing architecture will be varied and depending on the level of SRv6 awareness of the control and user plane entities.¶

Specifying how to modify the existing architecture to integrate SRv6 MUP is out of scope of this document. What this document provides for the existing architecture is an interface for SRv6 MUP which the existing or future architectures can easily integrate.¶

2. Terminology

MUP:

Mobile User Plane¶

MUP Segment:

Representation of mobile user plane segment¶

MUP PE:

Provider Edge node in a MUP network¶

MUP GW:

Gateway node to interwork with another mobile user plane networks¶

MUP Controller:

Controller node for a MUP network¶

UE:

User Equipment, as per [TS.23501]¶

MN:

Mobile Node, as per [RFC5213]¶

3. Architecture Overview

SRv6 MUP architecture defined in this document introduces a new segment type of the SR called "Mobile User Plane (MUP) segment" and new routing information called "Segment Discovery route" and "Session Transformed route", then 3 new network nodes; MUP PE, MUP GW and MUP Controller. Figure 1 depicts the overview.¶

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.¶

                          *   Mobility   *
                           * Management *
                            *  System  *
                             *........*
                                 |
                         Session Information
                                 |
                                 v
                         +----------------+
                       --| MUP Controller |--            ___________
                      /  +----------------+  \          /           \
  ___________        /         _______    +--------+   /             \
 /           \      /         /       \---| MUP PE |---\ MUP Segment /
/             \  +--------+  /         \  +--------+    \___________/
\ MUP Segment /--| MUP GW |--\ SRv6 NW /  +--------+     ___________
 \___________/   +--------+   \_______/---| MUP PE |----/           \
                                          +--------+   /             \
                                                       \ MUP Segment /
                                                        \___________/

6. MUP Controller

A MUP controller provides a northbound 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 transformed route 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).¶

SRv6 MUP architecture defines two types of session transformed route.¶

First type route is that IP prefix(es) for a UE or MN may be encoded in a BGP MP-NLRI attribute with associated session information of the tunnel endpoint identifier on the access side. The MUP controller advertises the UE or MN route to the SR domain.¶

Second type route is that the tunnel endpoint identifier of the session on the core side may also be encoded in another 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.¶

MUP PE and GW are expected to receive the routes advertised from the MUP controller. A MUP PE imports a Type 1 session transformed route for UE or MN into the corresponding Direct type routing instance. A MUP GW imports a Type 2 session transformed route for core side session tunnel endpoint identifier into the corresponding Interwork type routing instance.¶

7. Illustration

This section shows an illustration of SRv6 MUP deployment. The example deployment cases here is 3GPP 5G.¶

Before enabling SRv6 MUP, how SRv6 networks can accommodate existing mobile network service shown in Figure 2. SR nodes S1, S2, and S3 join an SR network. A routing instance is configured to each network of the mobile service. N6DN in S1 and S2 are supposed to provide connectivity to edge servers and the Internet respectively.¶

VRF (Virtual Routing Forwarding) may be a way to instantiate the routing instance for realizing the routing policy of each instance. 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:¶

• N3RAN in S1¶
• • export route V/v with route-target (RT) community C1¶
  • import routes which have route-target (RT) community C1 and C2¶

• N6DN in S1¶
• • export route E/e with RT C4¶
  • import routes which have RT C3 and C4¶

• N6DN in S2¶
• • export route W/w with RT C4¶
  • import routes which have RT C3 and C4¶

• N3UPF in S3¶
• • export route X/x with RT C2¶
  • import routes which have RT C1¶

• N6UPF in S3¶
• • export route Y/y with RT C3¶
  • import routes which have RT C4¶

Note:

The above configurations are just to provide typical IP connectivity for 3GPP 5G. When the above configurations have been done, each endpoint in V/v and X/x can communicate through S1 and S3, but they can not communicate with nodes in E/e, W/w and Y/y.¶

Here, SR nodes are configured to enable SRv6 MUP as following:¶

• S1 as MUP GW¶
• • advertises Interwork type discovery route: V/v with SID S1::¶
  • set S1:: behavior End.M.GTP4.E or End.M.GTP6.E¶

• S1 as MUP PE¶
• • advertise Direct type discovery route: MUP direct segment community D1 and SID S1:1::¶
  • set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1¶

• S2 as MUP PE¶
• • advertise Direct type route: MUP direct segment community D1 and SID S2::¶
  • set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2¶

S1 here adopts the local N6DN for D1 as long as S1 prioritizes closer segment for the same MUP direct segment. Another MUP GW runs on a SR node may adopt D1 from S2, if the SR node 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 comes to a MUP Controller, MUP-C, and MUP-C is configured to transforms U1 to the routes as follows:¶

• MUP-C¶
• • attach the RT C3 to the DN in U1¶
  • transforms UE's prefix U/u, the F-TEID on access side (gNB) and QFI in U1 to the Type 1 session transformed route for the prefix U/u with the F-TEID, the QFI, and RT C3¶
  • transforms F-TEID on core side (UPF) X in U1 to the Type 2 session transformed route for X with MUP segment-ID D1 and RT C2¶

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 be appeared 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.¶

Note:

When the above configurations have been done, SRv6 MUP is applied only to the packets from/to U/u. Each endpoint in U/u, W/w and E/e can communicate through S1 and S2. The rest of traffic from/to other UEs go through the usual 3GPP 5G user plane path using UPF via S3.¶

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:¶

• N3RAN in S1 (same with the previous case)¶
• • export route V/v with RT C1¶
  • import routes which have RT C1 and C2¶

• N6DN in S1¶
• • export no route¶
  • import routes which have RT C4¶

• N6DN in S2 (same with the previous case)¶
• • export route W/w with RT C4¶
  • import routes which have RT C3 and C4¶

• N3UPF in S3 (same with the previous case)¶
• • export route X/x with RT C2¶
  • import routes which have RT C1¶

• N6UPF in S3 (same with the previous case)¶
• • export route Y/y with RT C3¶
  • import routes which have RT C4¶

• N6DN in S4¶
• • export route E/e with RT C4¶
  • import routes which have RT C3 and C4¶

Here, SR nodes are configured to enable SRv6 MUP as following:¶

• S1 as MUP GW (same with the previous case)¶
• • advertises Interwork type route: V/v with SID S1::¶
  • set S1:: behavior End.M.GTP4.E or End.M.GTP6.E¶

• S1 as MUP PE¶
• • advertise Direct type route: MUP direct segment community D1 for the local N6DN¶
  • set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1¶

• S2 as MUP PE (same with the previous case)¶
• • advertise Direct type route: MUP direct segment community D1 and SID S2::¶
  • set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2¶

• S4 as MUP PE¶
• • advertise Direct type route: MUP direct segment community D2 and SID S4::¶
  • set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4¶

As same as the previous case, S1 adopts the local N6DN for D1 as long as S1 prioritizes closer segment for the same MUP direct segment. The Direct type route from S4 for D2 with SID S4:: will be kept in S1.¶

• MUP-C (same with the previous case)¶
• • attach the RT C3 to the DN in U1¶
  • transforms UE's prefix U/u, the F-TEID on access side (gNB) and QFI in U1 to the Type 1 session transformed route for the prefix U/u with the F-TEID, the QFI, and RT C3¶
  • transforms F-TEID on core side (UPF) X in U1 to the Type 2 session transformed route for X with MUP direct segment community D1 and RT C2¶

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 same as 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 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.¶

Note:

When the above configurations have been done, SRv6 MUP is applied only to the packets from/to U/u. Each endpoint in U/u, W/w and E/e can communicate through S1, S2 and S4. The rest of traffic from/to other UEs go through the usual 3GPP 5G user plane path using UPF via S3.¶

8. IANA Considerations

This memo includes no request to IANA.¶

9. Security Considerations

TBD.¶

Authors' Addresses