draft-ietf-dmm-srv6-mobile-uplane-06.txt   draft-ietf-dmm-srv6-mobile-uplane-07.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: March 29, 2020 M. Kohno Expires: May 7, 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
September 26, 2019 November 4, 2019
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-06 draft-ietf-dmm-srv6-mobile-uplane-07
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, end-to-end network slicing and SLA user-plane, providing flexibility, end-to-end network slicing and SLA
control for various applications. This document describes the SRv6 control for various applications. This document describes the SRv6
mobile user plane behavior and defines the SID functions for that. mobile user plane.
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 March 29, 2020. This Internet-Draft will expire on May 7, 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 39 skipping to change at page 2, line 39
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8
5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 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 . . . . . . 17 5.3.3. SRv6 Drop-in Interworking . . . . . . . . . . . . . . 16
6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17 5.3.4. Extensions to the interworking mechanisms . . . . . . 18
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 17 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 18 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 20
6.6. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 20 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 21
6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 22
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22 6.7. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 23
8. Network Slicing Considerations . . . . . . . . . . . . . . . 22 6.8. End.Limit: Rate Limiting function . . . . . . . . . . . . 23
9. Control Plane Considerations . . . . . . . . . . . . . . . . 22 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Network Slicing Considerations . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Control Plane Considerations . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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.
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
skipping to change at page 3, line 35 skipping to change at page 3, line 37
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Terminology 2.1. Terminology
o AMBR: Aggregate Maximum Bit Rate o AMBR: Aggregate Maximum Bit Rate
o Anchor: An topological endpoint of an UE
o APN: Access Point Name (commonly used to identify a network or o APN: Access Point Name (commonly used to identify a network or
class of service) class of service)
o BSID: SR Binding SID [RFC8402] o BSID: SR Binding SID [RFC8402]
o CNF: Cloud-native Network Function o CNF: Cloud-native Network Function
o gNB: gNodeB o gNB: gNodeB
o NH: The IPv6 next-header field. o NH: The IPv6 next-header field.
o NFV: Network Function Virtualization o NFV: Network Function Virtualization
o PDU: Packet Data Unit o PDU: Packet Data Unit
o Session: TBD... o Session: Context of an UE connects to a mobile network.
o SID: A Segment Identifier which represents a specific segment in a o SID: A Segment Identifier which represents a specific segment in a
segment routing domain. segment routing domain.
o SRH: The Segment Routing Header. o SRH: The Segment Routing Header.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
o TEID: Tunnel Endpoint Identifier o TEID: Tunnel Endpoint Identifier
o UE: User Equipment o UE: User Equipment
o UPF: User Plane Function o UPF: User Plane Function
o VNF: Virtual Network Function o VNF: Virtual Network Function
2.2. Conventions 2.2. Conventions
o NH=SRH means that NH is 43 with routing type 4. o NH=SRH means that NH is 43 with routing type 4.
o Multiple SRHs may be present inside each packet, but they must o Multiple SRHs may be present inside each packet, but they must
follow each other. The next-header field of each SRH, except the follow each other. The next-header field of each SRH, except the
last one, must be NH-SRH (43 type 4). last one, must be NH-SRH (43 type 4).
o For simplicity, no other extension headers are shown except the o For simplicity, no other extension headers are shown except the
SRH. SRH.
o The SID type used in this document is IPv6 address (also called o The SID type used in this document is SRv6 SID.
SRv6 Segment or SRv6 SID).
o gNB::1 is an IPv6 address (SID) assigned to the gNB. o gNB::1 is an IPv6 address (SID) assigned to the gNB.
o U1::1 is an IPv6 address (SID) assigned to UPF1. o U1::1 is an IPv6 address (SID) assigned to UPF1.
o U2::1 is an IPv6 address (SID) assigned to UPF2. o U2::1 is an IPv6 address (SID) assigned to UPF2.
o U2:: is some other IPv6 address (SID) assigned to UPF2. o U2:: is some other IPv6 address (SID) assigned to UPF2.
o A SID list is represented as <S1, S2, S3> where S1 is the first o A SID list is represented as <S1, S2, S3> where S1 is the first
SID to visit, S2 is the second SID to visit and S3 is the last SID SID to visit, S2 is the second SID to visit and S3 is the last SID
to visit along the SR path. to visit along the SR path.
o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
* IPv6 header with source and destination addresses SA and DA * IPv6 header with source and destination addresses SA and DA
skipping to change at page 7, line 26 skipping to change at page 7, line 26
The second mode is the "Enhanced mode". In this mode the SR policy The second mode is the "Enhanced mode". In this mode the SR policy
contains SIDs for Traffic Engineering and VNFs, which results in contains SIDs for Traffic Engineering and VNFs, which results in
effective end-to-end network slices. effective end-to-end network slices.
In both, the Traditional and the Enhanced modes, we assume that the In both, the Traditional and the Enhanced modes, we assume that the
gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6
interfaces are SRv6). interfaces are SRv6).
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 this document we introduce
introduce them applied to the Enhanced mode, although they could be them applied to the Enhanced mode, although they could be used in
used in combination with the Traditional mode as well. 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.ietf-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.
skipping to change at page 9, line 28 skipping to change at page 9, line 28
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.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.ietf-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
SIDs. SIDs.
The gNB control-plane (N2 interface) is unchanged, specifically a The gNB control-plane (N2 interface) is unchanged, specifically a
single IPv6 address is given to the gNB. single IPv6 address is given to the gNB.
skipping to change at page 11, line 35 skipping to change at page 11, line 35
5.3. Enhanced mode with unchanged gNB GTP behavior 5.3. Enhanced mode with unchanged gNB GTP behavior
This section describes two mechanisms for interworking with legacy This section describes two mechanisms for interworking with legacy
gNBs that still use GTP: one for IPv4, the other for IPv6. gNBs that still use GTP: one for IPv4, the other for IPv6.
In the interworking scenarios as illustrated in Figure 4, gNB does In the interworking scenarios as illustrated in Figure 4, gNB does
not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6. not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6.
To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added.
The SRGW maps the GTP traffic into SRv6. The SRGW maps the GTP traffic into SRv6.
The SRGW is not an anchor point, and maintains very little state. The SRGW is not an anchor point and maintains very little state. For
For this reason, both IPv4 and IPv6 methods scale to millions of UEs. this reason, both IPv4 and IPv6 methods scale to millions of UEs.
_______ _______
IP GTP SRv6 / \ IP GTP SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/ +--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node SR Gateway SRv6 node
Figure 4: Example topology for interworking Figure 4: Example topology for interworking
skipping to change at page 12, line 16 skipping to change at page 12, line 16
encapsulates into GTP (N3 interface is not modified). encapsulates into GTP (N3 interface is not modified).
o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6
address is needed (i.e. a BSID at the SRGW). address is needed (i.e. a BSID at the SRGW).
o The SRGW removes GTP, finds the SID list related to DA, and adds o The SRGW removes GTP, finds the SID list related to DA, and adds
SRH with the SID list. SRH with the SID list.
o There is no state for the downlink at the SRGW. o There is no state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW; using Enhanced o There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. A SR policy can mode results in fewer SR policies on this node. A SR policy can
be shared across UEs. be shared across UEs.
o When a packet from the UE leaves the gNB, it is SR-routed. This o When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.hegdeppsenak-isis-sr-flex-algo]. simplifies network slicing [I-D.ietf-lsr-flex-algo].
o In the uplink, the IPv6 DA BSID steers traffic into an SR policy o In the uplink, the IPv6 DA BSID steers traffic into an SR policy
when it arrives at the SRGW-UPF1. when it arrives at the SRGW-UPF1.
An example topology is shown in Figure 5. In this mode the gNB is an An example topology is shown in Figure 5. In this mode the gNB is an
unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before, unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before,
the SRGW maps IPv6/GTP traffic to SRv6. the SRGW maps IPv6/GTP traffic to SRv6.
S1 and C1 are two service segments. S1 represents a VNF in the S1 and C1 are two service segments. S1 represents a VNF in the
network, and C1 represents a router configured for Traffic network, and C1 represents a router configured for Traffic
Engineering. Engineering.
skipping to change at page 13, line 9 skipping to change at page 13, line 9
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW SID at the SRGW
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> PSP C1_out : (SRGW, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z 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 signaled over the N2 interface for that UE
PDU 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.
skipping to change at page 14, line 25 skipping to change at page 14, line 25
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 PDU Session; the state state can be shared need to be unique per UE PDU Session; the state state can be shared
among UEs. This enables much more scalable SRGW deployments compared among UEs. This enables much more scalable SRGW deployments compared
to a 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
For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
However based on local policy, a service provider MAY choose to do
SRH insertion. The main benefit is 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
interface interface
Key points: Key points:
o The gNB is unchanged and encapsulates packets into GTP (the N3 o The gNB is unchanged and encapsulates packets into GTP (the N3
interface is not modified). interface is not modified).
o In the uplink, traffic is classified by SRGW's Uplink Classifier o In the uplink, traffic is classified by SRGW's Uplink Classifier
skipping to change at page 16, line 46 skipping to change at page 16, line 42
current and previous generations. current and previous generations.
5.3.2.3. Scalability 5.3.2.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in For the downlink traffic, the SRGW is stateless. All the state is in
the SRH inserted by the UPF. The UPF must have this UE-base state the SRH inserted by the UPF. The UPF must have this UE-base state
anyway (since it is its anchor point). anyway (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per For the uplink traffic, the state at the SRGW is dedicated on a per
UE/session basis according to an Uplink Classifier. There is state UE/session basis according to an Uplink Classifier. There is state
for steering the different sessions on a SR policies. However, SR for steering the different sessions in the form of a SR Policy.
policies are shared among several UE/sessions. However, SR policies are shared among several UE/sessions.
5.3.2.4. IPv6 user-traffic 5.3.3. SRv6 Drop-in Interworking
For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. SRv6 drop-in interworking mode provides SRv6 user plane in between
Based on local policy, a service provider MAY choose to do SRH GTP-U tunnel endpoints. This mode employs two SRGWs to do GTP-U
insertion. The main benefit is a lower overhead. traffic to SRv6 mapping on one SRGW, and vice versa.
5.3.3. Extensions to the interworking mechanisms Unlike other interworking modes, both of the mobility overlay
endpoints use GTP-U. Two SRGWs are deployed in either N3 or N9
interface to realize an intermediate SR policy.
In this section we presented two mechanisms for interworking with The SRGW behaviors for this mode are equivalent with other modes
gNBs that do not support SRv6. These mechanism are done to support except in IPv6 GTP case on the GTP-U to SRv6 direction. Due to that
GTP over IPv4 and GTP over IPv6. only one exception, it is enough that this section focuses to
describe IPv6 GTP case on one direction with an illustration.
+----+
-| S1 |-
+-----------+ / +----+ \
| UPF2a/gNB |- SRv6 / SRv6 \ +----+ +------+ +-------+
+-----------+ \ [N9]/ VNF -| C1 |---| UPF1b|------| UPF2b |
GTP \ +------+ / +----+ +------+ +-------+
-| UPF1a|- SRv6 SR Gateway-B GTP
+------+ TE
SR Gateway-A
Figure 7: Example topology for SRv6 Drop-in
5.3.3.1. Packet flow
The packet flow of Figure 7 is as follows:
UPF2a/gNB_out: (UPF2a/gNB, U2b::)(GTP: TEID T)(A,Z)
SRGW-A_out : (SRGW-A, S1)(U2b::, U1b::TEID, C1; SL=3)(A,Z) -> U2b:: is an
End.M.GTP6.D.Di
SID at SRGW-A
S1_out : (SRGW-A, C1)(U2b::, U1b::TEID, C1; SL=2)(A,Z)
C1_out : (SRGW-A, U1b::TEID)(U2b::, U1b::TEID, C1; SL=1)(A,Z)
SRGW-B_out : (SRGW-B, U2b::)(GTP: TEID T)(A,Z) -> U1b::TEID is an
End.M.GTP6.E
SID at SRGW-B
UPF2b_out : (A,Z)
When a packet destined to Z arrives at the UPF2a, or gNB, which is
unmodified, performs encapsulates the packet into a new IPv6, UDP and
GTP headers. The IPv6 DA, U2b::, and the GTP TEID are the ones
received at the N2 interface.
The IPv6 address that was signalled over the N2 interface for that UE
PDU Session, U2b::, is now the IPv6 DA. U2b:: is an SRv6 Binding SID
at SRGW-A. Hence the packet is routed to the SRGW.
When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an
End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW
removes 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 Binding SID. There is one instance of the End.M.GTP6.D.Di
SID per PDU type.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
Once the packet arrives at SRGW-B, the SRGW identifies the active SID
as an End.M.GTP6.E function. The SRGW removes the IPv6 header and
all its extensions headers. The SRGW generates new IPv6, UDP and GTP
headers. The new IPv6 DA is U2b:: which is the last SID in the
received SRH. The TEID in the generated GTP header is an argument of
the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet toward UPF2b. There is one instance
of the End.M.GTP6.E SID per PDU type.
Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP
packet. The UPF looks for the specific rule for that TEID to forward
the packet. This UPF behavior is not modified from current and
previous generations.
5.3.4. Extensions to the interworking mechanisms
In this section we presented three mechanisms for interworking with
gNBs and UPFs that do not support SRv6. These mechanisms are used to
support GTP over IPv4 and IPv6.
Even though we have presented these methods as an extension to the Even though we have presented these methods as an extension to the
"Enhanced mode", it is straightforward in its applicability to the "Enhanced mode", it is straightforward in its applicability to the
"Traditional mode". "Traditional mode".
Furthermore, although these mechanisms are designed for interworking Furthermore, although these mechanisms are designed for interworking
with legacy RAN at the N3 interface, these methods could also be with legacy RAN at the N3 interface, these methods could also be
applied for interworking with a non-SRv6 capable UPF at the N9 applied for interworking with a non-SRv6 capable UPF at the N9
interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not).
skipping to change at page 18, line 4 skipping to change at page 19, line 22
|PDU Sess(cont')| |PDU Sess(cont')|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Args.Mob.Session format Args.Mob.Session format
o QFI: QoS Flow Identifier [TS.38415] o QFI: QoS Flow Identifier [TS.38415]
o R: Reflective QoS Indication [TS.23501]. This parameter indicates o R: Reflective QoS Indication [TS.23501]. This parameter indicates
the activaton of reflective QoS towards the UE for the transfered the activaton of reflective QoS towards the UE for the transfered
packet. Reflective QoS enables the UE to map UL User Plane packet. Reflective QoS enables the UE to map UL User Plane
traffic to QoS Flows without SMF provided QoS rules. traffic to QoS Flows without SMF provided QoS rules.
o U: Unused and for future use. MUST be 0 on transmission and o U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt. ignored on receipt.
o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent
is TEID. is TEID.
Since the SRv6 function is likely NOT to be instantiated per PDU Arg.Mob.Session is required in case that one SID aggregates multiple
session, Args.Mob.Session helps the UPF to perform the functions PDU Session. Since the SRv6 function is likely NOT to be
which require per QFI and/or per PDU Session granularity. instantiated per PDU session, Args.Mob.Session helps the UPF to
perform the functions which require per QFI and/or per PDU Session
granularity.
6.2. End.MAP 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:
skipping to change at page 19, line 16 skipping to change at page 20, line 39
NH is already known in advance. For the IPv4v6 PDU Session Type, in 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. 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 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 an Arg.Mob.Session argument space which is used to provide the
session identifiers. session identifiers.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway. gateway.
6.4. End.M.GTP6.E 6.4. End.M.GTP6.D.Di
The "Endpoint function with IPv6/GTP decapsulation into SR policy for
Drop-in Mode" function (End.M.GTP6.D.Di for short) is used in SRv6
drop-in interworking scenario described in Section 5.3.3. The
difference between End.M.GTP6.D as another variant of IPv6/GTP
decapsulation function is that the original IPv6 DA of GTP packet is
preserved as the last SID in SRH. Suppose, for example, this SID is
associated with an SR policy <S1, S2, S3> and an IPv6 Source Address
A.
When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D.Di SID, N does:
1. IF NH=UDP & UDP_DST_PORT = GTP THEN
2. preserve S and copy TEID to form SID S3
3. pop the IPv6, UDP and GTP headers
4. push a new IPv6 header with a SR policy in SRH <S1, S2, S3, S>
5. set the outer IPv6 SA to A
6. set the outer IPv6 DA to S1
7. set the outer IPv6 NH ;; Ref1
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.Di 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.5. 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 prefix of End.M.GTP6.E SID MUST be followed by the The prefix of End.M.GTP6.E SID MUST be followed by the
Arg.Mob.Session argument space which is used to provide the session Arg.Mob.Session argument space which is used to provide the session
identifiers. 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
skipping to change at page 19, line 40 skipping to change at page 22, line 4
2. store SRH[0] in variable new_DA 2. store SRH[0] in variable new_DA
3. store TEID in variable new_TEID from IPv6 DA ;; Ref2 3. store TEID in variable new_TEID from IPv6 DA ;; Ref2
4. pop IP header and all its extension headers 4. pop IP header and all its extension headers
5. push new IPv6 header and GTP-U header 5. push new IPv6 header and GTP-U header
6. set IPv6 DA to new_DA 6. set IPv6 DA to new_DA
7. set IPv6 SA to A 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
Ref1: 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.
Ref2: 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 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an
SR gateway. SR gateway.
6.5. End.M.GTP4.E 6.6. 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 and SL = 0) or ENH=4 THEN 1. IF (NH=SRH and SL = 0) or ENH=4 THEN
2. store IPv6 DA in buffer S 2. store IPv6 DA in buffer S
skipping to change at page 20, line 43 skipping to change at page 23, line 5
S' has the following format: S' has the following format:
0 127 0 127
+----------------------+--------+--------------------------+ +----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+ +----------------------+--------+--------------------------+
128-a-b a b 128-a-b a b
IPv6 SA Encoding for End.M.GTP4.E IPv6 SA Encoding for End.M.GTP4.E
6.6. T.M.GTP4.D 6.7. 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.GTP4.D 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. IPv4 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, TEID to form SID B 3. copy IPv4 DA, TEID to form SID B
4. copy IPv4 SA to form IPv6 SA B' 4. copy IPv4 SA to form IPv6 SA B'
5. encapsulate the packet into a new IPv6 header ;;Ref1 5. encapsulate the packet into a new IPv6 header ;;Ref1
6. set the IPv6 DA = B 6. set the IPv6 DA = B
skipping to change at page 21, line 35 skipping to change at page 23, line 44
T.M.GTP4.D SID Encoding T.M.GTP4.D SID Encoding
The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 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]. (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 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 instantiated at an SR gateway with the IPv4 SA of the receiving
packet. packet.
6.7. End.Limit: Rate Limiting function 6.8. 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 19 skipping to change at page 24, line 28
7. SRv6 supported 3GPP PDU session types 7. SRv6 supported 3GPP PDU session types
The 3GPP [TS.23501] defines the following PDU session types: The 3GPP [TS.23501] defines the following PDU session types:
o IPv4 o IPv4
o IPv6 o IPv6
o IPv4v6 o IPv4v6
o Ethernet o Ethernet
o Unstructured o Unstructured
SRv6 supports all the 3GPP PDU session types without any protocol SRv6 supports the 3GPP PDU session types without any protocol
overhead by using the corresponding SRv6 functions (End.DX4, End.DT4 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; 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). Unstructured PDUs are not supported.
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.ietf-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.ietf-lsr-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.ietf-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].
skipping to change at page 24, line 19 skipping to change at page 26, line 26
Japan Japan
Email: ebisawa@toyota-tokyo.tech Email: ebisawa@toyota-tokyo.tech
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
Routing Header (SRH)", draft-ietf-6man-segment-routing- (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
header-23 (work in progress), September 2019. progress), October 2019.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
bogdanov@google.com, b., and P. Mattes, "Segment Routing P. Mattes, "Segment Routing Policy Architecture", draft-
Policy Architecture", draft-ietf-spring-segment-routing- ietf-spring-segment-routing-policy-03 (work in progress),
policy-03 (work in progress), May 2019. May 2019.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Matsushima, S., and Z. Li, "SRv6 Network Programming",
Network Programming", draft-ietf-spring-srv6-network- draft-ietf-spring-srv6-network-programming-05 (work in
programming-02 (work in progress), September 2019. progress), October 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.
skipping to change at page 25, line 20 skipping to change at page 27, line 28
2019. 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-02 (work in progress), April 2019. 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 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use-
Mobility Use-Cases", draft-camarilloelmalky-springdmm- Cases", draft-camarilloelmalky-springdmm-srv6-mob-
srv6-mob-usecases-02 (work in progress), August 2019. usecases-02 (work in progress), August 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
(work in progress), September 2018. (work in progress), September 2018.
[I-D.hegdeppsenak-isis-sr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
Segment Routing Flexible Algorithm", draft-hegdeppsenak-
isis-sr-flex-algo-02 (work in progress), February 2018.
[I-D.ietf-dmm-fpc-cpdp] [I-D.ietf-dmm-fpc-cpdp]
Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12
(work in progress), June 2018. (work in progress), June 2018.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-04 (work in progress), September 2019.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central- Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017. epe-10 (work in progress), December 2017.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-ietf-spring-sr-service-
programming-00 (work in progress), October 2019.
[I-D.rodrigueznatal-lisp-srv6] [I-D.rodrigueznatal-lisp-srv6]
Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
Camarillo, P., and C. Filsfils, "LISP Control Plane for Camarillo, P., and C. Filsfils, "LISP Control Plane for
SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-02 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-02
(work in progress), July 2019. (work in progress), July 2019.
[I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
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-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].
 End of changes. 46 change blocks. 
102 lines changed or deleted 205 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/