Segment Routing IPv6 Mobile User Plane Architecture for Distributed Mobility Management
draft-mhkk-dmm-srv6mup-architecture-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Satoru Matsushima , Katsuhiro Horiba , Ashiq Khan , Yuya Kawakami , Tetsuya Murakami , Keyur Patel , Miya Kohno , Teppei Kamata , Pablo Camarillo , Daniel Voyer , Shay Zadok , Israel Meilik , Ashutosh Agrawal , Kumaresh Perumal | ||
| Last updated | 2021-11-10 (Latest revision 2021-10-25) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mhkk-dmm-srv6mup-architecture-01
Internet Engineering Task Force S. Matsushima
Internet-Draft K. Horiba
Intended status: Standards Track A. Khan
Expires: 14 May 2022 Y. Kawakami
SoftBank
T. Murakami
K. Patel
Arrcus, Inc
M. Kohno
T. Kamata
P. Camarillo
Cisco Systems, Inc.
D. Voyer
Bell Canada
S. Zadok
I. Meilik
Broadcom
A. Agrawal
K. Perumal
Intel
10 November 2021
Segment Routing IPv6 Mobile User Plane Architecture for Distributed
Mobility Management
draft-mhkk-dmm-srv6mup-architecture-01
Abstract
This document defines the Segment Routing IPv6 Mobile User Plane
(SRv6 MUP) architecture for Distributed Mobility Management. The
requirements for Distributed Mobility Management described in
[RFC7333] can be satisfied by routing fashion.
Mobile services are deployed over several parts of IP networks. A
Segment Routing over IPv6 (SRv6) network can accommodate all, or part
of those networks thanks to the large address space of IPv6 and the
network programming capability described in [RFC8986].
Segment Routing IPv6 Mobile User Plane Architecture can incorporate
existing session based mobile networks. By leveraging SRv6 network
programmability, mobile user plane can be integrated into the SRv6
data plane. In that routing paradigm, session information between
the entities of the mobile user plane is turned to routing
information.
Matsushima, et al. Expires 14 May 2022 [Page 1]
Internet-Draft SRv6 MUP Architecture November 2021
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 May 2022.
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 6
5. Distribution of Mobile User Plane Segment Information . . . . 7
5.1. MUP PE . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. MUP GW . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. MUP Controller . . . . . . . . . . . . . . . . . . . . . . . 8
7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Matsushima, et al. Expires 14 May 2022 [Page 2]
Internet-Draft SRv6 MUP Architecture November 2021
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Mobile services require IP connectivity for communication between the
entities of mobile service architecture [RFC5213][TS.23501]. To
provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a
candidate solution.
In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be
provided over SR networks, as well as LMA and Internet. In 3GPP 5G
[TS.23501], IP connectivity for N3 interface between gNodeB(es) and
UPFs can also be provided by SR, as well as for N6 interface between
UPFs and DNs (Data Network).
These IP connectivities may be covered by multiple SR networks, or
just one SR network, depending on the size of the deployment. In the
latter case, it is expected that the address space of the SR network
should be large enough to cover a vast number of nodes, such as
millions of base stations. For this reason, use of IPv6 for the SR
dataplane looks sufficiently suitable.
SRv6 is an instantiation of SR over IPv6 dataplane in which a single
network can accommodate all entities of mobile services thanks to the
huge available address space and network programming capability
described in [RFC8986].
Meanwhile, SRv6 network programmability enhances SRv6 dataplane to be
integrated with mobile user plane [I-D.ietf-dmm-srv6-mobile-uplane].
It will make an entire SRv6 network support the user plane in a very
efficient distributed routing fashion.
On the other hand, the requirements for Distributed Mobility
Management (DMM) described in [RFC7333] can be satisfied by session
management based solutions. [RFC8885] defines protocol extension to
PMIPv6 for the DMM requirements. 3GPP 5G defines an architecture in
which multiple session anchors can be added to one mobility session
by the session management.
As a reminder, the user plane related requirements in [RFC7333] are
reproduced here:
REQ1: Distributed mobility management
IP mobility, network access solutions, and forwarding
solutions provided by DMM MUST enable traffic to avoid
traversing a single mobility anchor far from the optimal
route. It is noted that the requirement on distribution
applies to the data plane only.
Matsushima, et al. Expires 14 May 2022 [Page 3]
Internet-Draft SRv6 MUP Architecture November 2021
REQ3: IPv6 deployment
DMM solutions SHOULD target IPv6 as the primary deployment
environment and SHOULD NOT be tailored specifically to
support IPv4, particularly in situations where private IPv4
addresses and/or NATs are used.
REQ4: Existing mobility protocols
A DMM solution MUST first consider reusing and extending IETF
standard protocols before specifying new protocols.
REQ5: Coexistence with deployed networks/hosts and operability
across different networks
A DMM solution may require loose, tight, or no integration
into existing mobility protocols and host IP stacks.
Regardless of the integration level, DMM implementations MUST
be able to coexist with existing network deployments, end
hosts, and routers that may or may not implement existing
mobility protocols. Furthermore, a DMM solution SHOULD work
across different networks, possibly operated as separate
administrative domains, when the needed mobility management
signaling, forwarding, and network access are allowed by the
trust relationship between them.
This document defines the Segment Routing IPv6 Mobile User Plane
(SRv6 MUP) architecture for Distributed Mobility Management. SRv6
MUP is not a mobility management system itself, but an architecture
to integrate mobile user plane into the SRv6 data plane.
In this routing paradigm, session information from a mobility
management system will be transformed to routing information. It
means that mobile user plane specific nodes for the anchor or
intermediate points are no longer required. The user plane anchor
and intermediate functions can be supported by SR throughout an SR
domain (REQ1), not to mention that SRv6 MUP will naturally be
deployed over IPv6 networks (REQ3).
SRv6 MUP architecture is independent from the mobility management
system. For the requirements (REQ4, 5), SRv6 MUP architecture is
designed to be pluggable user plane part of existing mobile service
architectures. Those existing architectures are for example defined
in [RFC5213], [TS.23501], or if any.
The level of SRv6 MUP integration for mobile networks running based
on the existing architecture will be varied and depending on the
level of SRv6 awareness of the control and user plane entities.
Matsushima, et al. Expires 14 May 2022 [Page 4]
Internet-Draft SRv6 MUP Architecture November 2021
Specifying how to modify the existing architecture to integrate SRv6
MUP is out of scope of this document. What this document provides
for the existing architecture is an interface for SRv6 MUP which the
existing or future architectures can easily integrate.
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: Provider Edge node in a MUP network
MUP GW: Gateway node to interwork with another mobile user plane
networks
MUP Controller: Controller node for a MUP network
UE: User Equipment, as per [TS.23501]
MN: Mobile Node, as per [RFC5213]
3. Architecture Overview
SRv6 MUP architecture defined in this document introduces a new
segment type of the SR called "Mobile User Plane (MUP) segment" and
new routing information called "Segment Discovery route" and "Session
Transformed route", then 3 new network nodes; MUP PE, MUP GW and MUP
Controller. Figure 1 depicts the overview.
To carry these new routing information, this architecture requires
extending the existing routing protocols. Any routing protocol can
be used to carry this information but this document recommends using
BGP. Thus, this document describes extensions on BGP as an example.
Matsushima, et al. Expires 14 May 2022 [Page 5]
Internet-Draft SRv6 MUP Architecture November 2021
* Mobility *
* 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
4. Mobile User Plane Segment
This document defines one new segment type. A Mobile User Plane
(MUP) segment may represent a network segment consisting of a mobile
service. The MUP segment can be created by an SR node which provides
connectivity for the mobile user plane. The MUP segment SID can be
any behavior defined in [RFC8986], [I-D.ietf-dmm-srv6-mobile-uplane],
or any other extensions for further use cases.
The behavior of the MUP segment will be chosen by the role of the
representing mobile network segment. For example, in case of an SR
node interfaces to 5G user plane on the access side defined as "N3"
in [TS.23501], the behavior of created segment SID will be
"End.M.GTP4.E", or "End.M.GTP6.E". In this case, the SR node may
associate the SID to a N3 access network (N3RAN) routing instance.
Another example here is the "N6" interface on the core data network
side. The behavior of the created segment SID will be "End.DT4",
"End.DT6", or "End.DT2". In this case the SR node may associate the
SID to a N6 data network (N6DN) routing instance.
Matsushima, et al. Expires 14 May 2022 [Page 6]
Internet-Draft SRv6 MUP Architecture November 2021
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. This
document defines two types of SR node, MUP PE and MUP GW, for
distributing MUP segment information.
A MUP Segment Discovery route is routing information, of which a MUP
segment is associated with network reachability. This document
defines the basic network reachability types, Direct type
reachability, and Interwork type reachability. Other types of
network reachability may be mobile service architecture specific.
Define the architecture specific network reachability is out of scope
of this document and it will be specified in another document.
5.1. MUP PE
A MUP PE accommodates a MUP segment to a routing instance for direct
reachability. The MUP PE advertises the MUP segment discovery route
for the routing instance with the direct network reachability
information and the corresponding MUP segment to the SR domain.
For example in 3GPP 5G specific case, an MUP PE may connect to N6
interface on a DN side, an MUP segment discovery route for the DN
will be advertised with a N6DN reachability and corresponding SID
from the MUP PE.
The MUP PE keeps the received MUP segment discovery routes advertised
from MUP GWs in the RIB. The MUP PE uses those received MUP segment
discovery routes to resolve the nexthop of session transformed routes
for UE, MN prefix. If a MUP segment discovery route matches to a
nexthop, the MUP PE updates the FIB entry for the route with the SID
of the matched MUP segment discovery route.
5.2. MUP GW
A MUP GW interfaces an MUP segment with the user plane protocol for
the existing mobile service architecture. The MUP GW accommodates
the MUP segment to a routing instance for the existing mobile service
architecture. The MUP GW advertises the corresponding MUP segment
discovery route with the interwork type reachability to the SR
domain.
For example in 3GPP 5G specific case, an interwork reachability for
N3 network accommodating RAN will be incorporated in an N3RAN segment
discovery route associated with a RAN segment SID.
Matsushima, et al. Expires 14 May 2022 [Page 7]
Internet-Draft SRv6 MUP Architecture November 2021
When a MUP GW receives a MUP segment discovery route with direct type
reachability, the MUP GW creates an SR Policy
[I-D.ietf-spring-segment-routing-policy] to the MUP segment with the
associated BSID. For example in 3GPP 5G specific case, the BSID
behavior for the N6DN segment discovery route will be H.M.GTP4.D or
End.M.GTP6.D. The received SID in the N6DN segment discovery route
will be the last SID of the created SR Policy.
The MUP GW may keep the received MUP segment discovery routes
advertised from other MUP GWs in the routing instance. The IP
prefixes for the received segments are imported into the routing
instance table. Thereby the MUP GW can provide network connectivity
between the nodes that exist in the segments.
The MUP GW may also accommodate another type of routing instance for
the routes of UE, MN or any other IP prefixes. In this case, the MUP
GW creates an SR policy with the BSID for the routing instance table
lookup.
6. MUP Controller
A MUP controller provides a northbound API. A consumer of the API
inputs session information for a UE or a MN from mobility management
system. The MUP controller transforms the received session
information to routing information and will advertise the transformed
route to the SR domain.
The received session information is expected to include the UE or MN
IP prefix(es), tunnel endpoint identifiers for both ends, and any
other attributes for the mobile networks. For example in a 3GPP 5G
specific case, the tunnel endpoint identifier will be a pair of the
F-TEIDs on both the N3 access side (RAN) and core side (UPF).
SRv6 MUP architecture defines two types of session transformed route.
First type route is that IP prefix(es) for a UE or MN may be encoded
in a BGP MP-NLRI attribute with associated session information of the
tunnel endpoint identifier on the access side. The MUP controller
advertises the UE or MN route to the SR domain.
Second type route is that the tunnel endpoint identifier of the
session on the core side may also be encoded in another BGP MP-NLRI
attribute. Longest match algorithm for the prefix in this type of
session transformed route should be applicable to aggregate the
routes for scale. And the MUP controller also advertises this type
of route with the BSID of SR Policy corresponding to the core MUP
segment.
Matsushima, et al. Expires 14 May 2022 [Page 8]
Internet-Draft SRv6 MUP Architecture November 2021
To ensure advertising the second type route, the MUP controller
collects SR Policies for the segments advertised from MUP GWs in the
SR domain. The MUP controller maintains the collected SR Policies
and manages them for the corresponding core segment.
MUP PE and GW are expected to receive the routes advertised from the
MUP controller. A MUP PE imports a route for UE or MN into the
corresponding Direct type routing instance. A MUP GW imports a
(aggregated) route for core side session tunnel endpoint identifier
into the corresponding Interwork type routing instance.
7. Illustration
This section shows an illustration of SRv6 MUP deployment. The
example deployment cases here is 3GPP 5G.
Before enabling SRv6 MUP, how SRv6 networks can accommodate existing
mobile network service shown in Figure 2. SR nodes S1, S2, and S3
join an SR network. A routing instance is configured to each network
of the mobile service. N6DN in S1 and S2 are supposed to provide
connectivity to edge servers and the Internet respectively.
VRF (Virtual Routing Forwarding) may be a way to instantiate the
routing instance for realizing the routing policy of each instance.
All example cases in this section follow the typical routing policy
control using the BGP extended community described in [RFC4360] and
[RFC4684]
__ N3 /-----------+-----+------------\
/ \RAN / |MUP-C| \
/ V/v\_ | +-----+ | N6 __
\ / \ |----+ +----| DN / \
\__/ \| S1 | | S2 |----/W/w \
__ /|----+ +----| \ /
/ \__/ | +----+ | \__/
/ E/e\N6 \ | S3 | /
\ /DN \------------+----+------------/
\__/ N3UPF /\ N6UPF
X/x / \ Y/y
+-----+
| UPF |
+-----+
Figure 2
The following routing instances are configured:
* N3RAN in S1
Matsushima, et al. Expires 14 May 2022 [Page 9]
Internet-Draft SRv6 MUP Architecture November 2021
- export route V/v with community C1
- import routes which have community C1 and C2
* N6DN in S1
- export route E/e with community C4
- import routes which have community C3 and C4
* N6DN in S2
- export route W/w with community C4
- import routes which have community C3 and C4
* N3UPF in S3
- export route X/x with community C2
- import routes which have community C1
* N6UPF in S3
- export route Y/y with community C3
- import routes which have community C4
Note: The above configurations are just to provide typical IP
connectivity for 3GPP 5G. When the above configurations have
been done, each endpoint in V/v and X/x can communicate through
S1 and S3, but they can not communicate with nodes in E/e, W/w
and Y/y.
Here, SR nodes are configured to enable SRv6 MUP as following:
* S1 as MUP GW
- advertises Interwork type route: V/v with SID S1::
- set S1:: behavior End.M.GTP4.E or End.M.GTP6.E
- advertise SR policy P with SID list <S1:1::> and BSID B1::
- set B1:: behavior H.M.GTP4.D or End.M.GTP6.D
* S1 as MUP PE
Matsushima, et al. Expires 14 May 2022 [Page 10]
Internet-Draft SRv6 MUP Architecture November 2021
- advertise Direct type route: E/e and SID S1:1::
- set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1
* S2 as MUP PE
- advertise Direct type route: W/w and SID S2::
- set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2
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 comes to a MUP Controller, MUP-C, and
MUP-C is configured to transforms U1 to the routes as follows:
* MUP-C
- attributes the community C3 to the DN in U1
- transforms UE's prefix U/u in U1 to the route for the prefix U/
u via V with community C3
- transforms F-TEID on core side (UPF) X in U1 to the route for X
via B1:: with community C2
Then N3RAN and N6DN import route X and U/u respectively. S1 and S2
resolves U/u's nexthop with V/v and then install SID S1:: for U/u in
FIB.
Note: When the above configurations have been done, SRv6 MUP is
Matsushima, et al. Expires 14 May 2022 [Page 11]
Internet-Draft SRv6 MUP Architecture November 2021
applied only to the packets from/to U/u. Each endpoint in U/u,
W/w and E/e can communicate through S1 and S2. The rest of
traffic from/to other UEs go through the usual 3GPP 5G user
plane path using UPF via S3.
Another case shown in Figure 4 is that S4 joins the SR network and
accommodates edge servers in the N6DN in S4.
U1
|
U/u v __
\__ N3 /-----------+-----+------------\ / \
/ \RAN / |MUP-C| \ __/W/w \
/ V/v\_ | +-----+ +----|_/N6\ /
\ / \ |----+ | S2 | DN \__/
\__/ \| S1 | +----| __
__ /|----+ +----|_ / \
/ \__/ | +----+ | S4 | \__/E/e \
/ \N6 \ | S3 | +----/ N6\ /
\ /DN \------------+----+------------/ DN \__/
\__/ N3UPF /\ N6UPF
X/x / \ Y/y
+-----+
| UPF |
+-----+
Figure 4
The following routing instances are configured:
* N3RAN in S1 (same with the previous case)
- export route V/v with community C1
- import routes which have community C1 and C2
* N6DN in S1
- export no route
- import routes which have community C4
* N6DN in S2 (same with the previous case)
- export route W/w with community C4
- import routes which have community C3 and C4
Matsushima, et al. Expires 14 May 2022 [Page 12]
Internet-Draft SRv6 MUP Architecture November 2021
* N3UPF in S3 (same with the previous case)
- export route X/x with community C2
- import routes which have community C1
* N6UPF in S3 (same with the previous case)
- export route Y/y with community C3
- import routes which have community C4
* N6DN in S4
- export route E/e with community C4
- import routes which have community C3 and C4
Here, SR nodes are configured to enable SRv6 MUP as following:
* S1 as MUP GW (same with the previous case)
- advertises Interwork type route: V/v with SID S1::
- set S1:: behavior End.M.GTP4.E or End.M.GTP6.E
- advertise SR policy P with SID list <S1:1::> and BSID B1::
- set B1:: behavior H.M.GTP4.D or End.M.GTP6.D
* S1 as MUP PE
- no Direct type route advertisement for the local N6DN
- set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1
* S2 as MUP PE (same with the previous case)
- advertise Direct type route: W/w and SID S2::
- set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2
* S4 as MUP PE
- advertise Direct type route: E/e and SID S4::
- set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4
Matsushima, et al. Expires 14 May 2022 [Page 13]
Internet-Draft SRv6 MUP Architecture November 2021
* MUP-C (same with the previous case)
- attributes the community C3 to the DN in U1
- transforms UE's prefix U/u in U1 to the route for the prefix U/
u via V with community C3
- transforms F-TEID on core side (UPF) X in U1 to the route for X
via B1:: with community C2
Then N3RAN and N6DN import route X and U/u respectively. S2 and S4
resolve U/u's nexthop with V/v and then install SID S1:: for U/u in
FIB.
Note: When the above configurations have been done, SRv6 MUP is
applied only to the packets from/to U/u. Each endpoint in U/u,
W/w and E/e can communicate through S1, S2 and S4. The rest of
traffic from/to other UEs go through the usual 3GPP 5G user
plane path using UPF via S3.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
TBD.
10. References
10.1. Normative References
[I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,
Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for
Mobile User Plane", Work in Progress, Internet-Draft,
draft-ietf-dmm-srv6-mobile-uplane-17, 12 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-
srv6-mobile-uplane-17>.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-14, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
segment-routing-policy-14>.
Matsushima, et al. Expires 14 May 2022 [Page 14]
Internet-Draft SRv6 MUP Architecture November 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<https://www.rfc-editor.org/info/rfc7333>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
10.2. Informative References
[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>.
[RFC8885] Bernardos, CJ., de la Oliva, A., Giust, F., Zúñiga, JC.,
and A. Mourad, "Proxy Mobile IPv6 Extensions for
Distributed Mobility Management", RFC 8885,
DOI 10.17487/RFC8885, October 2020,
<https://www.rfc-editor.org/info/rfc8885>.
[TS.23501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501 17.2.0, 24 September 2021,
<http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
Matsushima, et al. Expires 14 May 2022 [Page 15]
Internet-Draft SRv6 MUP Architecture November 2021
Authors' Addresses
Satoru Matsushima
SoftBank
Japan
Email: satoru.matsushima@g.softbank.co.jp
Katsuhiro Horiba
SoftBank
Japan
Email: katsuhiro.horiba@g.softbank.co.jp
Ashiq Khan
SoftBank
Japan
Email: ashiq.khan@g.softbank.co.jp
Yuya Kawakami
SoftBank
Japan
Email: yuya.kawakami01@g.softbank.co.jp
Tetsuya Murakami
Arrcus, Inc.
United States of America
Email: tetsuya@arrcus.com
Keyur Patel
Arrcus, Inc.
United States of America
Email: keyur@arrcus.com
Miya Kohno
Cisco Systems, Inc.
Japan
Matsushima, et al. Expires 14 May 2022 [Page 16]
Internet-Draft SRv6 MUP Architecture November 2021
Email: mkohno@cisco.com
Teppei Kamata
Cisco Systems, Inc.
Japan
Email: tkamata@cisco.com
Pablo Camarillo Garvia
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
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
Matsushima, et al. Expires 14 May 2022 [Page 17]
Internet-Draft SRv6 MUP Architecture November 2021
Kumaresh Perumal
Intel
United States of America
Email: kumaresh.perumal@intel.com
Matsushima, et al. Expires 14 May 2022 [Page 18]