Mobile User Plane Architecture for Distributed Mobility Management
draft-ietf-dmm-mup-architecture-02
| Document | Type | Active Internet-Draft (dmm WG) | |
|---|---|---|---|
| Authors | Satoru Matsushima , Katsuhiro Horiba , Yuya Kawakami , Tetsuya Murakami , Keyur Patel , Jakub Horn | ||
| Last updated | 2026-07-04 | ||
| Replaces | draft-mhkk-dmm-mup-architecture | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Reviews |
BGPDIR Early Review due 2026-08-28
Incomplete
RTGDIR Early Review due 2026-08-28
Requested
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dmm-mup-architecture-02
Internet Engineering Task Force S. Matsushima
Internet-Draft SoftBank
Intended status: Standards Track K. Horiba
Expires: 5 January 2027
Y. Kawakami
SoftBank
T. Murakami
K. Patel
Arrcus, Inc
J. Horn
Cisco Systems, Inc.
4 July 2026
Mobile User Plane Architecture for Distributed Mobility Management
draft-ietf-dmm-mup-architecture-02
Abstract
This document defines the Mobile User Plane (MUP) architecture for
Distributed Mobility Management. The requirements for Distributed
Mobility Management described in [RFC7333] can be satisfied by
routing fashion.
In MUP Architecture, session information between the entities of the
mobile user plane is turned to routing information so that mobile
user plane can be integrated into dataplane.
MUP architecture is designed to be pluggable user plane part of
existing mobile service architectures, enabled by auto-discovery for
the use plane. Segment Routing provides network programmability for
a scalable option with it.
While MUP architecture itself is independent from a specific
dataplane protocol, several dataplane options are available for the
architecture. This document describes IPv6 dataplane in Segment
Routing case (SRv6 MUP) due to the DMM requirement, and is suitable
for mobile services which require a large IP address space.
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/.
Matsushima, et al. Expires 5 January 2027 [Page 1]
Internet-Draft MUP Architecture July 2026
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 January 2027.
Copyright Notice
Copyright (c) 2026 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 Principles . . . . . . . . . . . . . . . . . . . 6
4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 7
4.1. Dataplane Considerations . . . . . . . . . . . . . . . . 8
5. Distribution of Mobile User Plane Segment Information . . . . 8
5.1. Direct Segment Discovery (DSD) Route . . . . . . . . . . 9
5.2. Interwork Segment Discovery (ISD) Route . . . . . . . . . 10
6. Distribution of Session Transformed Route . . . . . . . . . . 11
6.1. Type 1 Session Transformed (ST1) Route . . . . . . . . . 11
6.2. Type 2 Session Transformed (ST2) Route . . . . . . . . . 12
6.3. MUP Controller . . . . . . . . . . . . . . . . . . . . . 14
7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. SR Network Accommodating Existing Mobile Network
Services . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. MUP PE Deployment at All SR Domain Edges . . . . . . . . 16
7.3. Adding Direct Segment with New MUP PE . . . . . . . . . . 18
7.4. Collapsed MUP PE Deployment . . . . . . . . . . . . . . . 20
7.5. Distributed Home Routed Roaming Interconnection with
Multiple Home Operators . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
Matsushima, et al. Expires 5 January 2027 [Page 2]
Internet-Draft MUP Architecture July 2026
10.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Additional Authors . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Mobile service systems require IP connectivity for communication
between the entities defined by mobile service architectures for the
mobile service systems. [RFC5213][TS.23501].
In PMIPv6 [RFC5213], IP connectivity is required between LMA (Local
Mobility Anchor) and MAG (Mobility Access Gateway), as well as LMA
and Internet. In 3GPP 5G [TS.23501], IP connectivity for N3
interface between gNodeB(es) and UPFs (User Plane Function) is
required, as well as for N6 interface between UPFs and DNs (Data
Network).
These IP connectivities may be covered by multiple dataplane
networks, such as IPv4, IPv6, MPLS, or bunch of dataplane protocols.
When just one dataplane protocol network is adopted for simplicity,
it is expected that the address space of the dataplane network should
be large enough to cover a vast number of nodes, such as millions of
base stations. For this reason, use of IPv6 dataplane looks
sufficiently suitable.
IPv6 dataplane has been able to instantiate Segment Routing over IPv6
(SRv6) with network programming capability described in [RFC8986].
SRv6 network programmability enhances IPv6 dataplane to be integrated
with mobile user plane [RFC9433]. It will make an entire IPv6
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 PDU 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
Matsushima, et al. Expires 5 January 2027 [Page 3]
Internet-Draft MUP Architecture July 2026
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 for
Distributed Mobility Management. MUP is not a mobility management
system itself, but an architecture enables the dataplanes to
integrate mobile user plane into it for the IP networks.
Although MUP architecture is independent from a specific dataplane
protocol, this document describes IPv6 dataplane in Segment Routing
case (SRv6 MUP) due to the DMM requirement, and as a suitable
solution for scalable mobile service deployments. Other dataplane
options is out of scope of this document, and may be described in the
future.
In this routing paradigm, a session information from a mobile control
plane of a mobile service system will be transformed to routing
information. It means that any MUP dataplane nodes become functional
to the session instead of the mobile user plane specific nodes for
the role of anchor or intermediate points. The user plane anchor and
intermediate functions can be supported by MUP enabled networks
(REQ1), not to mention that MUP will naturally be deployed over IPv6
networks (REQ3).
Matsushima, et al. Expires 5 January 2027 [Page 4]
Internet-Draft MUP Architecture July 2026
MUP architecture is independent from the mobile service 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 service systems running based
on the existing mobile service architecture will be varied and
depending on the level of MUP 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 MUP networks
UE: User Equipment, as per [TS.23501]
MN: Mobile Node, as per [RFC5213]
Serving operator: Operator of the visited network which serves
roaming UEs, as per [TS.23501]
Home operator: Operator of the home network to which roaming UEs
subscribe, as per [TS.23501]
HR roaming: Home Routed roaming, a roaming scenario in which the
traffic of a roaming UE is routed to the home operator
network, as per [TS.23501]
Matsushima, et al. Expires 5 January 2027 [Page 5]
Internet-Draft MUP Architecture July 2026
3. Architecture Principles
This section describes the principles for MUP architecture that guide
its design and operation.
The first key principle is the abstraction of the mobile user plane.
A network segment consisting of a mobile service is abstracted and
represented as a MUP segment. It is noted that MUP segment described
in this document is NOT Segment Routing[RFC8402] specific, as
"segment" is widely common terminology through many networking
technologies, and is defined in each technology context.
A MUP PE may accommodate MUP segment(s), such as an Interwork Segment
and/or a Direct Segment described in Section 4. Figure 1 depicts the
overview.
* Mobility *
* Management *
* System *
*........*
|
Session Information
|
______________v______________
_______ / |MUP-C| \ _______
/ \ / +-----+ \ / \
/Interwork\__ | | __/ Direct \
\ Segment / \ |-------+ +------| / \ Segment /
\_______/ \| MUP PE| MUP |MUP PE|/ \_______/
_______ /|-------+ Network +------|\ _______
/ \ / | | \ / \
/ Direct \_/ \ / \_/Interwork\
\ Segment / \____________________________/ \ Segment /
\_______/ \_______/
Figure 1: Overview of MUP Architecture
The second principle is auto-discovery for MUP segment. A MUP PE
should be able to discover a MUP segment in a remote MUP PE. In MUP
architecture, the remote MUP PE should advertise an auto-discovery
route for a hosted MUP segment. The MUP PE can discover the MUP
segment in the remote MUP PE when the MUP PE finds the MUP segment
information in the received auto-discovery route from the remote MUP
PE.
Section 5 in this document defines auto-discovery route for each type
of MUP segment discovery.
Matsushima, et al. Expires 5 January 2027 [Page 6]
Internet-Draft MUP Architecture July 2026
It is noted that the auto-discovery route must be independent from a
specific dataplane. But with an attribute for the specific
dataplane, the auto-discovery route indicates specific dataplane
behavior required for the MUP segment.
The third principle is that transforming session information to
routing information. Assuming session information for a UE or a MN
includes a pair of endpoints between the entities of the mobile user
plane, a MUP Controller (MUP-C) advertises MUP PE(s) routing
information for the UE or the MN, transformed from the input of
corresponding session information in mobile service systems. In MUP
architecture, it is called session-transformed route.
Section 6 in this document defines each type of session-transformed
route. The session-transformed route must also be dataplane
independent.
A MUP PE should resolve reachability for a received session-
transformed route (ST route for short). When the MUP PE succeeds to
resolve the ST route reachability with a MUP segment in local, or in
remote via an auto-discovery route, and an appropriate dataplane
behavior indicated in it for the ST route, the MUP PE can perform the
dataplane action to the corresponding packet received from a local
MUP segment.
The MUP PE sends the packet toward the egress MUP segment after the
dataplane action applied to the packet. The egress MUP segment may
exist in local, or in a remote MUP PE. In latter case, the remote
MUP PE applies the dataplane action indicated by the received packet,
and sends it out to the egress MUP segment.
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.
4. Mobile User Plane Segment
This document defines two 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 MUP networks. Interwork Segment is
another type of MUP segment. It provides connectivity between a user
Matsushima, et al. Expires 5 January 2027 [Page 7]
Internet-Draft MUP Architecture July 2026
plane protocol of existing or future mobile service architecture and
other MUP segments through the MUP networks. For example in 3GPP 5G
case, an Interwork Segment may accommodate an N3 network for RANs, or
an N9 network interconnecting with a home operator network in a home
routed roaming case.
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 accommodates a
mobile user plane node of a mobile service system.
4.1. Dataplane Considerations
As in Section 1, this document describes IPv6 dataplane in Segment
Routing case due to the DMM requirement, and as a suitable solution
for scalable mobile service deployments.
When SRv6 is adopted as the dataplane, an SRv6 SID (Segment
Identifier) can represent a MUP segment. The SID can be any behavior
defined in [RFC8986], [RFC9433], 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 5 January 2027 [Page 8]
Internet-Draft MUP Architecture July 2026
A MUP Segment Discovery route is routing information that associates
the MUP segment with network reachability, and assistant metadata if
applicable. This document defines the basic discovery route types,
Direct Segment Discovery (DSD for short) route, and Interwork Segment
Discovery (ISD for short) 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.
To carry the assistant metadata for the MUP Segment Discovery route,
this document defines MUP extended community. When a metadata
applicable for a set of MUP Segment, a MUP extended community carries
the metadata in the corresponding MUP Segment Discovery routes. The
MUP extended community must be structured to indicate types of MUP
segment specific metadata. Section 5.1 describes Direct Segment type
MUP extended community, and Section 5.2 describes Interwork Segment
type MUP extended community. They are illustrated in Section 7.
MUP Segment Discovery route MUST be used only for resolving
reachability for the ST routes. The connectivity among the routing
instances for MUP Segments may be advertised as VPN routes. This is
to avoid forwarding entries to the prefixes of the MUP Segment
mingled in the other type of routing instance.
A MUP PE may discard the received MUP Segment Discovery route if the
Route Target extended communities of the route does not meet the MUP
PE's import policy.
5.1. Direct Segment Discovery (DSD) Route
When a MUP PE accommodates a network, a service, or an any type of
resource through an interface or a routing instance as a Direct
Segment, the MUP PE advertises the corresponding Direct Segment
Discovery (DSD) route for the interface or the routing instance to
the SR domain. The DSD route includes an address to indicate the
Direct Segment in the MUP PE in the network layer reachability
information (NLRI) with an extended community indicating the
corresponding Direct Segment. Dataplane specific attribute should be
attached to the DSD route, as a auto-discovery route, which itself
must be dataplane independent defined in Section 3.
Matsushima, et al. Expires 5 January 2027 [Page 9]
Internet-Draft MUP Architecture July 2026
For example in 3GPP 5G specific case with SRv6 dataplane, an MUP PE
may connect to N6 interface on a DN side, and a DSD route for the DN
will be advertised with an address of the MUP PE in NLRI, an
corresponding SRv6 SID in the SRv6 specific attribute, and a Direct
Segment type MUP extended community to the routing instance for the
DN from the MUP PE.
When a MUP PE receives a DSD route from other PEs, the MUP PE keeps
the received DSD route in the RIB. The MUP PE uses the received DSD
route to resolve Type 2 Session Transformed (ST2 for short) routes,
described in Section 6.2.
The ST2 route is resolved with the DSD route which has the matching
Direct Segment extended community, and the MUP PE updates the FIB
entry for the ST2 route with the SID of the matched DSD route. When
multiple DSD routes have the matching Direct Segment extended
community, the DSD route to resolve the ST2 route is selected by the
BGP best path selection.
The DSD routes MUST NOT be used to resolve the ST2 routes which do
not have a Direct Segment extended community: such ST2 routes are
resolved with the ISD routes as described in Section 6.2.
5.2. Interwork Segment Discovery (ISD) 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 (ISD) route with the
prefixes of the Interwork Segment. Dataplane specific attribute
should be attached to the ISD route, as a auto-discovery route, which
itself must be dataplane independent defined in Section 3.
For example in 3GPP 5G specific case with SRv6 dataplane, an MUP PE
may connect to N3 network accommodating a RAN, and a ISD route will
be advertised with IP prefix(es) of the N3 RAN in NLRI, and an
corresponding SRv6 SID in the SRv6 specific attribute.
When the MUP networks accommodate multiple Interwork Segments whose
routing and addressing policies need to be separated from each other,
such as N9 networks interconnecting with different home operators in
a home routed roaming case described in Section 7.5, the MUP PE
advertises the ISD route with an Interwork Segment type MUP extended
community which identifies the Interwork Segment that the ISD route
represents.
Matsushima, et al. Expires 5 January 2027 [Page 10]
Internet-Draft MUP Architecture July 2026
An Interwork Segment type extended community value identifies a
single Interwork Segment which consists of one or more networks under
a consistent routing and addressing policy: the ISD routes for the
networks of the Interwork Segment share the community value, and the
value MUST NOT identify more than one Interwork Segment within the
MUP networks.
An ISD route without an Interwork Segment type MUP extended community
is implicitly treated as an ISD route for the default Interwork
Segment. The Route Target based import policy SHOULD be used to keep
only the ISD routes of the intended networks available for the
default Interwork Segment, so that the ISD routes of the policy-
separated Interwork Segments do not fall into the default Interwork
Segment when the community is missing by a misconfiguration.
When a MUP PE receives a ISD route, the MUP PE keeps the received ISD
routes in the RIB. The MUP PE uses the received ISD routes to
resolve the reachability for remote endpoint of Type 1 Session
Transformed (ST1 for short) routes and for the destination endpoint
of ST2 routes, according to the resolution rules described in
Section 6.1 and Section 6.2 respectively. If the ISD route resolves
the reachability for the ST routes, the MUP PE updates the FIB
entries for the prefixes of the ST routes with the SID of the matched
ISD route.
6. Distribution of Session Transformed Route
MUP architecture defines two types of session transformed route.
6.1. Type 1 Session Transformed (ST1) Route
First type route, called Type 1 Session Transformed (ST1) 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-C advertises the ST1 route with the Route
Target extended communities for the UE or MN to the MUP networks.
A MUP PE may receive the ST1 routes from the MUP-C in the MUP
networks. The MUP PE may keep the received ST1 routes advertised
from the MUP-C. The receiving MUP PE will perform the importing of
the received ST1 routes in the configured routing instances based on
the Route Target extended communities. A MUP PE may discard the
received ST1 route if the MUP PE fails to import the route based on
the Route Target extended communities.
Matsushima, et al. Expires 5 January 2027 [Page 11]
Internet-Draft MUP Architecture July 2026
The MUP PE resolves the reachability for the remote endpoint in the
session information of the ST1 route with the received ISD routes.
The Interwork Segment extended community is not required for the ST1
route resolution.
When the MUP networks accommodate the policy-separated Interwork
Segments whose prefixes may overlap each other, the Route Target
based import policy for the ISD routes SHOULD be used to keep only
the ISD routes of the intended Interwork Segments available for the
ST1 route resolution.
The matched packets are carried to the remote endpoint by the
dataplane behavior indicated in the ISD route which resolves the ST1
route, together with the session information of the ST1 route.
For example in a 3GPP 5G case with SRv6 dataplane, the remote
endpoint will be the F-TEID of the gNB on the N3 interface, and the
downlink packets toward the UE are encapsulated into GTP-U toward the
gNB according to the SID behaviors of the MUP PEs, as illustrated in
Section 7.2.
When a MUP PE fails to resolve the reachability for an imported ST1
route, the MUP PE does not install the forwarding entry for the ST1
route, and the packets matched to the prefix of the ST1 route follow
the normal IP routing of the routing instance.
6.2. Type 2 Session Transformed (ST2) Route
Second type route, called Type 2 Session Transformed (ST2) route,
encodes the tunnel endpoint identifier of the session in a BGP MP-
NLRI attribute with the nature of tunnel endpoint base packet
handling. The encoded tunnel endpoint identifier is the key to match
the received packets to the ST2 route, and is called the matching
endpoint of the ST2 route in this document. Longest match algorithm
for the prefix in this type of session transformed route should be
applicable to aggregate the routes for scale.
The MUP-C may attach a MUP extended community to the ST2 route, in
addition to the Route Target extended communities, to indicate the
corresponding MUP segment and the packet handling for the segment.
When the MUP-C advertises the ST2 route with a Direct Segment
extended community, it indicates the corresponding Direct Segment and
tunnel decapsulation. The packets matched to the ST2 route are
decapsulated and looked up in the corresponding Direct Segment. Such
an ST2 route is resolved with the DSD routes as described in
Section 5.1.
Matsushima, et al. Expires 5 January 2027 [Page 12]
Internet-Draft MUP Architecture July 2026
When the MUP-C advertises the ST2 route with an Interwork Segment
extended community, it indicates the destination Interwork Segment
for the packets matched to the ST2 route. The ST2 route without a
MUP extended community indicates the default Interwork Segment as the
destination Interwork Segment.
The tunnel endpoint to which the matched packets are sent on the
destination Interwork Segment is called the destination endpoint of
the ST2 route in this document. The destination endpoint is
determined as follows:
* When the ST2 route includes the session information of a tunnel
endpoint identifier on the destination Interwork Segment, the
endpoint in the session information is the destination endpoint.
The MUP-C attaches the session information when the matched
packets need to be translated toward a tunnel endpoint different
from the matching endpoint.
* Otherwise, the matching endpoint itself is the destination
endpoint.
A MUP PE may receive the ST2 routes from the MUP-C in the MUP
networks. The MUP PE may keep the received ST2 routes advertised
from the MUP-C. The receiving MUP PE will perform the importing of
the received ST2 routes in the configured routing instances based on
the Route Target extended communities. A MUP PE may discard the
received ST2 route if the MUP PE fails to import the route based on
the Route Target extended communities.
When the ST2 route indicates a destination Interwork Segment, the MUP
PE resolves the reachability for the destination endpoint of the ST2
route with the received ISD routes. The ST2 route MUST be resolved
only with the ISD routes of the destination Interwork Segment: the
ISD routes with the matching Interwork Segment extended community, or
the ISD routes for the default Interwork Segment when the ST2 route
has no MUP extended community. This allows the MUP PE to resolve the
ST2 route with the intended Interwork Segment under the separated
routing and addressing policies, even when the prefixes of the
Interwork Segments overlap among them.
The matched packets are carried to the destination endpoint by the
dataplane behavior indicated in the ISD route which resolves the ST2
route, together with the attached session information if present.
Matsushima, et al. Expires 5 January 2027 [Page 13]
Internet-Draft MUP Architecture July 2026
For example in a 3GPP 5G home routed roaming case with SRv6
dataplane, the destination endpoint will be the F-TEID of the UPF in
the home operator network on the N9 interface, and the packets are
carried over the SRv6 dataplane according to the SID behaviors of the
MUP PEs, as illustrated in Section 7.5.
When a MUP PE fails to resolve the reachability for an imported ST2
route, the MUP PE does not install the forwarding entry for the ST2
route, and the packets matched to the prefix of the ST2 route follow
the normal IP routing of the routing instance.
6.3. MUP Controller
A MUP Controller (MUP-C) retrieves or receives session information
for a UE or a MN from mobile service system. The MUP-C transforms
the session information to routing information and will advertise the
session transformed routes with the corresponding extended
communities to the MUP networks.
The 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).
As the MUP architecture is independent from specific mobile service
systems, the MUP-C may leverage any available interfaces or APIs on
the mobile service systems for the session information to be
received. Each mobile service system specific interface/API of MUP-C
is out of scope of this document and other documents may describe
that specific interface/API.
7. Illustration
This section illustrates possible MUP deployments with SRv6
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 5 January 2027 [Page 14]
Internet-Draft MUP Architecture July 2026
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 5 January 2027 [Page 15]
Internet-Draft MUP Architecture July 2026
* 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 and S2 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
S3 does not enable MUP and serves the conventional user plane path as
an L3VPN PE.
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 5 January 2027 [Page 16]
Internet-Draft MUP Architecture July 2026
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 ST1 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 ST2 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
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.
Matsushima, et al. Expires 5 January 2027 [Page 17]
Internet-Draft MUP Architecture July 2026
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
- import routes which have RT C3 and C4
* N3UPF in S3 (same with the previous case)
- export route X/x with RT C2
Matsushima, et al. Expires 5 January 2027 [Page 18]
Internet-Draft MUP Architecture July 2026
- 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
As in the previous case, S3 does not enable MUP and serves the
conventional user plane path as an L3VPN PE.
Matsushima, et al. Expires 5 January 2027 [Page 19]
Internet-Draft MUP Architecture July 2026
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 ST1 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 ST2 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 ST2 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 5 January 2027 [Page 20]
Internet-Draft MUP Architecture July 2026
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 5 January 2027 [Page 21]
Internet-Draft MUP Architecture July 2026
* 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 ST1 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 ST2 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 ST1 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.
7.5. Distributed Home Routed Roaming Interconnection with Multiple Home
Operators
This case shows a home routed (HR) roaming scenario. The serving
operator enables MUP in the SR network. The SR network accommodates
the N3 network for RANs as an Interwork Segment, and it also
accommodates multiple N9 networks interconnecting with home operators
as Interwork Segments. The N9 interconnections are distributed over
the MUP PEs: any MUP PE may accommodate an N9 network, including the
MUP PE which accommodates the RANs. In this scenario, MUP PEs in the
serving operator network perform the user plane handling for HR
roaming sessions between the RAN and the home operator networks,
instead of the user plane specific nodes in the serving operator
network.
Matsushima, et al. Expires 5 January 2027 [Page 22]
Internet-Draft MUP Architecture July 2026
U1
|
U/u v
\__ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \
/ V/v\_ | +-----+ | ___
\ / \ |----+ +----| N9A / \
\__/ \| S1 | | S2 |--------/HO-A \
___ /|----+ +----| \ A/a /
/ \_/ | | \___/
/HO-B \ | +----+ |
\ B/b /N9B\ | S3 | /
\___/ \-----------+----+-----------/
N3UPF /\ N9UPF
X/x / \ Z/z
+-----+
| UPF |
+-----+
Figure 6
Figure 6 shows that S1 accommodates the N3 RAN and the N9 network N9B
which interconnects with home operator B (HO-B), and S2 accommodates
the N9 network N9A which interconnects with home operator A (HO-A).
The routing and addressing of an N9 interconnection are managed under
the policy of each home operator. N9A and N9B are accommodated in
the individual routing instances to separate the policies of the home
operators from each other. The prefixes of the home operator UPF N9
endpoints are A/a in HO-A and B/b in HO-B.
S3 accommodates the UPF of the serving operator as with the previous
cases. The N3 side of the UPF connects to N3UPF in S3, and the N9
side of the UPF connects to N9UPF in S3 with the prefix Z/z. The HR
roaming sessions which are not handled by MUP go through the UPF
between the N3 network and the N9 networks.
The following routing instances are configured:
* N3RAN in S1 (same with the previous cases)
- export route V/v with RT C1
- import routes which have RT C1 and C2
* N3UPF in S3 (same with the previous cases)
- export route X/x with RT C2
Matsushima, et al. Expires 5 January 2027 [Page 23]
Internet-Draft MUP Architecture July 2026
- import routes which have RT C1
* N9UPF in S3 (for the UPF N9 side)
- export route Z/z with RT C7
- import routes which have RT C9 and C10
* N9A in S2 (for the N9 network interconnecting with HO-A)
- export route A/a with RT C9
- import routes which have RT C5 and C7
* N9B in S1 (for the N9 network interconnecting with HO-B)
- export route B/b with RT C10
- import routes which have RT C6 and C7
The routing instance N9UPF exchanges the VPN routes with N9A and N9B
for the connectivity between the UPF N9 side and the N9 networks.
The HR roaming traffic through the UPF is carried among S3, S2 and S1
as the L3VPN traffic.
Here, the PEs are configured to enable MUP as following:
* S1
- advertises Interwork type route: V/v with SID S1:: without an
Interwork Segment community: the N3RAN is the default Interwork
Segment
- set S1:: behavior End.M.GTP4.E or End.M.GTP6.E
- advertises Interwork type route: B/b with SID S1:1:: and MUP
Interwork Segment community I2 for N9B
- set S1:1:: behavior End.M.GTP4.E or End.M.GTP6.E for the N9B in
S1
* S2
- advertises Interwork type route: A/a with SID S2:1:: and MUP
Interwork Segment community I1 for N9A
- set S2:1:: behavior End.M.GTP4.E or End.M.GTP6.E for the N9A in
S2
Matsushima, et al. Expires 5 January 2027 [Page 24]
Internet-Draft MUP Architecture July 2026
The ISD routes for N9A and N9B represent the Interwork Segments for
the N9 networks identified by the Interwork Segment communities I1
and I2. The identified Interwork Segments keep the routing and
addressing policies of the home operators separated in the MUP
networks. It also allows the home operators to use overlapping IP
address spaces for their N9 networks. S3 does not enable MUP and
serves the conventional user plane path as an L3VPN PE.
A session information U1 for a UE subscribing to HO-A is put to MUP-
C. U1 is a HR roaming session which includes the F-TEID V1 on the
access side (gNB) in V/v, the F-TEID Xa on the serving core side of
N3 in X/x, the F-TEID A1 of the HO-A UPF on N9A in A/a, and the
F-TEID Z1 on the serving side of N9A in Z/z.
The prefix Z/z which covers Z1 is advertised to HO-A through the N9A
routing, and the reachability to A/a of HO-A is available in the N9A
routing instance. MUP-C is configured to transform U1 to the routes
as follows:
* MUP-C
- transforms the F-TEID Xa on the serving core side in U1 to the
ST2 route for Xa with MUP Interwork Segment community I1, the
session information of the tunnel endpoint identifier A1 on the
destination Interwork Segment N9A, and RT C2
- transforms the F-TEID Z1 on the serving N9 side in U1 to the
ST2 route for Z1 without a MUP extended community, with the
session information of the tunnel endpoint identifier V1 on the
default Interwork Segment (N3RAN), and RT C5
Then N3RAN in S1 imports the ST2 route Xa. Since the ST2 route Xa
has the Interwork Segment community I1, S1 resolves the reachability
for the destination endpoint A1 in the session information of the
route only with the ISD routes which have I1, that is A/a with SID
S2:1::. N3RAN in S1 instantiates H.M.GTP4.D or End.M.GTP6.D for Xa
with S2:1:: as the last SID in the matched ISD route.
For uplink, the gNB sends GTP-U packets of U1 to Xa. S1 decapsulates
the GTP-U packets, and encapsulates the inner packets into SRv6 with
the SID composed from S2:1:: and the arguments embedding the tunnel
endpoint identifier A1 from the session information of the ST2 route.
S2 performs End.M.GTP4.E or End.M.GTP6.E for the received packets to
encapsulate them into GTP-U toward A1, and then the packets are
forwarded to the HO-A UPF through N9A.
Matsushima, et al. Expires 5 January 2027 [Page 25]
Internet-Draft MUP Architecture July 2026
In N3RAN, the ST2 route Xa is preferred to the VPN route X/x imported
from N3UPF due to the longest match, so that only the packets of U1
are handled by MUP.
N9A in S2 imports the ST2 route Z1. Since the ST2 route Z1 has no
MUP extended community, S2 resolves the reachability for the
destination endpoint V1 in the session information of the route with
the ISD routes for the default Interwork Segment, that is V/v with
SID S1::. N9A in S2 instantiates H.M.GTP4.D or End.M.GTP6.D for Z1
with S1:: as the last SID in the matched ISD route.
For downlink, the HO-A UPF sends GTP-U packets of U1 to Z1 through
N9A. S2 decapsulates the GTP-U packets, and encapsulates the inner
packets into SRv6 with the SID composed from S1:: and the arguments
embedding the tunnel endpoint identifier V1 from the session
information of the ST2 route. S1 performs End.M.GTP4.E or
End.M.GTP6.E for the received packets to encapsulate them into GTP-U
toward V1, and then the packets are delivered to the gNB.
In N9A, the ST2 route Z1 is preferred to the VPN route Z/z imported
from N9UPF due to the longest match, so that only the packets of U1
are handled by MUP.
For a HR roaming session of a UE subscribing to HO-B, MUP-C
advertises the ST2 routes with the Interwork Segment community I2 and
RT C6 in the same manner. The ST2 routes are resolved only with the
ISD route B/b with SID S1:1:: which has I2, and the packets of the
session are forwarded to N9B under the policy of HO-B, independently
from the policy of HO-A. Since S1 accommodates both the N3 RAN and
N9B, the packets of the session are handled locally within S1,
without traversing another MUP PE.
A home operator may also deploy MUP in its network. Figure 7 shows
the case where HO-B deploys MUP: S1 accommodates the RAN (V/v) in the
routing instance N3RAN, and the UE with the prefix U/u attaches to
the RAN. The MUP PE S4 of HO-B connects to S1 through the routing
instance N9B, and S4 accommodates the N6DN (E/e) of HO-B.
U/u ___ ___
\ / \ N3RAN +----+ N9B +----+ N6DN / \
\__/ V/v \-------| S1 |-------| S4 |-------/ E/e \
\ / +----+ +----+ \ /
\___/ \___/
Figure 7
Matsushima, et al. Expires 5 January 2027 [Page 26]
Internet-Draft MUP Architecture July 2026
In this case, the HR roaming sessions of HO-B are handled directly
between the MUP PEs S1 and S4 over the N9B interconnection, and the
packets of the sessions reach the N6DN in S4 without traversing the
user plane specific nodes of the operators. This enables a low-
latency interconnection for HR roaming, for example toward the edge
services in E/e of the home operator.
Note: In this scenario, the GTP-U tunnels of a HR roaming session on
the N3 side and the N9 side are terminated at the MUP PEs, and
the packets of the session are carried over the SRv6 dataplane
between S1 and S2 for the HO-A sessions, or handled locally
within S1 for the HO-B sessions, instead of the user plane
specific nodes on the serving side. The Interwork Segment
communities keep the resolution of the ST2 routes aligned with
the routing and addressing policy of each home operator, even
when the N9 networks use overlapping IP address space. The
rest of the HR roaming traffic from/to other UEs go through the
usual 3GPP 5G user plane path using the UPF via S3.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
The MUP architecture defines routing information that is transformed
from session information of a mobile service system. Spoofing or
tampering of the transformed routing information or the related
control messages may redirect mobile user plane traffic to unintended
segments. Therefore, the routing control plane of the MUP networks
MUST be protected from such spoofing and tampering. The interface
between the mobile service system and the MUP-C SHOULD also be
protected, while each specific interface/API is out of scope of this
document as described in Section 6.3.
When BGP is used to distribute the MUP Segment Discovery routes and
the Session Transformed routes, the deployment SHOULD follow the
operational and security practices in [RFC7454]. In particular, BGP
sessions that distribute these routes MUST be established only with
authorized peers. This is especially important when the routes are
exchanged across AS or administrative domain boundaries.
The import and export policies of the MUP networks MUST ensure that
the MUP Segment Discovery routes and the Session Transformed routes
are propagated only within the intended routing instances and only to
the intended MUP peers. Leakage of these routes may result in
unintended access to mobile user plane traffic or unintended packet
steering. For example in the home routed roaming case described in
Matsushima, et al. Expires 5 January 2027 [Page 27]
Internet-Draft MUP Architecture July 2026
Section 7.5, the routes for an Interwork Segment of a home operator
MUST NOT be leaked to the routing instances of the other home
operators, so that the routing and addressing policies of the home
operators are kept separated.
The forwarding states resolved from the Session Transformed routes
depend on the MUP Segment Discovery routes. When a MUP Segment
Discovery route which resolves Session Transformed routes is
withdrawn or its MUP extended community changes, the MUP PE SHOULD
re-evaluate the resolution of the affected Session Transformed routes
and remove the forwarding entries which no longer have an admissible
route, so that stale forwarding states do not remain.
The re-evaluation above does not protect the case where the operator
of the MUP networks reassigns an Interwork Segment extended community
value to a different Interwork Segment: the Session Transformed
routes still carrying the value would be resolved with the unintended
Interwork Segment, and the mobile user plane traffic may be delivered
to a network of an unintended operator. Therefore, the operator
SHOULD NOT reassign a community value to a different Interwork
Segment while Session Transformed routes carrying the value remain
advertised, and SHOULD take the propagation of the withdrawals across
the MUP networks into account when reassigning the value.
When SRv6 is used as the dataplane, the MUP deployment MUST follow
the security considerations of [RFC8754] and [RFC8986].
10. References
10.1. Normative References
[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>.
Matsushima, et al. Expires 5 January 2027 [Page 28]
Internet-Draft MUP Architecture July 2026
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[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
[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>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[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>.
[RFC9433] Matsushima, S., Ed., Filsfils, C., Kohno, M., Camarillo,
P., Ed., and D. Voyer, "Segment Routing over IPv6 for the
Mobile User Plane", RFC 9433, DOI 10.17487/RFC9433, July
2023, <https://www.rfc-editor.org/info/rfc9433>.
[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>.
Matsushima, et al. Expires 5 January 2027 [Page 29]
Internet-Draft MUP Architecture July 2026
Acknowledgements
The authors would like to thank Jeffrey Zhang, Keiichi Makizono,
Hideyuki Sasaki, Teruyuki Oya, Yoichi Funabiki, Daisuke Koshiro,
Derek Yeung, Kalyani Rajaraman, Csaba Keszei, Daiki Kijima, Ryuma
Seno, Keiji Hara, Mikio Nakajima, Masayuki Yamazaki, Takuto Shiozawa,
Manabu Mikami, Takaya Watanabe, Hidenori Aita, Hiroyuki Fukumori, Leo
Fujita, Toshihiro Yokomine, Toshikazu Morioka, Yadav Rituraji, Junya
Yoshino, Takayuki Koshikawa, Kazunari Nagai, Tadayuki Okuda, Takahiro
Hara, Yuya Kusakabe, Takeru Hayasaka, Hideki Takase, Yutaka Kikuchi,
Kazuma Nishiuchi, Mitsuhiro Osaki, Suresh Krishnan, Sri Gundavelli,
Zafar Ali, Luay Jalil, Markus Amend, Marco Liebsch, and Lionel Morand
for their reviews and discussions with the authors.
Contributors
Clarence Filsfils
Cisco Systems, Inc.
Belgium
Email: cf@cisco.com
Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
Additional Authors
Ashiq Khan
SoftBank
Japan
Email: ashiq.khan@g.softbank.co.jp
Miya Kohno
Cisco Systems, Inc.
Japan
Email: mkohno@cisco.com
Teppei Kamata
Cisco Systems, Inc.
Japan
Email: tkamata@cisco.com
Matsushima, et al. Expires 5 January 2027 [Page 30]
Internet-Draft MUP Architecture July 2026
Pablo Camarillo Garvia
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca
Shay Zadok
Broadcom
Israel
Email: shay.zadok@broadcom.com
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
Authors' Addresses
Satoru Matsushima
SoftBank
Japan
Email: satoru.matsushima@g.softbank.co.jp
Katsuhiro Horiba
Japan
Email: katsuhiro.horiba@gmail.com
Matsushima, et al. Expires 5 January 2027 [Page 31]
Internet-Draft MUP Architecture July 2026
Yuya Kawakami
SoftBank
Japan
Email: yuya.kawakami01@g.softbank.co.jp
Tetsuya Murakami
Arrcus, Inc.
United States of America
Email: tetsuya@arrcus.com
Keyur Patel
Arrcus, Inc.
United States of America
Email: keyur@arrcus.com
Jakub Horn
Cisco Systems, Inc.
Czech Republic
Email: jakuhorn@cisco.com
Matsushima, et al. Expires 5 January 2027 [Page 32]