draft-ietf-dmm-srv6-mobile-uplane-16.txt   draft-ietf-dmm-srv6-mobile-uplane-17.txt 
DMM Working Group S. Matsushima, Ed. DMM Working Group S. Matsushima, Ed.
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: 12 February 2022 M. Kohno Expires: 15 April 2022 M. Kohno
P. Camarillo, Ed. P. Camarillo, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C.E. Perkins C.E. Perkins
Lupin Lodge Lupin Lodge
11 August 2021 12 October 2021
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-16 draft-ietf-dmm-srv6-mobile-uplane-17
Abstract Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6) This document specifies the applicability of SRv6 (Segment Routing
to the user-plane of mobile networks. The network programming nature IPv6) to the user-plane of mobile networks. The network programming
of SRv6 accomplishes mobile user-plane functions in a simple manner. nature of SRv6 accomplishes mobile user-plane functions in a simple
The statelessness of SRv6 and its ability to control both service manner. The statelessness of SRv6 and its ability to control both
layer path and underlying transport can be beneficial to the mobile service layer path and underlying transport can be beneficial to the
user-plane, providing flexibility, end-to-end network slicing, and mobile user-plane, providing flexibility, end-to-end network slicing,
SLA control for various applications. This document describes the and SLA control for various applications.
SRv6 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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 February 2022. This Internet-Draft will expire on 15 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 35 skipping to change at page 2, line 35
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . 11 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11
5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11 5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12
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
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 18
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24
6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25
6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26
skipping to change at page 3, line 11 skipping to change at page 3, line 11
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 29 14.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 31 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
In mobile networks, mobility management systems provide connectivity In mobile networks, mobility systems provide connectivity over a
over a wireless link to stationary and non-stationary nodes. The wireless link to stationary and non-stationary nodes. The user-plane
user-plane establishes a tunnel between the mobile node and its establishes a tunnel between the mobile node and its anchor node over
anchor node over IP-based backhaul and core networks. IP-based backhaul and core networks.
This document shows the applicability of SRv6 (Segment Routing IPv6) This document specifies the applicability of SRv6 (Segment Routing
to mobile networks. IPv6) to mobile networks.
Segment Routing [RFC8402] is a source routing architecture: a node Segment Routing [RFC8402] is a source routing architecture: a node
steers a packet through an ordered list of instructions called steers a packet through an ordered list of instructions called
"segments". A segment can represent any instruction, topological or "segments". A segment can represent any instruction, topological or
service based. service based.
SRv6 applied to mobile networks enables a source-routing based mobile SRv6 applied to mobile networks enables a source-routing based mobile
architecture, where operators can explicitly indicate a route for the architecture, where operators can explicitly indicate a route for the
packets to and from the mobile node. The SRv6 Endpoint nodes serve packets to and from the mobile node. The SRv6 Endpoint nodes serve
as mobile user-plane anchors. as mobile user-plane anchors.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
"modes" that vary with respect to the use of SRv6. The first one is "modes" that vary with respect to the use of SRv6. The first one is
the "Traditional mode", which inherits the current 3GPP mobile the "Traditional mode", which inherits the current 3GPP mobile
architecture. In this mode GTP-U protocol [TS.29281] is replaced by architecture. In this mode GTP-U protocol [TS.29281] is replaced by
SRv6, however the N3, N9 and N6 interfaces are still point-to-point SRv6, however the N3, N9 and N6 interfaces are still point-to-point
interfaces with no intermediate waypoints as in the current mobile interfaces with no intermediate waypoints as in the current mobile
network architecture. network architecture.
The second mode is the "Enhanced mode". This is an evolution from The second mode is the "Enhanced mode". This is an evolution from
the "Traditional mode". In this mode the N3, N9 or N6 interfaces the "Traditional mode". In this mode the N3, N9 or N6 interfaces
have intermediate waypoints -SIDs- that are used for Traffic have intermediate waypoints -SIDs- that are used for Traffic
Engineering or VNF purposes. This results in optimal end-to-end Engineering or VNF purposes transparent to 3GPP functionalities.
policies across the mobile network with transport and services This results in optimal end-to-end policies across the mobile network
awareness. with transport and services awareness.
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).
In addition to those two modes, we introduce two mechanisms for In addition to those two modes, we introduce two mechanisms for
interworking with legacy access networks (those where the N3 interworking with legacy access networks (those where the N3
interface is unmodified). In this document we introduce them as a interface is unmodified). In this document we introduce them as a
variant to the Enhanced mode, however they are equally applicable to variant to the Enhanced mode, however they are equally applicable to
the Traditional mode. the Traditional mode.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
The traditional mode minimizes the changes required to the mobile The traditional mode minimizes the changes required to the mobile
system; hence it is a good starting point for forming a common system; hence it is a good starting point for forming a common
ground. ground.
The gNB/UPF control-plane (N2/N4 interface) is unchanged, The gNB/UPF control-plane (N2/N4 interface) is unchanged,
specifically a single IPv6 address is provided to the gNB. The same specifically a single IPv6 address is provided to the gNB. The same
control plane signalling is used, and the gNB/UPF decides to use SRv6 control plane signalling is used, and the gNB/UPF decides to use SRv6
based on signaled GTP-U parameters per local policy. The only based on signaled GTP-U parameters per local policy. The only
information from the GTP-U parameters used for the SRv6 policy is the information from the GTP-U parameters used for the SRv6 policy is the
TEID and the IPv6 Destination Address. TEID, QFI, and the IPv6 Destination Address.
Our example topology is shown in Figure 2. In traditional mode the Our example topology is shown in Figure 2. The gNB and the UPFs are
gNB and the UPFs are SR-aware. In the descriptions of the uplink and SR-aware. In the descriptions of the uplink and downlink packet
downlink packet flow, A is an IPv6 address of the UE, and Z is an flow, A is an IPv6 address of the UE, and Z is an IPv6 address
IPv6 address reachable within the Data Network DN. A new SRv6 reachable within the Data Network DN. A new SRv6 Endpoint Behavior,
Endpoint Behavior, End.MAP, defined in Section 6.2, is used. End.MAP, defined in Section 6.2, is used.
________ ________
SRv6 SRv6 / \ SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node
Figure 2: Traditional mode - example topology Figure 2: Traditional mode - example topology
skipping to change at page 8, line 39 skipping to change at page 8, line 39
The uplink packet flow is as follows: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1> gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
When the UE packet arrives at the gNB, the gNB performs a When the UE packet arrives at the gNB, the gNB performs a
H.Encaps.Red operation. Since there is only one SID, there is no H.Encaps.Red operation. Since there is only one SID, there is no
need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA
U1::1. U1::1 represents an anchoring SID specific for that session U1::1. gNB obtains the SID U1::1 from the existing control plane (N2
at UPF1. gNB obtains the SID U1::1 from the existing control plane interface). U1::1 represents an anchoring SID specific for that
(N2 interface). session at UPF1.
When the packet arrives at UPF1, the SID U1::1 is associated with the When the packet arrives at UPF1, the SID U1::1 is associated with the
End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1,
that belongs to the next UPF (U2). that belongs to the next UPF (U2).
When the packet arrives at UPF2, the SID U2::1 corresponds to an When the packet arrives at UPF2, the SID U2::1 corresponds to an
End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates
the packet, performs a lookup in a specific table associated with the packet, performs a lookup in a specific table associated with
that mobile network and forwards the packet toward the data network that mobile network and forwards the packet toward the data network
(DN). (DN).
skipping to change at page 10, line 13 skipping to change at page 10, line 13
policy instructs the gNB to use SRv6. policy instructs the gNB to use SRv6.
The gNB MAY resolve the IP address received via the control plane The gNB MAY resolve the IP address received via the control plane
into a SID list using a mechanism like PCEP, DNS-lookup, LISP into a SID list using a mechanism like PCEP, DNS-lookup, LISP
control-plane or others. The resolution mechanism is out of the control-plane or others. The resolution mechanism is out of the
scope of this document. scope of this document.
Note that the SIDs MAY use the arguments Args.Mob.Session if required Note that the SIDs MAY use the arguments Args.Mob.Session if required
by the UPFs. by the UPFs.
Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the Figure 3 shows an Enhanced mode topology. The gNB and the UPF are
gNB and the UPF are SR-aware. The Figure shows two service segments, SR-aware. The Figure shows two service segments, S1 and C1. S1
S1 and C1. S1 represents a VNF in the network, and C1 represents an represents a VNF in the network, and C1 represents an intermediate
intermediate router used for Traffic Engineering purposes to enforce router used for Traffic Engineering purposes to enforce a low-latency
a low-latency path in the network. Note that neither S1 nor C1 are path in the network. Note that neither S1 nor C1 are required to
required to have an N4 interface. have an N4 interface.
+----+ SRv6 _______ +----+ SRv6 _______
SRv6 --| C1 |--[N3] / \ SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / |UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/ +--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node SRv6 node \ +----+ / SRv6 node
-| S1 |- -| S1 |-
+----+ +----+
SRv6 node SRv6 node
skipping to change at page 13, line 5 skipping to change at page 13, line 5
the IPv6 DA, and adds SRH with the SID list. the IPv6 DA, and adds SRH with the SID list.
* There is no state for the downlink at the SRGW. * There is no state for the downlink at the SRGW.
* There is simple state in the uplink at the SRGW; using Enhanced * There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. An SR policy is mode results in fewer SR policies on this node. An SR policy is
shared across UEs as long as they belong to the same context shared across UEs as long as they belong to the same context
(i.e., tenant). A set of many different policies (i.e., different (i.e., tenant). A set of many different policies (i.e., different
SLAs) increases the amount of state required. SLAs) increases the amount of state required.
* When a packet from the UE leaves the gNB, it is SR-routed. This * When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo]. simplifies network slicing [I-D.ietf-lsr-flex-algo].
* In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic * In the uplink, the SRv6 BSID steers traffic into an SR policy when
into an SR policy when it arrives at the SRGW. it arrives at the SRGW.
An example topology is shown in Figure 5. An example topology is shown in Figure 5.
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.
+----+ +----+
IPv6/GTP -| S1 |- ___ IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
skipping to change at page 13, line 33 skipping to change at page 13, line 33
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
5.3.1.1. Packet flow - Uplink 5.3.1.1. Packet flow - Uplink
The uplink packet flow is as follows: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP) (IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D SRGW_out: (SRGW, S1)(U2::T, 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::T, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> End with PSP C1_out : (SRGW, U2::T)(A,Z) -> End with 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 signaled 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.
skipping to change at page 16, line 39 skipping to change at page 16, line 39
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
the data network. the data network.
Note that the interworking mechanisms for IPv4/GTP and IPv6/GTP Note that the interworking mechanisms for IPv4/GTP and IPv6/GTP
differs. This is due to the fact that in IPv6/GTP we can leverage differs. This is due to the fact that in IPv6/GTP we can leverage
the remote steering capabilities provided by SRv6. In IPv4 this is the remote steering capabilities provided by the Segment Routing
not the case, and it would require a significant address consumption. BSID. In IPv4 this construct is not available, and building a
similar mechanism would require a significant address consumption.
5.3.2.2. Packet flow - Downlink 5.3.2.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,GW::SA:DA:TEID> <C1, S1,GW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
skipping to change at page 20, line 19 skipping to change at page 20, line 29
Note that the encoding of user-plane messages (e.g., Echo Request, Note that the encoding of user-plane messages (e.g., Echo Request,
Echo Reply, Error Indication and End Marker) is out of the scope of Echo Reply, Error Indication and End Marker) is out of the scope of
this draft. [I-D.murakami-dmm-user-plane-message-encoding] defines this draft. [I-D.murakami-dmm-user-plane-message-encoding] defines
one possible encoding. one possible encoding.
6.2. End.MAP 6.2. End.MAP
The "Endpoint behavior with SID mapping" behavior (End.MAP for short) The "Endpoint behavior with SID mapping" behavior (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 by the intermediate UPFs.
When node N receives a packet whose IPv6 DA is S and S is a local When node N receives a packet whose IPv6 DA is S and S is a local
End.MAP SID, N does: End.MAP SID, N does:
S01. If (IPv6 Hop Limit <= 1) { S01. If (IPv6 Hop Limit <= 1) {
S02. Send an ICMP Time Exceeded message to the Source Address, S02. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (Hop limit exceeded in transit), Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet. interrupt packet processing, and discard the packet.
S03. } S03. }
S04. Decrement IPv6 Hop Limit by 1 S04. Decrement IPv6 Hop Limit by 1
S05. Lookup the IPv6 DA in the mapping table S05. Update the IPv6 DA with the new mapped SID
S06. Update the IPv6 DA with the new mapped SID S06. Submit the packet to the egress IPv6 FIB lookup for
S07. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
Notes: The SIDs in the SRH are not modified. Notes: The SIDs in the SRH are not modified.
6.3. End.M.GTP6.D 6.3. End.M.GTP6.D
The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" The "Endpoint behavior with IPv6/GTP decapsulation into SR policy"
behavior (End.M.GTP6.D for short) is used in interworking scenario behavior (End.M.GTP6.D for short) is used in interworking scenario
for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any
SID instance of this behavior is associated with an SR Policy B and SID instance of this behavior is associated with an SR Policy B and
skipping to change at page 21, line 18 skipping to change at page 21, line 21
Code 0 (Erroneous header field encountered), Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field, Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
When processing the Upper-layer header of a packet matching a FIB When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP6.D SID, N does: entry locally instantiated as an End.M.GTP6.D SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) {
S02. Copy the GTP TEID to buffer memory S02. Copy the GTP TEID and QFI to buffer memory
S03. Pop the IPv6, UDP, and GTP Headers S03. Pop the IPv6, UDP, and GTP Headers
S04. Push a new IPv6 header with its own SRH containing B S04. Push a new IPv6 header with its own SRH containing B
S05. Set the outer IPv6 SA to A S05. Set the outer IPv6 SA to A
S06. Set the outer IPv6 DA to the first SID of B S06. Set the outer IPv6 DA to the first SID of B
S07. Set the outer Payload Length, Traffic Class, Flow Label, S07. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next-Header fields Hop Limit, and Next-Header (NH) fields
S08. Write in the last SID of the SRH the Args.Mob.Session S08. Write in the last SID of the SRH the Args.Mob.Session
based on the information of buffer memory based on the information of buffer memory
S09. Submit the packet to the egress IPv6 FIB lookup and S09. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination transmission to the new destination
S10. } Else { S10. } Else {
S11. Process as per [RFC8986] Section 4.1.1 S11. Process as per [RFC8986] Section 4.1.1
S12. } S12. }
Notes: The NH is set based on the SID parameter. There is one Notes: 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 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 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 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 by 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
gateway.
6.4. End.M.GTP6.D.Di 6.4. End.M.GTP6.D.Di
The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for
Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6
drop-in interworking scenario described in Section 5.4. The drop-in interworking scenario described in Section 5.4. The
difference between End.M.GTP6.D as another variant of IPv6/GTP difference between End.M.GTP6.D as another variant of IPv6/GTP
decapsulation function is that the original IPv6 DA of GTP packet is decapsulation function is that the original IPv6 DA of GTP packet is
preserved as the last SID in SRH. preserved as the last SID in SRH.
Any SID instance of this behavior is associated with an SR Policy B Any SID instance of this behavior is associated with an SR Policy B
skipping to change at page 23, line 11 skipping to change at page 23, line 11
instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 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 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 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.5. End.M.GTP6.E 6.5. End.M.GTP6.E
The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" The "Endpoint behavior with encapsulation for IPv6/GTP tunnel"
behavior (End.M.GTP6.E for short) is used in interworking scenario behavior (End.M.GTP6.E for short) is used among others in the
for the downlink toward the legacy gNB using IPv6/GTP. interworking scenario 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
a local End.M.GTP6.E SID, N does the following: a local End.M.GTP6.E SID, N does the following:
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 1) { S02. If (Segments Left != 1) {
skipping to change at page 24, line 28 skipping to change at page 24, line 28
Pointer set to the Segments Left field, Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
When processing the Upper-layer header of a packet matching a FIB When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP4.E SID, N does: entry locally instantiated as an End.M.GTP4.E SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Sotre the IPv6 DA and SA in buffer memory S02. Store the IPv6 DA and SA in buffer memory
S03. Pop the IPv6 header and all its extension headers S03. Pop the IPv6 header and all its extension headers
S04. Push a new IPv4 header with a UDP/GTP Header S04. Push a new IPv4 header with a UDP/GTP Header
S05. Set the outer IPv4 SA and DA (from buffer memory) S05. Set the outer IPv4 SA and DA (from buffer memory)
S06. Set the outer Total Length, DSCP, Time To Live, and S06. Set the outer Total Length, DSCP, Time To Live, and
Next-Header fields Next-Header fields
S07. Set the GTP TEID (from buffer memory) S07. Set the GTP TEID (from buffer memory)
S08. Submit the packet to the egress IPv6 FIB lookup and S08. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination transmission to the new destination
S09. } Else { S09. } Else {
S10. Process as per [NET-PGM] Section 4.1.1 S10. Process as per [NET-PGM] Section 4.1.1
skipping to change at page 25, line 48 skipping to change at page 26, line 5
+-----------------------+-------+----------------+---------+ +-----------------------+-------+----------------+---------+
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+ +-----------------------+-------+----------------+---------+
128-a-b-c a b c 128-a-b-c a b c
Figure 11: H.M.GTP4.D SID Encoding Figure 11: H.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 an SR policy [I-D.ietf-spring-segment-routing-policy]. (U1) to bind an 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.8. End.Limit: Rate Limiting behavior 6.8. End.Limit: Rate Limiting behavior
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 behavior "End.Limit". The "End.Limit" purpose, we define a new behavior "End.Limit". The "End.Limit"
behavior encodes in its arguments the rate limiting parameter that behavior 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 the have the same group identifier in the SID when those flows are in the
same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of
the rate limit segment SID is as follows: the rate limit segment SID is as follows:
skipping to change at page 27, line 20 skipping to change at page 27, line 20
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. While there are benefits in an enhanced from the control plane. While there are benefits in an enhanced
control plane (e.g., to dynamically configure SR policies from a control plane (e.g., to dynamically configure SR policies from a
controller), this document does not impose any change to the existant controller, session aggregation), this document does not impose any
mobility control plane. change to the existent mobility control plane.
Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for
the new behaviors defined in this document. the new behaviors defined in this document.
10. Security Considerations 10. Security Considerations
The security considerations for Segment Routing are discussed in The security considerations for Segment Routing are discussed in
[RFC8402]. More specifically for SRv6 the security considerations [RFC8402]. More specifically for SRv6 the security considerations
and the mechanisms for securing an SR domain are discussed in and the mechanisms for securing an SR domain are discussed in
[RFC8754]. Together, they describe the required security mechanisms [RFC8754]. Together, they describe the required security mechanisms
skipping to change at page 30, line 18 skipping to change at page 30, line 18
Engineering", Work in Progress, Internet-Draft, draft- Engineering", Work in Progress, Internet-Draft, draft-
ietf-spring-segment-routing-central-epe-10, 21 December ietf-spring-segment-routing-central-epe-10, 21 December
2017, <https://datatracker.ietf.org/doc/html/draft-ietf- 2017, <https://datatracker.ietf.org/doc/html/draft-ietf-
spring-segment-routing-central-epe-10>. spring-segment-routing-central-epe-10>.
[I-D.ietf-spring-sr-service-programming] [I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing", S. Salsano, "Service Programming with Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-spring-sr- Work in Progress, Internet-Draft, draft-ietf-spring-sr-
service-programming-04, 10 March 2021, service-programming-05, 10 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring- <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-04>. sr-service-programming-05>.
[I-D.kohno-dmm-srv6mob-arch] [I-D.kohno-dmm-srv6mob-arch]
Kohno, M., Clad, F., Camarillo, P., and Z. Ali, Kohno, M., Clad, F., Camarillo, P., and Z. Ali,
"Architecture Discussion on SRv6 Mobile User plane", Work "Architecture Discussion on SRv6 Mobile User plane", Work
in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch- in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch-
04, 6 May 2021, <https://datatracker.ietf.org/doc/html/ 04, 6 May 2021, <https://datatracker.ietf.org/doc/html/
draft-kohno-dmm-srv6mob-arch-04>. draft-kohno-dmm-srv6mob-arch-04>.
[I-D.matsushima-spring-srv6-deployment-status] [I-D.matsushima-spring-srv6-deployment-status]
Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K.
Rajaraman, "SRv6 Implementation and Deployment Status", Rajaraman, "SRv6 Implementation and Deployment Status",
Work in Progress, Internet-Draft, draft-matsushima-spring- Work in Progress, Internet-Draft, draft-matsushima-spring-
srv6-deployment-status-11, 17 February 2021, srv6-deployment-status-11, 17 February 2021,
<https://datatracker.ietf.org/doc/html/draft-matsushima- <https://datatracker.ietf.org/doc/html/draft-matsushima-
spring-srv6-deployment-status-11>. spring-srv6-deployment-status-11>.
[I-D.murakami-dmm-user-plane-message-encoding] [I-D.murakami-dmm-user-plane-message-encoding]
Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P., Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P.,
and R. Shekhar, "User Plane Message Encoding", Work in and R. Shekhar, "User Plane Message Encoding", Work in
Progress, Internet-Draft, draft-murakami-dmm-user-plane- Progress, Internet-Draft, draft-murakami-dmm-user-plane-
message-encoding-03, 7 March 2021, message-encoding-04, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-murakami-dmm- <https://datatracker.ietf.org/doc/html/draft-murakami-dmm-
user-plane-message-encoding-03>. user-plane-message-encoding-04>.
[TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
December 2017. December 2017.
[TS.38415] 3GPP, "Draft Specification for 5GS container (TS 38.415)", [TS.38415] 3GPP, "Draft Specification for 5GS container (TS 38.415)",
3GPP R3-174510 0.0.0, August 2017. 3GPP R3-174510 0.0.0, August 2017.
Appendix A. Implementations Appendix A. Implementations
 End of changes. 30 change blocks. 
67 lines changed or deleted 60 lines changed or added

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