< draft-ietf-dmm-srv6-mobile-uplane-04.txt   draft-ietf-dmm-srv6-mobile-uplane-05.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 12, 2019 M. Kohno Expires: January 9, 2020 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 11, 2019 July 8, 2019
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-04 draft-ietf-dmm-srv6-mobile-uplane-05
Abstract Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
to the user-plane of mobile networks. The network programming nature to the user-plane of mobile networks. The network programming nature
of SRv6 accomplish mobile user-plane functions in a simple manner. of SRv6 accomplish mobile user-plane functions in a simple manner.
The statelessness of SRv6 and its ability to control both service The statelessness of SRv6 and its ability to control both service
layer path and underlying transport can be beneficial to the mobile layer path and underlying transport can be beneficial to the mobile
user-plane, providing flexibility and SLA control for various user-plane, providing flexibility, end-to-end network slicing and SLA
applications. This document describes the SRv6 mobile user plane control for various applications. This document describes the SRv6
behavior and defines the SID functions for that. mobile user plane behavior and defines the SID functions for that.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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 . . . . . . . . . . . . . 12 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 18 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19
6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19 6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19
6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20 6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20
6.6. T.M.Tmap . . . . . . . . . . . . . . . . . . . . . . . . 20 6.6. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 21
6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21 6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 22
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22
8. Network Slicing Considerations . . . . . . . . . . . . . . . 22 8. Network Slicing Considerations . . . . . . . . . . . . . . . 23
9. Control Plane Considerations . . . . . . . . . . . . . . . . 22 9. Control Plane Considerations . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 27
Appendix B. Changes from revision 02 to revision 03 . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
In mobile networks, mobility management systems provide connectivity In mobile networks, mobility management systems provide connectivity
while mobile nodes move. While the control-plane of the system while mobile nodes move. While the control-plane of the system
signals movements of a mobile node, the user-plane establishes a signals movements of a mobile node, the user-plane establishes a
tunnel between the mobile node and its anchor node over IP-based tunnel between the mobile node and its anchor node over IP-based
backhaul and core networks. backhaul and core networks.
skipping to change at page 4, line 48 skipping to change at page 4, line 47
detailed behavior, the (S3, S2, S1; SL) notation is more detailed behavior, the (S3, S2, S1; SL) notation is more
convenient. convenient.
o SRH[SL] represents the SID pointed by the SL field in the first 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 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2
and SRH[0] represents S3. and SRH[0] represents S3.
o SRH[SL] can be different from the DA of the IPv6 header. o SRH[SL] can be different from the DA of the IPv6 header.
2.3. Predefined SRv6 Functions 2.3. Predefined SRv6 Functions
The following functions are defined in The following functions are defined in
[I-D.filsfils-spring-srv6-network-programming]. [I-D.ietf-spring-srv6-network-programming].
o End.DT4 means to decapsulate and forward using a specific IPv4 o End.DT4 means to decapsulate and forward using a specific IPv4
table lookup. table lookup.
o End.DT6 means to decapsulate and forward using a specific IPv6 o End.DT6 means to decapsulate and forward using a specific IPv6
table lookup. table lookup.
o End.DX4 means to decapsulate the packet and forward through a o End.DX4 means to decapsulate the packet and forward through a
particular outgoing interface -or set of OIFs- configured with the particular outgoing interface -or set of OIFs- configured with the
SID. SID.
o End.DX6 means to decapsulate and forward through a particular o End.DX6 means to decapsulate and forward through a particular
skipping to change at page 5, line 49 skipping to change at page 5, line 49
In the meantime, applications have shifted to use IPv6, and network In the meantime, 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. SRv6,
the IPv6 dataplane instantiation of Segment Routing [RFC8402], the IPv6 dataplane instantiation of Segment Routing [RFC8402],
integrates both the application data-path and the underlying integrates both the application data-path and the underlying
transport layer into a single protocol, allowing operators to transport layer into a single protocol, allowing operators to
optimize the network in a simplified manner and removing forwarding optimize the network in a simplified manner and removing forwarding
state from the network. It is also suitable for virtualized state from the network. It is also suitable for virtualized
environments, VNF/CNF to VNF/CNF networking. environments, VNF/CNF to VNF/CNF networking.
SRv6 specifies network-programming (see SRv6 specifies network-programming (see
[I-D.filsfils-spring-srv6-network-programming]). Applied to [I-D.ietf-spring-srv6-network-programming]). Applied to mobility,
mobility, SRv6 can provide the user-plane functions needed for SRv6 can provide the user-plane functions needed for mobility
mobility management. SRv6 takes advantage of underlying transport management. SRv6 takes advantage of underlying transport awareness
awareness and flexibility to improve mobility user-plane functions. and flexibility to improve mobility user-plane functions.
The use-cases for SRv6 mobility are discussed in The use-cases for SRv6 mobility are discussed in
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. [I-D.camarilloelmalky-springdmm-srv6-mob-usecases].
4. A 3GPP Reference Architecture 4. A 3GPP Reference Architecture
This section presents a reference architecture and possible This section presents a reference architecture and possible
deployment scenarios. deployment scenarios.
Figure 1 shows a reference diagram from the 5G packet core Figure 1 shows a reference diagram from the 5G packet core
skipping to change at page 7, line 35 skipping to change at page 7, line 35
We introduce two mechanisms for interworking with legacy access We introduce two mechanisms for interworking with legacy access
networks (N3 interface is unmodified). In these document we networks (N3 interface is unmodified). In these document we
introduce them applied to the Enhanced mode, although they could be introduce them applied to the Enhanced mode, although they could be
used in combination with the Traditional mode as well. used in combination with the Traditional mode as well.
One of these mechanisms is designed to interwork with legacy gNBs One of these mechanisms is designed to interwork with legacy gNBs
using GTP/IPv4. The second method is designed to interwork with using GTP/IPv4. The second method is designed to interwork with
legacy gNBs using GTP/IPv6. legacy gNBs using GTP/IPv6.
This document uses SRv6 functions defined in This document uses SRv6 functions defined in
[I-D.filsfils-spring-srv6-network-programming] as well as new SRv6 [I-D.ietf-spring-srv6-network-programming] as well as new SRv6
functions designed for the mobile user plane. The new SRv6 functions functions designed for the mobile user plane. The new SRv6 functions
are detailed in Section 6. are detailed in Section 6.
5.1. Traditional mode 5.1. Traditional mode
In the traditional mode, the existing mobile UPFs remain unchanged 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 except for the use of SRv6 as the data plane instead of GTP-U. There
is no impact to the rest of mobile system. is no impact to the rest of mobile system.
In existing 3GPP mobile networks, an UE session is mapped 1-for-1 In existing 3GPP mobile networks, an UE PDU Session is mapped 1-for-1
with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored
here to replace GTP encapsulation with the SRv6 encapsulation, while here to replace GTP encapsulation with the SRv6 encapsulation, while
not changing anything else. There will be a unique SRv6 SID not changing anything else. There will be a unique SRv6 SID
associated with each UE session. associated with each UE PDU Session.
The traditional mode minimizes the changes required to the mobile The traditional mode minimizes the changes required to the mobile
system; it is a good starting point for forming a common basis. system; it is a good starting point for forming a common basis.
Our example topology is shown in Figure 2. In traditional mode the Our example topology is shown in Figure 2. In traditional mode the
gNB and the UPFs are SR-aware. In the descriptions of the uplink and 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 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 IPv6 address reachable within the Data Network DN. A new SRv6
function End.MAP, defined in Section 6.2, is used. function End.MAP, defined in Section 6.2, is used.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
5.1.2. Packet flow - Downlink 5.1.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) UPF2_in : (Z,A)
UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red <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 at the UPF2, the UPF2 maps that flow into a When the packet arrives at the UPF2, the UPF2 maps that flow into a
UE session. This UE session is associated with the segment endpoint UE PDU Session. This UE PDU Session is associated with the segment
<U1::1>. UPF2 performs a T.Encaps.Red operation, encapsulating the endpoint <U1::1>. UPF2 performs a T.Encaps.Red operation,
packet into a new IPv6 header with no SRH since there is only one encapsulating the packet into a new IPv6 header with no SRH since
SID. 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 to the next anchoring point and function. This function maps the SID to the next anchoring point and
replaces U1::1 by gNB::1, that belongs to the next hop. replaces U1::1 by gNB::1, that belongs to the next hop.
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
or End.DX6 function. The gNB decapsulates the packet, removing the or End.DX6 function. The gNB decapsulates the packet, removing the
IPv6 header and all its extensions headers, and forwards the traffic IPv6 header and all its extensions headers, and forwards the traffic
toward 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 [I-D.voyer-6man-extension-header-insertion] . The main SRH insertion. The main benefit is a lower overhead(40B less). In
benefit is a lower overhead (40B less). In such case, the functions such case, the functions used are T.Insert.Red at gNB, End.MAP at
used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T at UPF2 on UPF1 and End.T at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at
Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at gNB on UPF1 and End.X at gNB on Downlink.
Downlink.
5.2. Enhanced Mode 5.2. Enhanced Mode
Enhanced mode improves scalability, traffic steering and service Enhanced mode improves scalability, traffic steering and service
programming [I-D.xuclad-spring-sr-service-programming], thanks to the programming [I-D.xuclad-spring-sr-service-programming], thanks to the
use of multiple SIDs, instead of a single SID as done in the use of multiple SIDs, instead of a single SID as done in the
Traditional mode. Traditional mode.
The main difference is that the SR policy MAY include SIDs for The main difference is that the SR policy MAY include SIDs for
traffic engineering and service programming in addition to the UPFs traffic engineering and service programming in addition to the UPFs
skipping to change at page 11, line 17 skipping to change at page 11, line 17
The downlink packet flow is as follows: 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 at the UPF2, the UPF2 maps that particular When the packet arrives at the UPF2, the UPF2 maps that particular
flow into a UE session. This UE session is associated with the flow into a UE PDU Session. This UE PDU Session is associated with
policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Red operation, the policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Red
encapsulating the packet into a new IPv6 header with its operation, 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 at 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
decapsulates the packet, removing the IPv6 header and all its decapsulates the packet, removing the IPv6 header and all its
extensions headers and forwards the traffic toward the UE. extensions headers and forwards the traffic toward the UE.
5.2.3. IPv6 user-traffic 5.2.3. IPv6 user-traffic
skipping to change at page 13, line 36 skipping to change at page 13, line 36
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 toward 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 IPv6, UDP and GTP headers. The IPv6 DA B, and the the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and 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 at the PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the
SRGW. Hence the packet is routed to the SRGW. SRGW. Hence the packet is routed to the SRGW.
When the packet arrives at the SRGW, the SRGW identifies B as an When the packet arrives at the SRGW, the SRGW identifies B as an
End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes
the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own
SRH containing the SIDs bound to the SR policy associated with this SRH containing the SIDs bound to the SR policy associated with this
BindingSID. There is one instance of the End.M.GTP6.D SID per PDU BindingSID. There is one instance of the End.M.GTP6.D SID per PDU
type. type.
S1 and C1 perform their related Endpoint functionality and forward S1 and C1 perform their related Endpoint functionality and forward
skipping to change at page 14, line 46 skipping to change at page 14, line 46
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 inserted by the UPF2. The UPF2 must have the UE states since the SRH inserted by the UPF2. The UPF2 must have the UE states since
it is the UE's 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 unique per UE session; the state state can be shared among need to be unique per UE PDU Session; the state state can be shared
UEs. This enables much more scalable SRGW deployments compared to a among UEs. This enables much more scalable SRGW deployments compared
solution holding millions of states, one or more per UE. to a solution holding millions of states, one or more per UE.
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 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 the gNB uses GTP over IPv4 in the N3 In this interworking mode the gNB uses GTP over IPv4 in the N3
skipping to change at page 16, line 5 skipping to change at page 16, line 5
-| 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 as follows: 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.GTP4.D 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 toward 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 at the SRGW for UPF1, the SRGW has an Uplink When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
Classifier rule for incoming traffic from the gNB, that steers the Classifier rule for incoming traffic from the gNB, that steers the
traffic into an SR policy by using the function T.M.TMap. The SRGW traffic into an SR policy by using the function T.M.GTP4.D. The SRGW
removes the IPv4, UDP and GTP headers and pushes an IPv6 header with removes the IPv4, UDP and GTP headers and pushes an IPv6 header with
its own SRH containing the SIDs related to the SR policy associated its own SRH containing the SIDs related to the SR policy associated
with this traffic. The SRGW forwards according to the new IPv6 DA. with this traffic. The SRGW forwards according to the new IPv6 DA.
S1 and C1 perform their related Endpoint functionality and forward S1 and C1 perform their related Endpoint functionality and forward
the packet. 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 its extension headers) and forwards toward outer IPv6 header with all its extension headers) and forwards toward
skipping to change at page 19, line 5 skipping to change at page 19, line 5
6.2. End.MAP 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, End.MAP is is used in several scenarios. Particularly in mobility, End.MAP is
used in the UPFs for the PDU Session anchor functionality. 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 the following: End.MAP SID, N does the following:
1. look up the IPv6 DA in the mapping table 1. Lookup the IPv6 DA in the mapping table
2. update the IPv6 DA with the new mapped SID ;; Note 1 2. update the IPv6 DA with the new mapped SID ;; Ref1
3. IF segment_list > 1 3. IF segment_list > 1
4. insert a new SRH 4. insert a new SRH
5. forward according to the new mapped SID 5. forward according to the new mapped SID
6. ELSE
7. Drop the packet
Note 1: The SID in the SRH is NOT modified. Ref1: The SIDs in the SRH are NOT modified.
6.3. End.M.GTP6.D 6.3. End.M.GTP6.D
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 toward from the legacy gNB using IPv6/GTP. Suppose, for the uplink toward from the legacy gNB using IPv6/GTP. Suppose,
for example, this SID is associated with an SR policy <S1, S2, S3> for example, this SID is associated with an SR policy <S1, S2, S3>
and an IPv6 Source 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_DST_PORT = GTP THEN
2. pop the IPv6, UDP and GTP headers 2. copy TEID to form SID S3
3. push a new IPv6 header with its own SRH <S2, S3> 3. pop the IPv6, UDP and GTP headers
4. set the outer IPv6 SA to A 4. push a new IPv6 header with a SR policy in SRH <S1, S2, S3>
5. set the outer IPv6 DA to S1 5. set the outer IPv6 SA to A
6. forward according to the S1 segment of the SRv6 Policy 6. set the outer IPv6 DA to S1
7. ELSE 7. set the outer IPv6 NH ;; Ref1
8. Drop the packet 8. forward according to the S1 segment of the SRv6 Policy
9. ELSE
10. Drop the packet
Ref1: The NH is set based on the SID parameter. There is one
instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
NH is already known in advance. For the IPv4v6 PDU Session Type, in
addition we inspect the first nibble of the PDU to know the NH value.
The prefix of last segment(S3 in above example) SHOULD be followed by
an Arg.Mob.Session argument space which is used to provide the
session identifiers.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway.
6.4. End.M.GTP6.E 6.4. End.M.GTP6.E
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 toward 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 which is used The prefix of End.M.GTP6.E SID MUST be followed by the
to provide the GTP TEID. Arg.Mob.Session argument space which is used to provide the session
identifiers.
When the SR Gateway node N receives a packet destined to S, and S is When the SR Gateway node N receives a packet destined to S, and S is
a local End.M.GTP6.E SID, N does the following: a local End.M.GTP6.E SID, N does the following:
1. IF NH=SRH & SL = 1 THEN ;; Note 1 1. IF NH=SRH & SL = 1 THEN ;; Ref1
2. decrement SL 2. store SRH[0] in variable new_DA
3. store SRH[SL] in variable new_DA 3. store TEID in variable new_TEID from IPv6 DA ;; Ref2
4. store TEID in variable new_TEID ;; Note 2 4. pop IP header and all its extension headers
5. pop IP header and all its extension headers 5. push new IPv6 header and GTP-U header
6. push new IPv6 header and GTP-U header 6. set IPv6 DA to new_DA
7. set IPv6 DA to new_DA 7. set IPv6 SA to A
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
Note 1: An End.M.GTP6.E SID MUST always be the penultimate SID. Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID.
Note 2: TEID is extracted from the argument space of the current SID. Ref2: TEID is extracted from the argument space of the current SID.
The source address A SHOULD be an End.M.GTP6.D SID instantiated at an
SR gateway.
6.5. End.M.GTP4.E 6.5. End.M.GTP4.E
The "Endpoint function with encapsulation for IPv4/GTP tunnel" The "Endpoint function with encapsulation for IPv4/GTP tunnel"
function (End.M.GTP4.E 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 and SL = 0) or ENH=4 THEN
2. store SRH[0] in buffer S 2. store IPv6 DA in buffer S
3. pop the IPv6 header and its extension headers 3. store IPv6 SA in buffer S'
4. push UDP/GTP headers with GTP TEID from S 4. pop the IPv6 header and its extension headers
5. push outer IPv4 header with SA, DA from S 5. push UDP/GTP headers with GTP TEID from S
6. ELSE 6. push outer IPv4 header with SA, DA from S' and S
7. Drop the packet 7. ELSE
8. Drop the packet
S has the following format: The End.M.GTP4.E SID in S has the following format:
+----------------------+-------+-------+-------+ 0 127
| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | +-----------------------+-------+----------------+---------+
+----------------------+-------+-------+-------+ | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
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.6. T.M.Tmap S' has the following format:
0 127
+----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+
128-a-b a b
IPv6 SA Encoding for End.M.GTP4.E
6.6. T.M.GTP4.D
The "Transit with tunnel decapsulation and map to an SRv6 policy" The "Transit with tunnel decapsulation and map to an SRv6 policy"
function (T.M.Tmap for short) is used in the direction from legacy function (T.M.GTP4.D 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 Payload == UDP/GTP THEN 1. IF Payload == UDP/GTP THEN
2. pop the outer IPv4 header and UDP/GTP headers 2. pop the outer IPv4 header and UDP/GTP headers
3. copy IPv4 DA, SA, TUN-ID to form SID B 3. copy IPv4 DA, TEID to form SID B
4. encapsulate the packet into a new IPv6 header 4. copy IPv4 SA to form IPv6 SA B'
5. set the IPv6 DA = B 5. encapsulate the packet into a new IPv6 header ;;Ref1
6. forward along the shortest path to B 6. set the IPv6 DA = B
7. ELSE 7. forward along the shortest path to B
8. Drop the packet 8. ELSE
9. Drop the packet
B has the following format: Ref1: The NH value is identified by inspecting the first nibble of
the inner payload.
+----------------------+-------+-------+-------+ The SID B has the following format:
| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |
+----------------------+-------+-------+-------+
128-a-b-c a b c
End.M.GTP4.E SID Encoding 0 127
+-----------------------+-------+----------------+---------+
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
The SID B is an SRv6 BindingSID instantiated at the first UPF (U1). T.M.GTP4.D SID Encoding
A static format is used for this Binding SIDs in order to remove
state from the SRGW. The SID B MAY be an SRv6 Binding SID instantiated at the first UPF
(U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy].
The prefix of B' SHOULD be an End.M.GTP4.E SID with its format
instantiated at an SR gateway with the IPv4 SA of the receiving
packet.
6.7. End.Limit: Rate Limiting function 6.7. End.Limit: Rate Limiting function
The mobile user-plane requires a rate-limit feature. For this The mobile user-plane requires a rate-limit feature. For this
purpose, we define a new function "End.Limit". The "End.Limit" purpose, we define a new function "End.Limit". The "End.Limit"
function encodes in its arguments the rate limiting parameter that function encodes in its arguments the rate limiting parameter that
should be applied to this packet. Multiple flows of packets should should be applied to this packet. Multiple flows of packets should
have the same group identifier in the SID when those flows are in an have the same group identifier in the SID when those flows are in an
same AMBR group. The encoding format of the rate limit segment SID same AMBR group. The encoding format of the rate limit segment SID
is as follows: is as follows:
skipping to change at page 22, line 27 skipping to change at page 23, line 16
for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions; End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions;
End.DX2 for Unstructured PDU 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.ietf-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 adopting the mechanisms from: these slices can be further refined by adopting the mechanisms 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.ietf-spring-segment-routing-policy] for automated slice
provisioning and traffic steering. provisioning and traffic steering.
Further details on how these tools can be used to create end to end Further details on how these tools can be used to create end to end
network slices are documented in network slices are documented in
[I-D.ali-spring-network-slicing-building-blocks]. [I-D.ali-spring-network-slicing-building-blocks].
9. Control Plane Considerations 9. Control Plane Considerations
This document focuses on user-plane behavior and its independence This document focuses on user-plane behavior and its independence
from the control plane. from the control plane.
skipping to change at page 23, line 25 skipping to change at page 24, line 17
10. Security Considerations 10. Security Considerations
TBD TBD
11. IANA Considerations 11. IANA Considerations
IANA is requested to allocate, within the "SRv6 Endpoint Types" sub- IANA is requested to allocate, within the "SRv6 Endpoint Types" sub-
registry belonging to the top-level "Segment-routing with IPv6 registry belonging to the top-level "Segment-routing with IPv6
dataplane (SRv6) Parameters" registry dataplane (SRv6) Parameters" registry
[I-D.filsfils-spring-srv6-network-programming], the following values: [I-D.ietf-spring-srv6-network-programming], the following values:
+-------------+-----+-------------------+-----------+ +-------------+-----+-------------------+-----------+
| 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] |
+-------------+-----+-------------------+-----------+ +-------------+-----+-------------------+-----------+
skipping to change at page 23, line 49 skipping to change at page 24, line 41
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, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
Shekhar and Aeneas Dodd-Noble for their useful 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 Toyota Motor Corporation
Japan Japan
Email: ebiken@pontonetworks.com
Email: ebisawa@toyota-tokyo.tech
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.filsfils-spring-segment-routing-policy] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Sivabalan, S., Hegde, S., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., Routing Header (SRH)", draft-ietf-6man-segment-routing-
Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, header-21 (work in progress), June 2019.
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.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network- Network Programming", draft-ietf-spring-srv6-network-
programming-07 (work in progress), February 2019. programming-01 (work in progress), July 2019.
[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-16 (work in
progress), February 2019.
[I-D.voyer-6man-extension-header-insertion]
daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes,
D., Previdi, S., and S. Matsushima, "Insertion of IPv6
Segment Routing Headers in a Controlled Domain", draft-
voyer-6man-extension-header-insertion-05 (work in
progress), January 2019.
[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-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/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] [I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and d. Ali, Z., Filsfils, C., Camarillo, P., and d.
daniel.voyer@bell.ca, "Building blocks for Slicing in daniel.voyer@bell.ca, "Building blocks for Slicing in
Segment Routing Network", draft-ali-spring-network- Segment Routing Network", draft-ali-spring-network-
slicing-building-blocks-01 (work in progress), March 2019. slicing-building-blocks-01 (work in progress), March 2019.
[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-01 (work in progress), mobility-deployment-options-02 (work in progress), July
December 2018. 2019.
[I-D.camarillo-dmm-srv6-mobile-pocs] [I-D.camarillo-dmm-srv6-mobile-pocs]
Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A., Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A.,
Matsushima, S., and d. daniel.voyer@bell.ca, "Segment Matsushima, S., and d. daniel.voyer@bell.ca, "Segment
Routing IPv6 for mobile user-plane PoCs", draft-camarillo- Routing IPv6 for mobile user-plane PoCs", draft-camarillo-
dmm-srv6-mobile-pocs-01 (work in progress), October 2018. dmm-srv6-mobile-pocs-02 (work in progress), April 2019.
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases] [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S.,
daniel.voyer@bell.ca, d., Cui, A., and B. Peirens, "SRv6 daniel.voyer@bell.ca, d., Cui, A., and B. Peirens, "SRv6
Mobility Use-Cases", draft-camarilloelmalky-springdmm- Mobility Use-Cases", draft-camarilloelmalky-springdmm-
srv6-mob-usecases-01 (work in progress), January 2019. srv6-mob-usecases-01 (work in progress), January 2019.
[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-01 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01
skipping to change at page 26, line 16 skipping to change at page 26, line 44
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-01 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-01
(work in progress), January 2019. (work in progress), January 2019.
[I-D.xuclad-spring-sr-service-programming] [I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service- Segment Routing", draft-xuclad-spring-sr-service-
programming-01 (work in progress), October 2018. programming-02 (work in progress), April 2019.
[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] [TS.38415]
3GPP, "Draft Specification for 5GS container (TS 38.415)", 3GPP, , "Draft Specification for 5GS container (TS
3GPP R3-174510 0.0.0, August 2017. 38.415)", 3GPP R3-174510 0.0.0, August 2017.
Appendix A. Implementations Appendix A. Implementations
This document 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>.
There are also implementations in M-CORD NGIC and Open Air Interface There are also implementations in M-CORD NGIC and Open Air Interface
(OAI). Further details 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. 57 change blocks. 
161 lines changed or deleted 168 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/