draft-ietf-dmm-srv6-mobile-uplane-13.txt   draft-ietf-dmm-srv6-mobile-uplane-14.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: November 22, 2021 M. Kohno Expires: 27 January 2022 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.E. Perkins
Lupin Lodge Lupin Lodge
May 21, 2021 26 July 2021
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-13 draft-ietf-dmm-srv6-mobile-uplane-14
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 accomplishes 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 user-plane, providing flexibility, end-to-end network slicing, and
SLA control for various applications. This document describes the SLA control for various applications. This document describes the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 November 22, 2021. This Internet-Draft will expire on 27 January 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . 6 4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 5
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 6 skipping to change at page 2, line 49
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
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
In mobile networks, mobility management systems provide connectivity In mobile networks, mobility management systems provide connectivity
over a wireless link to stationary and non-stationary nodes. The over a wireless link to stationary and non-stationary nodes. The
user-plane establishes a tunnel between the mobile node and its user-plane establishes a tunnel between the mobile node and its
anchor node over IP-based backhaul and core networks. anchor node over IP-based backhaul and core networks.
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
to mobile networks. to mobile networks.
skipping to change at page 3, line 43 skipping to change at page 3, line 37
as mobile user-plane anchors. as mobile user-plane anchors.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Terminology 2.1. Terminology
o CNF: Cloud-native Network Function * CNF: Cloud-native Network Function
o NFV: Network Function Virtualization * NFV: Network Function Virtualization
o PDU: Packet Data Unit * PDU: Packet Data Unit
o PDU Session: Context of a UE connects to a mobile network. * PDU Session: Context of a UE connects to a mobile network.
o UE: User Equipment * UE: User Equipment
o UPF: User Plane Function * UPF: User Plane Function
o VNF: Virtual Network Function (including CNFs) * 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 25 skipping to change at page 4, line 21
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
SRH is 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
encoded in the SRH format where the rightmost SID in the SRH is the but encoded in the SRH format where the rightmost SID in the SRH
first SID and the leftmost SID in the SRH is the last SID. When is the first SID and the leftmost SID in the SRH is the last SID.
referring to an SR policy in a high-level use-case, it is simpler When referring to an SR policy in a high-level use-case, it is
to use the <S1, S2, S3> notation. When referring to an simpler to use the <S1, S2, S3> notation. When referring to an
illustration of the detailed packet behavior, the (S3, S2, S1; SL) illustration of the detailed packet behavior, the (S3, S2, S1; SL)
notation is more convenient. notation is more convenient.
- The payload of the packet is omitted. * The payload of the packet is omitted.
SRH[n]: A shorter representation of Segment List[n], as defined in SRH[n]: A shorter representation of Segment List[n], as defined in
[RFC8754]. SRH[SL] can be different from the DA of the IPv6 header. [RFC8754]. SRH[SL] can be different from the DA of the IPv6 header.
o gNB::1 is an IPv6 address (SID) assigned to the gNB. * gNB::1 is an IPv6 address (SID) assigned to the gNB.
o U1::1 is an IPv6 address (SID) assigned to UPF1. * U1::1 is an IPv6 address (SID) assigned to UPF1.
o U2::1 is an IPv6 address (SID) assigned to UPF2. * U2::1 is an IPv6 address (SID) assigned to UPF2.
o U2:: is some other IPv6 address (SID) assigned to UPF2. * U2:: is some other IPv6 address (SID) assigned to UPF2.
2.3. Predefined SRv6 Endpoint Behaviors 2.3. Predefined SRv6 Endpoint Behaviors
The following SRv6 Endpoint Behaviors are defined in [RFC8986]. The following SRv6 Endpoint Behaviors are defined in [RFC8986].
o End.DT4: Decapsulation and Specific IPv4 Table Lookup * End.DT4: Decapsulation and Specific IPv4 Table Lookup
o End.DT6: Decapsulation and Specific IPv6 Table Lookup * End.DT6: Decapsulation and Specific IPv6 Table Lookup
o End.DT46: Decapsulation and Specific IP Table Lookup * End.DT46: Decapsulation and Specific IP Table Lookup
o End.DX4: Decapsulation and IPv4 Cross-Connect * End.DX4: Decapsulation and IPv4 Cross-Connect
o End.DX6: Decapsulation and IPv6 Cross-Connect * End.DX6: Decapsulation and IPv6 Cross-Connect
o End.DX2: Decapsulation and L2 Cross-Connect * End.DX2: Decapsulation and L2 Cross-Connect
o End.T: Endpoint with specific IPv6 Table Lookup * End.T: Endpoint with specific IPv6 Table Lookup
This document defines new SRv6 Segment Endpoint Behaviors in This document defines new SRv6 Segment Endpoint Behaviors in
Section 6. Section 6.
3. Motivation 3. Motivation
Mobile networks are becoming more challenging to operate. On one Mobile networks are becoming more challenging to operate. On one
hand, traffic is constantly growing, and latency requirements are hand, traffic is constantly growing, and latency requirements are
tighter; on the other-hand, there are new use-cases like distributed tighter; on the other-hand, there are new use-cases like distributed
NFVi that are also challenging network operations. NFVi that are also challenging network operations.
skipping to change at page 6, line 32 skipping to change at page 6, line 24
+------/ | SMF | +------/ | SMF |
/ +-----+ / +-----+
/ / \ / / \
/ / \ [N4] / / \ [N4]
/ / \ ________ / / \ ________
/ / \ / \ / / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
Figure 1: 3GPP 5G Reference Architecture Figure 1: 3GPP 5G Reference Architecture
o UE: User Endpoint * UE: User Endpoint
o gNB: gNodeB with N3 interface towards packet core (and N2 for * gNB: gNodeB with N3 interface towards packet core (and N2 for
control plane) control plane)
o UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane) * UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane)
o UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane) * UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane)
o SMF: Session Management Function * SMF: Session Management Function
o AMF: Access and Mobility Management Function * AMF: Access and Mobility Management Function
o DN: Data Network e.g. operator services, Internet access * DN: Data Network e.g. operator services, Internet access
This reference diagram does not depict a UPF that is only connected This reference diagram does not depict a UPF that is only connected
to N9 interfaces, although the mechanisms defined in this document to N9 interfaces, although the mechanisms defined in this document
also work in such case. also work in such case.
Each session from a UE gets assigned to a UPF. Sometimes multiple Each session from a UE gets assigned to a UPF. Sometimes multiple
UPFs may be used, providing richer service functions. A UE gets its UPFs may be used, providing richer service functions. A UE gets its
IP address from the DHCP block of its UPF. The UPF advertises that IP address from the DHCP block of its UPF. The UPF advertises that
IP address block toward the Internet, ensuring that return traffic is IP address block toward the Internet, ensuring that return traffic is
routed to the right UPF. routed to the right UPF.
skipping to change at page 8, line 14 skipping to change at page 8, line 8
associated with each PDU Session, and the SID list only contains a associated with each PDU Session, and the SID list only contains a
single SID. single SID.
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. based on signaled GTP-U parameters per local policy. The only
information from the GTP-U parameters used for the SRv6 policy is the
TEID 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. In traditional mode the
gNB and the UPFs are SR-aware. In the descriptions of the uplink and gNB and the UPFs are SR-aware. In the descriptions of the uplink and
downlink packet flow, A is an IPv6 address of the UE, and Z is an downlink packet flow, A is an IPv6 address of the UE, and Z is an
IPv6 address reachable within the Data Network DN. A new SRv6 IPv6 address reachable within the Data Network DN. A new SRv6
Endpoint Behavior, End.MAP, defined in Section 6.2, is used. Endpoint Behavior, End.MAP, defined in Section 6.2, is used.
________ ________
SRv6 SRv6 / \ SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
skipping to change at page 10, line 5 skipping to change at page 9, line 46
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
meters connected to the same cell) to improve scalability. meters connected to the same cell) to improve scalability.
The gNB control-plane (N2 interface) is unchanged, specifically a The gNB/UPF control-plane (N2/N4 interface) is unchanged,
single IPv6 address is provided to the gNB. A local policy instructs specifically a single IPv6 address is provided to the gNB. A local
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. 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 neither S1 nor C1 are 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 --| UPF1 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/ +--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node SRv6 node \ +----+ / SRv6 node
-| S1 |- -| S1 |-
+----+ +----+
SRv6 node SRv6 node
VNF VNF
Figure 3: Enhanced mode - Example topology Figure 3: Enhanced mode - Example topology
5.2.1. Packet flow - Uplink 5.2.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, S1)(U2::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U2::1> gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U1::1>
S1_out : (gNB, C1)(U2::1, C1; SL=1)(A,Z) S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z)
C1_out : (gNB, U2::1)(A,Z) ->End with PSP C1_out : (gNB, U1::1)(A,Z) ->End with PSP
UPF2_out: (A,Z) ->End.DT4,End.DT6,End.DT2U UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U
UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's
control plane associates that session from the UE(A) with the IPv6 control plane associates that session from the UE(A) with the IPv6
address B. gNB's control plane does a lookup on B to find the address B. gNB's control plane does a lookup on B to find the
related SID list <S1, C1, U2::1>. related SID list <S1, C1, U1::1>.
When gNB transmits the packet, it contains all the segments of the SR When gNB transmits the packet, it contains all the segments of the SR
policy. The SR policy includes segments for traffic engineering (C1) policy. The SR policy includes segments for traffic engineering (C1)
and for service programming (S1). and for service programming (S1).
Nodes S1 and C1 perform their related Endpoint functionality and Nodes S1 and C1 perform their related Endpoint functionality and
forward the packet. forward the packet.
When the packet arrives at UPF2, the active segment (U2::1) is an When the packet arrives at UPF1, the active segment (U1::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/ UPF1_in : (Z,A) ->UPF1 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 UPF1_out: (U1::1, C1)(gNB, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) C1_out : (U1::1, S1)(gNB, S1; SL=1)(Z,A)
S1_out : (U2::1, gNB)(Z,A) ->End with PSP S1_out : (U1::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 UPF1, the UPF1 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 UPF1 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.
Note that there are several means to provide the UE session
aggregation. The decision on which one to use is a local decision
made by the operator. One option is to use the Args.Mob.Session
(Section 6.1). Another option comprises the gNB performing an IP
lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2
behaviors.
5.2.3. Scalability 5.2.3. Scalability
The Enhanced Mode improves since it allows the aggregation of several The Enhanced Mode improves since it allows the aggregation of several
UEs under the same SID list. For example, in the case of stationary UEs under the same SID list. For example, in the case of stationary
residential meters that are connected to the same cell, all such residential meters that are connected to the same cell, all such
devices can share the same SID list. This improves scalability devices can share the same SID list. This improves scalability
compared to Traditional Mode (unique SID per UE) and compared to compared to Traditional Mode (unique SID per UE) and compared to
GTP-U (dedicated TEID per UE). GTP-U (dedicated TEID per UE).
5.3. Enhanced mode with unchanged gNB GTP behavior 5.3. Enhanced mode with unchanged gNB GTP behavior
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Both of the mechanisms described in this section are applicable to Both of the mechanisms described in this section are applicable to
either the Traditional Mode or the Enhanced Mode. either the Traditional Mode or the Enhanced Mode.
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 * 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 towards the gNB (N2 interface) is unmodified; * The 5G Control-Plane towards the gNB (N2 interface) is unmodified;
one IPv6 address is needed (i.e. a BSID at the SRGW). one IPv6 address is needed (i.e. a BSID at the SRGW). The SRv6
o In the uplink, the SRGW removes GTP, finds the SID list related to SID is different depending on the required SLA.
* In the uplink, the SRGW removes GTP, finds the SID list related to
the IPv6 DA, 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. * There is no state for the downlink at the SRGW.
o 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. shared across UEs as long as they belong to the same context
o When a packet from the UE leaves the gNB, it is SR-routed. This (i.e., tenant). A set of many different policies (i.e., different
SLAs) increases the amount of state required.
* 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
* In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic
into an SR policy when it arrives at the SRGW. into an SR policy when 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] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___ GTP \ +------+ / +----+ +------+ \___
-| SRGW |- SRv6 SRv6 -| SRGW |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
5.3.1.1. Packet flow - Uplink 5.3.1.1. Packet flow - Uplink
The uplink packet flow is 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::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW SID at the SRGW
skipping to change at page 13, line 47 skipping to change at page 14, line 9
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 the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its
own SRH containing the SIDs bound to the SR policy associated with own SRH containing the SIDs bound to the SR policy associated with
this BindingSID. There is one instance of the End.M.GTP6.D SID per this BindingSID. There at least one instance of the End.M.GTP6.D SID
PDU type. 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.
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 15, line 14 skipping to change at page 15, line 23
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 * 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 * 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 an * SRGW removes GTP, finds the SID list related to DA, and adds an
SRH 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.
+----+ +----+
IPv4/GTP -| S1 |- ___ IPv4/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___ GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6 -| UPF1 |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
5.3.2.1. Packet flow - Uplink 5.3.2.1. Packet flow - Uplink
The uplink packet flow is as follows: The uplink packet flow is as follows:
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
unchanged IPv4/GTP unchanged IPv4/GTP
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> 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
skipping to change at page 17, line 31 skipping to change at page 17, line 41
5.3.3. Extensions to the interworking mechanisms 5.3.3. Extensions to the interworking mechanisms
In this section we presented two 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
with legacy RAN at the N3 interface, these methods could also be
applied for interworking with a non-SRv6 capable UPF at the N9
interface.
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.
Unlike other interworking modes, in this mode both of the mobility Unlike other interworking modes, in this mode both of the mobility
skipping to change at page 18, line 15 skipping to change at page 18, line 15
+----+ +----+
-| S1 |- -| S1 |-
+-----+ / +----+ \ +-----+ / +----+ \
| gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+
+-----+ \ / 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: (GW-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 : (GW-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 : (GW-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: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an
skipping to change at page 19, line 34 skipping to change at page 19, line 34
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QFI |R|U| PDU Session ID | | QFI |R|U| PDU Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDU Sess(cont')| |PDU Sess(cont')|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Args.Mob.Session format Figure 8: Args.Mob.Session format
o QFI: QoS Flow Identifier [TS.38415] * QFI: QoS Flow Identifier [TS.38415]
o R: Reflective QoS Indication [TS.23501]. This parameter indicates * R: Reflective QoS Indication [TS.23501]. This parameter indicates
the activation of reflective QoS towards the UE for the the activation of reflective QoS towards the UE for the
transferred packet. Reflective QoS enables the UE to map UL User transferred packet. Reflective QoS enables the UE to map UL User
Plane traffic to QoS Flows without SMF provided QoS rules. Plane traffic to QoS Flows without SMF provided QoS rules.
o U: Unused and for future use. MUST be 0 on transmission and * U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt. ignored on receipt.
o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent * PDU Session ID: Identifier of PDU Session. The GTP-U equivalent
is TEID. is TEID.
Arg.Mob.Session is required in case that one SID aggregates multiple Arg.Mob.Session is required in case that one SID aggregates multiple
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)
skipping to change at page 20, line 25 skipping to change at page 20, line 25
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 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
an IPv6 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
skipping to change at page 21, line 21 skipping to change at page 21, line 21
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 [RFC8986] 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
The NH is set based on the SID parameter. There is one instantiation instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already NH is already known in advance. For the IPv4v6 PDU Session Type, in
known in advance. For the IPv4v6 PDU Session Type, in addition we 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
session identifiers. session identifiers.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway. gateway.
6.4. End.M.GTP6.D.Di 6.4. End.M.GTP6.D.Di
skipping to change at page 22, line 33 skipping to change at page 22, line 33
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 [RFC8986] 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
The NH is set based on the SID parameter. There is one instantiation instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already NH is already known in advance. For the IPv4v6 PDU Session Type, in
known in advance. For the IPv4v6 PDU Session Type, in addition we 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.
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 in interworking scenario
for the downlink toward the legacy gNB using IPv6/GTP. for the downlink toward the legacy gNB using IPv6/GTP.
skipping to change at page 23, line 33 skipping to change at page 23, line 30
S03. Push a new IPv6 header with a UDP/GTP Header S03. Push a new IPv6 header with a UDP/GTP Header
S04. Set the outer IPv6 SA to A S04. Set the outer IPv6 SA to A
S05. Set the outer IPv6 DA from buffer memory S05. Set the outer IPv6 DA from buffer memory
S06. Set the outer Payload Length, Traffic Class, Flow Label, S06. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next-Header fields Hop Limit, and 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. } S09. }
Notes: Notes: An End.M.GTP6.E SID MUST always be the penultimate SID. The
An End.M.GTP6.E SID MUST always be the penultimate SID. 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
The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" The "Endpoint behavior with encapsulation for IPv4/GTP tunnel"
behavior (End.M.GTP4.E for short) is used in the downlink when doing behavior (End.M.GTP4.E for short) is used in the downlink when doing
interworking with legacy gNB using IPv4/GTP. interworking with legacy gNB using IPv4/GTP.
skipping to change at page 24, line 32 skipping to change at page 24, line 32
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 Figure 9: End.M.GTP4.E SID Encoding
The IPv6 Source Address 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 Figure 10: IPv6 SA Encoding for End.M.GTP4.E
6.7. H.M.GTP4.D 6.7. H.M.GTP4.D
The "SR Policy Headend with tunnel decapsulation and map to an SRv6 The "SR Policy Headend with tunnel decapsulation and map to an SRv6
policy" behavior (H.M.GTP4.D for short) is used in the direction from policy" behavior (H.M.GTP4.D for short) is used in the direction from
legacy IPv4 user-plane to SRv6 user-plane network. legacy IPv4 user-plane to SRv6 user-plane network.
When the SR Gateway node N receives a packet destined to a IW- When the SR Gateway node N receives a packet destined to a IW-
IPv4-Prefix, N does: IPv4-Prefix, N does:
skipping to change at page 25, line 43 skipping to change at page 25, line 35
the inner payload. the inner payload.
The SID B has the following format: The SID B has the following format:
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 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 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
skipping to change at page 26, line 20 skipping to change at page 26, line 20
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:
+----------------------+----------+-----------+ +----------------------+----------+-----------+
| 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 Figure 12: End.Limit: Rate limiting behavior argument format
If the limit-rate bits are set to zero, the node should not do rate If the limit-rate bits are set to zero, the node should not do rate
limiting unless static configuration or control-plane sets the limit limiting unless static configuration or control-plane sets the limit
rate associated to the SID. rate associated to the SID.
7. SRv6 supported 3GPP PDU session types 7. SRv6 supported 3GPP PDU session types
The 3GPP [TS.23501] defines the following PDU session types: The 3GPP [TS.23501] defines the following PDU session types:
o IPv4 * IPv4
o IPv6 * IPv6
o IPv4v6 * IPv4v6
o Ethernet * Ethernet
o Unstructured * Unstructured
SRv6 supports the 3GPP PDU session types without any protocol SRv6 supports the 3GPP PDU session types without any protocol
overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4
for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU
sessions). sessions).
8. Network Slicing Considerations 8. Network Slicing Considerations
A mobile network may be required to implement "network slices", which A mobile network may be required to implement "network slices", which
logically separate network resources. User-plane behaviors logically separate network resources. User-plane behaviors
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] * IGP Flex-Algo [I-D.ietf-lsr-flex-algo]
o Inter-Domain policies * 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 (On Demand Nexthop/ Furthermore, these can be combined with ODN/AS (On Demand Nexthop/
Automated Steering) [I-D.ietf-spring-segment-routing-policy] for Automated Steering) [I-D.ietf-spring-segment-routing-policy] for
automated slice 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. While there are benefits in an enhanced
control plane (e.g., to dynamically configure SR policies from a
The control plane could be the current 3GPP-defined control plane controller), this document does not impose any change to the existant
with slight modifications to the N4 interface [TS.29244]. mobility control plane.
Alternatively, SRv6 could be used in conjunction with a new mobility
control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6],
hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in
conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new
mobility control-planes and its applicability to an SRv6 user-plane
is out of the scope of this document.
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 28, line 11 skipping to change at page 28, line 5
This document introduces new SRv6 Endpoint Behaviors. Those This document introduces new SRv6 Endpoint Behaviors. Those
behaviors do not need any special 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 |
+-------+--------+-------------------+-----------+ +=======+========+===================+===========+
| 40 | 0x0028 | End.MAP | [This.ID] | | 40 | 0x0028 | End.MAP | [This.ID] |
+-------+--------+-------------------+-----------+
| 41 | 0x0029 | End.Limit | [This.ID] | | 41 | 0x0029 | End.Limit | [This.ID] |
+-------+--------+-------------------+-----------+
| 69 | 0x0045 | End.M.GTP6.D | [This.ID] | | 69 | 0x0045 | End.M.GTP6.D | [This.ID] |
+-------+--------+-------------------+-----------+
| 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | | 70 | 0x0046 | End.M.GTP6.Di | [This.ID] |
+-------+--------+-------------------+-----------+
| 71 | 0x0047 | End.M.GTP6.E | [This.ID] | | 71 | 0x0047 | End.M.GTP6.E | [This.ID] |
+-------+--------+-------------------+-----------+
| 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, Carlos Jesus Bernardos, Dirk v. Hugo and Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and
Jeffrey Zhang for their 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 Japan
Toyota Motor Corporation
Japan
Email: ebisawa@toyota-tokyo.tech Email: ebisawa@toyota-tokyo.tech
Tetsuya Murakami Tetsuya Murakami Arrcus, Inc. United States of America
Arrcus, Inc.
United States of America
Email: tetsuya.ietf@gmail.com Email: tetsuya.ietf@gmail.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", Work in
ietf-spring-segment-routing-policy-11 (work in progress), Progress, Internet-Draft, draft-ietf-spring-segment-
April 2021. routing-policy-13, 28 May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
segment-routing-policy-13>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 29, line 32 skipping to change at page 29, line 26
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[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-04 (work Work in Progress, Internet-Draft, draft-ali-spring-
in progress), February 2021. network-slicing-building-blocks-04, 21 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ali-spring-
[I-D.auge-dmm-hicn-mobility-deployment-options] network-slicing-building-blocks-04>.
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-04 (work in progress), July
2020.
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases] [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
Garvia, P. C., 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", Work in Progress, Internet-Draft, draft-
usecases-02 (work in progress), August 2019. camarilloelmalky-springdmm-srv6-mob-usecases-02, 15 August
2019, <https://datatracker.ietf.org/doc/html/draft-
[I-D.ietf-dmm-fpc-cpdp] camarilloelmalky-springdmm-srv6-mob-usecases-02>.
Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. E. Perkins, "Protocol for Forwarding
Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-
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", Work in Progress,
algo-15 (work in progress), April 2021. Internet-Draft, draft-ietf-lsr-flex-algo-17, 6 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
flex-algo-17>.
[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", Work in Progress, Internet-Draft, draft-
epe-10 (work in progress), December 2017. ietf-spring-segment-routing-central-epe-10, 21 December
2017, <https://datatracker.ietf.org/doc/html/draft-ietf-
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",
draft-ietf-spring-sr-service-programming-04 (work in Work in Progress, Internet-Draft, draft-ietf-spring-sr-
progress), March 2021. service-programming-04, 10 March 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-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",
draft-matsushima-spring-srv6-deployment-status-11 (work in Work in Progress, Internet-Draft, draft-matsushima-spring-
progress), February 2021. srv6-deployment-status-11, 17 February 2021,
<https://datatracker.ietf.org/doc/html/draft-matsushima-
[I-D.rodrigueznatal-lisp-srv6] spring-srv6-deployment-status-11>.
Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
Camarillo, P., and C. Filsfils, "LISP Control Plane for
SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-04
(work in progress), July 2020.
[TS.29244]
3GPP, "Interface between the Control Plane and the User
Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017.
[TS.29281] [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
December 2017. December 2017.
[TS.38415] [TS.38415] 3GPP, "Draft Specification for 5GS container (TS 38.415)",
3GPP, "Draft Specification for 5GS container (TS 38.415)",
3GPP R3-174510 0.0.0, August 2017. 3GPP R3-174510 0.0.0, August 2017.
Appendix A. Implementations Appendix A. Implementations
This document introduces new SRv6 Endpoint Behaviors. These This document introduces new SRv6 Endpoint Behaviors. These
behaviors have an open-source P4 implementation available in behaviors have an open-source P4 implementation available in
<https://github.com/ebiken/p4srv6>. https://github.com/ebiken/p4srv6.
Additionally, a full implementation of this document is available in Additionally, a full implementation of this document is available in
Linux Foundation FD.io VPP project since release 20.05. More Linux Foundation FD.io VPP project since release 20.05. More
information available here: <https://docs.fd.io/vpp/20.05/d7/d3c/ information available here: https://docs.fd.io/vpp/20.05/d7/d3c/
srv6_mobile_plugin_doc.html>. srv6_mobile_plugin_doc.html.
There are also experimental implementations in M-CORD NGIC and Open There are also experimental implementations in M-CORD NGIC and Open
Air Interface (OAI). Air Interface (OAI).
Authors' Addresses Authors' Addresses
Satoru Matsushima (editor) Satoru Matsushima (editor)
SoftBank SoftBank
Japan Japan
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
skipping to change at page 32, line 19 skipping to change at page 31, line 37
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
Charles E. Perkins Charles E. Perkins
Lupin Lodge Lupin Lodge
20600 Aldercroft Heights Rd. 20600 Aldercroft Heights Rd.
Los Gatos, CA 95033 Los Gatos, CA 95033
USA United States of America
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 81 change blocks. 
200 lines changed or deleted 185 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/