draft-ietf-dmm-srv6-mobile-uplane-11.txt   draft-ietf-dmm-srv6-mobile-uplane-12.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: October 9, 2021 M. Kohno Expires: November 5, 2021 M. Kohno
P. Camarillo, Ed. P. Camarillo, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C. Perkins C. Perkins
Futurewei Futurewei
April 7, 2021 May 4, 2021
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-11 draft-ietf-dmm-srv6-mobile-uplane-12
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 accomplishes 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
control for various applications. This document describes the SRv6 SLA control for various applications. This document describes the
mobile user plane. 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 October 9, 2021. This Internet-Draft will expire on November 5, 2021.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4 2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 5 4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 6
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 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.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 . . . . . . . . . . . . . 14 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15
5.3.3. Extensions to the interworking mechanisms . . . . . . 17 5.3.3. Extensions to the interworking mechanisms . . . . . . 17
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 18 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . 21 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 23 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 23
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
8. Network Slicing Considerations . . . . . . . . . . . . . . . 26 8. Network Slicing Considerations . . . . . . . . . . . . . . . 26
9. Control Plane Considerations . . . . . . . . . . . . . . . . 27 9. Control Plane Considerations . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 45 skipping to change at page 3, line 46
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 CNF: Cloud-native Network Function o CNF: Cloud-native Network Function
o NFV: Network Function Virtualization o NFV: Network Function Virtualization
o PDU: Packet Data Unit o PDU: Packet Data Unit
o PDU Session: Context of an UE connects to a mobile network. o PDU Session: Context of a UE connects to a mobile network.
o UE: User Equipment o UE: User Equipment
o UPF: User Plane Function o UPF: User Plane Function
o VNF: Virtual Network Function (including CNFs) o VNF: Virtual Network Function (including CNFs)
The following terms used within this document are defined in The following terms used within this document are defined in
[RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding
SID. SID.
The following terms used within this document are defined in The following terms used within this document are defined in
[RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint
Node and Reduced SRH. Node and Reduced SRH.
The following terms used within this document are defined in The following terms used within this document are defined in
skipping to change at page 4, line 19 skipping to change at page 4, line 21
Node and Reduced SRH. Node and Reduced SRH.
The following terms used within this document are defined in The following terms used within this document are defined in
[RFC8986]: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 Segment [RFC8986]: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 Segment
Endpoint Behavior. Endpoint Behavior.
2.2. Conventions 2.2. Conventions
An SR Policy is resolved to a SID list. A SID list is represented as An SR Policy is resolved to a SID list. A SID list is represented as
<S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID
to visit and S3 is the last SID to visit along the SR path. to visit, and S3 is the last SID to visit along the SR path.
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
- Source Address is SA, Destination Address is DA, and next-header is - Source Address is SA, Destination Address is DA, and next-header is
SRH SRH
- SRH with SID list <S1, S2, S3> with Segments Left = SL - SRH with SID list <S1, S2, S3> with Segments Left = SL
- Note the difference between the <> and () symbols: <S1, S2, S3> - Note the difference between the <> and () symbols: <S1, S2, S3>
represents a SID list where S1 is the first SID and S3 is the last represents a SID list where S1 is the first SID and S3 is the last
SID to traverse. (S3, S2, S1; SL) represents the same SID list but SID to traverse. (S3, S2, S1; SL) represents the same SID list but
encoded in the SRH format where the rightmost SID in the SRH is the encoded in the SRH format where the rightmost SID in the SRH is the
skipping to change at page 9, line 29 skipping to change at page 9, line 33
next hop. 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,
End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The
gNB decapsulates the packet, removing the IPv6 header and all its gNB 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. Enhanced Mode 5.2. Enhanced Mode
Enhanced mode improves scalability, provides traffic engineering Enhanced mode improves scalability, provides traffic engineering
capabilities and allows service programming capabilities, and allows service programming
[I-D.ietf-spring-sr-service-programming], thanks to the use of [I-D.ietf-spring-sr-service-programming], thanks to the use of
multiple SIDs in the SID list (instead of a direct connectivity in multiple SIDs in the SID list (instead of a direct connectivity in
between UPFs with no intermediate waypoints as in Traditional Mode). between UPFs with no intermediate waypoints as in Traditional Mode).
Thus, the main difference is that the SR policy MAY include SIDs for Thus, the main difference is that the SR policy MAY include SIDs for
traffic engineering and service programming in addition to the traffic engineering and service programming in addition to the
anchoring SIDs at UPFs. anchoring SIDs at UPFs.
Additionally in this mode the operator may choose to aggregate Additionally in this mode the operator may choose to aggregate
several devices under the same SID list (e.g., stationary residential several devices under the same SID list (e.g., stationary residential
skipping to change at page 10, line 9 skipping to change at page 10, line 12
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. In the Enhanced mode, the
gNB and the UPF are SR-aware. The Figure shows two service segments, gNB and the UPF are SR-aware. The Figure shows two service segments,
S1 and C1. S1 represents a VNF in the network, and C1 represents an S1 and C1. S1 represents a VNF in the network, and C1 represents an
intermediate router used for Traffic Engineering purposes to enforce intermediate router used for Traffic Engineering purposes to enforce
a low-latency path in the network. Note that both S1 and C1 are not a low-latency path in the network. Note that neither S1 nor C1 are
required to have an N4 interface. required to have an N4 interface.
+----+ SRv6 _______ +----+ SRv6 _______
SRv6 --| C1 |--[N3] / \ SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/ +--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node SRv6 node \ +----+ / SRv6 node
-| S1 |- -| S1 |-
+----+ +----+
skipping to change at page 11, line 9 skipping to change at page 11, line 11
When the packet arrives at UPF2, the active segment (U2::1) is an When the packet arrives at UPF2, the active segment (U2::1) is an
End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing
the IPv6 header with all its extension headers) and forwards toward the IPv6 header with all its extension headers) and forwards toward
the data network. the data network.
5.2.2. Packet flow - Downlink 5.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 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) ->H.Encaps.Red UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) ->H.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) ->End with PSP S1_out : (U2::1, gNB)(Z,A) ->End with PSP
gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2
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 PDU Session. This UE PDU Session is associated with flow into a UE PDU Session. This UE PDU Session is associated with
the policy <C1, S1, gNB>. The UPF2 performs a H.Encaps.Red the policy <C1, S1, gNB>. The UPF2 performs a H.Encaps.Red
operation, 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, End.DX6 or End.DX2 behavior at the gNB (depending on the End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
underlying traffic). The gNB decapsulates the packet, removing the underlying traffic). The gNB decapsulates the packet, removing the
IPv6 header and forwards the traffic toward the UE. IPv6 header and forwards the traffic toward the UE.
5.2.3. Scalability
The Enhanced Mode improves since it allows the aggregation of several
UEs under the same SID list. For example, in the case of stationary
residential meters that are connected to the same cell, all such
devices can share the same SID list. This improves scalability
compared to Traditional Mode (unique SID per UE) and compared to
GTP-U (dedicated TEID per UE).
5.3. Enhanced mode with unchanged gNB GTP behavior 5.3. Enhanced mode with unchanged gNB GTP behavior
This section describes three mechanisms for interworking with legacy This section describes two mechanisms for interworking with legacy
gNBs that still use GTP: one for IPv4, and two other for IPv6. gNBs that still use GTP: one for IPv4, and another for IPv6.
In the interworking scenarios as illustrated in Figure 4, the gNB In the interworking scenarios as illustrated in Figure 4, the gNB
does not support SRv6. The gNB supports GTP encapsulation over IPv4 does not support SRv6. The gNB supports GTP encapsulation over IPv4
or IPv6. To achieve interworking, a SR Gateway (SRGW-UPF1) entity is or IPv6. To achieve interworking, an SR Gateway (SRGW-UPF1) entity
added. The SRGW maps the GTP traffic into SRv6. is added. The SRGW maps the GTP traffic into SRv6.
The SRGW is not an anchor point and maintains very little state. For The SRGW is not an anchor point and maintains very little state. 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
skipping to change at page 12, line 14 skipping to change at page 12, line 26
5.3.1. Interworking with IPv6 GTP 5.3.1. Interworking with IPv6 GTP
In this interworking mode the gNB at the N3 interface uses GTP over In this interworking mode the gNB at the N3 interface uses GTP over
IPv6. IPv6.
Key points: Key points:
o The gNB is unchanged (control-plane or user-plane) and o The gNB is unchanged (control-plane or user-plane) and
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 towards the gNB (N2 interface) is unmodified;
address is needed (i.e. a BSID at the SRGW). one IPv6 address is needed (i.e. a BSID at the SRGW).
o The SRGW removes GTP, finds the SID list related to the IPv6 DA, o In the uplink, the SRGW removes GTP, finds the SID list related to
and adds SRH with the SID list. the IPv6 DA, and adds 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. An SR policy is mode results in fewer SR policies on this node. An SR policy is
shared across UEs. 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.ietf-lsr-flex-algo]. simplifies network slicing [I-D.ietf-lsr-flex-algo].
o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic
into an SR policy when it arrives at the SRGW-UPF1. into an SR policy when it arrives at the SRGW-UPF1.
An example topology is shown in Figure 5. An example topology is shown in Figure 5.
skipping to change at page 13, line 16 skipping to change at page 13, line 32
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP) (IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW SID at the SRGW
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> End with PSP C1_out : (SRGW, U2::1)(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.
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
SRH containing the SIDs bound to the SR policy associated with this own SRH containing the SIDs bound to the SR policy associated with
BindingSID. There is one instance of the End.M.GTP6.D SID per PDU this BindingSID. There is one instance of the End.M.GTP6.D SID per
type. PDU type.
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. UPF2 then decapsulates (removing the outer is bound to End.DT4/6. UPF2 then decapsulates (removing the outer
IPv6 header with all its extension headers) and forwards the packet IPv6 header with all its extension headers) and forwards the packet
toward the data network. toward the data network.
5.3.1.2. Packet flow - Downlink 5.3.1.2. Packet flow - Downlink
skipping to change at page 14, line 11 skipping to change at page 14, line 27
When a packet destined to A arrives at the UPF2, the UPF2 performs a When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the table associated to A and finds the SID list <C1, S1, lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation, SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
C1 and S1 perform their related Endpoint processing. C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active Once the packet arrives at the SRGW, the SRGW identifies the active
SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 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 and all its extensions headers. The SRGW generates new IPv6, UDP,
GTP headers. The new IPv6 DA is the gNB which is the last SID in the and GTP headers. The new IPv6 DA is the gNB which is the last SID in
received SRH. The TEID in the generated GTP header is an argument of the received SRH. The TEID in the generated GTP header is an
the received End.M.GTP6.E SID. The SRGW pushes the headers to the argument of the received End.M.GTP6.E SID. The SRGW pushes the
packet and forwards the packet toward the gNB. There is one instance headers to the packet and forwards the packet toward the gNB. There
of the End.M.GTP6.E SID per PDU type. is one instance of the End.M.GTP6.E SID per PDU type.
Once the packet arrives at the gNB, the packet is a regular IPv6/GTP Once the packet arrives at the gNB, the packet is a regular IPv6/GTP
packet. The gNB looks for the specific radio bearer for that TEID packet. The gNB looks for the specific radio bearer for that TEID
and forward it on the bearer. This gNB behavior is not modified from and forward it on the bearer. This gNB behavior is not modified from
current and previous generations. current and previous generations.
5.3.1.3. Scalability 5.3.1.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in For the downlink traffic, the SRGW is stateless. All the state is in
the SRH inserted by the UPF2. The UPF2 must have the UE states since the SRH pushed 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 PDU Session; the SR policy can be shared among need to be unique per PDU Session; the SR policy can be shared among
UEs. This enables more scalable SRGW deployments compared to a UEs. This enables more scalable SRGW deployments compared to a
solution holding millions of states, one or more per UE. solution holding millions of states, one or more per UE.
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
and steered into an SR policy. The SRGW is a UPF1 functionality and steered into an SR policy. The SRGW is a UPF1 functionality
and can coexist with UPF1's Uplink Classifier functionality. and can coexist with UPF1's Uplink Classifier functionality.
o SRGW removes GTP, finds the SID list related to DA, and adds a SRH o SRGW removes GTP, finds the SID list related to DA, and adds an
with the SID list. SRH with the SID list.
An example topology is shown in Figure 6. In this mode the gNB is an An example topology is shown in Figure 6. In this mode the gNB is an
unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before,
the SRGW maps the IPv4/GTP traffic to SRv6. the SRGW maps the IPv4/GTP traffic to SRv6.
S1 and C1 are two service segment endpoints. S1 represents a VNF in S1 and C1 are two service segment endpoints. S1 represents a VNF in
the network, and C1 represents a router configured for Traffic the network, and C1 represents a router configured for Traffic
Engineering. Engineering.
+----+ +----+
skipping to change at page 15, line 34 skipping to change at page 16, line 4
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) -> H.M.GTP4.D function SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.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,
the GTP TEID are the ones received at the N2 interface. and 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 H.M.GTP4.D. The SRGW traffic into an SR policy by using the function H.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
the data network. the data network.
5.3.2.2. Packet flow - Downlink 5.3.2.2. Packet flow - Downlink
The downlink packet flow is 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,SRGW::SA:DA:TEID> <C1, S1,GW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(SRGW::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)(SRGW::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, SRGW::SA:DA:TEID)(Z,A) S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A) gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the table associated to A and finds the SID list <C1, S1, lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::SA:DA:TEID>. The UPF2 performs a H.Encaps.Red operation, SRGW::SA:DA:TEID>. The UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active Once the packet arrives at the SRGW, the SRGW identifies the active
SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header
and all its extensions headers. The SRGW generates an IPv4, UDP and and all its extensions headers. The SRGW generates an IPv4, UDP, and
GTP headers. The IPv4 SA and DA are received as SID arguments. The GTP headers. The IPv4 SA and DA are received as SID arguments. The
TEID in the generated GTP header is also the arguments of the TEID in the generated GTP header is also the arguments of the
received End.M.GTP4.E SID. The SRGW pushes the headers to the packet received End.M.GTP4.E SID. The SRGW pushes the headers to the packet
and forwards the packet toward the gNB. and forwards the packet toward the gNB.
When the packet arrives at the gNB, the packet is a regular IPv4/GTP When the packet arrives at the gNB, the packet is a regular IPv4/GTP
packet. The gNB looks for the specific radio bearer for that TEID packet. The gNB looks for the specific radio bearer for that TEID
and forward it on the bearer. This gNB behavior is not modified from and forwards it on the bearer. This gNB behavior is not modified
current and previous generations. from 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 pushed by the UPF2. 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 in the form of a SR Policy. for steering the different sessions in the form of an SR Policy.
However, SR policies are shared among several UE/sessions. However, SR policies are shared among several UE/sessions.
5.3.3. Extensions to the interworking mechanisms 5.3.3. Extensions to the interworking mechanisms
In this section we presented three mechanisms for interworking with In this section we presented two mechanisms for interworking with
gNBs and UPFs that do not support SRv6. These mechanisms are used to gNBs and UPFs that do not support SRv6. These mechanisms are used to
support GTP over IPv4 and IPv6. 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).
5.4. SRv6 Drop-in Interworking 5.4. SRv6 Drop-in Interworking
In this section we introduce another mode useful for legacy gNB and In this section we introduce another mode useful for legacy gNB and
UPFs that still operate with GTP-U. This mode provides an UPFs that still operate with GTP-U. This mode provides an
SRv6-enabled user plane in between two GTP-U tunnel endpoints. SRv6-enabled user plane in between two GTP-U tunnel endpoints.
In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and
vice-versa. vice-versa.
skipping to change at page 18, line 5 skipping to change at page 18, line 19
+-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF |
GTP[N3]\ +--------+ / +----+ +--------+ +-----+ GTP[N3]\ +--------+ / +----+ +--------+ +-----+
-| SRGW-A |- SRv6 SR Gateway-B GTP -| SRGW-A |- SRv6 SR Gateway-B GTP
+--------+ TE +--------+ TE
SR Gateway-A SR Gateway-A
Figure 7: Example topology for SRv6 Drop-in mode Figure 7: Example topology for SRv6 Drop-in mode
The packet flow of Figure 7 is as follows: The packet flow of Figure 7 is as follows:
gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z)
GW-A_out: (SRGW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an
End.M.GTP6.D.Di End.M.GTP6.D.Di
SID at SRGW-A SID at SRGW-A
S1_out : (SRGW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z)
C1_out : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z) ->U1b::TEID is an GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an
End.M.GTP6.E End.M.GTP6.E
SID at SRGW-B SID at SRGW-B
UPF_out : (A,Z) UPF_out : (A,Z)
When a packet destined to Z to the gNB, which is unmodified, it When a packet destined to Z is sent to the gNB, which is unmodified
performs encapsulation into a new IP, UDP and GTP headers. The IPv6 (control-plane and user-plane remain GTP-U), gNB performs
DA, U::1, and the GTP TEID are the ones received at the N2 interface. encapsulation into a new IP, UDP, and GTP headers. The IPv6 DA,
U::1, and the GTP TEID are the ones received at the N2 interface.
The IPv6 address that was signaled over the N2 interface for that PDU The IPv6 address that was signaled over the N2 interface for that PDU
Session, U::1, is now the IPv6 DA. U2b:: is an SRv6 Binding SID at Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding SID at
SRGW-A. Hence the packet is routed to the SRGW. SRGW-A. Hence the packet is routed to the SRGW.
When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an When the packet arrives at SRGW-A, the SRGW identifies U::1 as an
End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 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 removes the IPv6, UDP, and GTP headers, and pushes an IPv6 header
its own SRH containing the SIDs bound to the SR policy associated with its own SRH containing the SIDs bound to the SR policy
with this Binding SID. There is one instance of the End.M.GTP6.D.Di associated with this Binding SID. There is one instance of the
SID per PDU type. End.M.GTP6.D.Di SID per PDU type.
S1 and C1 perform their related Endpoint functionality and forward S1 and C1 perform their related Endpoint functionality and forward
the packet. the packet.
Once the packet arrives at SRGW-B, the SRGW identifies the active SID 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 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 all its extensions headers. The SRGW generates new IPv6, UDP, and
headers. The new IPv6 DA is U::1 which is the last SID in the GTP headers. The new IPv6 DA is U::1 which is the last SID in the
received SRH. The TEID in the generated GTP header is an argument of 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 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 packet and forwards the packet toward UPF. There is one instance of
of the End.M.GTP6.E SID per PDU type. the End.M.GTP6.E SID per PDU type.
Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP Once the packet arrives at UPF, the packet is a regular IPv6/GTP
packet. The UPF looks for the specific rule for that TEID to forward packet. The UPF looks for the specific rule for that TEID to forward
the packet. This UPF behavior is not modified from current and the packet. This UPF behavior is not modified from current and
previous generations. previous generations.
6. SRv6 Segment Endpoint Mobility Behaviors 6. SRv6 Segment Endpoint Mobility Behaviors
6.1. Args.Mob.Session 6.1. Args.Mob.Session
Args.Mob.Session provide per-session information for charging, Args.Mob.Session provide per-session information for charging,
buffering and lawful intercept (among others) required by some mobile buffering and lawful intercept (among others) required by some mobile
nodes. The Args.Mob.Session argument format is used in combination nodes. The Args.Mob.Session argument format is used in combination
with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2
behaviors. Note that proposed format is applicable for 5G networks, behaviors. Note that proposed format is applicable for 5G networks,
while similar formats could be used for legacy networks. while similar formats could be used for legacy networks.
0 1 2 3 0 1 2 3
skipping to change at page 19, line 44 skipping to change at page 20, line 11
PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated
per PDU session, Args.Mob.Session helps the UPF to perform the per PDU session, Args.Mob.Session helps the UPF to perform the
behaviors which require per QFI and/or per PDU Session granularity. behaviors which require per QFI and/or per PDU Session granularity.
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 in the UPFs for the PDU Session anchor functionality.
When N receives a packet whose IPv6 DA is S and S is a local End.MAP When node N receives a packet whose IPv6 DA is S and S is a local
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. Lookup the IPv6 DA in the mapping table
S06. Update the IPv6 DA with the new mapped SID S06. Update the IPv6 DA with the new mapped SID
S07. 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: Notes:
The SIDs in the SRH are not modified. 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 toward from the legacy gNB using IPv6/GTP. Suppose, for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any
for example, this SID is associated with an SR policy B and an IPv6 SID instance of this behavior is associated with an SR Policy B and
Source Address A. 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:
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address,
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 = UDP & UDP_Dest_port = GTP) {
S02. Copy the GTP TEID to buffer memory S02. Copy the GTP TEID 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 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 [NET-PGM] Section 4.1.1 S11. Process as per [RFC8986] Section 4.1.1
S12. } S12. }
Notes: Notes:
The NH is set based on the SID parameter. There is one instantiation 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 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 known in advance. For the IPv4v6 PDU Session Type, in addition we
inspect the first nibble of the PDU to know the NH value. 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
skipping to change at page 22, line 10 skipping to change at page 22, line 10
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.Di SID, N does: local End.M.GTP6.D.Di SID, N does:
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address,
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.Di SID, N does: entry locally instantiated as an End.M.GTP6.Di SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Copy S to buffer memory S02. Copy S 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 fields
S08. Write S to the SRH S08. Write S to the SRH
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 [NET-PGM] Section 4.1.1 S11. Process as per [RFC8986] Section 4.1.1
S12. } S12. }
Notes: Notes:
The NH is set based on the SID parameter. There is one instantiation 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 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 known in advance. For the IPv4v6 PDU Session Type, in addition we
inspect the first nibble of the PDU to know the NH value. 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.
skipping to change at page 23, line 13 skipping to change at page 23, line 13
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) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address,
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.E SID, N does: entry locally instantiated as an End.M.GTP6.E SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Copy SRH[0] to buffer memory S02. Copy SRH[0] to 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 IPv6 header with a UDP/GTP Header S04. Push a new IPv6 header with a UDP/GTP Header
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 fields
S08. Set the GTP TEID (from buffer memory) S08. Set the GTP TEID (from 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 [NET-PGM] Section 4.1.1 S11. Process as per [RFC8986] Section 4.1.1
S12. } S12. }
Notes: Notes:
An End.M.GTP6.E SID MUST always be the penultimate SID. An End.M.GTP6.E SID MUST always be the penultimate SID.
The TEID is extracted from the argument space of the current SID. The 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.6. End.M.GTP4.E 6.6. End.M.GTP4.E
skipping to change at page 24, line 10 skipping to change at page 24, line 10
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:
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address,
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.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. Sotre 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
S11. } S11. }
Notes: Notes:
The End.M.GTP4.E SID in S has the following format: The End.M.GTP4.E SID in S has the following format:
0 127 0 127
+-----------------------+-------+----------------+---------+ +-----------------------+-------+----------------+---------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | | 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
S' has the following format: The IPv6 Source Address 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.7. H.M.GTP4.D 6.7. H.M.GTP4.D
skipping to change at page 25, line 46 skipping to change at page 25, line 46
0 127 0 127
+-----------------------+-------+----------------+---------+ +-----------------------+-------+----------------+---------+
|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
H.M.GTP4.D SID Encoding 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 a 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 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.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 an 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:
+----------------------+----------+-----------+ +----------------------+----------+-----------+
| LOC+FUNC rate-limit | group-id | limit-rate| | LOC+FUNC rate-limit | group-id | limit-rate|
+----------------------+----------+-----------+ +----------------------+----------+-----------+
128-i-j i j 128-i-j i j
End.Limit: Rate limiting behavior argument format End.Limit: Rate limiting behavior argument format
skipping to change at page 27, line 7 skipping to change at page 27, line 7
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.ietf-lsr-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 (On Demand Nexthop/
[I-D.ietf-spring-segment-routing-policy] for automated slice Automated Steering) [I-D.ietf-spring-segment-routing-policy] for
provisioning and traffic steering. automated slice 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 27, line 48 skipping to change at page 27, line 48
[RFC8754]. Together, they describe the required security mechanisms [RFC8754]. Together, they describe the required security mechanisms
that allow establishment of an SR domain of trust to operate that allow establishment of an SR domain of trust to operate
SRv6-based services for internal traffic while preventing any SRv6-based services for internal traffic while preventing any
external traffic from accessing or exploiting the SRv6-based external traffic from accessing or exploiting the SRv6-based
services. services.
The technology described in this document is applied to a mobile The technology described in this document is applied to a mobile
network that is within the SR Domain. network that is within the SR Domain.
This document introduces new SRv6 Endpoint Behaviors. Those This document introduces new SRv6 Endpoint Behaviors. Those
behaviors do not need any especial security consideration given that behaviors do not need any special security consideration given that
it is deployed within that SR Domain. it is deployed within that SR Domain.
11. IANA Considerations 11. IANA Considerations
The following values have been allocated within the "SRv6 Endpoint The following values have been allocated within the "SRv6 Endpoint
Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment
Routing Parameters" registry: Routing Parameters" registry:
+-------+--------+-------------------+-----------+ +-------+--------+-------------------+-----------+
| Value | Hex | Endpoint behavior | Reference | | Value | Hex | Endpoint behavior | Reference |
skipping to change at page 28, line 29 skipping to change at page 28, line 29
| 72 | 0x0048 | End.M.GTP4.E | [This.ID] | | 72 | 0x0048 | End.M.GTP4.E | [This.ID] |
+-------+--------+-------------------+-----------+ +-------+--------+-------------------+-----------+
Table 1: SRv6 Mobile User-plane Endpoint Behavior Types Table 1: SRv6 Mobile User-plane Endpoint Behavior Types
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Daisuke Yokota, Bart Peirens, The authors would like to thank Daisuke Yokota, Bart Peirens,
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
Shekhar, Aeneas Dodd-Noble and Carlos Jesus Bernardos for their Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and
useful comments of this work. Jeffrey Zhang for their useful comments of this work.
13. Contributors 13. Contributors
Kentaro Ebisawa Kentaro Ebisawa
Toyota Motor Corporation Toyota Motor Corporation
Japan Japan
Email: ebisawa@toyota-tokyo.tech Email: ebisawa@toyota-tokyo.tech
Tetsuya Murakami Tetsuya Murakami
skipping to change at page 29, line 41 skipping to change at page 29, line 41
[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.
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. Voyer, Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer,
"Building blocks for Slicing in Segment Routing Network", "Building blocks for Slicing in Segment Routing Network",
draft-ali-spring-network-slicing-building-blocks-03 (work draft-ali-spring-network-slicing-building-blocks-04 (work
in progress), November 2020. in progress), February 2021.
[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-04 (work in progress), July mobility-deployment-options-04 (work in progress), July
2020. 2020.
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases] [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., Garvia, P. C., Filsfils, C., Elmalky, H., Matsushima, S.,
Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use-
Cases", draft-camarilloelmalky-springdmm-srv6-mob- Cases", draft-camarilloelmalky-springdmm-srv6-mob-
usecases-02 (work in progress), August 2019. usecases-02 (work in progress), August 2019.
[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. E. Perkins, "Protocol for Forwarding
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-14 Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-
(work in progress), September 2020. cpdp-14 (work in progress), September 2020.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-13 (work in progress), October 2020. algo-14 (work in progress), February 2021.
[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] [I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
Henderickx, W., and S. Salsano, "Service Programming with S. Salsano, "Service Programming with Segment Routing",
Segment Routing", draft-ietf-spring-sr-service- draft-ietf-spring-sr-service-programming-04 (work in
programming-03 (work in progress), September 2020. progress), March 2021.
[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",
draft-matsushima-spring-srv6-deployment-status-10 (work in draft-matsushima-spring-srv6-deployment-status-11 (work in
progress), December 2020. progress), February 2021.
[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-04 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-04
(work in progress), July 2020. (work in progress), July 2020.
[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.
 End of changes. 76 change blocks. 
123 lines changed or deleted 134 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/