< draft-mhkk-dmm-srv6mup-architecture-02.txt   draft-mhkk-dmm-srv6mup-architecture-03.txt >
Internet Engineering Task Force S. Matsushima Internet Engineering Task Force S. Matsushima
Internet-Draft K. Horiba Internet-Draft K. Horiba
Intended status: Standards Track A. Khan Intended status: Standards Track A. Khan
Expires: 8 September 2022 Y. Kawakami Expires: 20 September 2022 Y. Kawakami
SoftBank SoftBank
T. Murakami T. Murakami
K. Patel K. Patel
Arrcus, Inc Arrcus, Inc
M. Kohno M. Kohno
T. Kamata T. Kamata
P. Camarillo P. Camarillo
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
S. Zadok S. Zadok
I. Meilik I. Meilik
Broadcom Broadcom
A. Agrawal A. Agrawal
K. Perumal K. Perumal
Intel Intel
J. Horn J. Horn
Cisco Systems, Inc. Cisco Systems, Inc.
7 March 2022 19 March 2022
Segment Routing IPv6 Mobile User Plane Architecture for Distributed Segment Routing IPv6 Mobile User Plane Architecture for Distributed
Mobility Management Mobility Management
draft-mhkk-dmm-srv6mup-architecture-02 draft-mhkk-dmm-srv6mup-architecture-03
Abstract Abstract
This document defines the Segment Routing IPv6 Mobile User Plane This document defines the Segment Routing IPv6 Mobile User Plane
(SRv6 MUP) architecture for Distributed Mobility Management. The (SRv6 MUP) architecture for Distributed Mobility Management. The
requirements for Distributed Mobility Management described in requirements for Distributed Mobility Management described in
[RFC7333] can be satisfied by routing fashion. [RFC7333] can be satisfied by routing fashion.
Mobile services are deployed over several parts of IP networks. A Mobile services are deployed over several parts of IP networks. A
Segment Routing over IPv6 (SRv6) network can accommodate all, or part Segment Routing over IPv6 (SRv6) network can accommodate all, or part
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022. This Internet-Draft will expire on 20 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 6 4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 6
5. Distribution of Mobile User Plane Segment Information . . . . 7 5. Distribution of Mobile User Plane Segment Information . . . . 7
5.1. MUP PE . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Direct Segment Discovery Route . . . . . . . . . . . . . 7
5.2. MUP GW . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Interwork Segment Discovery Route . . . . . . . . . . . . 8
6. MUP Controller . . . . . . . . . . . . . . . . . . . . . . . 8 6. Distribution of Session Transformed Route . . . . . . . . . . 8
7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Type 1 Session Transformed Route . . . . . . . . . . . . 9
6.2. Type 2 Session Transformed Route . . . . . . . . . . . . 9
6.3. MUP Controller . . . . . . . . . . . . . . . . . . . . . 9
7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Mobile services require IP connectivity for communication between the Mobile services require IP connectivity for communication between the
entities of mobile service architecture [RFC5213][TS.23501]. To entities of mobile service architecture [RFC5213][TS.23501]. To
provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a
candidate solution. candidate solution.
In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be
skipping to change at page 5, line 22 skipping to change at page 5, line 26
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
MUP: Mobile User Plane MUP: Mobile User Plane
MUP Segment: Representation of mobile user plane segment MUP Segment: Representation of mobile user plane segment
MUP PE: Provider Edge node in a MUP network PE: Provider Edge node in an SR network
MUP GW: Gateway node to interwork with another mobile user plane
networks
MUP Controller: Controller node for a MUP network MUP Controller: Controller node for an SR network
UE: User Equipment, as per [TS.23501] UE: User Equipment, as per [TS.23501]
MN: Mobile Node, as per [RFC5213] MN: Mobile Node, as per [RFC5213]
3. Architecture Overview 3. Architecture Overview
SRv6 MUP architecture defined in this document introduces a new SRv6 MUP architecture defined in this document introduces new segment
segment type of the SR called "Mobile User Plane (MUP) segment" and types of MUP segment called "Direct segment", and "Interwork
new routing information called "Segment Discovery route" and "Session Segment". An SR node of PE accommodates an Interwork Segment and/or
Transformed route", then 3 new network nodes; MUP PE, MUP GW and MUP a Direct Segment. Figure 1 depicts the overview.
Controller. Figure 1 depicts the overview.
To carry these new routing information, this architecture requires * Mobility *
extending the existing routing protocols. Any routing protocol can * Management *
be used to carry this information but this document recommends using * System *
BGP. Thus, this document describes extensions on BGP as an example. *........*
|
Session Information
|
______________v______________
_______ / |MUP-C| \ _______
/ \ / +-----+ \ / \
/Interwork\__ | | __/ Direct \
\ Segment / \ |----+ +----| / \ Segment /
\_______/ \| PE | SRv6 | PE |/ \_______/
_______ /|----+ Network +----|\ _______
/ \ / | | \ / \
/ Direct \_/ \ / \_/Interwork\
\ Segment / \____________________________/ \ Segment /
\_______/ \_______/
* Mobility * Figure 1: Overview of SRv6 MUP Architecture
* Management *
* System *
*........*
|
Session Information
|
v
+----------------+
--| MUP Controller |-- ___________
/ +----------------+ \ / \
___________ / _______ +--------+ / \
/ \ / / \---| MUP PE |---\ MUP Segment /
/ \ +--------+ / \ +--------+ \___________/
\ MUP Segment /--| MUP GW |--\ SRv6 NW / +--------+ ___________
\___________/ +--------+ \_______/---| MUP PE |----/ \
+--------+ / \
\ MUP Segment /
\___________/
Figure 1: Overview of SRv6 MUP Architecture This document also defines new routing information called "Segment
Discovery route" and "Session Transformed route". To carry these new
routing information, this architecture requires extending the
existing routing protocols. Any routing protocol can be used to
carry this information but this document recommends using BGP. Thus,
this document describes extensions on BGP as an example.
4. Mobile User Plane Segment 4. Mobile User Plane Segment
This document defines one new segment type. A Mobile User Plane This document defines two new types of Mobile User Plane (MUP)
(MUP) segment may represent a network segment consisting of a mobile segment. A MUP segment represents a network segment consisting of a
service. The MUP segment can be created by an SR node which provides mobile service. The MUP segment can be created by a PE which
connectivity for the mobile user plane. The MUP segment SID can be provides connectivity for the mobile user plane.
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 Direct Segment is a type of MUP segment that provides connectivity
representing mobile network segment. For example, in case of an SR between MUP segments through the SRv6 network. Interwork Segment is
node interfaces to 5G user plane on the access side defined as "N3" another type of MUP segment. It provides connectivity between a user
in [TS.23501], the behavior of created segment SID will be plane protocol of existing or future mobile service architecture and
"End.M.GTP4.E", or "End.M.GTP6.E". In this case, the SR node may other MUP segments through the SRv6 networks.
associate the SID to a N3 access network (N3RAN) routing instance.
Another example here is the "N6" interface on the core data network An SRv6 SID (Segment Identifier) can represents a MUP segment. The
side. The behavior of the created segment SID will be "End.DT4", SID can be any behavior defined in [RFC8986],
"End.DT6", or "End.DT2". In this case the SR node may associate the [I-D.ietf-dmm-srv6-mobile-uplane], or any other extensions for
SID to a N6 data network (N6DN) routing instance. further use cases. The behavior of the MUP segment will be chosen by
the role of the representing MUP segment.
For example, in case of a PE interfaces to 5G user plane on the
access side defined as "N3" in [TS.23501], the PE accommodates the N3
network as Interwork Segment in a routing instance and then the
behavior of created segment SID by the PE will be "End.M.GTP4.E", or
"End.M.GTP6.E". In this case, the PE may associate the SID to the
routing instance for the N3 access network (N3RAN).
Another example here is that a PE interfaces to 5G DN on the core
side defined as "N6" in [TS.23501], the PE accommodates the N6
network in a routing instance as Direct Segment and then the behavior
of the created segment SID by the PE will be "End.DT4", "End.DT6", or
"End.DT2". In this case, the PE may associate the SID to the routing
instance for the N6 data network (N6DN).
5. Distribution of Mobile User Plane Segment Information 5. Distribution of Mobile User Plane Segment Information
Distribution of MUP segment information can be done by advertising Distribution of MUP segment information can be done by advertising
routing information with the MUP segment for mobile service. This routing information with the MUP segment for mobile service. A PE
document defines two types of SR node, MUP PE and MUP GW, for distributes MUP segment information when a MUP segment is connected
distributing MUP segment information. to the PE.
A MUP Segment Discovery route is routing information, of which a MUP A MUP Segment Discovery route is routing information that associates
segment is associated with network reachability. This document the MUP segment with network reachability. This document defines the
defines the basic discovery route types, Direct Segment Discovery basic discovery route types, Direct Segment Discovery route, and
route, and Interwork Segment Discovery route. Other types of segment Interwork Segment Discovery route. Other types of segment discovery
discovery route may be mobile service architecture specific. Define route may be mobile service architecture specific. Defining the
the architecture specific network reachability is out of scope of architecture specific network reachability is out of scope of this
this document and it will be specified in another document. document and it will be specified in another document.
5.1. MUP PE 5.1. Direct Segment Discovery Route
A MUP PE accommodates a MUP Segment to a routing instance for MUP When a PE accommodates a network through an interface or a routing
Direct Segment. The MUP PE advertises the Direct Segment Discovery instance as a Direct Segment, the PE advertises the corresponding
route for the routing instance. The Direct Segment Discovery route Direct Segment Discovery route for the interface or the routing
includes an address of the MUP PE in the network reachability instance. The Direct Segment Discovery route includes an address of
information with the corresponding Direct Segment indicating the PE in the network reachability information with an extended
community, and SID of the routing instance to the SR domain. community indicating the corresponding Direct Segment, and SID of the
routing instance to the SR domain.
For example in 3GPP 5G specific case, an MUP PE may connect to N6 For example in 3GPP 5G specific case, an PE may connect to N6
interface on a DN side, an MUP Segment Discovery route for the DN 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 will be advertised with an address of the PE, corresponding SID and
and Direct Segment indicating community to the routing instance for Direct Segment extended community to the routing instance for the DN
the DN from the MUP PE. from the PE.
When a MUP PE receives a Interwork Segment Discovery route, the MUP When a PE receives a Direct Segment Discovery route from other PEs,
PE keeps the received Interwork Segment Discovery routes in the RIB. the PE keeps the received Direct Segment Discovery route in the RIB.
The MUP PE uses the received Interwork Segment Discovery routes to The PE uses the received Direct Segment Discovery route to resolve
resolve the reachability for remote endpoint of Type 1 session Type 2 session transformed routes reachability, described in
transformed routes, described in Section 6. If the Interwork Segment Section 6.2. If the Direct Segment Discovery route resolves
Discovery route resolves the reachability for Type 1 session reachability for the endpoints, and match the Direct Segment extended
transformed routes, the MUP PE updates the FIB entry for the prefix community of the Type 2 session transformed routes, the PE updates
of Type 1 session transformed route with the SID of the matched MUP the FIB entry for the Type 2 session transformed route with the SID
segment discovery route. 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.
When a PE receives a Interwork Segment Discovery route, the PE keeps
the received Interwork Segment Discovery routes in the RIB. The PE
uses the received Interwork Segment Discovery routes to resolve the
reachability for remote endpoint of Type 1 session transformed
routes, described in Section 6.1. If the Interwork Segment Discovery
route resolves the reachability for Type 1 session transformed
routes, the PE updates the FIB entry for the prefix of Type 1 session
transformed route with the SID of the matched MUP segment discovery
route.
The received Interwork Segment Discovery routes MUST be used only to The received Interwork Segment Discovery routes MUST be used only to
resolve reachability for the remote endpoints of Type 1 session resolve reachability for the remote endpoints of Type 1 session
transformed routes. The connectivity among the routing instances for transformed routes. The connectivity among the routing instances for
Interwork Segments may be advertised as VPN routes. This is to avoid Interwork Segments may be advertised as VPN routes. This is to avoid
forwarding entries to the prefixes of Interwork Segment mingled in forwarding entries to the prefixes of Interwork Segment mingled in
the other type of routing instance. A SR node MAY discard the the other type of routing instance. A PE may discard the received
received Interwork segment discovery route if the Route Target Interwork segment discovery route if the Route Target extended
extended communities of the route does not meet the SR node's import communities of the route does not meet the PE's import policy.
poilicy.
5.2. MUP GW 6. Distribution of Session Transformed Route
A MUP GW interfaces an Interwork Segment with the user plane protocol SRv6 MUP architecture defines two types of session transformed route.
for the existing mobile service architecture. The MUP GW
accommodates the Interwork Segment to a routing instance for the 6.1. Type 1 Session Transformed Route
existing mobile service architecture. The MUP GW advertises the
corresponding Interwork Segment Discovery route with the prefixes of First type route, called Type 1 Session Transformed route, encodes IP
the Interwork Segment and the corresponding SID of the prefixes to 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. the SR domain.
For example in 3GPP 5G specific case, an Interwork Segment Discovery A PE may receive the Type 1 Session Transformed routes from the MUP
route for N3 network accommodating RAN will be incorporated in an Controller in the SR domain. The PE may keep the received Type 1
N3RAN segment discovery route associated with a RAN segment SID. Session Transformed routes advertised from the MUP Controller. The
receiving PE will perform the importing of the received Type 1
Session Transformed routes in the configured routing instances based
on the Route Target extended communities. A PE may discard the
received Type 1 Session Transformed route if the PE fails to import
the route based on the Route Target extended communities.
When a MUP GW receives a Direct Segment Discovery route from MUP PEs, 6.2. Type 2 Session Transformed Route
the MUP GW keeps the received Direct Segment Discovery route in the
RIB. The MUP GW uses the received Direct Segment Discovery route to
resolve Type 2 session transformed routes reachability, described in
Section 6. If the Direct Segment Discovery route resolves
reachability for the endpoints, and match the Direct Segment
indication community of the Type 2 session transformed routes, the
MUP GW updates the FIB entry for the Type 2 session transformed route
with the SID of the matched MUP segment discovery route.
In case that an SR node accommodates MUP GW and PE simultaneously, Second type route, called Type 2 Session Transformed route, encodes
the MUP GW in the SR node uses a local Direct Segment routing the tunnel endpoint identifier of the session on the core side in a
instance if a received Type 2 session transformed route indicates the BGP MP-NLRI attribute with the nature of tunnel decapsulation.
local Direct Segment routing instance by the Direct Segment Longest match algorithm for the prefix in this type of session
indicating community in the Type 2 session transformed route. 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.
6. MUP Controller A PE may receive the Type 2 Session Transformed routes from the MUP
Controller in the SR domain. The PE may keep the received Type 2
Session Transformed routes advertised from the MUP Controller. The
receiving PE will perform the importing of the received Type 2
Session Transformed routes in the configured routing instances based
on the Route Target extended communities. A PE may discard the
received Type 2 Session Transformed route if the PE fails to import
the route based on the Route Target extended communities.
6.3. MUP Controller
A MUP controller provides a northbound API. A consumer of the API A MUP controller provides a northbound API. A consumer of the API
inputs session information for a UE or a MN from mobility management inputs session information for a UE or a MN from mobility management
system. The MUP controller transforms the received session system. The MUP controller transforms the received session
information to routing information and will advertise the transformed information to routing information and will advertise the session
route to the SR domain. transformed routes with the corresponding extended communities to the
SR domain.
The received session information is expected to include the UE or MN The received session information is expected to include the UE or MN
IP prefix(es), tunnel endpoint identifiers for both ends, and any IP prefix(es), tunnel endpoint identifiers for both ends, and any
other attributes for the mobile networks. For example in a 3GPP 5G other attributes for the mobile networks. For example in a 3GPP 5G
specific case, the tunnel endpoint identifier will be a pair of the 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). F-TEIDs on both the N3 access side (RAN) and core side (UPF).
SRv6 MUP architecture defines two types of session transformed route.
First type route is that IP prefix(es) for a UE or MN may be encoded
in a BGP MP-NLRI attribute with associated session information of the
tunnel endpoint identifier on the access side. The MUP controller
advertises the UE or MN route to the SR domain.
Second type route is that the tunnel endpoint identifier of the
session on the core side may also be encoded in another BGP MP-NLRI
attribute with the nature of tunnel decapsulation. Longest match
algorithm for the prefix in this type of session transformed route
should be applicable to aggregate the routes for scale.
MUP PE and GW are expected to receive the routes advertised from the
MUP controller. A MUP PE imports a Type 1 session transformed route
for UE or MN into the corresponding Direct type routing instance. A
MUP GW imports a Type 2 session transformed route for core side
session tunnel endpoint identifier into the corresponding Interwork
type routing instance.
7. Illustration 7. Illustration
This section shows an illustration of SRv6 MUP deployment. The This section shows an illustration of SRv6 MUP deployment. The
example deployment cases here is 3GPP 5G. example deployment cases here is 3GPP 5G.
Before enabling SRv6 MUP, how SRv6 networks can accommodate existing Before enabling SRv6 MUP, how SRv6 networks can accommodate existing
mobile network service shown in Figure 2. SR nodes S1, S2, and S3 mobile network service shown in Figure 2. The PEs of S1, S2, and S3
join an SR network. A routing instance is configured to each network join an SR network. A routing instance is configured to each network
of the mobile service. N6DN in S1 and S2 are supposed to provide of the mobile service. N6DN in S1 and S2 are supposed to provide
connectivity to edge servers and the Internet respectively. connectivity to edge servers and the Internet respectively.
VRF (Virtual Routing Forwarding) may be a way to instantiate the VRF (Virtual Routing Forwarding) is the routing instance to
routing instance for realizing the routing policy of each instance. accommodate MUP segments in this section. All example cases in this
All example cases in this section follow the typical routing policy section follow the typical routing policy control using the BGP
control using the BGP extended community described in [RFC4360] and extended community described in [RFC4360] and [RFC4684]
[RFC4684]
__ N3 /-----------+-----+------------\ __ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \ / \RAN / |MUP-C| \
/ V/v\_ | +-----+ | N6 __ / V/v\_ | +-----+ | N6 __
\ / \ |----+ +----| DN / \ \ / \ |----+ +----| DN / \
\__/ \| S1 | | S2 |----/W/w \ \__/ \| S1 | | S2 |----/W/w \
__ /|----+ +----| \ / __ /|----+ +----| \ /
/ \__/ | +----+ | \__/ / \__/ | +----+ | \__/
/ E/e\N6 \ | S3 | / / E/e\N6 \ | S3 | /
\ /DN \------------+----+------------/ \ /DN \------------+----+------------/
\__/ N3UPF /\ N6UPF \__/ N3UPF /\ N6UPF
skipping to change at page 11, line 11 skipping to change at page 11, line 32
- export route Y/y with RT C3 - export route Y/y with RT C3
- import routes which have RT C4 - import routes which have RT C4
Note: The above configurations are just to provide typical IP Note: The above configurations are just to provide typical IP
connectivity for 3GPP 5G. When the above configurations have connectivity for 3GPP 5G. When the above configurations have
been done, each endpoint in V/v and X/x can communicate through 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 S1 and S3, but they can not communicate with nodes in E/e, W/w
and Y/y. and Y/y.
Here, SR nodes are configured to enable SRv6 MUP as following: Here, the PEs are configured to enable SRv6 MUP as following:
* S1 as MUP GW * S1
- advertises Interwork type discovery route: V/v with SID S1:: - advertises Interwork type discovery route: V/v with SID S1::
- set S1:: behavior End.M.GTP4.E or End.M.GTP6.E - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E
* S1 as MUP PE * S1
- advertise Direct type discovery route: MUP direct segment - advertise Direct type discovery route: MUP Direct Segment
community D1 and SID S1:1:: community D1 and SID S1:1::
- set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1
* S2 as MUP PE * S2
- advertise Direct type route: MUP direct segment community D1 - advertise Direct type route: MUP Direct Segment community D1
and SID S2:: and SID S2::
- set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2
S1 here adopts the local N6DN for D1 as long as S1 prioritizes closer S1 here adopts the local N6DN to prioritize closer segment for the
segment for the same MUP direct segment. Another MUP GW runs on a SR same Direct Segment. Another PE may adopt D1 from S2, if the PE has
node may adopt D1 from S2, if the SR node has no local N6DN for D1 no local N6DN for D1 and closer to S2 than S1.
and closer to S2 than S1.
U1 U1
| |
U/u v U/u v
\__ N3 /-----------+-----+------------\ \__ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \ / \RAN / |MUP-C| \
/ V/v\_ | +-----+ | N6 __ / V/v\_ | +-----+ | N6 __
\ / \ |----+ +----| DN / \ \ / \ |----+ +----| DN / \
\__/ \| S1 | | S2 |----/W/w \ \__/ \| S1 | | S2 |----/W/w \
__ /|----+ +----| \ / __ /|----+ +----| \ /
skipping to change at page 12, line 25 skipping to change at page 12, line 31
/ E/e\N6 \ | S3 | / / E/e\N6 \ | S3 | /
\ /DN \------------+----+------------/ \ /DN \------------+----+------------/
\__/ N3UPF /\ N6UPF \__/ N3UPF /\ N6UPF
X/x / \ Y/y X/x / \ Y/y
+-----+ +-----+
| UPF | | UPF |
+-----+ +-----+
Figure 3 Figure 3
Now, session information U1 comes to a MUP Controller, MUP-C, and Now, session information U1 is put to a MUP Controller, MUP-C, and
MUP-C is configured to transforms U1 to the routes as follows: MUP-C is configured to transforms U1 to the routes as follows:
* MUP-C * MUP-C
- attach the RT C3 to the DN in U1 - attach the RT C3 to the DN in U1
- transforms UE's prefix U/u, the F-TEID on access side (gNB) and - 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 QFI in U1 to the Type 1 session transformed route for the
prefix U/u with the F-TEID, the QFI, and RT C3 prefix U/u with the F-TEID, the QFI, and RT C3
skipping to change at page 14, line 23 skipping to change at page 14, line 26
- export route Y/y with RT C3 - export route Y/y with RT C3
- import routes which have RT C4 - import routes which have RT C4
* N6DN in S4 * N6DN in S4
- export route E/e with RT C4 - export route E/e with RT C4
- import routes which have RT C3 and C4 - import routes which have RT C3 and C4
Here, SR nodes are configured to enable SRv6 MUP as following: Here, the PEs are configured to enable SRv6 MUP as following:
* S1 as MUP GW (same with the previous case) * S1 (same with the previous case)
- advertises Interwork type route: V/v with SID S1:: - advertises Interwork type route: V/v with SID S1::
- set S1:: behavior End.M.GTP4.E or End.M.GTP6.E - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E
* S1 as MUP PE * S1
- advertise Direct type route: MUP direct segment community D1 - advertise Direct type route: MUP Direct Segment community D1
for the local N6DN for the local N6DN
- set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1
* S2 as MUP PE (same with the previous case) * S2 (same with the previous case)
- advertise Direct type route: MUP direct segment community D1 - advertise Direct type route: MUP Direct Segment community D1
and SID S2:: and SID S2::
- set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2
* S4 as MUP PE * S4
- advertise Direct type route: MUP direct segment community D2 - advertise Direct type route: MUP Direct Segment community D2
and SID S4:: and SID S4::
- set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4 - set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4
As same as the previous case, S1 adopts the local N6DN for D1 as long As same as the previous case, S1 adopts the local N6DN for D1 as long
as S1 prioritizes closer segment for the same MUP direct segment. as S1 prioritizes closer segment for the same MUP Direct Segment.
The Direct type route from S4 for D2 with SID S4:: will be kept in The Direct type route from S4 for D2 with SID S4:: will be kept in
S1. S1.
* MUP-C (same with the previous case) * MUP-C (same with the previous case)
- attach the RT C3 to the DN in U1 - attach the RT C3 to the DN in U1
- transforms UE's prefix U/u, the F-TEID on access side (gNB) and - 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 QFI in U1 to the Type 1 session transformed route for the
prefix U/u with the F-TEID, the QFI, and RT C3 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 - transforms F-TEID on core side (UPF) X in U1 to the Type 2
session transformed route for X with MUP direct segment session transformed route for X with MUP Direct Segment
community D1 and RT C2 community D1 and RT C2
Then N3RAN and N6DN import route X and U/u respectively. S2 and S4 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 resolve U/u's remote endpoint with V/v and then install SID S1:: for
U/u in FIB. U/u in FIB.
As same as the previous case, S1 adopts local N6DN for D1, N3RAN in As same as the previous case, S1 adopts local N6DN for D1, N3RAN in
S1 decapsulates GTP-U packets from V/v to X and then lookup the inner S1 decapsulates GTP-U packets from V/v to X and then lookup the inner
packets from U/u in N6DN after the decapsulation. packets from U/u in N6DN after the decapsulation.
For D2 on the other hand, no corresponding N6DN existed in S1. 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 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. route, E/e is reachable from U/u via N6DN for D1 in S1.
If a session U1' includes DN corresponding to D2, MUP-C advertises If a session U1' includes DN corresponding to D2, MUP-C advertises
Type 2 session transformed route X' with MUP direct segment community 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 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 X with S4:: as the last SID in the received Direct type route from
S4. S4.
Note: When the above configurations have been done, SRv6 MUP is Note: When the above configurations have been done, SRv6 MUP is
applied only to the packets from/to U/u. Each endpoint in U/u, 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 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 traffic from/to other UEs go through the usual 3GPP 5G user
plane path using UPF via S3. plane path using UPF via S3.
 End of changes. 52 change blocks. 
168 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/