Internet DRAFT - draft-mhkk-dmm-srv6mup-architecture
draft-mhkk-dmm-srv6mup-architecture
Internet Engineering Task Force S. Matsushima
Internet-Draft K. Horiba
Intended status: Standards Track A. Khan
Expires: 25 April 2024 Y. Kawakami
SoftBank
T. Murakami
K. Patel
Arrcus, Inc
M. Kohno
T. Kamata
P. Camarillo
J. Horn
Cisco Systems, Inc.
D. Voyer
Bell Canada
S. Zadok
I. Meilik
Broadcom
A. Agrawal
K. Perumal
Intel
23 October 2023
Mobile User Plane Architecture using Segment Routing for Distributed
Mobility Management
draft-mhkk-dmm-srv6mup-architecture-06
Abstract
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.
Matsushima, et al. Expires 25 April 2024 [Page 1]
Internet-Draft MUP Architecture October 2023
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 25 April 2024.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6
4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 7
4.1. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 7
5. Distribution of Mobile User Plane Segment Information . . . . 7
5.1. Direct Segment Discovery Route . . . . . . . . . . . . . 8
5.2. Interwork Segment Discovery Route . . . . . . . . . . . . 8
6. Distribution of Session Transformed Route . . . . . . . . . . 9
6.1. Type 1 Session Transformed Route . . . . . . . . . . . . 9
6.2. Type 2 Session Transformed Route . . . . . . . . . . . . 10
6.3. MUP Controller . . . . . . . . . . . . . . . . . . . . . 10
7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 10
Matsushima, et al. Expires 25 April 2024 [Page 2]
Internet-Draft MUP Architecture October 2023
7.1. SR Network Accommodating Existing Mobile Network
Services . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. MUP PE Deployment at All SR Domain Edges . . . . . . . . 12
7.3. Adding Direct Segment with New MUP PE . . . . . . . . . . 14
7.4. Collapsed MUP PE Deployment . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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.
Matsushima, et al. Expires 25 April 2024 [Page 3]
Internet-Draft MUP Architecture October 2023
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 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.
Matsushima, et al. Expires 25 April 2024 [Page 4]
Internet-Draft MUP Architecture October 2023
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.
1.1. Requirements Language
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].
2. Terminology
MUP: Mobile User Plane
MUP Segment: Representation of mobile user plane segment
MUP PE: MUP aware Provider Edge node
MUP Controller: Controller node for an SR network
UE: User Equipment, as per [TS.23501]
MN: Mobile Node, as per [RFC5213]
Matsushima, et al. Expires 25 April 2024 [Page 5]
Internet-Draft MUP Architecture October 2023
3. Architecture Overview
In the MUP architecture, a network segment consists of a mobile
service is represented as a MUP segment. This document introduces
new segment types of MUP segment called "Direct segment", and
"Interwork Segment". Other segment types may be specified in another
document in the future. A MUP PE may accommodate MUP segment(s),
such as 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 /
\_______/ \| MUP PE| SR |MUP PE|/ \_______/
_______ /|-------+ Network +------|\ _______
/ \ / | | \ / \
/ Direct \_/ \ / \_/Interwork\
\ Segment / \____________________________/ \ Segment /
\_______/ \_______/
Figure 1: Overview of MUP Architecture
This document also defines new routing information called "Segment
Discovery route" and "Session Transformed route". A MUP PE sends
and/or receives these types of routing information, and does the
dataplane action indicated by the routing information at wherever the
MUP PE instantiated. The illustrations are described in Section 7.
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.
Matsushima, et al. Expires 25 April 2024 [Page 6]
Internet-Draft MUP Architecture October 2023
4. Mobile User Plane Segment
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 MUP 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.
A MUP PE may be instantiated as a physical node or a virtual node.
The MUP PE may also be instantiated on a device which accomodates a
mobile user plane node of a mobility management system.
4.1. IPv6 Dataplane
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 MUP PE interfaces to 5G user plane on the
access side defined as "N3" in [TS.23501], the MUP PE accommodates
the N3 network as Interwork Segment in a routing instance and then
the behavior of created segment SID by the MUP PE will be
"End.M.GTP4.E", or "End.M.GTP6.E". In this case, the MUP PE may
associate the SID to the routing instance for the N3 access network
(N3RAN).
Another example here is that a MUP PE interfaces to 5G DN on the core
side defined as "N6" in [TS.23501], the MUP PE accommodates the N6
network in a routing instance as Direct Segment and then the behavior
of the created segment SID by the MUP PE will be "End.DT4",
"End.DT6", or "End.DT2". In this case, the MUP PE may associate the
SID to the routing instance for the N6 data network (N6DN).
5. Distribution of Mobile User Plane Segment Information
Distribution of MUP segment information can be done by advertising
routing information with the MUP segment for mobile service. A MUP
PE distributes MUP segment information when a MUP segment is
connected to the MUP PE.
Matsushima, et al. Expires 25 April 2024 [Page 7]
Internet-Draft MUP Architecture October 2023
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.
5.1. Direct Segment Discovery Route
When a MUP PE accommodates a network through an interface or a
routing instance as a Direct Segment, the MUP 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 MUP 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 MUP 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 MUP PE, corresponding SID
and Direct Segment extended community to the routing instance for the
DN from the MUP PE.
When a MUP PE receives a Direct Segment Discovery route from other
PEs, the MUP PE keeps the received Direct Segment Discovery route in
the RIB. The MUP 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 MUP PE
updates the FIB entry for the Type 2 session transformed route with
the SID of the matched Direct Segment Discovery route.
5.2. Interwork 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.
Matsushima, et al. Expires 25 April 2024 [Page 8]
Internet-Draft MUP Architecture October 2023
When a MUP PE receives a Interwork Segment Discovery route, the MUP
PE keeps the received Interwork Segment Discovery routes in the RIB.
The MUP 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 MUP 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 MUP PE may discard the
received Interwork segment discovery route if the Route Target
extended communities of the route does not meet the MUP PE's import
policy.
6. Distribution of Session Transformed Route
MUP architecture defines two types of session transformed route.
6.1. Type 1 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 MUP PE may receive the Type 1 Session Transformed routes from the
MUP Controller in the SR domain. The MUP PE may keep the received
Type 1 Session Transformed routes advertised from the MUP Controller.
The receiving MUP 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 MUP PE may discard
the received Type 1 Session Transformed route if the MUP PE fails to
import the route based on the Route Target extended communities.
Matsushima, et al. Expires 25 April 2024 [Page 9]
Internet-Draft MUP Architecture October 2023
6.2. Type 2 Session Transformed Route
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 MUP PE may receive the Type 2 Session Transformed routes from the
MUP Controller in the SR domain. The MUP PE may keep the received
Type 2 Session Transformed routes advertised from the MUP Controller.
The receiving MUP 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 MUP PE may discard
the received Type 2 Session Transformed route if the MUP PE fails to
import the route based on the Route Target extended communities.
6.3. MUP Controller
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).
7. Illustration
This section illustrates possible MUP deployments with IPv6
dataplane. 3GPP 5G is an example mobile service for the deployment
cases in this section.
7.1. SR Network Accommodating Existing Mobile Network Services
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.
Matsushima, et al. Expires 25 April 2024 [Page 10]
Internet-Draft MUP Architecture October 2023
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 |
+-----+
Figure 2
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
Matsushima, et al. Expires 25 April 2024 [Page 11]
Internet-Draft MUP Architecture October 2023
* 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.
7.2. MUP PE Deployment at All SR Domain Edges
Here, the PEs S1, S2 and S3 are configured to enable MUP as follows:
* S1
- advertises Interwork type discovery route: V/v with SID S1::
- set S1:: behavior End.M.GTP4.E or End.M.GTP6.E
* S1
- 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
- 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 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.
Matsushima, et al. Expires 25 April 2024 [Page 12]
Internet-Draft MUP Architecture October 2023
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 |
+-----+
Figure 3
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:
* MUP-C
- attach the MUP Direct Segment ID D1 and 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 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.
Note: When the above configurations have been done, MUP is applied
Matsushima, et al. Expires 25 April 2024 [Page 13]
Internet-Draft MUP Architecture October 2023
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.
7.3. Adding Direct Segment with New MUP PE
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 |
+-----+
Figure 4
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
Matsushima, et al. Expires 25 April 2024 [Page 14]
Internet-Draft MUP Architecture October 2023
- 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, the PEs are configured to enable MUP as following:
* S1 (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
- 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 (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
- 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
Matsushima, et al. Expires 25 April 2024 [Page 15]
Internet-Draft MUP Architecture October 2023
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.
* MUP-C (same with the previous case)
- attach the MUP Direct Segment ID D1 and 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 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.
Note: When the above configurations have been done, 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.
7.4. Collapsed MUP PE Deployment
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.
Matsushima, et al. Expires 25 April 2024 [Page 16]
Internet-Draft MUP Architecture October 2023
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 |
+-----+
Figure 5
The difference between the previous case in Section 7.1 for the
routing instance configuration is following:
* N6DN in S1
- export route E/e with RT C4
- import routes which have RT C3, C4 and C5
Here, S1 is configured to enable MUP and S2 as an L3VPN PE is
configured as follows:
* S1
- may not advertise Interwork type discovery route for V/v
- may not advertise Direct type discovery route with MUP Direct
Segment community D1 and S1:1::
- set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1
* S2
- set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2
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:
Matsushima, et al. Expires 25 April 2024 [Page 17]
Internet-Draft MUP Architecture October 2023
* MUP-C
- attach the MUP Direct Segment ID D1 and RT C5 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 C5
- 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
* S1
- advertises U/u as an L3VPN route with RT C4 and SID S1:1::,
when the Type 1 session transformed route is imported into the
N6DN
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.
Note: When the above configurations have been done, 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.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
TBD.
10. References
10.1. Normative References
Matsushima, et al. Expires 25 April 2024 [Page 18]
Internet-Draft MUP Architecture October 2023
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<https://www.rfc-editor.org/info/rfc7333>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
10.2. Informative References
[I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
and D. Voyer, "Segment Routing IPv6 for Mobile User
Plane", Work in Progress, Internet-Draft, draft-ietf-dmm-
srv6-mobile-uplane-24, 17 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-
srv6-mobile-uplane-24>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
Matsushima, et al. Expires 25 April 2024 [Page 19]
Internet-Draft MUP Architecture October 2023
[RFC8885] Bernardos, CJ., de la Oliva, A., Giust, F., Zúñiga, JC.,
and A. Mourad, "Proxy Mobile IPv6 Extensions for
Distributed Mobility Management", RFC 8885,
DOI 10.17487/RFC8885, October 2020,
<https://www.rfc-editor.org/info/rfc8885>.
[TS.23501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501 17.2.0, 24 September 2021,
<http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
Acknowledgements
The authors would like to thank Jeffrey Zhang for his review and
discussions with the authors.
Contributors
Clarence Filsfils
Cisco Systems, Inc.
Belgium
Email: cf@cisco.com
Authors' Addresses
Satoru Matsushima
SoftBank
Japan
Email: satoru.matsushima@g.softbank.co.jp
Katsuhiro Horiba
SoftBank
Japan
Email: katsuhiro.horiba@g.softbank.co.jp
Ashiq Khan
SoftBank
Japan
Email: ashiq.khan@g.softbank.co.jp
Yuya Kawakami
SoftBank
Japan
Email: yuya.kawakami01@g.softbank.co.jp
Matsushima, et al. Expires 25 April 2024 [Page 20]
Internet-Draft MUP Architecture October 2023
Tetsuya Murakami
Arrcus, Inc.
United States of America
Email: tetsuya@arrcus.com
Keyur Patel
Arrcus, Inc.
United States of America
Email: keyur@arrcus.com
Miya Kohno
Cisco Systems, Inc.
Japan
Email: mkohno@cisco.com
Teppei Kamata
Cisco Systems, Inc.
Japan
Email: tkamata@cisco.com
Pablo Camarillo Garvia
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Jakub Horn
Cisco Systems, Inc.
Czech Republic
Email: jakuhorn@cisco.com
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca
Shay Zadok
Broadcom
Israel
Email: shay.zadok@broadcom.com
Matsushima, et al. Expires 25 April 2024 [Page 21]
Internet-Draft MUP Architecture October 2023
Israel Meilik
Broadcom
Israel
Email: israel.meilik@broadcom.com
Ashutosh Agrawal
Intel
United States of America
Email: ashutosh.agrawal@intel.com
Kumaresh Perumal
Intel
United States of America
Email: kumaresh.perumal@intel.com
Matsushima, et al. Expires 25 April 2024 [Page 22]
