draft-ietf-dmm-srv6-mobile-uplane-02.txt   draft-ietf-dmm-srv6-mobile-uplane-03.txt 
DMM Working Group 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: January 3, 2019 M. Kohno Expires: April 25, 2019 M. Kohno
P. Camarillo P. Camarillo
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C. Perkins C. Perkins
Futurewei Futurewei
July 2, 2018 October 22, 2018
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-02 draft-ietf-dmm-srv6-mobile-uplane-03
Abstract Abstract
This document discusses the applicability of SRv6 (Segment Routing This document shows the applicability of SRv6 (Segment Routing IPv6)
IPv6) to user-plane of mobile networks (N3 and N9 interfaces). The to the user-plane of mobile networks. The network programming nature
source routing capability and the network programming nature of SRv6, of SRv6 accomplish mobile user-plane functions in a simple manner.
accomplish mobile user-plane functions in a simple manner. The The statelessness of SRv6 and its ability to control both service
statelessness and the ability to control underlying layer will be layer path and underlying transport can be beneficial to the mobile
even more beneficial to the mobile user-plane, in terms of providing user-plane, providing flexibility and SLA control for various
flexibility and SLA control for various applications. It also applications. This document describes the SRv6 mobile user plane
simplifies the network architecture by eliminating the necessity of behavior and defines the SID functions for that. It also provides a
tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS, mechanism for end-to-end network slicing.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 5 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6 2.3. Predefined SRv6 Functions . . . . . . . . . . . . . . . . 4
5.1. Traditional mode (formerly Basic mode) . . . . . . . . . 7 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 7 4. A 3GPP Reference Architecture . . . . . . . . . . . . . . . . 6
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8
5.1.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 8 5.1.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 9
5.2. Enhanced Mode (formerly Aggregate mode) . . . . . . . . . 8 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 9 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10
5.2.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 10 5.2.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 11
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15
5.3.3. Extensions to the interworking mechanisms . . . . . . 17 5.3.3. Extensions to the interworking mechanisms . . . . . . 17
6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18
6.1. End.MAP: Endpoint function with SID mapping . . . . . . . 17 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18
6.2. End.M.GTP6.D: Endpoint function with decapsulation from 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18
IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 17 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19
6.3. End.M.GTP6.E: Endpoint function with encapsulation for 6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19
IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18 6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP4.E: Endpoint function with encapsulation for 6.6. T.M.Tmap . . . . . . . . . . . . . . . . . . . . . . . . 20
IPv4/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18 6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21
6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22
and mapping into an SRv6 Policy . . . . . . . . . . . . . 19 8. Network Slicing Considerations . . . . . . . . . . . . . . . 22
6.6. End.Limit: Rate Limiting function . . . . . . . . . . . . 20 9. Control Plane Considerations . . . . . . . . . . . . . . . . 22
7. SRv6 supported PDU session types . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Network Slicing Considerations . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Control Plane Considerations . . . . . . . . . . . . . . . . 21 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 22 Appendix B. Changes from revision 02 to revision 03 . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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. While the control-plane of the system
system signals movements of a mobile node, user-plane establishes signals movements of a mobile node, the user-plane establishes a
tunnel between the mobile node and anchor node over IP based backhaul tunnel between the mobile node and its anchor node over IP-based
and core networks. backhaul and core networks.
This document discusses the applicability of SRv6 (Segment Routing This document shows the applicability of SRv6 (Segment Routing IPv6)
IPv6) to those mobile networks. SRv6 provides source routing to to those mobile networks. SRv6 provides source routing to networks
networks where operators can explicitly indicate a route for the so that operators can explicitly indicate a route for the packets to
packets from and to the mobile node. SRv6 endpoint nodes perform the and from the mobile node. SRv6 endpoint nodes serve as the anchors
roles of anchor of mobile user-plane. 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].
SRH is the abbreviation for the Segment Routing Header. We assume 2.1. Terminology
that the SRH may be present multiple times inside each packet.
NH is the abbreviation of the IPv6 next-header field.
NH=SRH means that the next-header field is 43 with routing type 4.
When there are multiple SRHs, they must follow each other: the next-
header field of all SRH, except the last one, must be SRH.
The effective next-header (ENH) is the next-header field of the IP
header when no SRH is present, or is the next-header field of the
last SRH.
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 o AMBR: Aggregate Maximum Bit Rate
segment routing domain. The SID type used in this document is IPv6 o APN: Access Point Name (commonly used to identify a network or
address (also referenced as SRv6 Segment or SRv6 SID). class of service)
o BSID: SR Binding SID [RFC8402]
o CNF: Cloud-native Network Function
o gNB: gNodeB
o NH: The IPv6 next-header field.
o NFV: Network Function Virtualization
o PDU: Packet Data Unit
o Session: TBD...
o SID: A Segment Identifier which represents a specific segment in a
segment routing domain.
o SRH: The Segment Routing Header.
[I-D.ietf-6man-segment-routing-header]
o TEID: Tunnel Endpoint Identifier
o UE: User Equipment
o UPF: User Plane Function
o VNF: Virtual Network Function
A SID list is represented as <S1, S2, S3> where S1 is the first SID 2.2. Conventions
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 NH=SRH means that NH is 43 with routing type 4.
o Multiple SRHs may be present inside each packet, but they must
follow each other. The next-header field of each SRH, except the
last one, must be NH-SRH (43 type 4).
o For simplicity, no other extension headers are shown except the
SRH.
o The SID type used in this document is IPv6 address (also called
SRv6 Segment or SRv6 SID).
o gNB::1 is an IPv6 address (SID) assigned to the gNB.
o U1::1 is an IPv6 address (SID) assigned to UPF1.
o U2::1 is an IPv6 address (SID) assigned to UPF2.
o U2:: is some other IPv6 address (SID) assigned to UPF2.
o 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.
o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
o IPv6 header with source and destination addresses respectively SA * IPv6 header with source and destination addresses SA and DA
and DA and next-header is SRH respectively, and next-header SRH, with SID list <S1, S2, S3>
o SRH with SID list <S1, S2, S3> with SegmentsLeft = SL with SegmentsLeft = SL
* The payload of the packet is not represented.
o Note the difference between the <> and () symbols: <S1, S2, S3> 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 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 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 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 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 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 <S1, S2, S3> notation. When referring to an illustration of the
detailed behavior, the (S3, S2, S1; SL) notation is more detailed behavior, the (S3, S2, S1; SL) notation is more
convenient. convenient.
o The payload of the packet is omitted. o 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.
o SRH[SL] can be different from the DA of the IPv6 header.
SRH[SL] represents the SID pointed by the SL field in the first SRH. 2.3. Predefined SRv6 Functions
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 The following functions are defined in
lookup in the forwarding table. When a packet is intercepted on a [I-D.filsfils-spring-srv6-network-programming].
wire, it is possible that SRH[SL] is different from the DA.
o End.DT4 means to decapsulate and forward using a specific IPv4
table lookup.
o End.DT6 means to decapsulate and forward using a specific IPv6
table lookup.
o End.DX4 means to decapsulate and forward through a particular link
configured with the SID.
o End.DX6 means to decapsulate and forward through a particular link
configured with the SID.
o End.T means to forward using a specific IPv6 table lookup.
o End.X means to forward through a link configured with the SID.
o T.Encaps.Red means encapsulation without pushing SRH (resulting in
"Reduced" packet size).
o PSP means Penultimate Segment Pop. The packet is subsequently
forwarded without the popped SRH.
New SRv6 functions are defined in Section 6 to support the needs of
the mobile user plane.
3. Motivation 3. Motivation
Every day mobility networks are getting more challenging to operate: Mobility networks are becoming more challenging to operate. On one
on one hand, traffic is constantly growing, and latency requirements hand, traffic is constantly growing, and latency requirements are
are more strict; on the other-hand, there are new use-cases like NFV more strict; on the other-hand, there are new use-cases like NFV that
that are also challenging network management. are also challenging network management.
Problem comes from the fact that the current architecture of mobile The current architecture of mobile networks does not take into
networks is agnostic to the underlying transport. Indeed, it rigidly account the underlying transport. The user-plane is rigidly
fragments the user-plane into radio access, core and service networks fragmented into radio access, core and service networks, connected by
and connects them by tunneling techniques through the user-plane tunneling according to user-plane roles such as access and anchor
roles such as access and anchor nodes. Such agnosticism and nodes. These factors have made it difficult for the operator to
rigidness make it difficult for the operator to optimize and operate optimize and operate the data-path.
the data-path.
While the mobile network industry has been trying to solve those In the meantime, applications have shifted to use IPv6, and network
problems, applications have shifted to use IPv6, and network operators have started adopting IPv6 as their IP transport. SRv6,
operators have started adopting IPv6 as their IP transport as well. the IPv6 dataplane instantiation of Segment Routing [RFC8402],
SRv6, the IPv6 instantiation of Segment Routing integrates both the application data-path and the underlying
[I-D.ietf-spring-segment-routing], integrates both the application transport layer into a single protocol, allowing operators to
data-path and the underlying transport layer into one single optimize the network in a simplified manner and removing forwarding
protocol, allowing operators to optimize the network in a simplified state from the network. It is also suitable for virtualized
manner and removing forwarding state from the network. environments, VNF/CNF to VNF/CNF networking.
Further on, SRv6 introduces the notion of network-programming SRv6 specifies network-programming (see
[I-D.filsfils-spring-srv6-network-programming], that applied to [I-D.filsfils-spring-srv6-network-programming]). Applied to
mobility fulfils the user-plane functions of mobility management. mobility, SRv6 can provide the user-plane functions needed for
SRv6 takes advantage of underlying transport awareness and mobility management. SRv6 takes advantage of underlying transport
flexibility to deploy mobility user-plane functions in an optimized awareness and flexibility to improve mobility user-plane functions.
manner. Those are the motivations to adopt SRv6 for mobile user-
plane.
4. Reference Architecture The use-cases for SRv6 mobility are discussed in
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases].
This section describes a reference architecture and possible 4. A 3GPP Reference Architecture
This section presents a reference architecture and possible
deployment scenarios. deployment scenarios.
Figure 1 shows a reference architecture, based on 5G packet core Figure 1 shows a reference diagram from the 5G packet core
architecture [TS.23501]. architecture [TS.23501].
Please note that all the user-plane described in this document does The user plane described in this document does not depend on any
not depend on any specific architecture. This architecture is just specific architecture. The 5G packet core architecture as shown is
used as a reference based on the latest 3GPP standards at the time of based on the latest 3GPP standards at the time of writing this draft.
writing this draft. Other type of architectures can be seen in Other architectures can be seen in [I-D.gundavelli-dmm-mfa] and
[I-D.gundavelli-dmm-mfa] and [WHITEPAPER-5G-UP]. [WHITEPAPER-5G-UP].
+-----+ +-----+
| AMF | | AMF |
+-----+ +-----+
/ | [N11] / | [N11]
[N2] / +-----+ [N2] / +-----+
+------/ | SMF | +------/ | SMF |
/ +-----+ / +-----+
/ / \ / / \
/ / \ [N4] / / \ [N4]
/ / \ ________ / / \ ________
/ / \ / \ / / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
Figure 1: Reference Architecture Figure 1: 3GPP 5G Reference Architecture
o UE : User Equipment o gNB: gNodeB
o gNB : gNodeB o UPF1: UPF with Interfaces N3 and N9
o UPF : User Plane Function o UPF2: UPF with Interfaces N9 and N6
o SMF: Session Management Function
o AMF: Access and Mobility Management Function
o DN: Data Network e.g. operator services, Internet access
* UPF1: Interfaces N3 and N9 This reference diagram does not depict a UPF that is only connected
* UPF2: Interfaces N9 and N6 to N9 interfaces, although the description in this document also work
* Note: For simplicity we don't depict a UPF that is only for such UPFs.
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 Each session from an UE gets assigned to a UPF. Sometimes multiple
one UPF may be used for providing a certain kind of richer service UPFs may be used, providing richer service functions. A UE gets its
functions. UE gets its IP address from the DHCP block of its UPF. IP address from the DHCP block of its UPF. The UPF advertises that
The UPF advertises the IP address block towards the Internet ensuring IP address block toward the Internet, ensuring that return traffic is
that return traffic is routed to the right UPF. routed to the right UPF.
5. User-plane behaviors 5. User-plane behaviors
This section describes the mobile user-plane behaviors using SRv6. This section describes some mobile user-plane behaviors using SRv6.
In order to simplify the SRv6 adoption, we present two different In order to simplify the adoption of SRv6, we present two different
"modes" that vary with respect the SRv6 SID allocation. The first "modes" that vary with respect to the use of SRv6. The first one is
one is the "Traditional mode", which inherits the traditional mobile the "Traditional mode", which inherits the current 3GPP mobile user-
user-plane. In this mode there is no change to mobility networks plane. In this mode there is no change to mobility networks
architecture, except for the pure replacement of GTP-U [TS.29281] for architecture, except that GTP-U [TS.29281] is replaced by SRv6.
SRv6.
The second mode is the "Enhanced mode", which aggregates the mobile The second mode is the "Enhanced mode". In this mode the SR policy
sessions and allocates SID on a per policy basis. The benefit of the contains SIDs for Traffic Engineering and VNFs, which results in
latter is that the SR policy contains SIDs for Traffic Engineering effective end-to-end network slices.
and VNFs. Both of these modes assume both the gNB and UPFs are SR-
aware (N3 and N9 interfaces are SRv6).
Additionally, we introduce a new "Enhanced mode with unchanged gNB In both, the Traditional and the Enhanced modes, we assume that the
GTP behavior". This mode consists of two mechanisms for interworking gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6
with legacy access networks -interface N3 unmodified-. One of these interfaces are SRv6).
mechanism is designed to interwork with legacy gNBs using GTP/IPv4.
The second method is designed to interwork with legacy gNBs using
GTP/IPv6.
This section makes reference to already existing SRv6 functions We introduce two mechanisms for interworking with legacy access
defined in [I-D.filsfils-spring-srv6-network-programming] as well as networks (N3 interface is unmodified). In these document we
new SRv6 functions designed for the mobile userplane. The new SRv6 introduce them applied to the Enhanced mode, although they could be
functions are detailed in the Section 6. used in combination with the Traditional mode as well.
5.1. Traditional mode (formerly Basic mode) One of these mechanisms is designed to interwork with legacy gNBs
using GTP/IPv4. The second method is designed to interwork with
legacy gNBs using GTP/IPv6.
In the traditional mode, we assume that mobile user-plane functions This document uses SRv6 functions defined in
are the same as existing ones except the use of SRv6 as the data [I-D.filsfils-spring-srv6-network-programming] as well as new SRv6
plane instead of GTP-U. No impact to the rest of mobile system functions designed for the mobile user plane. The new SRv6 functions
should be expected. are detailed in Section 6.
In the traditional mobile network, an UE session is mapped 1-for-1 5.1. Traditional mode
In the traditional mode, the existing mobile UPFs remain unchanged
except for the use of SRv6 as the data plane instead of GTP-U. There
is no impact to the rest of mobile system.
In existing 3GPP mobile networks, an UE session is mapped 1-for-1
with a specific GTP tunnel (TEID). This 1-for-1 mapping is with a specific GTP tunnel (TEID). This 1-for-1 mapping is
replicated here to replace the GTP encaps with the SRv6 encaps, while replicated here to replace GTP encapsulation with the SRv6
not changing anything else. encapsulation, while not changing anything else.
This mode minimizes the changes required to the entire system and it The traditional mode minimizes the changes required to the mobile
is a good starting point for forming the common basis. Note that in system; it is a good starting point for forming a common basis.
this mode the TEID is embedded in each SID.
Our reference topology is shown in Figure 2. In this mode we assume Our example topology is shown in Figure 2. In traditional mode the
that the gNB and the UPFs are SR-aware. gNB and the UPFs are SR-aware. In the descriptions of the uplink and
downlink packet flow, A is an IPv6 address of the UE, and Z is an
IPv6 address reachable within the Data Network DN. A new SRv6
function End.MAP, defined in Section 6.2, is used.
________ ________
SRv6 SRv6 / \ SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node
Figure 2: Traditional mode - Reference topology Figure 2: Traditional mode - example topology
5.1.1. Packet flow - Uplink 5.1.1. Packet flow - Uplink
The uplink packet flow is the following: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Reduced <U1::1> gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE packet arrives to the gNB. The gNB performs a When the UE packet arrives at the gNB, the gNB performs a
T.Encaps.Reduced operations. Since there is only one SID, there is T.Encaps.Red operation. Since there is only one SID, there is no
no need to push an SRH. gNB only adds an outer IPv6 header with IPv6 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA
DA U1::1. U1::1 represents an anchoring SID specific for that U1::1. U1::1 represents an anchoring SID specific for that session
session at UPF1. The SID U1::1 is retrieved through the existing at UPF1. gNB obtains the SID U1::1 from the existing control plane
control plane (N2 interface). (N2 interface).
Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP When the packet arrives at UPF1, the SID U1::1 identifies a local
function. This function maps the SID with the next anchoring point End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to
and replaces U1::1 by U2::1, that belongs to the next anchoring the next UPF (U2).
point.
Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT When the packet arrives at UPF2, the SID U2::1 corresponds to an
function. UPF2 decapsulates the packet, performs a lookup in a End.DT function. UPF2 decapsulates the packet, performs a lookup in
specific table and forwards the packet towards the data network. a specific table and forwards the packet toward the data network
(DN).
5.1.2. Packet flow - Downlink 5.1.2. Packet flow - Downlink
The downlink packet flow is the following: The downlink packet flow is as follows:
UPF2_in : (Z,A) UPF2_in : (Z,A)
UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Reduced <U1::1> UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red <U1::1>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
gNB_out : (Z,A) -> End.DX4 or End.DX6 gNB_out : (Z,A) -> End.DX4 or End.DX6
When the packet arrives to the UPF2, the UPF2 will map that When the packet arrives at the UPF2, the UPF2 maps that flow into a
particular flow into a UE session. This UE session is associated UE session. This UE session is associated with the segment endpoint
with the policy <U1::1>. The UPF2 performs a T.Encaps.Reduced <U1::1>. UPF2 performs a T.Encaps.Red operation, encapsulating the
operation, encapsulating the packet into a new IPv6 header with no packet into a new IPv6 header with no SRH since there is only one
SRH since there is only one SID. SID.
Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 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 function. This function maps the SID to the next anchoring point and
and replaces U1::1 by gNB::1, that belongs to the next anchoring replaces U1::1 by gNB::1, that belongs to the next hop.
point.
Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4/ Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4
End.DX6 function. The gNB will decapsulates the packet, removing the or End.DX6 function. The gNB decapsulates the packet, removing the
IPv6 header and all it's extensions headers and will forward the IPv6 header and all its extensions headers, and forwards the traffic
traffic towards the UE. toward the UE.
5.1.3. IPv6 user-traffic 5.1.3. IPv6 user-traffic
For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
However based on local policy, a service provider MAY choose to do However based on local policy, a service provider MAY choose to do
SRH insertion. The main benefit is a lower overhead. In such case, 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 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 at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at
gNB on Downlink. gNB on Downlink.
5.2. Enhanced Mode (formerly Aggregate mode) 5.2. Enhanced Mode
This mode improves the scalability. In addition, it provides key
improvements in terms of traffic steering and service programming
[I-D.xuclad-spring-sr-service-programming] , thanks to the use of an
SR policy of multiple SIDs, instead of single one in the Traditional
mode.
Key points: Enhanced mode improves scalability, traffic steering and service
programming [I-D.xuclad-spring-sr-service-programming], thanks to the
use of multiple SIDs, instead of a single SID as done in the
Traditional mode.
o Several UE share the same SR Policy (and it's composing SID) The main difference is that the SR policy MAY include SIDs for
o The SR policy MAY include SIDs for traffic engineering and service traffic engineering and service programming in addition to the UPFs
programming on top of the UPF anchor. SIDs.
The gNB control-plane (N2 interface) is unchanged, specifically a The gNB control-plane (N2 interface) is unchanged, specifically a
single IPv6 address is given to the gNB. single IPv6 address is given to the gNB.
o The gNB MAY resolve the IP address into a SID list through a o The gNB MAY resolve the IP address into a SID list using a
mechanism like PCEP, DNS-lookup, small augment for LISP control- mechanism like PCEP, DNS-lookup, small augment for LISP control-
plane, etc. plane, etc.
Our reference topology is shown in Figure 3. In this mode we assume Note that the SIDs MAY use the arguments Args.Mob.Session if required
that the gNB and the UPF are SR-aware. We also assume that we have by the UPFs.
two services segments, S1 and C1. S1 represents a VNF in the
network, and C1 represents a constraint path on a router over which Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the
we are going to perform Traffic Engineering. Note that S1 and C1 gNB and the UPF are SR-aware. The Figure shows two service segments,
belong to the underlay and don't have an N4 interface. For this S1 and C1. S1 represents a VNF in the network, and C1 represents a
reason we don't consider them UPFs. constraint path on a router requiring Traffic Engineering. S1 and C1
belong to the underlay and don't have an N4 interface, so they are
not considered UPFs.
+----+ SRv6 _______ +----+ SRv6 _______
SRv6 --| C1 |--[N3] / \ SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/ +--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node SRv6 node \ +----+ / SRv6 node
-| S1 |- -| S1 |-
+----+ +----+
SRv6 node SRv6 node
VNF CNF
Figure 3: Enhanced mode - Reference topology Figure 3: Enhanced mode - Example topology
5.2.1. Packet flow - Uplink 5.2.1. Packet flow - Uplink
The uplink packet flow is the following: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red<S1,C1,U2::1> 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) S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z)
C1_out : (gNB, U2::1)(A,Z) -> PSP C1_out : (gNB, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
UE sends its packet (A,Z) on a specific bearer session to its gNB. UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's
gNB's CP associates that session from the UE(A) with the IPv6 address control plane associates that session from the UE(A) with the IPv6
B and GTP TEID T. gNB's CP does a lookup on B (by reverseDNS, LISP, address B and GTP TEID T. gNB's control plane does a lookup on B to
etc.) to find the related SID list <S1, C1, U2::1>. find the related SID list <S1, C1, U2::1>.
Once the packet leaves the gNB, it already contains all the segments When gNB transmits the packet, it contains all the segments of the SR
of the SR policy. This SR policy contains segments for traffic policy. The SR policy can include segments for traffic engineering
engineering (C1) and for service programming (S1). (C1) and for service programming (S1).
The nodes S1 and C1 perform their related Endpoint functionality and Nodes S1 and C1 perform their related Endpoint functionality and
forward. forward the packet.
When the packet arrives to UPF2, the active segment (U2::1) is an When the packet arrives at UPF2, the active segment (U2::1) is an
End.DT4/6 which performs the decapsulation (removing the IPv6 header End.DT4/6 which performs the decapsulation (removing the IPv6 header
with all it's extension headers) and forward towards the data with all its extension headers) and forwards toward the data network.
network.
Note that in case several APNs are using duplicated IPv4 private
address spaces, then the aggregated SR policies are unique per APNs.
5.2.2. Packet flow - Downlink 5.2.2. Packet flow - Downlink
The downlink packet flow is the following: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow w/ UPF2_in : (Z,A) -> UPF2 maps the flow w/
SID list <C1,S1, gNB> SID list <C1,S1, gNB>
UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red
C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
S1_out : (U2::1, gNB)(Z,A) -> PSP S1_out : (U2::1, gNB)(Z,A) -> PSP
gNB_out : (Z,A) -> End.DX4 or End.DX6 gNB_out : (Z,A) -> End.DX4 or End.DX6
When the packet arrives to the UPF2, the UPF2 will map that When the packet arrives at the UPF2, the UPF2 maps that particular
particular flow into a UE session. This UE session is associated flow into a UE session. This UE session is associated with the
with the policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Reduced policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Red operation,
operation, encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives to the gNB, the IPv6 DA corresponds to an Once the packet arrives at the gNB, the IPv6 DA corresponds to an
End.DX4 or End.DX6 (depending on the underlying traffic). The gNB End.DX4 or End.DX6 (depending on the underlying traffic). The gNB
will decapsulate the packet, removing the IPv6 header and all it's decapsulates the packet, removing the IPv6 header and all its
extensions headers and will forward the traffic towards the UE. extensions headers and forwards the traffic toward the UE.
5.2.3. IPv6 user-traffic 5.2.3. IPv6 user-traffic
For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
However based on local policy, a service provider MAY choose to do However based on local policy, a service provider MAY choose to do
SRH insertion. The main benefit is a lower overhead. In such case, 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 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. Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink.
5.3. Enhanced mode with unchanged gNB GTP behavior 5.3. Enhanced mode with unchanged gNB GTP behavior
In this section we introduce two mechanisms for interworking with This section describes two mechanisms for interworking with legacy
legacy gNBs that still use GTP. One of the mechanisms is valid for gNBs that still use GTP: one for IPv4, the other for IPv6.
IPv4 while the other for IPv6.
In this scenario, it is assumed that gNB does not support SRv6. It In the interworking scenarios as illustrated in Figure 4, gNB does
just supports GTP encapsulation over IPv4 or IPv6. Hence in order to not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6.
achieve interworking we are going to add a new SR Gateway (SRGW-UPF1) To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added.
entity. This SRGW is going to map the GTP traffic into SRv6. Note The SRGW maps the GTP traffic into SRv6.
that the SR GW is not an anchor point.
The SRGW maintains very little state on it. For this reason, both of The SRGW is not an anchor point, and maintains very little state.
these methods (IPv4 and IPv6) scale to millions of UEs. For this reason, both IPv4 and IPv6 methods scale to millions of UEs.
_______ _______
IP GTP SRv6 / \ IP GTP SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/ +--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node SR Gateway SRv6 node
Figure 4: Reference topology for interworking Figure 4: Example topology for interworking
5.3.1. Interworking with IPv6 GTP 5.3.1. Interworking with IPv6 GTP
In this interworking mode we assume that the gNB is using GTP over In this interworking mode the gNB uses GTP over IPv6 via the N3
IPv6 in the N3 interface interface
Key points: Key points:
o gNB is unchanged (control-plane or user-plane) and encaps into GTP o The gNB is unchanged (control-plane or user-plane) and
(N3 interface is not modified). encapsulates into GTP (N3 interface is not modified).
o 5G Control-Plane (N2 interface) is unmodified: 1 IPv6 address o The 5G Control-Plane (N2 interface) is unmodified; one IPv6
(i.e. a BSID at the SRGW) address is needed (i.e. a BSID at the SRGW).
o SRGW removes GTP, finds SID list related to DA, add SRH with the o The SRGW removes GTP, finds the SID list related to DA, and adds
SID list. SRH with the SID list.
o There is NO state for the downlink at the SRGW. o There is no state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW (leveraging the o There is simple state in the uplink at the SRGW; using Enhanced
enhanced mode results in few SR policies on this node. A SR mode results in fewer SR policies on this node. A SR policy can
policy can be shared across UEs). be shared across UEs.
o As soon as the packet leaves the gNB (uplink), the traffic is SR- o When a packet from the UE leaves the gNB, it is SR-routed. This
routed. This simplifies considerably network slicing simplifies network slicing [I-D.hegdeppsenak-isis-sr-flex-algo].
[I-D.hegdeppsenak-isis-sr-flex-algo]. o In the uplink, the IPv6 DA BSID steers traffic into an SR policy
o In the uplink, we use the IPv6 DA BSID to steer the traffic into when it arrives at the SRGW-UPF1.
an SR policy when it arrives at the SRGW-UPF1-.
Our reference topology is shown in Figure 5. In this mode we assume An example topology is shown in Figure 5. In this mode the gNB is an
that the gNB is an unmodified gNB using IPv6/GTP. The UPFs are SR- unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before,
aware. Also, as explained before, we introduce a new SRGW entity the SRGW maps IPv6/GTP traffic to SRv6.
that is going to map the IPv6/GTP traffic to SRv6.
We also assume that we have two service segment, S1 and C1. S1 S1 and C1 are two service segments. S1 represents a VNF in the
represents a VNF in the network, and C1 represents a router over network, and C1 represents a router configured for Traffic
which we are going to perform Traffic Engineering. Engineering.
+----+ +----+
IPv6/GTP -| S1 |- ___ IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___ GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6 -| UPF1 |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
5.3.1.1. Packet flow - Uplink 5.3.1.1. Packet flow - Uplink
The uplink packet flow is the following: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP) (IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW SID at the SRGW
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> PSP C1_out : (SRGW, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z towards the gNB on a specific The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates 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 packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the
the GTP TEID T are the ones received in the N2 interface. GTP TEID T are the ones received in the N2 interface.
The IPv6 address that was signalled over the N2 interface for that UE 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 session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the
instantiated at the SRGW. Hence the packet, will be routed up to the SRGW. Hence the packet is routed to the SRGW.
SRGW.
When the packet arrives at the SRGW, the SRGW realises that B is an When the packet arrives at the SRGW, the SRGW identifies B as an
End.M.GTP6.D BindingSID. Hence, the SRGW will remove the IPv6, UDP End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes
and GTP headers, and will push a new IPv6 header with its own SRH the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own
containing the SIDs bound to the SR policy associated with this SRH containing the SIDs bound to the SR policy associated with this
BindingSID. Note that there will be one instance of the End.M.GTP6.D BindingSID. There is one instance of the End.M.GTP6.D SID per PDU
SID per PDU type. type.
The nodes S1 and C1 perform their related Endpoint functionality and S1 and C1 perform their related Endpoint functionality and forward
forward. the packet.
When the packet arrives to UPF2, the active segment is (U2::1) which When the packet arrives at UPF2, the active segment is (U2::1) which
bound to End.DT4/6 which is going to perform the decapsulation is bound to End.DT4/6. UPF2 then decapsulates (removing the outer
(removing the outer IPv6 header with all it's extension headers) and IPv6 header with all its extension headers) and forwards the packet
forward towards the data network. toward the data network.
5.3.1.2. Packet flow - Downlink 5.3.1.2. Packet flow - Downlink
The downlink packet flow is the following: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow with UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB> <C1, S1, SRGW::TEID,gNB>
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 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) 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) 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 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A) gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the associated table to A and finds the SID list <C1, S1, lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::TEID, gNB>. The UPF2 performs a T.Encaps.Reduced operation, SRGW::TEID, gNB>. The UPF2 performs a T.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. C1 and S1 perform their related Endpoint processing.
Once the packet arrives to the SRGW, the SRGW realizes the active SID Once the packet arrives at the SRGW, the SRGW identifies the active
is an End.M.GTP6.E function. The SRGW removes the IPv6 header and SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header
all it's extensions headers. The SRGW generates an IPv6, UDP and GTP and all its extensions headers. The SRGW generates new IPv6, UDP and
headers. The new IPv6 DA is the gNB which is the last SID in the GTP headers. The new IPv6 DA is the gNB which is the last SID in the
received SRH. The TEID in the generated GTP header is the arguments received SRH. The TEID in the generated GTP header is an argument of
of the received End.M.GTP6.E SID. The SRGW pushes the headers to the the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet towards the gNB. Note that there will packet and forwards the packet toward the gNB. There is one instance
be one instance of the End.M.GTP6.E SID per PDU type. of the End.M.GTP6.E SID per PDU type.
Once the packet arrives to the gNB, the packet is a regular IPv6/GTP Once the packet arrives at the gNB, the packet is a regular IPv6/GTP
packet. The gNB looks for the specific radio bearer for that TEID 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 and forward it on the bearer. This gNB behavior is not modified from
current and previous generations. current and previous generations.
5.3.1.3. Scalability 5.3.1.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in For the downlink traffic, the SRGW is stateless. All the state is in
the SRH imposed by the UPF2. The UPF2 must have the UE states as the the SRH inserted by the UPF2. The UPF2 must have the UE states since
session anchor point. it is the UE's session anchor point.
For the uplink traffic, the state at the SRGW does not necessarily For the uplink traffic, the state at the SRGW does not necessarily
need to be per UE session basis. A state of SR policy of which state need to be unique per UE session; the state state can be shared among
can be shared among UE's. Hence it is possible to deploy SRGW in UEs. This enables much more scalable SRGW deployments compared to a
very scalable way compared to hold millions of states per UE session solution holding millions of states, one or more per UE.
basis.
5.3.1.4. IPv6 user-traffic 5.3.1.4. IPv6 user-traffic
For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
However based on local policy, a service provider MAY choose to do However based on local policy, a service provider MAY choose to do
SRH insertion. The main benefit is a lower overhead. SRH insertion. The main benefit is lower overhead.
5.3.2. Interworking with IPv4 GTP 5.3.2. Interworking with IPv4 GTP
In this interworking mode we assume that the gNB is using GTP over In this interworking mode the gNB uses GTP over IPv4 in the N3
IPv4 in the N3 interface interface
Key points: Key points:
o gNB is unchanged and encaps into GTP (N3 interface is not o The gNB is unchanged and encapsulates packets into GTP (the N3
modified). interface is not modified).
o In the uplink, traffic is classified at SRGW by UL CL(Uplink o In the uplink, traffic is classified by SRGW's Uplink Classifier
Classifier) and steered into an SR policy. The SRGW is a UPF1 and steered into an SR policy. The SRGW is a UPF1 functionality
functionality, hence it can coexist with UPF UL CL functionality. and can coexist with UPF1's Uplink Classifier functionality.
o SRGW removes GTP, finds SID list related to DA, add SRH with SID o SRGW removes GTP, finds the SID list related to DA, and adds a SRH
list. with the SID list.
Our reference topology is shown in Figure 6. In this mode we assume An example topology is shown in Figure 6. In this mode the gNB is an
that the gNB is an unmodified gNB using IPv4/GTP. The UPFs are SR- unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before,
aware. Also, as explained before, we introduce a new SRGW entity the SRGW maps the IPv4/GTP traffic to SRv6.
that is going to map the IPv4/GTP traffic to SRv6.
We also assume that we have two service segment, S1 and C1. S1 S1 and C1 are two service segment endpoints. S1 represents a VNF in
represents a VNF in the network, and C1 represents a router over the network, and C1 represents a router configured for Traffic
which we are going to perform Traffic Engineering. Engineering.
+----+ +----+
IPv4/GTP -| S1 |- ___ IPv4/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___ GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6 -| UPF1 |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
5.3.2.1. Packet flow - Uplink 5.3.2.1. Packet flow - Uplink
The uplink packet flow is the following: The uplink packet flow is as follows:
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
unchanged IPv4/GTP unchanged IPv4/GTP
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1) (A,Z) -> PSP C1_out : (SRGW, U2::1) (A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z towards the gNB on a specific The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates bearer for that session. The gNB, which is unmodified, encapsulates
the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and
the GTP TEID are the ones received at the N2 interface. the GTP TEID are the ones received at the N2 interface.
When the packet arrives to the SRGW -UPF1-, the SRGW has an UL CL When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
(uplink classifier) rule for incoming traffic from the gNB that Classifier rule for incoming traffic from the gNB, that steers the
steers the traffic into an SR policy by using the function T.M.TMap. traffic into an SR policy by using the function T.M.TMap. The SRGW
The SRGW removes the IPv4, UDP and GTP headers and pushes an IPv6 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with
header with its own SRH containing the SIDs related to the SR policy its own SRH containing the SIDs related to the SR policy associated
associated with this traffic. The SRGW forwards according to the new with this traffic. The SRGW forwards according to the new IPv6 DA.
IPv6 DA.
The nodes S1 and C1 perform their related Endpoint functionality and S1 and C1 perform their related Endpoint functionality and forward
forward. the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6 which performs the decapsulation (removing the is bound to End.DT4/6 which performs the decapsulation (removing the
outer IPv6 header with all it's extension headers) and forwards outer IPv6 header with all its extension headers) and forwards toward
towards the data network. the data network.
5.3.2.2. Packet flow - Downlink 5.3.2.2. Packet flow - Downlink
The downlink packet flow is the following: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,SRGW::SA:DA:TEID> <C1, S1,SRGW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red
C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A)
SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A) gNB_out : (Z,A)
When a packet destined to A arrives to the UPF2, the UPF2 performs a When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the associated table to A and finds the SID list <C1, S1, lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::SA:DA:TEID>. The UPF2 performs a T.Encaps.Reduced operation, SRGW::SA:DA:TEID>. The UPF2 performs a T.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives to the SRGW, the SRGW realizes the active SID Once the packet arrives at the SRGW, the SRGW identifies the active
is an End.M.GTP4.E function. The SRGW removes the IPv6 header and SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header
all it's extensions headers. The SRGW generates an IPv4, UDP and GTP and all its extensions headers. The SRGW generates an IPv4, UDP and
headers. The IPv4 SA and DA will the ones received as part of the GTP headers. The IPv4 SA and DA are received as SID arguments. The
SID arguments. The TEID in the generated GTP header is also the TEID in the generated GTP header is also the arguments of the
arguments of the received End.M.GTP4.E SID The SRGW pushes the received End.M.GTP4.E SID. The SRGW pushes the headers to the packet
headers to the packet and forwards the packet towards the gNB. and forwards the packet toward the gNB.
Once the packet arrives to the gNB, the packet is a regular IPv4/GTP When the packet arrives at the gNB, the packet is a regular IPv4/GTP
packet. The gNB looks for the specific radio bearer for that TEID 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 and forward it on the bearer. This gNB behavior is not modified from
current and previous generations. current and previous generations.
5.3.2.3. Scalability 5.3.2.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in For the downlink traffic, the SRGW is stateless. All the state is in
the SRH imposed by the UPF. The UPF must have this UE-base state the SRH inserted by the UPF. The UPF must have this UE-base state
anyway (it is its anchor point). anyway (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per 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 UE/session basis according to an Uplink Classifier. There is state
state for steering the different sessions on a SR policies. Notice for steering the different sessions on a SR policies. However, SR
however that the SR policies are shared among several UE/sessions. policies are shared among several UE/sessions.
5.3.2.4. IPv6 user-traffic 5.3.2.4. IPv6 user-traffic
For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
However based on local policy, a service provider MAY choose to do Based on local policy, a service provider MAY choose to do SRH
SRH insertion. The main benefit is a lower overhead. insertion. The main benefit is a lower overhead.
5.3.3. Extensions to the interworking mechanisms 5.3.3. Extensions to the interworking mechanisms
In this section we presented two mechanisms for interworking with In this section we presented two mechanisms for interworking with
gNBs that do not support SRv6. These mechanism are done to support gNBs that do not support SRv6. These mechanism are done to support
GTP over IPv4 and GTP over IPv6. GTP over IPv4 and GTP over IPv6.
Even though we have presented these methods as an extension to the Even though we have presented these methods as an extension to the
"Enhanced mode", it is straightforward in its applicability to the "Enhanced mode", it is straightforward in its applicability to the
"Traditional mode". "Traditional mode".
Furthermore, although these mechanisms are designed for interworking Furthermore, although these mechanisms are designed for interworking
with legacy RAN at the N3 interface, these methods could also be with legacy RAN at the N3 interface, these methods could also be
applied for interworking with a non-SRv6 capable UPF at the N9 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). interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not).
6. SRv6 SID Mobility Functions 6. SRv6 SID Mobility Functions
6.1. End.MAP: Endpoint function with SID mapping 6.1. Args.Mob.Session
Args.Mob.Session provide per-session information for charging,
buffering and lawful intercept (among others) required by some mobile
nodes. The Args.Mob.Session argument format is used in combination
with End.Map, End.DT and End.DX functions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QFI |R|U| PDU Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDU Sess(cont')|
+-+-+-+-+-+-+-+-+
Args.Mob.Session format
o QFI: QoS Flow Identifier [TS.38415]
o R: Reflective QoS Indication [TS.23501]. This parameter indicates
the activaton of reflective QoS towards the UE for the transfered
packet. Reflective QoS enables the UE to map UL User Plane
traffic to QoS Flows without SMF provided QoS rules.
o U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt.
o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent
is TEID.
Since the SRv6 function is likely NOT to be instantiated per PDU
session, Args.Mob.Session helps the UPF to perform the functions
which require per QFI and/or per PDU Session granularity.
6.2. End.MAP
The "Endpoint function with SID mapping" function (End.MAP for short) The "Endpoint function with SID mapping" function (End.MAP for short)
is used in several scenarios. Particularly in mobility, it is used is used in several scenarios. Particularly in mobility, End.MAP is
in the UPFs for the anchor functionality in some of the use-cases. used in the UPFs for the PDU Session anchor functionality.
When a SR node N receives a packet destined to S and S is a local When a SR node N receives a packet destined to S and S is a local
End.MAP SID, N does: End.MAP SID, N does the following:
1. look up the IPv6 DA in the mapping table 1. look up the IPv6 DA in the mapping table
2. update the IPv6 DA with the new mapped SID ;; Ref1 2. update the IPv6 DA with the new mapped SID ;; Note 1
3. forward according to the new mapped SID 3. IF segment_list > 1
4. ELSE 4. insert a new SRH
5. Drop the packet 5. forward according to the new mapped SID
6. ELSE
7. Drop the packet
Ref1: Note that the SID in the SRH is NOT modified. Note 1: The SID in the SRH is NOT modified.
6.2. End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP 6.3. End.M.GTP6.D
tunnel
The "Endpoint function with IPv6/GTP decapsulation into SR policy" The "Endpoint function with IPv6/GTP decapsulation into SR policy"
function (End.M.GTP6.D for short) is used in interworking scenario 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 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose,
is associated with an SR policy <S1, S2, S3> and an IPv6 Source for example, this SID is associated with an SR policy <S1, S2, S3>
Address A. and an IPv6 Source Address A.
When the SR Gateway node N receives a packet destined to S and S is a When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D SID, N does: local End.M.GTP6.D SID, N does:
1. IF NH=UDP & UDP_PORT = GTP THEN 1. IF NH=UDP & UDP_PORT = GTP THEN
2. pop the IP, UDP and GTP headers 2. pop the IP, UDP and GTP headers
3. push a new IPv6 header with its own SRH <S2, S3> 3. push a new IPv6 header with its own SRH <S2, S3>
4. set the outer IPv6 SA to A 4. set the outer IPv6 SA to A
5. set the outer IPv6 DA to S1 5. set the outer IPv6 DA to S1
6. forward according to the first segment of the SRv6 Policy 6. forward according to the S1 segment of the SRv6 Policy
7. ELSE 7. ELSE
8. Drop the packet 8. Drop the packet
6.3. End.M.GTP6.E: Endpoint function with encapsulation for IPv6/GTP 6.4. End.M.GTP6.E
tunnel
The "Endpoint function with encapsulation for IPv6/GTP tunnel" The "Endpoint function with encapsulation for IPv6/GTP tunnel"
function (End.M.GTP6.E for short) is used in interworking scenario function (End.M.GTP6.E for short) is used in interworking scenario
for the downlink towards the legacy gNB using IPv6/GTP. for the downlink toward the legacy gNB using IPv6/GTP.
The End.M.GTP6.E function has a 32-bit argument space. This argument The End.M.GTP6.E function has a 32-bit argument space which is used
corresponds to the GTP TEID. to provide the GTP TEID.
When the SR Gateway node N receives a packet destined to S and S is a When the SR Gateway node N receives a packet destined to S, and S is
local End.M.GTP6.E SID, N does: a local End.M.GTP6.E SID, N does the following:
1. IF NH=SRH & SL = 1 THEN ;; Ref1 1. IF NH=SRH & SL = 1 THEN ;; Note 1
2. decrement SL 2. decrement SL
3. store SRH[SL] in variable new_DA 3. store SRH[SL] in variable new_DA
4. store TEID in variable new_TEID ;; Ref2 4. store TEID in variable new_TEID ;; Note 2
5. pop IP header and all it's extension headers 5. pop IP header and all its extension headers
6. push new IPv6 header and GTP-U header 6. push new IPv6 header and GTP-U header
7. set IPv6 DA to new_DA 7. set IPv6 DA to new_DA
8. set GTP_TEID to new_TEID 8. set GTP_TEID to new_TEID
9. lookup the new_DA and forward the packet accordingly 9. lookup the new_DA and forward the packet accordingly
10. ELSE 10. ELSE
11. Drop the packet 11. Drop the packet
Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID. Note 1: An End.M.GTP6.E SID MUST always be the penultimate SID.
Ref2: TEID is extracted from the argument space of the current SID. Note 2: TEID is extracted from the argument space of the current SID.
6.4. End.M.GTP4.E: Endpoint function with encapsulation for IPv4/GTP 6.5. End.M.GTP4.E
tunnel
The "Endpoint function with encapsulation for IPv4/GTP tunnel" The "Endpoint function with encapsulation for IPv4/GTP tunnel"
function (End.M.GTP4.UP for short) is used in the downlink when doing function (End.M.GTP4.E for short) is used in the downlink when doing
interworking with legacy gNB using IPv4/GTP. interworking with legacy gNB using IPv4/GTP.
When the SR Gateway node N receives a packet destined to S and S is a When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP4.E SID, N does: local End.M.GTP4.E SID, N does:
1. IF NH=SRH & SL > 0 THEN 1. IF NH=SRH & SL > 0 THEN
2. decrement SL 2. decrement SL
3. update the IPv6 DA with SRH[SL] 3. update the IPv6 DA with SRH[SL]
4. pop the SRH 4. pop the SRH
5. push header of TUN-PROTO with tunnel ID from S ;; Ref1 5. push UDP/GTP headers with tunnel ID from S
6. push outer IPv4 header with SA, DA from S 6. push outer IPv4 header with SA, DA from S
7. ELSE 7. ELSE
8. Drop the packet 8. Drop the packet
Ref1: TUN-PROTO indicates target tunnel type. S has the following format:
Note that S has the following format:
+----------------------+-------+-------+-------+ +----------------------+-------+-------+-------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |
+----------------------+-------+-------+-------+ +----------------------+-------+-------+-------+
128-a-b-c a b c 128-a-b-c a b c
End.M.GTP4.E SID Encoding End.M.GTP4.E SID Encoding
6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation and mapping 6.6. T.M.Tmap
into an SRv6 Policy
The "Transit with tunnel decapsulation and map to an SRv6 policy" The "Transit with tunnel decapsulation and map to an SRv6 policy"
function (T.Tmap for short) is used in the direction from legacy function (T.M.Tmap for short) is used in the direction from legacy
user-plane to SRv6 user-plane network. user-plane to SRv6 user-plane network.
When the SR Gateway node N receives a packet destined to a IW- When the SR Gateway node N receives a packet destined to a IW-
IPv4-Prefix, N does: IPv4-Prefix, N does:
1. IF P.PLOAD == TUN-PROTO THEN ;; Ref1 1. IF Payload == UDP/GTP THEN
2. pop the outer IPv4 header and tunnel headers 2. pop the outer IPv4 header and UDP/GTP headers
3. copy IPv4 DA, SA, TUN-ID to form SID B with SRGW-IPv6-Prefix 3. copy IPv4 DA, SA, TUN-ID to form SID B
4. encapsulate the packet into a new IPv6 header ;; Ref2, Ref2bis 4. encapsulate the packet into a new IPv6 header
5. set the IPv6 DA = B 5. set the IPv6 DA = B
6. forward along the shortest path to B 6. forward along the shortest path to B
7. ELSE 7. ELSE
8. Drop the packet 8. Drop the packet
Ref1: TUN-PROTO indicates target tunnel type. B has the following format:
Note that B has the following format:
+----------------------+-------+-------+-------+ +----------------------+-------+-------+-------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |
+----------------------+-------+-------+-------+ +----------------------+-------+-------+-------+
128-a-b-c a b c 128-a-b-c a b c
End.M.GTP4.E SID Encoding End.M.GTP4.E SID Encoding
Note that the B SID, is going to be an SRv6 BindingSID instantiated The SID B is an SRv6 BindingSID instantiated at the first UPF (U1).
at the first UPF (anchor point). A static format is leveraged to A static format is used for this Binding SIDs in order to remove
instantiate this Binding SIDs in order to remove state from the SRGW. state from the SRGW.
6.6. End.Limit: Rate Limiting function 6.7. End.Limit: Rate Limiting function
Mobile user-plane requires a rate-limit feature. SID is able to The mobile user-plane requires a rate-limit feature. For this
encode limiting rate as an argument in SID. Multiple flows of purpose, we define a new function "End.Limit". The "End.Limit"
packets should have same group identifier in SID when those flows are function encodes in its arguments the rate limiting parameter that
in an same AMBR group. This helps to keep user-plane stateless. should be applied to this packet. Multiple flows of packets should
That enables SRv6 endpoint nodes which are unaware from the mobile have the same group identifier in the SID when those flows are in an
control-plane information. Encoding format of rate limit segment SID same AMBR group. The encoding format of the rate limit segment SID
is following: is as follows:
+----------------------+----------+-----------+ +----------------------+----------+-----------+
| LOC+FUNC rate-limit | group-id | limit-rate| | LOC+FUNC rate-limit | group-id | limit-rate|
+----------------------+----------+-----------+ +----------------------+----------+-----------+
128-i-j i j 128-i-j i j
End.Limit: Rate limiting function argument format End.Limit: Rate limiting function argument format
In case of j bit length is zero in SID, the node should not do rate If the j bit length is zero, the node should not do rate limiting
limiting unless static configuration or control-plane sets the limit unless static configuration or control-plane sets the limit rate
rate associated to the SID. associated to the SID.
7. SRv6 supported PDU session types 7. SRv6 supported 3GPP PDU session types
The 3GPP [TS.23501] defines the following PDU session types: The 3GPP [TS.23501] defines the following PDU session types:
o IPv4 o IPv4
o IPv6 o IPv6
o IPv4v6 o IPv4v6
o Ethernet o Ethernet
o Unstructured o Unstructured
SRv6 supports all the PDU session types without any protocol overhead SRv6 supports all the 3GPP PDU session types without any protocol
by using the corresponding SRv6 functions (End.DX4, End.DT4 for IPv4 overhead by using the corresponding SRv6 functions (End.DX4, End.DT4
PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; End.DT46 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
for IPv4v6 PDU sessions; End.DX2, End.DT2M for L2 PDU sessions; End.DT46 for IPv4v6 PDU sessions; End.DX2, End.DT2M for L2 PDU
End.DX2 for Unstructured PDU sessions). sessions; End.DX2 for Unstructured PDU sessions).
8. Network Slicing Considerations 8. Network Slicing Considerations
A mobile network may be required to implement "network slices", which A mobile network may be required to implement "network slices", which
logically separate network resources. User-plane functions logically separate network resources. User-plane functions
represented as SRv6 segments would be part of a slice. represented as SRv6 segments would be part of a slice.
[I-D.filsfils-spring-segment-routing-policy] describes a solution to [I-D.filsfils-spring-segment-routing-policy] describes a solution to
build basic network slices with SR. Depending on the requirements, build basic network slices with SR. Depending on the requirements,
these slices can be further refined by leveraging the mechanisms these slices can be further refined by adopting the mechanisms from:
from:
o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo] o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo]
o Inter-Domain policies o Inter-Domain policies
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Furthermore, these can be combined with ODN/AS Furthermore, these can be combined with ODN/AS
[I-D.filsfils-spring-segment-routing-policy] for automated slice [I-D.filsfils-spring-segment-routing-policy] for automated slice
provisioning and traffic steering. provisioning and traffic steering.
A separate document will explain in detail how each one of these Further details on how these tools can be used to create end to end
tools is leveraged to build a network slice. network slices are documented in
[I-D.ali-spring-network-slicing-building-blocks].
9. Control Plane Considerations 9. Control Plane Considerations
This documents focuses on the user-plane behavior and it's This document focuses on user-plane behavior and its independence
independent from the control plane. from the control plane.
The control plane could be the current 3GPP-defined control plane The control plane could be the current 3GPP-defined control plane
with slight modifications to the N4 interface [TS.29244]. with slight modifications to the N4 interface [TS.29244].
Alternatively, SRv6 could be used in conjunction with a new mobility Alternatively, SRv6 could be used in conjunction with a new mobility
control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6],
hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA
[I-D.gundavelli-dmm-mfa] or in cunjunction with FPC [I-D.gundavelli-dmm-mfa] or in conjunction with FPC
[I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes
and it's applicability to SRv6 is is out of the scope of this and its applicability to SRv6 is out of the scope of this document.
document.
Note that the IANA section of this document allocates the SRv6 Section 11 allocates SRv6 endpoint function types for the new
endpoint function types for the new functions defined in this functions defined in this document. Control-plane protocols are
document. All control-plane protocols are expected to leverage these expected to use these function type codes to signal each function.
function type-codes to signal each function.
It's notable that SRv6's network programming nature allows a flexible SRv6's network programming nature allows a flexible and dynamic UPF
and dynamic anchor placement. placement.
10. Security Considerations 10. Security Considerations
TBD TBD
11. IANA Considerations 11. IANA Considerations
This I-D requests to IANA to allocate, within the "SRv6 Endpoint IANA is requested to allocate, within the "SRv6 Endpoint Types" sub-
Types" sub-registry belonging to the top-level "Segment-routing with registry belonging to the top-level "Segment-routing with IPv6
IPv6 dataplane (SRv6) Parameters" registry dataplane (SRv6) Parameters" registry
[I-D.filsfils-spring-srv6-network-programming], the following [I-D.filsfils-spring-srv6-network-programming], the following values:
allocations:
+-------------+-----+-------------------+-----------+ +-------------+-----+-------------------+-----------+
| Value/Range | Hex | Endpoint function | Reference | | Value/Range | Hex | Endpoint function | Reference |
+-------------+-----+-------------------+-----------+ +-------------+-----+-------------------+-----------+
| TBA | TBA | End.MAP | [This.ID] | | TBA | TBA | End.MAP | [This.ID] |
| TBA | TBA | End.M.GTP6.D | [This.ID] | | TBA | TBA | End.M.GTP6.D | [This.ID] |
| TBA | TBA | End.M.GTP6.E | [This.ID] | | TBA | TBA | End.M.GTP6.E | [This.ID] |
| TBA | TBA | End.M.GTP4.E | [This.ID] | | TBA | TBA | End.M.GTP4.E | [This.ID] |
| TBA | TBA | End.Limit | [This.ID] | | TBA | TBA | End.Limit | [This.ID] |
+-------------+-----+-------------------+-----------+ +-------------+-----+-------------------+-----------+
Table 1: SRv6 Mobile User-plane Endpoint Types Table 1: SRv6 Mobile User-plane Endpoint Types
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Daisuke Yokota, Bart Peirens, The authors would like to thank Daisuke Yokota, Bart Peirens,
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
Clad, Sridhar Bhaskaran and Arashmid Akhavain for their useful Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
comments of this work. Shekhar and Aeneas Dodd-Noble for their useful comments of this work.
13. Contributors 13. Contributors
Kentaro Ebisawa Kentaro Ebisawa
Ponto Networks Ponto Networks
Japan Japan
Email: ebiken@pontonetworks.com Email: ebiken@pontonetworks.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.filsfils-spring-segment-routing-policy] [I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Hegde, S., Filsfils, C., Sivabalan, S., Hegde, S.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
skipping to change at page 23, line 15 skipping to change at page 24, line 20
[I-D.filsfils-spring-segment-routing-policy] [I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Hegde, S., Filsfils, C., Sivabalan, S., Hegde, S.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
J., Clad, F., and K. Raza, "Segment Routing Policy J., Clad, F., and K. Raza, "Segment Routing Policy
Architecture", draft-filsfils-spring-segment-routing- Architecture", draft-filsfils-spring-segment-routing-
policy-06 (work in progress), May 2018. policy-06 (work in progress), May 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Network Programming", draft-filsfils-spring-srv6-network-
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and programming-05 (work in progress), July 2018.
M. Sharif, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-04 (work in progress),
March 2018.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-14 (work in (SRH)", draft-ietf-6man-segment-routing-header-14 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
draft-xuclad-spring-sr-service-programming-00 (work in
progress), July 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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
14.2. Informative References 14.2. Informative References
[I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., and P. Camarillo, "Building blocks
for Slicing in Segment Routing Network", draft-ali-spring-
network-slicing-building-blocks-00 (work in progress),
July 2018.
[I-D.auge-dmm-hicn-mobility-deployment-options] [I-D.auge-dmm-hicn-mobility-deployment-options]
Auge, J., Carofiglio, G., Muscariello, L., and M. Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn- (hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-00 (work in progress), June mobility-deployment-options-00 (work in progress), June
2018. 2018.
[I-D.camarillo-dmm-srv6-mobile-pocs] [I-D.camarillo-dmm-srv6-mobile-pocs]
Camarillo Garvia, P., Filsfils, C., Bertz, L., Akhavain, Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A.,
A., Matsushima, S., and D. Voyer, "Segment Routing IPv6 Matsushima, S., and d. daniel.voyer@bell.ca, "Segment
for mobile user-plane PoCs", draft-xuclad-spring-sr- Routing IPv6 for mobile user-plane PoCs", draft-camarillo-
service-programming-00 (work in progress), July 2018. dmm-srv6-mobile-pocs-00 (work in progress), July 2018.
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
Camarillo, P., Filsfils, C., Elmalky, H., Allan, D.,
Matsushima, S., daniel.voyer@bell.ca, d., Cui, A., and B.
Peirens, "SRv6 Mobility Use-Cases", draft-
camarilloelmalky-springdmm-srv6-mob-usecases-00 (work in
progress), July 2018.
[I-D.gundavelli-dmm-mfa] [I-D.gundavelli-dmm-mfa]
Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-00 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01
(work in progress), February 2018. (work in progress), September 2018.
[I-D.hegdeppsenak-isis-sr-flex-algo] [I-D.hegdeppsenak-isis-sr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
Segment Routing Flexible Algorithm", draft-hegdeppsenak- Segment Routing Flexible Algorithm", draft-hegdeppsenak-
isis-sr-flex-algo-02 (work in progress), February 2018. 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-12 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12
skipping to change at page 24, line 46 skipping to change at page 26, line 5
Afanasiev, "Segment Routing Centralized BGP Egress Peer Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central- Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017. epe-10 (work in progress), December 2017.
[I-D.rodrigueznatal-lisp-srv6] [I-D.rodrigueznatal-lisp-srv6]
Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
Camarillo, P., and C. Filsfils, "LISP Control Plane for Camarillo, P., and C. Filsfils, "LISP Control Plane for
SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00
(work in progress), July 2018. (work in progress), July 2018.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [I-D.xuclad-spring-sr-service-programming]
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
RFC 5213, DOI 10.17487/RFC5213, August 2008, d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
<https://www.rfc-editor.org/info/rfc5213>. Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service-
[TR.29891] programming-00 (work in progress), July 2018.
3GPP, "5G System - Phase 1 CT WG4 Aspects", 3GPP TR
29.891 15.0.0, December 2017.
[TS.23501] [TS.23501]
3GPP, "System Architecture for the 5G System", 3GPP TS 3GPP, "System Architecture for the 5G System", 3GPP TS
23.501 15.0.0, November 2017. 23.501 15.0.0, November 2017.
[TS.29244] [TS.29244]
3GPP, "Interface between the Control Plane and the User 3GPP, "Interface between the Control Plane and the User
Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 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 15.1.0, Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
December 2017. December 2017.
[TS.38415]
3GPP, "Draft Specification for 5GS container (TS 38.415)",
3GPP R3-174510 0.0.0, August 2017.
Appendix A. Implementations Appendix A. Implementations
This I-D introduces new SRv6 functions. These functions have an This document introduces new SRv6 functions. These functions have an
open-source P4 implementation available in open-source P4 implementation available in
<https://github.com/ebiken/p4srv6>. <https://github.com/ebiken/p4srv6>.
Additionally, there are ongoing PoC efforts in M-CORD NGIC and Open There are also implementations in M-CORD NGIC and Open Air Interface
Air Interface (OAI). Progress and results can be found in (OAI). Further details can be found in
[I-D.camarillo-dmm-srv6-mobile-pocs]. [I-D.camarillo-dmm-srv6-mobile-pocs].
Appendix B. Changes from revision 02 to revision 03
This section lists the changes between draft-ietf-dmm-srv6-mobile-
uplane revisions ...-02 and ...-03.
o Added new terminology section for abbreviations.
o Added new terminology section for predefined SRv6 functions.
o Made terminology section for conventions used in the document.
o Renamed "Basic" mode to be called "Traditional" mode.
o Renamed "Aggregate" mode to be called "Enhanced" mode.
o Added new Args.Mob.Session format to supply QFI, RQI indication
and PDU Session ID.
o Modified End.MAP function to define the SID argument format and
support more than one SID
o Added missing references.
o Editorial updates to improve readability.
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
Clarence Filsfils Clarence Filsfils
 End of changes. 161 change blocks. 
505 lines changed or deleted 567 lines changed or added

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