draft-ietf-dmm-srv6-mobile-uplane-00.txt   draft-ietf-dmm-srv6-mobile-uplane-01.txt 
SPRING and DMM S. Matsushima DMM Working Group S. Matsushima
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: June 3, 2018 M. Kohno Expires: September 6, 2018 M. Kohno
P. Camarillo
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C. Perkins C. Perkins
Futurewei Futurewei
November 30, 2017 March 5, 2018
Segment Routing IPv6 for Mobile User-Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-00 draft-ietf-dmm-srv6-mobile-uplane-01
Abstract Abstract
This document discusses the applicability of SRv6 (Segment Routing This document discusses the applicability of SRv6 (Segment Routing
IPv6) to user-plane of mobile networks that SRv6 source routing IPv6) to user-plane of mobile networks. The source routing
capability with its programmability can fulfill the user-plane capability and the network programming nature of SRv6, accomplish
functions, such as access and anchor functions. It takes advantage mobile user-plane functions in a simple manner. The statelessness
of underlying layer awareness and flexibility to deploy user-plane and the ability to control underlying layer will be even more
functions that enables optimizing data-path for applications. beneficial to the mobile user-plane, in terms of providing
Network slicing and an interworking way between SRv6 and existing flexibility and SLA control for various applications. It also
mobile user-plane are also discussed in this document. simplifies the network architecture by eliminating the necessity of
tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
and so on. In addition, Segment Routing provides an enhanced method
for network slicing, which is briefly introduced by this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 June 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . . 4 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 5
5. Supporting Mobile User-Plane Functions . . . . . . . . . . . 5 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6
5.1. Access Point . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Traditional mode (formerly Basic mode) . . . . . . . . . 6
5.2. Layer-2 Anchor . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 7
5.3. Layer-3 Anchor . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8
5.4. Stateless Interworking . . . . . . . . . . . . . . . . . 7 5.1.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 8
5.4.1. End.TM: End point function with encapsulation for 5.2. Enhanced Mode (formerly Aggregate mode) . . . . . . . . . 8
mapped tunnel . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 9
5.4.2. T.Tmap: Transit behavior with tunnel decapsulation 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10
and mapping an SRv6 Policy . . . . . . . . . . . . . 8 5.2.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 10
5.5. Rate Limit . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 10
6. Segment Routing IPv6 Functions and Behaviors by Use Cases . . 9 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11
6.1. Basic Mode . . . . . . . . . . . . . . . . . . . . . . . 9 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14
6.1.1. Uplink . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.3. Extensions to the interworking mechanisms . . . . . . 16
6.1.2. Downlink . . . . . . . . . . . . . . . . . . . . . . 10 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17
6.2. Aggregate Mode . . . . . . . . . . . . . . . . . . . . . 11 6.1. End.MAP: Endpoint function with SID mapping . . . . . . . 17
6.2.1. Uplink . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. End.M.GTP6.D: Endpoint function with decapsulation from
6.2.2. Downlink . . . . . . . . . . . . . . . . . . . . . . 13 IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 17
6.3. Stateless Interworking with Legacy Access Network . . . . 14 6.3. End.M.GTP6.E: Endpoint function with encapsulation for
6.3.1. Uplink: Lagacy Access to SRv6 . . . . . . . . . . . . 14 IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. Downlink: SRv6 to Legacy Access . . . . . . . . . . . 15 6.4. End.M.GTP4.E: Endpoint function with encapsulation for
7. Network Slicing Considerations . . . . . . . . . . . . . . . 16 IPv4/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18
8. Control Plane Considerations . . . . . . . . . . . . . . . . 16 6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation
8.1. Existing Control Plane . . . . . . . . . . . . . . . . . 16 and mapping into an SRv6 Policy . . . . . . . . . . . . . 19
8.2. Aggregate Mode . . . . . . . . . . . . . . . . . . . . . 17 6.6. End.Limit: Rate Limiting function . . . . . . . . . . . . 20
8.3. User-Plane Sepalated Control Plane . . . . . . . . . . . 17 7. Network Slicing Considerations . . . . . . . . . . . . . . . 20
8.4. Centralized Controller . . . . . . . . . . . . . . . . . 17 8. Control Plane Considerations . . . . . . . . . . . . . . . . 20
8.5. Stateless Interworking . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
In mobile networks, mobility management systems provide connectivity In mobile networks, mobility management systems provide connectivity
while mobile nodes move around. While the control-plane of the while mobile nodes move around. While the control-plane of the
system signals movements of a mobile node, user-plane establishes system signals movements of a mobile node, user-plane establishes
tunnel between the mobile node and anchor node over IP based backhaul tunnel between the mobile node and anchor node over IP based backhaul
and core networks. and core networks.
This document discusses the applicability of SRv6 (Segment Routing This document discusses the applicability of SRv6 (Segment Routing
IPv6) to those mobile networks. SRv6 provides source routing to IPv6) to those mobile networks. SRv6 provides source routing to
networks where operators can explicitly indicate route for the networks where operators can explicitly indicate a route for the
packets from and to the mobile node. SRv6 endpoint nodes act as packets from and to the mobile node. SRv6 endpoint nodes perform the
roles of anchor of mobile user-plane. roles of anchor of mobile user-plane.
2. Conventions and Terminology 2. Conventions and Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
All segment routing and SRv6 network programming terms are defined in SRH is the abbreviation for the Segment Routing Header. We assume
[I-D.ietf-spring-segment-routing] and that the SRH may be present multiple times inside each packet.
"[I-D.filsfils-spring-srv6-network-programming].
3. Motivations NH is the abbreviation of the IPv6 next-header field.
Today's and future applications are requiring highly optimized data- NH=SRH means that the next-header field is 43 with routing type 4.
path between mobile nodes and the entities of those applications in
perspectives of latency, bandwidth, etc,. However current
architecture of mobile management is agnostic about underlying
topologies of transport layer. It rigidly fragments the user-plane
in radio access, core and service networks and connects them by
tunneling techniques through the user-plane functions such as access
and anchor nodes. Those agnostic and rigidness make it difficult for
the operator to optimize the data-path.
While the mobile network industry has been trying to solve that, When there are multiple SRHs, they must follow each other: the next-
applications shift to use IPv6 data-path and network operators adopt header field of all SRH, except the last one, must be SRH.
it as their IP transport as well. SRv6 integrates both application
data-path and underlying transport layer in data-path optimization
aspects that does not require any other techniques.
SRv6 source routing capability with programmable functions The effective next-header (ENH) is the next-header field of the IP
[I-D.filsfils-spring-srv6-network-programming] could fulfills the header when no SRH is present, or is the next-header field of the
user-plane functions of mobility management. It takes advantage of last SRH.
underlying layer awareness and flexibility to deploy user-plane
functions. Those are the motivations to adopt SRv6 for mobile user- In this version of the document, we assume that there is no other
extension header than the SRH. This will be lifted in future
versions of the document.
SID: A Segment Identifier which represents a specific segment in
segment routing domain. The SID type used in this document is IPv6
address (also referenced as SRv6 Segment or SRv6 SID).
A SID list is represented as <S1, S2, S3> where S1 is the first SID
to visit, S2 is the second SID to visit and S3 is the last SID to
visit along the SR path.
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
o IPv6 header with source and destination addresses respectively SA
and DA and next-header is SRH
o SRH with SID list <S1, S2, S3> with SegmentsLeft = SL
o Note the difference between the <> and () symbols: <S1, S2, S3>
represents a SID list where S1 is the first SID and S3 is the last
SID. (S3, S2, S1; SL) represents the same SID list but encoded in
the SRH format where the rightmost SID in the SRH is the first SID
and the leftmost SID in the SRH is the last SID. When referring
to an SR policy in a high-level use-case, it is simpler to use the
<S1, S2, S3> notation. When referring to an illustration of the
detailed behavior, the (S3, S2, S1; SL) notation is more
convenient.
o The payload of the packet is omitted.
SRH[SL] represents the SID pointed by the SL field in the first SRH.
In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0]
represents S3.
FIB is the abbreviation for the forwarding table. A FIB lookup is a
lookup in the forwarding table. When a packet is intercepted on a
wire, it is possible that SRH[SL] is different from the DA.
3. Motivation
Every day mobility networks are getting more challenging to operate:
on one hand, traffic is constantly growing, and latency requirements
are more strict; on the other-hand, there are new use-cases like NFV
that are also challenging network management.
Problem comes from the fact that the current architecture of mobile
networks is agnostic to the underlying transport. Indeed, it rigidly
fragments the user-plane into radio access, core and service networks
and connects them by tunneling techniques through the user-plane
roles such as access and anchor nodes. Such agnosticism and
rigidness make it difficult for the operator to optimize and operate
the data-path.
While the mobile network industry has been trying to solve those
problems, applications have shifted to use IPv6, and network
operators have started adopting IPv6 as their IP transport as well.
SRv6, the IPv6 instantiation of Segment Routing
[I-D.ietf-spring-segment-routing], integrates both the application
data-path and the underlying transport layer into one single
protocol, allowing operators to optimize the network in a simplified
manner and removing state from the network.
Further on, SRv6 introduces the notion of network-programming
[I-D.filsfils-spring-srv6-network-programming], that applied to
mobility fulfils the user-plane functions of mobility management.
SRv6 takes advantage of underlying transport awareness and
flexibility to deploy mobility user-plane functions in an optimized
manner. Those are the motivations to adopt SRv6 for mobile user-
plane. plane.
4. Mobile User-Plane 4. Reference Architecture
This section describes user-plane using SRv6 for mobile networks. This section describes a reference architecture and possible
This clarifies mobile user-plane functions to which SRv6 endpoint deployment scenarios.
applied.
Figure 1 shows mobile user-plane functions which are connected Figure 1 shows a reference architecture, based on 5G packet core
through IPv6-only networks. In the Figure 1, an mobile node (MN) architecture [TS.23501].
connects to an SRv6 endpoint serving access point role for the MN.
When the endpoint receives packets from the MN, it pushes SRH to the
packets. The segment list in the SRH indicates the rest of user-
plane segments which are L2 and L3 anchors respectively. Then the
endpoint send the packets to the IPv6 network. In opposite
direction, when an SRv6 endpoint serving L3 anchor role for the MN
receives packets to it, the endpoint push SRH consist of the L2
anchor and access point segments to the packets.
User-plane Please note that all the user-plane described in this document does
Function not depend on any specific architecture. This architecture is just
<L2 Anchor> used as a reference based on the latest 3GPP standards at the time of
O------O writing this draft. Other type of architectures can be seen in
| SRv6 | [I-D.gundavelli-dmm-mfa] and [WHITEPAPER-5G-UP].
| End |
| Point|
O------O
User-plane || User-plane
[MN] Function _____||_____ Function
| <Access Point> / \ <L3 Anchor>
___v___ O------O / \ O------O ________
/ Radio \ | SRv6 | / \ | SRv6 | / \
/ Access \==| End |===/ IPv6-Only \===| End |===/ Service \
\ NW / | Point| \ Network / | Point| \ NW /
\________/ O------O \ / O------O \________/
\ /
\____________/
Figure 1: Mobile User-plane with SRv6 +-----+
| AMF |
+-----+
/ | [N11]
[N2] / +-----+
+------/ | SMF |
/ +-----+
/ / \
/ / \ [N4]
/ / \ ________
/ / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
An SRv6 segment represents those each function, such as Access Point, Figure 1: Reference Architecture
Layer-2 (L2) Anchor and Layer-3 (L3) Anchor. This makes mobile
networks highly flexible to deploy any user-plane functions to which
nodes in user flow basis. An SRv6 segment can represent a set of
flows in any granularity of aggregation even though it is just for a
single flow.
Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile o UE : User Equipment
user-plane, which is defined in [RFC5213] and [TS.29281]. An SRv6 o gNB : gNodeB
segment in the endpoint represents interworking function which o UPF : User Plane Function
enables interworking between existing access point and SRv6 anchor
segment, or SRv6 access point segment and existing anchor node.
Existing mobile user-plane with IPv6 underlay is expected to be * UPF1: Interfaces N3 and N9
widely deployed. As IPv6 network should be interoperable with SRv6 * UPF2: Interfaces N9 and N6
endpoints can be accommodated on it, interworking with existing IPv6 * Note: For simplicity we don't depict a UPF that is only
network is out of scope of this document. connected to N9 interfaces, although the techniques described
in this document are also valid in such case.
o SMF : Session Management Function
o AMF : Access and Mobility Management Function
o DN : Data Network e.g. operator services, Internet access
________ _______ A session from an UE gets assigned to an UPF. Sometimes more than
/ \ O------O / \ one UPF may be used for providing a certain kind of richer service
/ Service \===|L2/L3 | / Service \ functions. UE gets its IP address from the DHCP block of its UPF.
\ NW / |Anchor| User-plane \ NW / The UPF advertises the IP address block towards the Internet ensuring
\________/ |Node | Function \_______/ that return traffic is routed to the right UPF.
O------O <Interworking> ||
\\_______ O------O ________ O------O
/ \ | SRv6 | / \ | SRv6 |
/ Existing \===| End |===/ IPv6-Only\===| End |
\ IPv4 NW / | Point| \ Network / | Point|
[MN] \________/ O------O \________/ O------O
| // ||
___v____ O------O ___||__
/ Radio \ |Access| / Radio \
/ Access \==|Point | [MN]~~~/ Access \
\ NW / |Node | \ NW /
\________/ O------O \________/
Figure 2: Interworking with Existing Mobile Networks 5. User-plane behaviors
The detail of SRv6 segments representing user-plane functions are This section describes the mobile user-plane behaviors using SRv6.
described in Section 5.
5. Supporting Mobile User-Plane Functions In order to simplify the SRv6 adoption, we present two different
"modes" that vary with respect the SRv6 SID allocation. The first
one is the "Traditional mode", which inherits the traditional mobile
user-plane. In this mode there is no change to mobility networks
architecture, except for the pure replacement of GTP-U [TS.29281] for
SRv6.
This section describes mobile user-plane functions to which an SRv6 The second mode is the "Enhanced mode", which aggregates the mobile
node can apply SRv6 functions and behaviors. The SRv6 node sessions and allocates SID on a per policy basis. The benefit of the
configured with those segments thereby fulfills the user-plane latter is that the SR policy contains SIDs for Traffic Engineering
functions. Each function consist of two segments which are uplink and VNFs. Both of these modes assume both the gNB and UPFs are SR-
(UL) from mobile node to the correspondent node, and downlink (DL) aware (N3 and N9 interfaces are SRv6).
from the correspondent node to mobile node.
An SRv6 node may be configured with multiple type of user-plane Additionally, we introduce a new "Enhanced mode with unchanged gNB
functions. Each function may also be configured with multiple sets GTP behavior". This mode consists of two mechanisms for interworking
of the segments for one type of function that to purpose of with legacy access networks -interface N3 unmodified-. One of these
separating tenants, resources and service policies, etc. mechanism is designed to interwork with legacy gNBs using GTP/IPv4.
The second method is designed to interwork with legacy gNBs using
GTP/IPv6.
5.1. Access Point This section makes reference to already existing SRv6 functions
defined in [I-D.filsfils-spring-srv6-network-programming] as well as
new SRv6 functions designed for the mobile userplane. The new SRv6
functions are detailed in the Section 6.
Access Point function provides SRv6 node the role to which mobile 5.1. Traditional mode (formerly Basic mode)
node is connected directly. eNodeB could be referenced as an entity
implementing the access point in 3GPP term.
When an SRv6 node is configured for an Access Point function, the In the traditional mode, we assume that mobile user-plane functions
SRv6 node allocates one DL access-point segment SID per session, or are the same as existing ones except the use of SRv6 as the data
per Access Point function which represents one policy that is shared plane instead of GTP-U. No impact to the rest of mobile system
by multiple sessions. should be expected.
Applicable SRv6 functions and behaviors are determined by use cases In the traditional mobile network, an UE session is mapped 1-for-1
described in Section 6. with a specific GTP tunnel (TEID). This 1-for-1 mapping is
replicated here to replace the GTP encaps with the SRv6 encaps, while
not changing anything else.
5.2. Layer-2 Anchor This mode minimizes the changes required to the entire system and it
is a good starting point for forming the common basis. Note that in
this mode the TEID is embedded in each SID.
Layer-2 anchor function provides SRv6 node the role to be anchor Our reference topology is shown in Figure 2. In this mode we assume
point while mobile node move around within a serving area which could that the gNB and the UPFs are SR-aware.
be assumed as a layer-2 network. Serving Gateway (SGW) could be
referenced as an entity implementing the layer-2 anchor in 3GPP term.
When an SRv6 node is configured for a Layer-2 anchor function, the ________
SRv6 node allocates UL L2-anchor segment SID per SRv6 policy, which SRv6 SRv6 / \
is bound to next L3-anchor function and specific service if needed. +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
The SRv6 node also allocates one DL L2-anchor segment SID per SRv6 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
policy, which is bound to serving access point SID and specific +--+ +-----+ +------+ +------+ \________/
service if needed. SRv6 node SRv6 node SRv6 node
Applicable SRv6 functions and behaviors are determined by use cases Figure 2: Traditional mode - Reference topology
described in Section 6.
5.3. Layer-3 Anchor 5.1.1. Packet flow - Uplink
Layer-3 anchor function provides SRv6 node the role to be anchor The uplink packet flow is the following:
point across a mobile network consists of multiple serving areas.
Packet data network gateway (PGW) could be referenced as an entity
implementing the layer-3 anchor.
When an SRv6 node is configured for a Layer-3 Anchor function, the UE_out : (A,Z)
SRv6 node allocates one UL L3-anchor segment SID per L3-anchor gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Reduced <U1::1>
function. Each L3-anchor SID represents one policy which is shared UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
by multiple sessions, such as a routing table, or a service policy UPF2_out: (A,Z) -> End.DT4 or End.DT6
with in the table. The routing table should maintain forwarding
entries of the belonging MNs.
Applicable SRv6 functions and behaviors are determined by use cases The UE packet arrives to the gNB. The gNB performs a
described in Section 6. T.Encaps.Reduced operations. Since there is only one SID, there is
no need to push an SRH. gNB only adds an outer IPv6 header with IPv6
DA U1::1. U1::1 represents an anchoring SID specific for that
session at UPF1. The SID U1::1 is retrieved through the existing
control plane (N2 interface).
5.4. Stateless Interworking Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP
function. This function maps the SID with the next anchoring point
and replaces U1::1 by U2::1, that belongs to the next anchoring
point.
Stateless interworking function provides SRv6 node a role to Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT
interworking between existing mobile user-plane and SRv6 mobile user- function. UPF2 decapsulates the packet, performs a lookup in a
plane. Figure 3 shows the SRv6 SID format for stateless interworking specific table and forwards the packet towards the data network.
function that is encoding identifiers of corresponding tunnel in
existing network as argument of the SID.
+----------------------+-------+-------+-------+ 5.1.2. Packet flow - Downlink
| IW-IPv6-Prefix |IPv4DA |IPv4SA |TUN-ID |
+----------------------+-------+-------+-------+
128-a-b-c a b c
Figure 3: Stateless Interworking SID Encoding The downlink packet flow is the following:
Stateless interworking function introduce following SRv6 end function UPF2_in : (Z,A)
and transit behavior. UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Reduced <U1::1>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
gNB_out : (Z,A) -> End.DX4 or End.DX6
End.TM: End point function with encapsulation for When the packet arrives to the UPF2, the UPF2 will map that
mapped tunnel particular flow into a UE session. This UE session is associated
T.Tmap: Transit behavior with tunnel decapsulation with the policy <U1::1>. The UPF2 performs a T.Encaps.Reduced
and mapping an SRv6 Policy operation, encapsulating the packet into a new IPv6 header with no
SRH since there is only one SID.
Stateless interworking function is associated with the following Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP
mandatory parameters: function. This function maps the SID with the next anchoring point
and replaces U1::1 by gNB::1, that belongs to the next anchoring
point.
IW-IPv4-Prefix: IPv4 prefix representing network of SRv6 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4/
user-plane for legacy mobile user-plane End.DX6 function. The gNB will decapsulates the packet, removing the
IW-IPv6-Prefix: IPv6 prefix representing network of legacy IPv6 header and all it's extensions headers and will forward the
mobile user-plane for SRv6 user-plane traffic towards the UE.
TUN-PROTO: Tunnel protocol type, such as GTP-U or GRE
for PMIP
5.4.1. End.TM: End point function with encapsulation for mapped tunnel 5.1.3. IPv6 user-traffic
The "End point to encapsulate for mapped tunnel" function (End.TM for For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
short) is used to the direction from SRv6 user-plane to legacy user- However based on local policy, a service provider MAY choose to do
plane network. SRH insertion. The main benefit is a lower overhead. In such case,
the functions used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T
at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at
gNB on Downlink.
When interworking node N receives a packet destined to S and S is a 5.2. Enhanced Mode (formerly Aggregate mode)
local End.TM SID, N does:
1. IF NH=SRH & SL > 0 THEN This mode improves the scalability. In addition, it provides key
2. decrement SL improvements in terms of traffic steering and service chaining,
3. update the IPv6 DA with SRH[SL] thanks to the use of an SR policy of multiple SIDs, instead of single
4. push header of TUN-PROTO with tunnel ID from S ;; Ref1 one in the Traditional mode.
5. push outer IPv4 header with SA, DA from S
6. ELSE
7. Drop the packet
Ref1: TUN-PROTO indicates target tunnel type. Key points:
5.4.2. T.Tmap: Transit behavior with tunnel decapsulation and mapping o Several UE share the same SR Policy (and it's composing SID)
an SRv6 Policy o The SR policy MAY include SIDs for traffic engineering and service
chaining on top of the UPF anchor.
The "Transit with tunnel decapsulation and map to an SRv6 policy" The gNB control-plane (N2 interface) is unchanged, specifically a
function (T.Tmap for short) is used to the direction from legacy single IPv6 address is given to the gNB.
user-plane to SRv6 user-plane network.
When interworking node N receives a packet destined to a IW- o The gNB MAY resolve the IP address into a SID list through a
IPv4-Prefix, N does: mechanism like PCEP, DNS-lookup, small augment for LISP control-
plane, etc.
1. IF P.PLOAD == TUN-PROTO & T.PLOAD == IPv6 THEN ;; Ref1, Ref1bis Our reference topology is shown in Figure 3. In this mode we assume
2. pop the outer IPv4 header and tunnel headers that the gNB and the UPF are SR-aware. We also assume that we have
3. copy IPv4 DA, SA, TUN-ID to form SID B with IW-IPv6-Prefix two services segments, S1 and C1. S1 represents a VNF in the
4. insert the SRH (D, B; SL=1) ;; Ref2, Ref2bis network, and C1 represents a constraint path on a router over which
5. set the IPv6 DA = B we are going to perform Traffic Engineering. Note that S1 and C1
6. forward along the shortest path to B belong to the underlay and don't have an N4 interface. For this
7. ELSE reason we don't consider them UPFs.
8. Drop the packet
Ref1: P.PLOAD and T.PLOAD represent payload protocol of the receiving +----+ SRv6 _______
packet, and payload protocol of the tunnel respectively. SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node
-| S1 |-
+----+
SRv6 node
NFV
Ref1bis: First nibble of payload is used to determine payload Figure 3: Enhanced mode - Reference topology
protocol in GTP-U case due to it has no payload protocol indicator in
the header.
Ref2: The received IPv6 DA is placed as last SID of the inserted SRH. 5.2.1. Packet flow - Uplink
Ref2bis: The SRH is inserted before any other IPv6 Routing Extension The uplink packet flow is the following:
Header.
5.5. Rate Limit UE_out : (A,Z)
gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red<S1,C1,U2::1>
S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z)
C1_out : (gNB, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
Mobile user-plane requires rate-limit feature. SID is able to encode UE sends its packet (A,Z) on a specific bearer session to its gNB.
limiting rate as an argument in SID. Multiple flows of packets gNB's CP associates that session from the UE(A) with the IPv6 address
should have same group identifier in SID when those flows are in an B and GTP TEID T. gNB's CP does a lookup on B (by reverseDNS, LISP,
same AMBR group. This helps to keep user-plane stateless. That etc.) to find the related SID list <S1, C1, U2::1>.
enables SRv6 endpoint nodes which are unaware from the mobile
control-plane information. Encoding format of rate limit segment SID
is following:
+----------------------+----------+-----------+ Once the packet leaves the gNB, it already contains all the segments
| Locater of rate-limit| group-id | limit-rate| of the SR policy. This SR policy contains segments for traffic
+----------------------+----------+-----------+ engineering (C1) and for service chaining (S1).
128-i-j i j
Figure 4: Stateless Interworking SID Encoding The nodes S1 and C1 perform their related Endpoint functionality and
forward.
In case of j bit length is zero in SID, the node should not do rate When the packet arrives to UPF2, the active segment (U2::1) is an
limiting unless static configuration or control-plane sets the limit End.DT4/6 which performs the decapsulation (removing the IPv6 header
rate associated to the SID. with all it's extension headers) and forward towards the data
network.
6. Segment Routing IPv6 Functions and Behaviors by Use Cases Note that in case several APNs are using duplicated IPv4 private
address spaces, then the aggregated SR policies are unique per APNs.
This section describes SRv6 functions and behavior applied to mobile 5.2.2. Packet flow - Downlink
user-plane functions by use cases. Terminology of SRv6 endpoint
functions refers to [I-D.filsfils-spring-srv6-network-programming].
6.1. Basic Mode The downlink packet flow is the following:
In the basic mode, we assume that mobile user-plane functions are as UPF2_in : (Z,A) -> UPF2 maps the flow w/
same as existing ones except using SRv6. This means that there is no SID list <C1,S1, gNB>
impact to rest part of mobile system should be expected while no UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red
advanced segment routing features are introduced to it. C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
S1_out : (U2::1, gNB)(Z,A) -> PSP
gNB_out : (Z,A) -> End.DX4 or End.DX6
+---------------------+----------+----------+ When the packet arrives to the UPF2, the UPF2 will map that
| User-plane Function | Uplink | Downlink | particular flow into a UE session. This UE session is associated
+---------------------+----------+----------+ with the policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Reduced
| Access Point | T.Insert | End.X | operation, encapsulating the packet into a new IPv6 header with its
| L2-anchor | End.B6 | End.B6 | corresponding SRH.
| L3-anchor | End.T | T.Insert |
+---------------------+----------+----------+
Table 1: SRv6 Functions for Basic Mode The nodes C1 and S1 perform their related Endpoint processing.
6.1.1. Uplink Once the packet arrives to the gNB, the IPv6 DA corresponds to an
End.DX4 or End.DX6 (depending on the underlying traffic). The gNB
will decapsulate the packet, removing the IPv6 header and all it's
extensions headers and will forward the traffic towards the UE.
In uplink, SRv6 node applies following SRv6 end point functions and 5.2.3. IPv6 user-traffic
transit behavior. SIDs are allocated per L3-anchor function in the
SRv6 nodes of both L2 and L3-anchor functions in basic mode.
Access Point: For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
However based on local policy, a service provider MAY choose to do
SRH insertion. The main benefit is a lower overhead. In such case,
the functions used are T.Insert.Red at gNB and End.T at UPF2 on
Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink.
When the access point node receives a packet destine to "D::1" 5.3. Enhanced mode with unchanged gNB GTP behavior
from a mobile node "S::1", it does T.Insert process for the
receiving packets to push a SRH with SID list <A2::1, D::1>
with SL=1. The access point node update DA to next UL
L2-anchor SID "A2::1" which the SL indicates and forward the
packet.
Layer-2 Anchor: In this section we introduce two mechanisms for interworking with
legacy gNBs that still use GTP. One of the mechanisms is valid for
IPv4 while the other for IPv6.
The L2-anchor node of "A2::1" segment does End.B6 process for In this scenario, it is assumed that gNB does not support SRv6. It
the receiving packet according to the SRH. The node updates DA just supports GTP encapsulation over IPv4 or IPv6. Hence in order to
to next UL L3-anchor SID "A3::1" bound to "A2::1" and forward achieve interworking we are going to add a new SR Gateway (SRGW-UPF1)
the packet. In this basic use case, just one UL L3-anchor SID entity. This SRGW is going to map the GTP traffic into SRv6. Note
with SL=0 is enough to do it so that there is no need to push that the SR GW is not an anchor point.
another SRH to the packet in that PSP (Penultimate Segment Pop)
operation.
Layer-3 Anchor: The SRGW maintains very little state on it. For this reason, both of
these methods (IPv4 and IPv6) scale to millions of UEs.
The L3-anchor node of "A3::1" segment does End.T process for _______
the receiving packet according to the SRH. The node decrement IP GTP SRv6 / \
SL to 0, updates DA to D::1 which the SL indicates and lookup +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
IPv6 table associated with "A3::1". In this basic use case, |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN /
the decremented SL is 0 so that the node does PSP operation of +--+ +-----+ +------+ +------+ \_______/
popped out the SRH from the packet and forward it. SR Gateway SRv6 node
6.1.2. Downlink Figure 4: Reference topology for interworking
In downlink, SRv6 node applies following SRv6 end point functions and 5.3.1. Interworking with IPv6 GTP
transit behavior. SIDs are allocated per session in the SRv6 nodes
of both L2-anchor and access point functions in basic mode.
Layer-3 Anchor: In this interworking mode we assume that the gNB is using GTP over
IPv6 in the N3 interface
When the L3-anchor node receives a packet destine to "S::1" Key points:
from a correspondent node "D::1", it does T.Insert process for
the receiving packets to push a SRH with SID list <A2::2, S::1>
with SL=1. The L3-anchor node update DA to next DL L2-anchor
SID "A2::2" which the SL indicates and forward the packet.
Layer-2 Anchor: o gNB is unchanged (control-plane or user-plane) and encaps into GTP
(N3 interface is not modified).
o 5G Control-Plane (N2 interface) is unmodified: 1 IPv6 address
(i.e. a BSID at the SRGW)
o SRGW removes GTP, finds SID list related to DA, add SRH with the
SID list.
o There is NO state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW (leveraging the
enhanced mode results in few SR policies on this node. A SR
policy can be shared across UEs).
o As soon as the packet leaves the gNB (uplink), the traffic is SR-
routed. This simplifies considerably network slicing
[I-D.hegdeppsenak-isis-sr-flex-algo].
o In the uplink, we use the IPv6 DA BSID to steer the traffic into
an SR policy when it arrives at the SRGW-UPF1-.
The L2-anchor node of "A2::2" segment does End.B6 process for Our reference topology is shown in Figure 5. In this mode we assume
the receiving packet according to the SRH. The node updates DA that the gNB is an unmodified gNB using IPv6/GTP. The UPFs are SR-
to next DL access point segment "A1::1" bound to "A2::2" and aware. Also, as explained before, we introduce a new SRGW entity
forward the packet. In this basic use case, just one DL access that is going to map the IPv6/GTP traffic to SRv6.
point SID with SL=0 is enough to do it so that there is no need
to push another SRH to the packet in that PSP (Penultimate
Segment Pop) operation.
Access Point: We also assume that we have two service segment, S1 and C1. S1
represents a VNF in the network, and C1 represents a router over
which we are going to perform Traffic Engineering.
The access point node of "A1::1" segment does End.X process for +----+
the receiving packet according to the segment. The node IPv6/GTP -| S1 |- ___
decrement SL to 0, updates DA to S::1 which the SL indicates +--+ +-----+ [N3] / +----+ \ /
and forward the packet to the mobile node of "S::1" through |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
radio channel associated with "A1::1". In this use case, the +--+ +-----+ \ [N9]/ NFV -| C1 |---| UPF2 |------\ DN
decremented SL is 0 so that the node does PSP operation of GTP \ +------+ / +----+ +------+ \___
popped out the SRH from the packet and forward it. -| UPF1 |- SRv6 SRv6
+------+ TE
SR Gateway
6.2. Aggregate Mode Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
In the aggregate mode, user-plane function is able to steer multiple 5.3.1.1. Packet flow - Uplink
mobile sessions per service policy. This means that mobile sessions
paths are aggregated into a service path which includes not only
mobile user-plane functions but also other nodes, links or service
functions. SIDs are allocated per service policy in the SRv6 nodes
of user-plane functions in the aggregate mode.
Aggregate mode user-plane can take advantage of SRv6 that enables The uplink packet flow is the following:
seamless mobile user-plane deployment with service chaining, VPNs,
traffic-engineering by computed path to fulfil the policy.
+---------------------+---------------+---------------+ UE_out : (A,Z)
| User-plane Function | Uplink | Downlink | gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
+---------------------+---------------+---------------+ (IPv6/GTP)
| Access Point | T.Insert | End | SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
| L2-anchor | End or End.B6 | End or End.B6 | SID at the SRGW
| L3-anchor | End.T | T.Insert | S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
+---------------------+---------------+---------------+ C1_out : (SRGW, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
Table 2: SRv6 Functions for Aggregate Mode The UE sends a packet destined to Z towards the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates
the packet into a new IPv6, UDP and GTP headers. The IPv6 DA B, and
the GTP TEID T are the ones received in the N2 interface.
6.2.1. Uplink The IPv6 address that was signalled over the N2 interface for that UE
session, B, is now the IPv6 DA. B is an SRv6 Binding SID
instantiated at the SRGW. Hence the packet, will be routed up to the
SRGW.
In uplink, SRv6 node applies following SRv6 end point functions and When the packet arrives at the SRGW, the SRGW realises that B is an
transit behavior. End.M.GTP6.D BindingSID. Hence, the SRGW will remove the IPv6, UDP
and GTP headers, and will push a new IPv6 header with its own SRH
containing the SIDs bound to the SR policy associated with this
BindingSID.
Access Point: The nodes S1 and C1 perform their related Endpoint functionality and
forward.
When the access point node receives a packet destine to "D::1" When the packet arrives to UPF2, the active segment is (U2::1) which
from a mobile node "S::1", it does T.Insert process for the bound to End.DT4/6 which is going to perform the decapsulation
receiving packets. (removing the outer IPv6 header with all it's extension headers) and
forward towards the data network.
First scenario is that the service policy for "D::1" is via 5.3.1.2. Packet flow - Downlink
service function S1 and node C1 before reach to L2-anchor
"A2::1" so that the node pushes a SRH with SID list <S1, C1,
A2::1, D::1> with SL=3. The node updates DA to service
function S1 which the SL indicates and forward the packet.
Second case is that the access point function directly The downlink packet flow is the following:
indicates the path beyond the L2-anchor, service function S2
and L3-anchor "A3::1" for example, the SID list shoud be <S1,
C1, A2::, S2, A3::1, D::1> with SL=5.
Layer-2 Anchor: UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB>
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red
C1_out : (U2::1, S1)(gNB, S1; SL=2)(Z,A)
S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A)
SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A)
It is assumed that the packet successfully traversed S1 and C1 When a packet destined to A arrives at the UPF2, the UPF2 performs a
segments so that the SL was decremented 3 to 1 in the first lookup in the associated table to A and finds the SID list <C1, S1,
scenario, and 5 to 3 in the second scenario before arriving the SRGW::TEID, gNB>. The UPF2 performs a T.Encaps.Reduced operation,
node of "A2::1" or "A2::" segment. encapsulating the packet into a new IPv6 header with its
corresponding SRH.
In the first scenario that the L2-anchor node of "A2::1" The nodes C1 and S1 perform their related Endpoint processing.
segment is bound to a service policy which indicates path via
service function S2 and L3-anchor function A3::1, the node does
End.B6 process for the receiving packet to push a new SRH with
SID list <S2, A3::1> with SL=1. The node updates DA to next
service function SID S2 which the SL indicates and forward the
packet.
In the second scenario that one SRH with SIDs <S1, C1, A2::, Once the packet arrives to the SRGW, the SRGW realizes the active SID
S2, A3::1, D::1>, the L2-anchor node of "A2::" segment is bound is an End.M.GTP6.E function. The SRGW removes the IPv6 header and
to just End function. The node does End process for the all it's extensions headers. The SRGW generates an IPv6, UDP and GTP
receiving packet according to the SRH that decrements SL to 2, headers. The new IPv6 DA is the gNB which is the last SID in the
updates DA to next service function SID S2 which the SL received SRH. The TEID in the generated GTP header is the arguments
indicates and forward the packet. of the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet towards the gNB.
Layer-3 Anchor: Once the packet arrives to the gNB, the packet is a regular IPv6/GTP
packet. The gNB looks for the specific radio bearer for that TEID
and forward it on the bearer. This gNB behavior is not modified from
current and previous generations.
The L3-anchor node of "A3::1" segment does End.T process for 5.3.1.3. Scalability
the receiving packet according to the SRH(s).
In the first scenario that outer SRH with SIDs <S2, A3::1>, it For the downlink traffic, the SRGW is stateless. All the state is in
is assumed that the SL is decremented to 0 at service function the SRH imposed by the UPF2. The UPF2 must have the UE states as the
S2 so that the node pops outer SRH. Then the node processes session anchor point.
second SRH with SIDs <S1, C1, A2::1, D::1> that decrements SL
to 0, updates DA to D::1 which the SL indicates and lookup IPv6
table associated with "A3::1". In this case, the decremented
SL is 0 so that the node does PSP operation of popped out the
SRH from the packet and forward it.
In the second scenario that one SRH with SIDs <S1, C1, A2::, For the uplink traffic, the state at the SRGW does not necessarily
S2, A3::1, D::1>, L3-anchor node of "A3::" segment does End.T need to be per UE session basis. A state of SR policy of which state
process for the receiving packet according to the SRH. Rest can be shared among UE's. Hence it is possible to deploy SRGW in
part of processes are as same as previous case. very scalable way compared to hold millions of states per UE session
basis.
6.2.2. Downlink 5.3.1.4. IPv6 user-traffic
In downlink, SRv6 node applies following SRv6 end point functions and For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
transit behavior. However based on local policy, a service provider MAY choose to do
SRH insertion. The main benefit is a lower overhead.
Layer-3 Anchor: 5.3.2. Interworking with IPv4 GTP
When the L3-anchor node receives a packet destine to "S::1" In this interworking mode we assume that the gNB is using GTP over
from a mobile node "D::1", it does T.Insert process for the IPv4 in the N3 interface
receiving packets.
First scenario is that the service policy for "S::1" is via Key points:
service function S2 before reach to L2-anchor "A2::2" so that
the node pushes a SRH with SID list <S2, A2::2, S::1> with
SL=2. The node updates DA to service function S2 which the SL
indicates and forward the packet.
Second scenario is that the L3-anchor function directly o gNB is unchanged and encaps into GTP (N3 interface is not
indicates the path beyond the L2-anchor, service function S1, modified).
node C3 and access point "A1::" for example, the SID list shoud o In the uplink, traffic is classified at SRGW by UL CL(Uplink
be <S2, A2::, S1, C1, A1::1, D::1> with SL=5. Classifier) and steered into an SR policy. The SRGW is a UPF1
functionality, hence it can coexist with UPF UL CL functionality.
o SRGW removes GTP, finds SID list related to DA, add SRH with SID
list.
Layer-2 Anchor: Our reference topology is shown in Figure 6. In this mode we assume
that the gNB is an unmodified gNB using IPv4/GTP. The UPFs are SR-
aware. Also, as explained before, we introduce a new SRGW entity
that is going to map the IPv4/GTP traffic to SRv6.
It is assumed that the packet successfully traversed S2 segment We also assume that we have two service segment, S1 and C1. S1
so that the SL was decremented 2 to 1 in the former case, and 5 represents a VNF in the network, and C1 represents a router over
to 4 in the latter case before arriving the node of "A2::2" or which we are going to perform Traffic Engineering.
"A2::" segment.
In the first scenario that the L2-anchor node of "A2::2" +----+
segment is bound to a service policy which indicates path via IPv4/GTP -| S1 |- ___
node C1, service function S1 and access point function A1::, +--+ +-----+ [N3] / +----+ \ /
the node does End.B6 process for the receiving packet to push a |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
new SRH with SID list <C1, S1, A1::1> with SL=1. The node +--+ +-----+ \ [N9]/ NFV -| C1 |---| UPF2 |------\ DN
updates DA to next service function SID C1 which the SL GTP \ +------+ / +----+ +------+ \___
indicates and forward the packet. -| UPF1 |- SRv6 SRv6
+------+ TE
SR Gateway
In the second scenario that one SRH with SIDs <S1, C1, A2::, Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
S2, A3::1, D::1>, the L2-anchor node of "A2::" segment is bound
to just End function. The node does End process for the
receiving packet according to the SRH that decrements SL to 2,
updates DA to next node C1 which the SL indicates and forward
the packet.
Access Point: 5.3.2.1. Packet flow - Uplink
The access point node of "A1::1" segment does End process for The uplink packet flow is the following:
the receiving packet according to the SRH(s).
In the first scenario that outer SRH with SIDs <C1, S1, A1::1>, gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
it is assumed that the SL is decremented 2 to 0 at node C1 and unchanged IPv4/GTP
service function S1 so that the outer SRH is popped out by PSP SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function
at S1. Thus the node processes second SRH with SIDs <S2, S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
A2::2, S::1> that decrements SL to 0, updates DA to S::1 which C1_out : (SRGW, U2::1) (A,Z) -> PSP
the SL indicates and forward the packet to the mobile node UPF2_out: (A,Z) -> End.DT4 or End.DT6
through radio channel associated with "S::1". In this case,
the decremented SL is 0 so that the node does PSP operation of
popped out the SRH from the packet and forward it.
In the second scenario that one SRH with SIDs <S2, A2::, C1, The UE sends a packet destined to Z towards the gNB on a specific
S1, A1::1, S::1>, access node of "A1::1" segment does End bearer for that session. The gNB, which is unmodified, encapsulates
process for the receiving packet according to the SRH. Rest the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and
part of processes are as same as previous case. the GTP TEID are the ones received at the N2 interface.
6.3. Stateless Interworking with Legacy Access Network When the packet arrives to the SRGW -UPF1-, the SRGW has an UL CL
(uplink classifier) rule for incoming traffic from the gNB that
steers the traffic into an SR policy by using the function T.M.TMap.
The SRGW removes the IPv4, UDP and GTP headers and pushes an IPv6
header with its own SRH containing the SIDs related to the SR policy
associated with this traffic. The SRGW forwards according to the new
IPv6 DA.
This section describes an use case where user-plane functions are The nodes S1 and C1 perform their related Endpoint functionality and
interworking in stateless between SRv6 and legacy access networks. forward.
Here stateless means that there's no need to be aware any states of
mobility sessions in the node.
As some types of interworking scenarios could be considered, we will When the packet arrives at UPF2, the active segment is (U2::1) which
describe other cases in the future versions of this document. is bound to End.DT4/6 which performs the decapsulation (removing the
outer IPv6 header with all it's extension headers) and forwards
towards the data network.
6.3.1. Uplink: Lagacy Access to SRv6 5.3.2.2. Packet flow - Downlink
Legacy Access Point: The downlink packet flow is the following:
When a legacy access point node receives a packet destined to UPF2_in : (Z,A) -> UPF2 maps flow with SID
"D::1" from a mobile node "S::1" through associated radio <C1, S1,SRGW::SA:DA:TEID>
channel, it does tunnel encapsulation with the tunneling UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red
parameters, IPv4 DA, SA and tunnel header with ID, and sends C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
out the packet to the network. S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A)
SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A)
Stateless Interworking: When a packet destined to A arrives to the UPF2, the UPF2 performs a
lookup in the associated table to A and finds the SID list <C1, S1,
SRGW::SA:DA:TEID>. The UPF2 performs a T.Encaps.Reduced operation,
encapsulating the packet into a new IPv6 header with its
corresponding SRH.
The stateless interworking node of corresponding to the IPv4 DA The nodes C1 and S1 perform their related Endpoint processing.
does T.Tmap process for the receiving packet to pop the tunnel
headers and push a SRH to the packet. The SRH consists of SIDs
<B1, D::1> with SL=1, where "B1" encodes IW-IPv6-Prefix, tunnel
IPv4 DA, SA and TUN-ID in it as Figure 3 defined. The
stateless interworking node updates DA to "B1" and forward the
packet. SA of the packet must be kept as "S::1".
Layer-2 or Layer-3 Anchor: Once the packet arrives to the SRGW, the SRGW realizes the active SID
is an End.M.GTP4.E function. The SRGW removes the IPv6 header and
all it's extensions headers. The SRGW generates an IPv4, UDP and GTP
headers. The IPv4 SA and DA will the ones received as part of the
SID arguments. The TEID in the generated GTP header is also the
arguments of the received End.M.GTP4.E SID The SRGW pushes the
headers to the packet and forwards the packet towards the gNB.
The receiving node of the packet destine to B1 either be Once the packet arrives to the gNB, the packet is a regular IPv4/GTP
Layer-2 anchor, or Layer-3 anchor node. Which type of anchor packet. The gNB looks for the specific radio bearer for that TEID
function bound to B1 depends on operational policy. and forward it on the bearer. This gNB behavior is not modified from
current and previous generations.
In case of B1 to an L2-anchor node, the L2-anchor node does 5.3.2.3. Scalability
End.B6 process for the receiving packet as same as previous
section.
In case of B1 to an L3-anchor node, the L3-anchor node does For the downlink traffic, the SRGW is stateless. All the state is in
End.T process for the receiving packet as same as previous the SRH imposed by the UPF. The UPF must have this UE-base state
section. anyway (it is its anchor point).
6.3.2. Downlink: SRv6 to Legacy Access For the uplink traffic, the state at the SRGW is dedicated on a per
UE/session basis. This is an UL CL (uplink classifier). There is
state for steering the different sessions on a SR policies. Notice
however that the SR policies are shared among several UE/sessions.
Layer-2 or Layer-3 Anchor: 5.3.2.4. IPv6 user-traffic
In case of an L3-anchor node receives a packet destine to S::1 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
from the correspondent node "D::1", and stateless interworking However based on local policy, a service provider MAY choose to do
SID is bound to the next segment of S::1 , the L3-anchor node SRH insertion. The main benefit is a lower overhead.
does T.Insert process for the receiving packet to push a SRH
with SID list <B2::, S::1> with SL=1, where "B2" which encodes
IW-IPv6-Prefix, tunnel IPv4 DA, SA and TUN-ID in it as Figure 3
defined. The L3-anchor node updates DA to "B2" and forward the
packet.
In case of an L2-anchor node receives a packet destine to SID 5.3.3. Extensions to the interworking mechanisms
"A2::B2" and the SID is bound to "B2", the L2-anchor node does
End.B6 process for the receiving packet as same as previous
section. The node updates DA to B2 and forward the packet.
Stateless Interworking: In this section we presented two mechanisms for interworking with
gNBs that do not support SRv6. These mechanism are done to support
GTP over IPv4 and GTP over IPv6.
The stateless interworking node of "B2" End.TM process for the Even though we have presented these methods as an extension to the
receiving packet according to the SRH. The node decrement SL "Enhanced mode", it is straightforward in its applicability to the
to 0, updates DA to "D::1" which the SL indicates, push IPv4 "Traditional mode".
and tunnel headers with IPv4 DA, SA and TUN-ID extracted from
"B2", and forward the packet to the legacy network.
In this use case, decremented SL is 0 so that the node does PSP Furthermore, although these mechanisms are designed for interworking
operation of popped out the SRH from the packet and forward it. with legacy RAN at the N3 interface, these methods could also be
applied for interworking with a non-SRv6 capable UPF at the N9
interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not).
Legacy Access Point: 6. SRv6 SID Mobility Functions
The legacy access point node of the IPv4 DA does tunnel 6.1. End.MAP: Endpoint function with SID mapping
termination process for the receiving packet according to the
tunnel header. The node pop the IPv4 and tunnel header and
forward the packet to the mobile node through radio channel
associated with the tunnel.
7. Network Slicing Considerations The "Endpoint function with SID mapping" function (End.MAP for short)
is used in several scenarios. Particularly in mobility, it is used
in the UPFs for the anchor functionality in some of the use-cases.
Mobile network may be required to create a network slicing that When a SR node N receives a packet destined to S and S is a local
represent a set of network resources and isolate those resource from End.MAP SID, N does:
other slices. User-plane functions represented as SRv6 segments
would be part of a slice.
To represent a set of user-plane function segments for a slice, 1. look up the IPv6 DA in the mapping table
sharing same prefix through those SIDs within the slice could be a 2. update the IPv6 DA with the new mapped SID ;; Ref1
straightforward way. SIDs in a network slice may include other type 5. forward according to the new mapped SID
of functions in addition to the mobile user-plane functions described 8. ELSE
in this document, and underlay integration to meet SLA and quality 9. Drop the packet
requirements.
While network slicing has been discussed in the IETF and other Ref1: Note that the SID in the SRH is NOT modified.
standardization bodies, what functionalities are required for network
slicing in mobile user-plane is further study item and to be
discussed.
8. Control Plane Considerations 6.2. End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP
tunnel
8.1. Existing Control Plane The "Endpoint function with IPv6/GTP decapsulation into SR policy"
function (End.M.GTP6.D for short) is used in interworking scenario
for the uplink towards from the legacy gNB using IPv6/GTP. This SID
is associated with an SR policy <S1, S2, S3> and an IPv6 Source
Address A.
A mobile control-plane entity may allocate SIDs to the node of When the SR Gateway node N receives a packet destined to S and S is a
corresponding user-plane function. In this case, the control-plane local End.M.GTP6.D SID, N does:
entity must signal allocated SIDs to other side of entity.
If the control-plane entity needs to employ existing mobile control- 1. IF NH=UDP & UDP_PORT = GTP THEN
plane protocol to signal, GTP-C or PMIP for example, it must require 2. pop the IP, UDP and GTP headers
not to impact the control-plane protocols. In this case, tunnel 3. push a new IPv6 header with its own SRH <S2, S3>
endpoint IPv6 address field in the control-plane message can be used 4. set the outer IPv6 SA to A
to signal a SID. 5. set the outer IPv6 DA to S1
6. forward according to the first segment of the SRv6 Policy
7. ELSE
8. Drop the packet
The basic mode described in Section 6.1 should be adopted. In the 6.3. End.M.GTP6.E: Endpoint function with encapsulation for IPv6/GTP
basic mode, SID indicates unique session so that tunnel identifier is tunnel
not required to SRv6 user-plane. But the mobile control-plane may be
assumed that one user-plane entity has one IPv6 address and it
allocates tunnel identifier per session. In this case, SRv6 node of
user-plane can form SID with the IPv6 address and the tunnel
identifier.
When an IPv6 prefix "A::/64" is allocated to an user-plane, and the The "Endpoint function with encapsulation for IPv6/GTP tunnel"
control-plane allocate one 32bits tunnel identifier of "0x12345678" function (End.M.GTP6.E for short) is used in interworking scenario
for a mobile session, the user-plane node forms a 128bits SID for the downlink towards the legacy gNB using IPv6/GTP.
"A::1234:5678".
In this way, there is no impact to the control-plane. The End.M.GTP6.E function has a 32-bit argument space. This argument
corresponds to the GTP TEID.
8.2. Aggregate Mode When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.E SID, N does:
To support aggregate mode described in Section 6.2 in control-plane 1. IF NH=SRH & SL = 1 THEN ;; Ref1
protocol, allocated SIDs for service policies can be signaled as 2. decrement SL
tunnel endpoint IPv6 address too. In this case, SRv6 policy 3. store SRH[SL] in variable new_DA
associated to the SID should be configured in the user-plane node 4. store TEID in variable new_TEID ;; Ref2
through other means. 5. pop IP header and all it's extension headers
6. push new IPv6 header and GTP-U header
7. set IPv6 DA to new_DA
8. set GTP_TEID to new_TEID
9. lookup the new_DA and forward the packet accordingly
10. ELSE
11. Drop the packet
Aggregate mode user-plane can take advantage of SRv6 that enables Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID.
seamless mobile user-plane deployment with service chaining, VPNs,
traffic-engineering by computed path to fulfil the policy.
In case of a mobile control-plane is aware those policies and is Ref2: TEID is extracted from the argument space of the current SID.
capable to advertise them, the mobile control-plane can integrate
SRv6 advanced features.
8.3. User-Plane Sepalated Control Plane 6.4. End.M.GTP4.E: Endpoint function with encapsulation for IPv4/GTP
tunnel
In an user-plane separated control-plane system, a mobile user-plane The "Endpoint function with encapsulation for IPv4/GTP tunnel"
entity may allocate SIDs to an user-plane function instead of the function (End.M.GTP4.UP for short) is used in the downlink when doing
control-plane. In this case, the user-plane entity should inform interworking with legacy gNB using IPv4/GTP.
allocated SIDs back to the control-plane entity.
If the control- and user-plane entities need to employ existing user- When the SR Gateway node N receives a packet destined to S and S is a
plane control protocol in between, such as PFCP for example, it may local End.M.GTP4.E SID, N does:
be required not to impact that protocol. In this case, the control-
plane entity is only allowed to signal SID in a tunnel endpoint IPv6
address field.
8.4. Centralized Controller 1. IF NH=SRH & SL > 0 THEN
2. decrement SL
3. update the IPv6 DA with SRH[SL]
4. pop the SRH
4. push header of TUN-PROTO with tunnel ID from S ;; Ref1
5. push outer IPv4 header with SA, DA from S
6. ELSE
7. Drop the packet
Ref1: TUN-PROTO indicates target tunnel type.
When a centralized controller interfaces to mobile control-planes is Note that S has the following format:
capable to allocate SIDs to the controlling SRv6 nodes, the mobile
control-planes just need to indicate nodes and their user-plane
functions to the controller. In this case, the controller must
allocate appropriate SIDs for the user-plane functions to the SRv6
nodes. The controller must configure allocated SIDs to the nodes.
To indicate nodes and their user-plane functions from mobile control- +----------------------+-------+-------+-------+
plane to user-plane, the centralized controller could take advantage | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |
of [I-D.ietf-dmm-fpc-cpdp]. It provides interface to the control- +----------------------+-------+-------+-------+
plane to manage the user-plane of mobile networks. To build 128-a-b-c a b c
centralized controller for mobile user-plane is out of scope of this
document.
8.5. Stateless Interworking End.M.GTP4.E SID Encoding
A mobile control-plane is not required to configure statless 6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation and mapping
interworking function in interworking node. This benefits operators into an SRv6 Policy
to gradually migrate from legacy to advanced mobile user-plane with
no impact to the legacy system.
SID allocating entity of SRv6 user-plane nodes needs to be aware of The "Transit with tunnel decapsulation and map to an SRv6 policy"
IW-IPv6-Prefix to form interworking SID. Legacy user-plane network function (T.Tmap for short) is used in the direction from legacy
allocate IPv4 address space routed to SRv6 user-plane network. The user-plane to SRv6 user-plane network.
mobile control-plane of legacy user-plane also need to allocate
tunnel endpoint IPv4 addresses from that address space for mobile When the SR Gateway node N receives a packet destined to a IW-
sessions which is usual operation for it and no difference from IPv4-Prefix, N does:
legacy system.
1. IF P.PLOAD == TUN-PROTO THEN ;; Ref1
2. pop the outer IPv4 header and tunnel headers
3. copy IPv4 DA, SA, TUN-ID to form SID B with SRGW-IPv6-Prefix
4. encapsulate the packet into a new IPv6 header ;; Ref2, Ref2bis
5. set the IPv6 DA = B
6. forward along the shortest path to B
7. ELSE
8. Drop the packet
Ref1: TUN-PROTO indicates target tunnel type.
Note that B has the following format:
+----------------------+-------+-------+-------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |
+----------------------+-------+-------+-------+
128-a-b-c a b c
End.M.GTP4.E SID Encoding
Note that the B SID, is going to be an SRv6 BindingSID instantiated
at the first UPF (anchor point). A static format is leveraged to
instantiate this Binding SIDs in order to remove state from the SRGW.
6.6. End.Limit: Rate Limiting function
Mobile user-plane requires a rate-limit feature. SID is able to
encode limiting rate as an argument in SID. Multiple flows of
packets should have same group identifier in SID when those flows are
in an same AMBR group. This helps to keep user-plane stateless.
That enables SRv6 endpoint nodes which are unaware from the mobile
control-plane information. Encoding format of rate limit segment SID
is following:
+----------------------+----------+-----------+
| LOC+FUNC rate-limit | group-id | limit-rate|
+----------------------+----------+-----------+
128-i-j i j
End.Limit: Rate limiting function argument format
In case of j bit length is zero in SID, the node should not do rate
limiting unless static configuration or control-plane sets the limit
rate associated to the SID.
7. Network Slicing Considerations
A mobile network may be required to implement "network slices", which
logically separate network resources. User-plane functions
represented as SRv6 segments would be part of a slice.
A simple way to represent slice would be to apply L2/L3 VPN described
in [I-D.filsfils-spring-srv6-network-programming]. Segment Routing
with [I-D.hegdeppsenak-isis-sr-flex-algo] provides even more advanced
separation based on metrics like link-delay. Thus, a service
provider would be able to have network slices per required SLA.
The SRv6 SID and quite a few SR extended capability would be a
powerful tool for providing logical separation/integration within a
network. Details are for further study.
8. Control Plane Considerations
This documents focuses on the dataplane behavior. The control planes
could be based on the existing 3GPP based signalling for N4 interface
[TS.29244], [I-D.ietf-dmm-fpc-cpdp], control-plane protocols
described in [WHITEPAPER-5G-UP], etc. and to be discussed further.
Note that the IANA section of this document allocates the SRv6
endpoint function types for the new functions defined in this
document. All control-plane protocols are expected to leverage these
function type-codes to signal each function.
It's notable that SRv6's network programming nature allows a flexible
and dynamic anchor placement.
9. Security Considerations 9. Security Considerations
TBD TBD
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This I-D requests to IANA to allocate, within the "SRv6 Endpoint
Types" sub-registry belonging to the top-level "Segment-routing with
IPv6 dataplane (SRv6) Parameters" registry
[I-D.filsfils-spring-srv6-network-programming], the following
allocations:
+-------------+-----+-------------------+-----------+
| Value/Range | Hex | Endpoint function | Reference |
+-------------+-----+-------------------+-----------+
| TBA | TBA | End.MAP | [This.ID] |
| TBA | TBA | End.M.GTP6.D | [This.ID] |
| TBA | TBA | End.M.GTP6.E | [This.ID] |
| TBA | TBA | End.M.GTP4.E | [This.ID] |
| TBA | TBA | End.Limit | [This.ID] |
+-------------+-----+-------------------+-----------+
Table 1: SRv6 Mobile User-plane Endpoint Types
11. Acknowledgements 11. Acknowledgements
TBD The authors would like to thank Daisuke Yokota, Bart Peirens,
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch and Darren Dukes for
their useful comments of this work.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
Camarillo, "SRv6 Network Programming", draft-filsfils- Camarillo, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-02 (work in progress), spring-srv6-network-programming-03 (work in progress),
October 2017. December 2017.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-13 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), October 2017. in progress), January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
12.2. Informative References 12.2. Informative References
[I-D.gundavelli-dmm-mfa]
Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-00
(work in progress), February 2018.
[I-D.hegdeppsenak-isis-sr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
Segment Routing Flexible Algorithm", draft-hegdeppsenak-
isis-sr-flex-algo-02 (work in progress), February 2018.
[I-D.ietf-dmm-fpc-cpdp] [I-D.ietf-dmm-fpc-cpdp]
Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09
(work in progress), October 2017. (work in progress), October 2017.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>. <https://www.rfc-editor.org/info/rfc5213>.
[TS.23501]
3GPP, , "System Architecture for the 5G System", 3GPP TS
23.501 15.0.0, November 2017.
[TS.29244]
3GPP, , "Interface between the Control Plane and the User
Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017.
[TS.29281] [TS.29281]
3GPP, , "General Packet Radio System (GPRS) Tunnelling 3GPP, , "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
September 2011. December 2017.
Authors' Addresses Authors' Addresses
Satoru Matsushima Satoru Matsushima
SoftBank SoftBank
Tokyo Tokyo
Japan Japan
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
skipping to change at page 20, line 4 skipping to change at page 23, line 19
Tokyo Tokyo
Japan Japan
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
Email: cf@cisco.com Email: cf@cisco.com
Miya Kohno Miya Kohno
Cisco Systems, Inc. Cisco Systems, Inc.
Japan Japan
Email: mkohno@cisco.com Email: mkohno@cisco.com
Pablo Camarillo Garvia
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
Charles E. Perkins Charles E. Perkins
Futurewei Inc. Futurewei Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
 End of changes. 175 change blocks. 
606 lines changed or deleted 772 lines changed or added

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