draft-ietf-dmm-srv6-mobile-uplane-01.txt   draft-ietf-dmm-srv6-mobile-uplane-02.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: September 6, 2018 M. Kohno Expires: January 3, 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
March 5, 2018 July 2, 2018
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-01 draft-ietf-dmm-srv6-mobile-uplane-02
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. The source routing IPv6) to user-plane of mobile networks (N3 and N9 interfaces). The
capability and the network programming nature of SRv6, accomplish source routing capability and the network programming nature of SRv6,
mobile user-plane functions in a simple manner. The statelessness accomplish mobile user-plane functions in a simple manner. The
and the ability to control underlying layer will be even more statelessness and the ability to control underlying layer will be
beneficial to the mobile user-plane, in terms of providing even more beneficial to the mobile user-plane, in terms of providing
flexibility and SLA control for various applications. It also flexibility and SLA control for various applications. It also
simplifies the network architecture by eliminating the necessity of simplifies the network architecture by eliminating the necessity of
tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS, tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
and so on. In addition, Segment Routing provides an enhanced method and so on. In addition, Segment Routing provides an enhanced method
for network slicing, which is briefly introduced by this document. 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 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 September 6, 2018. This Internet-Draft will expire on January 3, 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
(http://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 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 5 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 5
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6
5.1. Traditional mode (formerly Basic mode) . . . . . . . . . 6 5.1. Traditional mode (formerly Basic mode) . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 7 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 8
5.2. Enhanced Mode (formerly Aggregate mode) . . . . . . . . . 8 5.2. Enhanced Mode (formerly Aggregate mode) . . . . . . . . . 8
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 9 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 10
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 10 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 . . . . . . . . . . . . . 11
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14
5.3.3. Extensions to the interworking mechanisms . . . . . . 16 5.3.3. Extensions to the interworking mechanisms . . . . . . 17
6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17
6.1. End.MAP: Endpoint function with SID mapping . . . . . . . 17 6.1. End.MAP: Endpoint function with SID mapping . . . . . . . 17
6.2. End.M.GTP6.D: Endpoint function with decapsulation from 6.2. End.M.GTP6.D: Endpoint function with decapsulation from
IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 17 IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 17
6.3. End.M.GTP6.E: Endpoint function with encapsulation for 6.3. End.M.GTP6.E: Endpoint function with encapsulation for
IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18 IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18
6.4. End.M.GTP4.E: Endpoint function with encapsulation for 6.4. End.M.GTP4.E: Endpoint function with encapsulation for
IPv4/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18 IPv4/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18
6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation 6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation
and mapping into an SRv6 Policy . . . . . . . . . . . . . 19 and mapping into an SRv6 Policy . . . . . . . . . . . . . 19
6.6. End.Limit: Rate Limiting function . . . . . . . . . . . . 20 6.6. End.Limit: Rate Limiting function . . . . . . . . . . . . 20
7. Network Slicing Considerations . . . . . . . . . . . . . . . 20 7. SRv6 supported PDU session types . . . . . . . . . . . . . . 20
8. Control Plane Considerations . . . . . . . . . . . . . . . . 20 8. Network Slicing Considerations . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Control Plane Considerations . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . 23
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 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
skipping to change at page 5, line 6 skipping to change at page 5, line 12
rigidness make it difficult for the operator to optimize and operate rigidness make it difficult for the operator to optimize and operate
the data-path. the data-path.
While the mobile network industry has been trying to solve those While the mobile network industry has been trying to solve those
problems, 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 as well. operators have started adopting IPv6 as their IP transport as well.
SRv6, the IPv6 instantiation of Segment Routing SRv6, the IPv6 instantiation of Segment Routing
[I-D.ietf-spring-segment-routing], integrates both the application [I-D.ietf-spring-segment-routing], integrates both the application
data-path and the underlying transport layer into one single data-path and the underlying transport layer into one single
protocol, allowing operators to optimize the network in a simplified protocol, allowing operators to optimize the network in a simplified
manner and removing state from the network. manner and removing forwarding state from the network.
Further on, SRv6 introduces the notion of network-programming Further on, SRv6 introduces the notion of network-programming
[I-D.filsfils-spring-srv6-network-programming], that applied to [I-D.filsfils-spring-srv6-network-programming], that applied to
mobility fulfils the user-plane functions of mobility management. mobility fulfils the user-plane functions of mobility management.
SRv6 takes advantage of underlying transport awareness and SRv6 takes advantage of underlying transport awareness and
flexibility to deploy mobility user-plane functions in an optimized flexibility to deploy mobility user-plane functions in an optimized
manner. Those are the motivations to adopt SRv6 for mobile user- manner. Those are the motivations to adopt SRv6 for mobile user-
plane. plane.
4. Reference Architecture 4. Reference Architecture
skipping to change at page 8, line 11 skipping to change at page 8, line 15
Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT
function. UPF2 decapsulates the packet, performs a lookup in a function. UPF2 decapsulates the packet, performs a lookup in a
specific table and forwards the packet towards the data network. specific table and forwards the packet towards the data network.
5.1.2. Packet flow - Downlink 5.1.2. Packet flow - Downlink
The downlink packet flow is the following: The downlink packet flow is the following:
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.Reduced <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 to the UPF2, the UPF2 will map that
particular flow into a UE session. This UE session is associated particular flow into a UE session. This UE session is associated
with the policy <U1::1>. The UPF2 performs a T.Encaps.Reduced with the policy <U1::1>. The UPF2 performs a T.Encaps.Reduced
operation, encapsulating the packet into a new IPv6 header with no operation, encapsulating the packet into a new IPv6 header with no
SRH since there is only one SID. SRH since there is only one 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 with the next anchoring point
skipping to change at page 8, line 42 skipping to change at page 8, line 46
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 (formerly Aggregate mode)
This mode improves the scalability. In addition, it provides key This mode improves the scalability. In addition, it provides key
improvements in terms of traffic steering and service chaining, improvements in terms of traffic steering and service programming
thanks to the use of an SR policy of multiple SIDs, instead of single [I-D.xuclad-spring-sr-service-programming] , thanks to the use of an
one in the Traditional mode. SR policy of multiple SIDs, instead of single one in the Traditional
mode.
Key points: Key points:
o Several UE share the same SR Policy (and it's composing SID) o Several UE share the same SR Policy (and it's composing SID)
o The SR policy MAY include SIDs for traffic engineering and service o The SR policy MAY include SIDs for traffic engineering and service
chaining on top of the UPF anchor. programming on top of the UPF anchor.
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 through 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 Our reference topology is shown in Figure 3. In this mode we assume
that the gNB and the UPF are SR-aware. We also assume that we have that the gNB and the UPF are SR-aware. We also assume that we have
skipping to change at page 9, line 29 skipping to change at page 9, line 33
+----+ 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
NFV VNF
Figure 3: Enhanced mode - Reference topology Figure 3: Enhanced mode - Reference 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 the following:
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 session to its gNB.
gNB's CP associates that session from the UE(A) with the IPv6 address gNB's CP associates that session from the UE(A) with the IPv6 address
B and GTP TEID T. gNB's CP does a lookup on B (by reverseDNS, LISP, B and GTP TEID T. gNB's CP does a lookup on B (by reverseDNS, LISP,
etc.) to find the related SID list <S1, C1, U2::1>. etc.) to find the related SID list <S1, C1, U2::1>.
Once the packet leaves the gNB, it already contains all the segments Once the packet leaves the gNB, it already contains all the segments
of the SR policy. This SR policy contains segments for traffic of the SR policy. This SR policy contains segments for traffic
engineering (C1) and for service chaining (S1). engineering (C1) and for service programming (S1).
The nodes S1 and C1 perform their related Endpoint functionality and The nodes S1 and C1 perform their related Endpoint functionality and
forward. forward.
When the packet arrives to UPF2, the active segment (U2::1) is an When the packet arrives to 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 it's extension headers) and forward towards the data
network. network.
Note that in case several APNs are using duplicated IPv4 private Note that in case several APNs are using duplicated IPv4 private
skipping to change at page 12, line 13 skipping to change at page 12, line 18
that is going to map the 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 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 represents a VNF in the network, and C1 represents a router over
which we are going to perform Traffic Engineering. which we are going to perform Traffic Engineering.
+----+ +----+
IPv6/GTP -| S1 |- ___ IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ NFV -| 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 the following:
skipping to change at page 12, line 48 skipping to change at page 13, line 4
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
instantiated at the SRGW. Hence the packet, will be routed up to the instantiated at the SRGW. Hence the packet, will be routed up 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 realises that B is an
End.M.GTP6.D BindingSID. Hence, the SRGW will remove the IPv6, UDP 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 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 containing the SIDs bound to the SR policy associated with this
BindingSID. BindingSID. Note that there will be one instance of the End.M.GTP6.D
SID per PDU type.
The nodes S1 and C1 perform their related Endpoint functionality and The nodes S1 and C1 perform their related Endpoint functionality and
forward. forward.
When the packet arrives to UPF2, the active segment is (U2::1) which When the packet arrives to UPF2, the active segment is (U2::1) which
bound to End.DT4/6 which is going to perform the decapsulation bound to End.DT4/6 which is going to perform the decapsulation
(removing the outer IPv6 header with all it's extension headers) and (removing the outer IPv6 header with all it's extension headers) and
forward towards the data network. forward towards the data network.
5.3.1.2. Packet flow - Downlink 5.3.1.2. Packet flow - Downlink
skipping to change at page 13, line 36 skipping to change at page 13, line 41
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 to the SRGW, the SRGW realizes the active SID
is an End.M.GTP6.E function. The SRGW removes the IPv6 header and is an End.M.GTP6.E function. The SRGW removes the IPv6 header and
all it's extensions headers. The SRGW generates an IPv6, UDP and GTP all it's extensions headers. The SRGW generates an IPv6, UDP and GTP
headers. The new IPv6 DA is the gNB which is the last SID in the 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 the arguments
of the received End.M.GTP6.E SID. The SRGW pushes the headers to the of the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet towards the gNB. packet and forwards the packet towards the gNB. Note that there will
be one instance 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 to 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 imposed by the UPF2. The UPF2 must have the UE states as the
skipping to change at page 14, line 41 skipping to change at page 15, line 9
that is going to map 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 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 represents a VNF in the network, and C1 represents a router over
which we are going to perform Traffic Engineering. which we are going to perform Traffic Engineering.
+----+ +----+
IPv4/GTP -| S1 |- ___ IPv4/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ NFV -| 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 the following:
skipping to change at page 17, line 20 skipping to change at page 17, line 39
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, it is used
in the UPFs for the anchor functionality in some of the use-cases. in the UPFs for the anchor functionality in some of the use-cases.
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:
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 ;; Ref1
5. forward according to the new mapped SID 3. forward according to the new mapped SID
8. ELSE 4. ELSE
9. Drop the packet 5. Drop the packet
Ref1: Note that the SID in the SRH is NOT modified. Ref1: Note that the SID in the SRH is NOT modified.
6.2. End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP 6.2. End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP
tunnel 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 towards from the legacy gNB using IPv6/GTP. This SID
is associated with an SR policy <S1, S2, S3> and an IPv6 Source is associated with an SR policy <S1, S2, S3> and an IPv6 Source
skipping to change at page 18, line 48 skipping to change at page 19, line 12
function (End.M.GTP4.UP for short) is used in the downlink when doing function (End.M.GTP4.UP 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
4. push header of TUN-PROTO with tunnel ID from S ;; Ref1 5. push header of TUN-PROTO with tunnel ID from S ;; Ref1
5. push outer IPv4 header with SA, DA from S 6. push outer IPv4 header with SA, DA from S
6. ELSE 7. ELSE
7. Drop the packet 8. Drop the packet
Ref1: TUN-PROTO indicates target tunnel type. Ref1: TUN-PROTO indicates target tunnel type.
Note that 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
skipping to change at page 20, line 26 skipping to change at page 20, line 37
| 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 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 limiting unless static configuration or control-plane sets the limit
rate associated to the SID. rate associated to the SID.
7. Network Slicing Considerations 7. SRv6 supported PDU session types
The 3GPP [TS.23501] defines the following PDU session types:
o IPv4
o IPv6
o IPv4v6
o Ethernet
o Unstructured
SRv6 supports all the PDU session types without any protocol overhead
by using the corresponding SRv6 functions (End.DX4, End.DT4 for IPv4
PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; End.DT46
for IPv4v6 PDU sessions; End.DX2, End.DT2M for L2 PDU sessions;
End.DX2 for Unstructured PDU sessions).
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.
A simple way to represent slice would be to apply L2/L3 VPN described [I-D.filsfils-spring-segment-routing-policy] describes a solution to
in [I-D.filsfils-spring-srv6-network-programming]. Segment Routing build basic network slices with SR. Depending on the requirements,
with [I-D.hegdeppsenak-isis-sr-flex-algo] provides even more advanced these slices can be further refined by leveraging the mechanisms
separation based on metrics like link-delay. Thus, a service from:
provider would be able to have network slices per required SLA.
The SRv6 SID and quite a few SR extended capability would be a o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo]
powerful tool for providing logical separation/integration within a o Inter-Domain policies
network. Details are for further study. [I-D.ietf-spring-segment-routing-central-epe]
8. Control Plane Considerations Furthermore, these can be combined with ODN/AS
[I-D.filsfils-spring-segment-routing-policy] for automated slice
provisioning and traffic steering.
This documents focuses on the dataplane behavior. The control planes A separate document will explain in detail how each one of these
could be based on the existing 3GPP based signalling for N4 interface tools is leveraged to build a network slice.
[TS.29244], [I-D.ietf-dmm-fpc-cpdp], control-plane protocols
described in [WHITEPAPER-5G-UP], etc. and to be discussed further. 9. Control Plane Considerations
This documents focuses on the user-plane behavior and it's
independent from the control plane.
The control plane could be the current 3GPP-defined control plane
with slight modifications to the N4 interface [TS.29244].
Alternatively, SRv6 could be used in conjunction with a new mobility
control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6],
hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA
[I-D.gundavelli-dmm-mfa] or in cunjunction with FPC
[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
document.
Note that the IANA section of this document allocates the SRv6 Note that the IANA section of this document allocates the SRv6
endpoint function types for the new functions defined in this endpoint function types for the new functions defined in this
document. All control-plane protocols are expected to leverage these document. All control-plane protocols are expected to leverage 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 It's notable that SRv6's network programming nature allows a flexible
and dynamic anchor placement. and dynamic anchor placement.
9. Security Considerations 10. Security Considerations
TBD TBD
10. IANA Considerations 11. IANA Considerations
This I-D requests to IANA to allocate, within the "SRv6 Endpoint This I-D requests to IANA to allocate, within the "SRv6 Endpoint
Types" sub-registry belonging to the top-level "Segment-routing with Types" sub-registry belonging to the top-level "Segment-routing with
IPv6 dataplane (SRv6) Parameters" registry IPv6 dataplane (SRv6) Parameters" registry
[I-D.filsfils-spring-srv6-network-programming], the following [I-D.filsfils-spring-srv6-network-programming], the following
allocations: 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
11. 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 and Darren Dukes for Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
their useful comments of this work. Clad, Sridhar Bhaskaran and Arashmid Akhavain for their useful
comments of this work.
12. References 13. Contributors
12.1. Normative References Kentaro Ebisawa
Ponto Networks
Japan
Email: ebiken@pontonetworks.com
14. References
14.1. Normative References
[I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Hegde, S.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
J., Clad, F., and K. Raza, "Segment Routing Policy
Architecture", draft-filsfils-spring-segment-routing-
policy-06 (work in progress), May 2018.
[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., Li, Z., 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., and
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., M. Sharif, "SRv6 Network Programming", draft-filsfils-
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. spring-srv6-network-programming-04 (work in progress),
Camarillo, "SRv6 Network Programming", draft-filsfils- March 2018.
spring-srv6-network-programming-03 (work in progress),
December 2017. [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-14 (work in
progress), June 2018.
[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-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. 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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References 14.2. Informative References
[I-D.auge-dmm-hicn-mobility-deployment-options]
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-00 (work in progress), June
2018.
[I-D.camarillo-dmm-srv6-mobile-pocs]
Camarillo Garvia, P., Filsfils, C., Bertz, L., Akhavain,
A., Matsushima, S., and D. Voyer, "Segment Routing IPv6
for mobile user-plane PoCs", draft-xuclad-spring-sr-
service-programming-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-00
(work in progress), February 2018. (work in progress), February 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-09 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12
(work in progress), October 2017. (work in progress), June 2018.
[I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017.
[I-D.rodrigueznatal-lisp-srv6]
Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
Camarillo, P., and C. Filsfils, "LISP Control Plane for
SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00
(work in progress), July 2018.
[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>.
[TR.29891]
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.
Appendix A. Implementations
This I-D introduces new SRv6 functions. These functions have an
open-source P4 implementation available in
<https://github.com/ebiken/p4srv6>.
Additionally, there are ongoing PoC efforts in M-CORD NGIC and Open
Air Interface (OAI). Progress and results can be found in
[I-D.camarillo-dmm-srv6-mobile-pocs].
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. 45 change blocks. 
78 lines changed or deleted 184 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/