rfc9433.original   rfc9433.txt 
DMM Working Group S. Matsushima, Ed. Internet Engineering Task Force (IETF) S. Matsushima, Ed.
Internet-Draft SoftBank Request for Comments: 9433 SoftBank
Intended status: Informational C. Filsfils Category: Informational C. Filsfils
Expires: 21 July 2023 M. Kohno ISSN: 2070-1721 M. Kohno
P. Camarillo, Ed. P. Camarillo, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
17 January 2023 July 2023
Segment Routing IPv6 for Mobile User Plane Segment Routing over IPv6 for the Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-24
Abstract Abstract
This document discusses the applicability of SRv6 (Segment Routing This document discusses the applicability of Segment Routing over
IPv6) to the user-plane of mobile networks. The network programming IPv6 (SRv6) to the user plane of mobile networks. The network
nature of SRv6 accomplishes mobile user-plane functions in a simple programming nature of SRv6 accomplishes mobile user-plane functions
manner. The statelessness of SRv6 and its ability to control both in a simple manner. The statelessness of SRv6 and its ability to
service layer path and underlying transport can be beneficial to the control both service layer path and underlying transport can be
mobile user-plane, providing flexibility, end-to-end network slicing, beneficial to the mobile user plane, providing flexibility, end-to-
and SLA control for various applications. end network slicing, and Service Level Agreement (SLA) control for
various applications.
This document discusses how SRv6 (Segment Routing over IPv6) could be This document discusses how SRv6 could be used as the user plane of
used as user-plane of mobile networks. This document also specifies mobile networks. This document also specifies the SRv6 Endpoint
the SRv6 Segment Endpoint behaviors required for mobility use-cases. Behaviors required for mobility use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 21 July 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9433.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Conventions
2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 5 2.3. Predefined SRv6 Endpoint Behaviors
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation
4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 6 4. 3GPP Reference Architecture
5. User-plane modes . . . . . . . . . . . . . . . . . . . . . . 7 5. User-Plane Modes
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 8 5.1. Traditional Mode
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 9 5.1.1. Packet Flow - Uplink
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9 5.1.2. Packet Flow - Downlink
5.2. Enhanced mode . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Enhanced Mode
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 11 5.2.1. Packet Flow - Uplink
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11 5.2.2. Packet Flow - Downlink
5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 12 5.2.3. Scalability
5.3. Enhanced mode with unchanged gNB GTP-U behavior . . . . . 12 5.3. Enhanced Mode with Unchanged gNB GTP-U Behavior
5.3.1. Interworking with IPv6 GTP-U . . . . . . . . . . . . 13 5.3.1. Interworking with IPv6 GTP-U
5.3.2. Interworking with IPv4 GTP-U . . . . . . . . . . . . 16 5.3.2. Interworking with IPv4 GTP-U
5.3.3. Extensions to the interworking mechanisms . . . . . . 18 5.3.3. Extensions to the Interworking Mechanisms
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 18 5.4. SRv6 Drop-In Interworking
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 20 6. SRv6 Segment Endpoint Mobility Behaviors
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 20 6.1. Args.Mob.Session
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. End.MAP
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 21 6.3. End.M.GTP6.D
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22 6.4. End.M.GTP6.D.Di
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23 6.5. End.M.GTP6.E
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24 6.6. End.M.GTP4.E
6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 26 6.7. H.M.GTP4.D
6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 6.8. End.Limit
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 27 7. SRv6-Supported 3GPP PDU Session Types
8. Network Slicing Considerations . . . . . . . . . . . . . . . 27 8. Network Slicing Considerations
9. Control Plane Considerations . . . . . . . . . . . . . . . . 28 9. Control Plane Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Informative References
14.1. Normative References . . . . . . . . . . . . . . . . . . 29 Acknowledgements
14.2. Informative References . . . . . . . . . . . . . . . . . 30 Contributors
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 32 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
In mobile networks, mobility systems provide connectivity over a In mobile networks, mobility systems provide connectivity over a
wireless link to stationary and non-stationary nodes. The user-plane wireless link to stationary and non-stationary nodes. The user plane
establishes a tunnel between the mobile node and its anchor node over establishes a tunnel between the mobile node and its anchor node over
IP-based backhaul and core networks. IP-based backhaul and core networks.
This document specifies the applicability of SRv6 (Segment Routing This document specifies the applicability of SRv6 [RFC8754] [RFC8986]
IPv6) [RFC8754][RFC8986] to mobile networks. to mobile networks.
Segment Routing [RFC8402] is a source routing architecture: a node Segment Routing (SR) [RFC8402] is a source-routing architecture: a
steers a packet through an ordered list of instructions called node steers a packet through an ordered list of instructions called
"segments". A segment can represent any instruction, topological or "segments". A segment can represent any instruction, topological or
service based. service based.
SRv6 applied to mobile networks enables a source-routing based mobile SRv6 applied to mobile networks enables a mobile architecture based
architecture, where operators can explicitly indicate a route for the on source routing, where operators can explicitly indicate a route
packets to and from the mobile node. The SRv6 Endpoint nodes serve for the packets to and from the mobile node. The SRv6 Endpoint nodes
as mobile user-plane anchors. serve 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Terminology 2.1. Terminology
* CNF: Cloud-native Network Function CNF: Cloud-native Network Function
* NFV: Network Function Virtualization
* PDU: Packet Data Unit NFV: Network Function Virtualization
* PDU Session: Context of a UE connected to a mobile network.
* UE: User Equipment PDU: Packet Data Unit
* gNB: gNodeB [TS.23501]
* UPF: User Plane Function PDU Session: Context of a UE connected to a mobile network
* VNF: Virtual Network Function
* DN: Data Network UE: User Equipment
* Uplink: from the UE towards the DN
* Downlink: from the DN towards the UE gNB: gNodeB [TS.23501]
UPF: User Plane Function
VNF: Virtual Network Function
DN: Data Network
Uplink: from the UE towards the DN
Downlink: from the DN towards the UE
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, and Binding SID (BSID).
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]: Segment Routing Header (SRH) 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 (next header), SL (the Segments Left field of the SRH),
Endpoint Behavior. FIB (Forwarding Information Base), SA (Source Address), DA
(Destination Address), and SRv6 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 where:
* Source Address is SA, Destination Address is DA, and next-header * Source Address is SA, Destination Address is DA, and next header
is 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 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 but encoded in the SRH format where the rightmost SID in the SRH
is the first SID and the leftmost SID in the SRH is the last SID. is the first SID and the leftmost SID in the SRH is the last SID.
When referring to an SR policy in a high-level use-case, it is When referring to an SR Policy in a high-level use case, it is
simpler 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.
(SA1,DA1) (SA2, DA2) represents an IPv6 packet with: (SA1,DA1) (SA2, DA2) represents an IPv6 packet where:
* Source Address is SA1, Destination Address is DA1, and next-header * Source Address is SA1, Destination Address is DA1, and next header
is IP is IP.
* Source Address is SA2, Destination Address is DA2.
Throughout the document the representation SRH[n] is used as shorter * Source Address is SA2, and Destination Address is DA2.
representation of Segment List[n], as defined in [RFC8754].
Throughout the document, the representation SRH[n] is used as a
shorter representation of Segment List[n], as defined in [RFC8754].
This document uses the following conventions throughout the different This document uses the following conventions throughout the different
examples: examples:
* gNB::1 is an IPv6 address (SID) assigned to the gNB. * gNB::1 is an IPv6 address (SID) assigned to the gNB.
* U1::1 is an IPv6 address (SID) assigned to UPF1. * U1::1 is an IPv6 address (SID) assigned to UPF1.
* U2::1 is an IPv6 address (SID) assigned to UPF2. * U2::1 is an IPv6 address (SID) assigned to UPF2.
* U2:: is the Locator of UPF2. * U2:: is the Locator of 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 used throughout this
document. They are defined in [RFC8986].
* End.DT4: Decapsulation and Specific IPv4 Table Lookup * End.DT4: Decapsulation and Specific IPv4 Table Lookup
* End.DT6: Decapsulation and Specific IPv6 Table Lookup * End.DT6: Decapsulation and Specific IPv6 Table Lookup
* End.DT46: Decapsulation and Specific IP Table Lookup * End.DT46: Decapsulation and Specific IP Table Lookup
* End.DX4: Decapsulation and IPv4 Cross-Connect * End.DX4: Decapsulation and IPv4 Cross-Connect
* End.DX6: Decapsulation and IPv6 Cross-Connect * End.DX6: Decapsulation and IPv6 Cross-Connect
* End.DX2: Decapsulation and L2 Cross-Connect * End.DX2: Decapsulation and L2 Cross-Connect
* 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 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
NFV Infrastructure that are also challenging network operations. On NFV Infrastructure that are also challenging network operations. On
top of this, the number of devices connected is steadily growing, top of this, the number of devices connected is steadily growing,
causing scalability problems in mobile entities as the state to causing scalability problems in mobile entities as the state to
maintain keeps increasing. maintain keeps increasing.
The current architecture of mobile networks does not take into The current architecture of mobile networks does not take into
account the underlying transport. The user-plane is rigidly account the underlying transport. The user plane is rigidly
fragmented into radio access, core and service networks, connected by fragmented into radio access, core, and service networks that
tunneling according to user-plane roles such as access and anchor connected by tunneling according to user-plane roles such as access
nodes. These factors have made it difficult for the operator to and anchor nodes. These factors have made it difficult for the
optimize and operate the data-path. operator to optimize and operate the data path.
In the meantime, applications have shifted to use IPv6, and network In the meantime, applications have shifted to use IPv6, and network
operators have started adopting IPv6 as their IP transport. SRv6, operators have started adopting IPv6 as their IP transport. SRv6,
the IPv6 dataplane instantiation of Segment Routing [RFC8402], the IPv6 data plane instantiation of Segment Routing [RFC8402],
integrates both the application data-path and the underlying integrates both the application data path and the underlying
transport layer into a single protocol, allowing operators to transport layer into a single protocol, allowing operators to
optimize the network in a simplified manner and removing forwarding optimize the network in a simplified manner and removing forwarding
state from the network. It is also suitable for virtualized state from the network. It is also suitable for virtualized
environments, like VNF/CNF to VNF/CNF networking. SRv6 has been environments, like VNF/CNF-to-VNF/CNF networking. SRv6 has been
deployed in dozens of networks deployed in dozens of networks [SRV6-DEPLOY-STAT].
[I-D.matsushima-spring-srv6-deployment-status].
SRv6 defines the network-programming concept [RFC8986]. Applied to SRv6 defines the network programming concept [RFC8986]. Applied to
mobility, SRv6 can provide the user-plane behaviors needed for mobility, SRv6 can provide the user-plane behaviors needed for
mobility management. SRv6 takes advantage of the underlying mobility management. SRv6 takes advantage of the underlying
transport awareness and flexibility together with the ability to also transport awareness and flexibility together with the ability to also
include services to optimize the end-to-end mobile dataplane. include services to optimize the end-to-end mobile data plane.
The use-cases for SRv6 mobility are discussed in The use cases for SRv6 mobility are discussed in [SRV6-MOB-USECASES],
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases], and the and the architectural benefits are discussed in
architectural benefits are discussed in [I-D.kohno-dmm-srv6mob-arch]. [SRV6-MOB-ARCH-DISCUSS].
4. 3GPP Reference Architecture 4. 3GPP Reference Architecture
This section presents the 3GPP Reference Architecture and possible This section presents the 3GPP reference architecture and possible
deployment scenarios. deployment scenarios.
Figure 1 shows a reference diagram from the 5G packet core Figure 1 shows a reference diagram from the 5G packet core
architecture [TS.23501]. architecture [TS.23501].
The user plane described in this document does not depend on any The user plane described in this document does not depend on any
specific architecture. The 5G packet core architecture as shown is specific architecture. The 5G packet core architecture as shown is
based on the 3GPP standards. based on the 3GPP standards.
+-----+ +-----+
skipping to change at page 7, line 4 skipping to change at line 297
[N2] / +-----+ [N2] / +-----+
+------/ | 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
* UE: User Equipment UE: User Equipment
* 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)
* UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane)
* UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane) UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane)
* SMF: Session Management Function
* AMF: Access and Mobility Management Function UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane)
* DN: Data Network e.g., operator services, Internet access
SMF: Session Management Function
AMF: Access and Mobility Management Function
DN: Data Network, e.g., operator services and 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 a case. also work in such a 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
IPv4 address, or IPv6 prefix, from the DHCP block of its UPF. The IPv4 address, or IPv6 prefix, from the DHCP block of its UPF. The
UPF advertises that IP address block toward the Internet, ensuring UPF advertises that IP address block toward the Internet, ensuring
that return traffic is routed to the right UPF. that return traffic is routed to the right UPF.
5. User-plane modes 5. User-Plane Modes
This section introduces an SRv6 based mobile user-plane.It presents This section introduces an SRv6-based mobile user plane. It presents
two different "modes" that vary with respect to the use of SRv6. The two different "modes" that vary with respect to the use of SRv6.
first one is the "Traditional mode", which inherits the current 3GPP
mobile architecture. In this mode GTP-U protocol [TS.29281] is The first mode is the "Traditional mode", which inherits the current
replaced by SRv6, however the N3, N9 and N6 interfaces are still 3GPP mobile architecture. In this mode, the GTP-U protocol
point-to-point interfaces with no intermediate waypoints as in the [TS.29281] is replaced by SRv6. However, the N3, N9, and N6
current mobile network architecture. interfaces are still point-to-point interfaces with no intermediate
waypoints as in the current mobile network architecture.
The second mode is the "Enhanced mode". This is an evolution from The second mode is the "Enhanced mode". This is an evolution from
the "Traditional mode". In this mode the N3, N9 or N6 interfaces the "Traditional mode". In this mode, the N3, N9, or N6 interfaces
have intermediate waypoints -SIDs- that are used for Traffic have intermediate waypoints (SIDs) that are used for traffic
Engineering or VNF purposes transparent to 3GPP functionalities. engineering or VNF purposes transparent to 3GPP functionalities.
This results in optimal end-to-end policies across the mobile network This results in optimal end-to-end policies across the mobile network
with transport and services awareness. with transport and services awareness.
In both, the Traditional and the Enhanced modes, this document In both the Traditional and the Enhanced modes, this document assumes
assumes that the gNB as well as the UPFs are SR-aware (N3, N9 and that the gNB as well as the UPFs are SR-aware (N3, N9, and
-potentially- N6 interfaces are SRv6). potentially N6 interfaces are SRv6).
In addition to those two modes, this document introduces three In addition to those two modes, this document introduces three
mechanisms for interworking with legacy access networks (those where mechanisms for interworking with legacy access networks (those where
the N3 interface is unmodified). In this document they are the N3 interface is unmodified). In this document, they are
introduced as a variant to the Enhanced mode, however they are introduced as a variant to the Enhanced mode, but they are equally
equally applicable to the Traditional mode. applicable to the Traditional mode.
One of these mechanisms is designed to interwork with legacy gNBs One of these mechanisms is designed to interwork with legacy gNBs
using GTP-U/IPv4. The second mechanism is designed to interwork with using GTP-U/IPv4. The second mechanism is designed to interwork with
legacy gNBs using GTP-U/IPv6. The third of those mechanisms is legacy gNBs using GTP-U/IPv6. The third mechanism is another mode
another mode that allows deploying SRv6 when legacy gNBs and UPFs that allows deploying SRv6 when legacy gNBs and UPFs still run GTP-U.
that still run GTP-U.
This document uses SRv6 Segment Endpoint Behaviors defined in This document uses the SRv6 Endpoint Behaviors defined in [RFC8986]
[RFC8986] as well as new SRv6 Segment Endpoint Behaviors designed for as well as the new SRv6 Endpoint Behaviors designed for the mobile
the mobile user plane that are defined in this document in Section 6. user plane that are defined in Section 6 of this document.
5.1. Traditional mode 5.1. Traditional Mode
In the traditional mode, the existing mobile UPFs remain unchanged In the Traditional mode, the existing mobile UPFs remain unchanged
with the sole exception of the use of SRv6 as the data plane instead with the sole exception of the use of SRv6 as the data plane instead
of GTP-U. There is no impact to the rest of the mobile system. of GTP-U. There is no impact to the rest of the mobile system.
In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1
with a specific GTP-U tunnel (Tunnel Endpoint Identifier - TEID). with a specific GTP-U tunnel (Tunnel Endpoint Identifier (TEID)).
This 1-for-1 mapping is mirrored here to replace GTP-U encapsulation This 1-for-1 mapping is mirrored here to replace GTP-U encapsulation
with the SRv6 encapsulation, while not changing anything else. There with the SRv6 encapsulation, while not changing anything else. There
will be a unique SRv6 SID associated with each PDU Session, and the will be a unique SRv6 SID associated with each PDU Session, and the
SID list only contains a single SID. SID list only contains a single SID.
The traditional mode minimizes the changes required to the mobile The Traditional mode minimizes the required changes 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 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 signaling is used, and the gNB/UPF decides to use SRv6
based on signaled GTP-U parameters per local policy. The only based on signaled GTP-U parameters per local policy. The only
information from the GTP-U parameters used for the SRv6 policy is the information from the GTP-U parameters used for the SRv6 policy is the
TEID, QFI -QoS Flow Identifier-, and the IPv6 Destination Address. TEID, QFI (QoS Flow Identifier), and the IPv6 Destination Address.
Our example topology is shown in Figure 2. The gNB and the UPFs are Our example topology is shown in Figure 2. The gNB and the UPFs are
SR-aware. In the descriptions of the uplink and downlink packet SR-aware. In the descriptions of the uplink and downlink packet
flow, A is an IPv6 address of the UE, and Z is an IPv6 address flow, A is an IPv6 address of the UE, and Z is an IPv6 address
reachable within the Data Network DN. A new SRv6 Endpoint Behavior, reachable within the DN. End.MAP, a new SRv6 Endpoint Behavior
End.MAP, defined in Section 6.2, is used. defined in Section 6.2, is used.
________ ________
SRv6 SRv6 / \ SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node
Figure 2: Traditional mode - example topology Figure 2: Traditional Mode - Example Topology
5.1.1. Packet flow - Uplink 5.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, U1::1) (A,Z) -> H.Encaps.Red <U1::1> gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
When the UE packet arrives at the gNB, the gNB performs a When the UE packet arrives at the gNB, the gNB performs an
H.Encaps.Red operation. Since there is only one SID, there is no H.Encaps.Red operation. Since there is only one SID, there is no
need to push an SRH (reduced SRH). gNB only adds an outer IPv6 header need to push an SRH (reduced SRH). gNB only adds an outer IPv6 header
with IPv6 DA U1::1. gNB obtains the SID U1::1 from the existing with IPv6 DA U1::1. gNB obtains the SID U1::1 from the existing
control plane (N2 interface). U1::1 represents an anchoring SID control plane (N2 interface). U1::1 represents an anchoring SID
specific for that session at UPF1. specific for that session at UPF1.
When the packet arrives at UPF1, the SID U1::1 is associated with the When the packet arrives at UPF1, the SID U1::1 is associated with the
End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 with U2::1,
that belongs to the next UPF (U2). which belongs to the next UPF (U2).
When the packet arrives at UPF2, the SID U2::1 corresponds to an When the packet arrives at UPF2, the SID U2::1 corresponds to an
End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates
the packet, performs a lookup in a specific table associated with the packet, performs a lookup in a specific table associated with
that mobile network and forwards the packet toward the data network that mobile network, and forwards the packet toward the DN.
(DN).
5.1.2. Packet flow - Downlink 5.1.2. Packet Flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) UPF2_in : (Z,A)
UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2> UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
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 flow into a When the packet arrives at the UPF2, the UPF2 maps that flow into a
PDU Session. This PDU Session is associated with the segment PDU Session. This PDU Session is associated with the segment
endpoint <U1::2>. UPF2 performs a H.Encaps.Red operation, endpoint <U1::2>. UPF2 performs an H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with no SRH since encapsulating the packet into a new IPv6 header with no SRH since
there is only one SID. there is only one SID.
Upon packet arrival on UPF1, the SID U1::2 is a local SID associated Upon packet arrival on UPF1, the SID U1::2 is a local SID associated
with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next
anchoring point and replaces U1::2 by gNB::1, that belongs to the anchoring point and replaces U1::2 with gNB::1, which belongs to the
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).
gNB decapsulates the packet, removing the IPv6 header and all its The 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 [SR-SERV-PROG], thanks
[I-D.ietf-spring-sr-service-programming], thanks to the use of to the use of multiple SIDs in the SID list (instead of a direct
multiple SIDs in the SID list (instead of a direct connectivity in connectivity in between UPFs with no intermediate waypoints as in
between UPFs with no intermediate waypoints as in Traditional Mode). 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 [water/energy] connected to the same cell) to improve meters (water and energy) connected to the same cell) to improve
scalability. scalability.
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. A local specifically, a single IPv6 address is provided to the gNB. A local
policy instructs the gNB to use SRv6. policy instructs the gNB to use SRv6.
The gNB resolves the IP address received via the control plane into a The gNB resolves the IP address received via the control plane into a
SID list. The resolution mechanism is out of the scope of this SID list. The resolution mechanism is out of the scope of this
document. document.
Note that the SIDs MAY use the arguments Args.Mob.Session Note that the SIDs MAY use the argument Args.Mob.Session
(Section 6.1) if required by the UPFs. (Section 6.1) if required by the UPFs.
Figure 3 shows an Enhanced mode topology. The gNB and the UPF are Figure 3 shows an Enhanced mode topology. The gNB and the UPF are
SR-aware. The Figure shows two service segments, S1 and C1. S1 SR-aware. The figure shows two service segments, S1 and C1. S1
represents a VNF in the network, and C1 represents an intermediate represents a VNF in the network, and C1 represents an intermediate
router used for Traffic Engineering purposes to enforce a low-latency router used for traffic engineering purposes to enforce a low-latency
path in the network. Note that neither S1 nor C1 are required to path in the network. Note that neither S1 nor C1 are required to
have an N4 interface. have an N4 interface.
+----+ SRv6 _______ +----+ SRv6 _______
SRv6 --| C1 |--[N3] / \ SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / |UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/ +--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node SRv6 node \ +----+ / SRv6 node
-| S1 |- -| S1 |-
+----+ +----+
SRv6 node SRv6 node
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)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U1::1> gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U1::1>
S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z) S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z)
C1_out : (gNB, U1::1)(A,Z) ->End with PSP C1_out : (gNB, U1::1)(A,Z) ->End with PSP
UPF1_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 resolves B into a SID list. <S1, C1, U1::1>. address B. gNB resolves B into a 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. The End with PSP functionality referes to the forward the packet. The "End with PSP" functionality refers to the
Endpoint behavior with Penultimate Segment Popping as defined in Endpoint Behavior with Penultimate Segment Popping as defined in
RFC8986. [RFC8986].
When the packet arrives at UPF1, the active segment (U1::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 DN.
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:
UPF1_in : (Z,A) ->UPF1 maps the flow w/ UPF1_in : (Z,A) ->UPF1 maps the flow w/
SID list <C1,S1, gNB> SID list <C1,S1, gNB>
UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red
C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A) C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A)
S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP S1_out : (U1::1, gNB::1)(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 UPF1, the UPF1 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 UPF1 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 towards the UE. The SID gNB::1 IPv6 header, and forwards the traffic towards the UE. The SID gNB::1
is one example of a SID associated to this service. is one example of a SID associated to this service.
Note that there are several means to provide the UE session Note that there are several means to provide the UE session
aggregation. The decision on which one to use is a local decision aggregation. The decision about which one to use is a local decision
made by the operator. One option is to use the Args.Mob.Session made by the operator. One option is to use Args.Mob.Session
(Section 6.1). Another option comprises the gNB performing an IP (Section 6.1). Another option comprises the gNB performing an IP
lookup on the inner packet by using the End.DT4, End.DT6, and lookup on the inner packet by using the End.DT4, End.DT6, and
End.DT2U behaviors. End.DT2U behaviors.
5.2.3. Scalability 5.2.3. Scalability
The Enhanced Mode improves scalability since it allows the The Enhanced mode improves scalability since it allows the
aggregation of several UEs under the same SID list. For example, in aggregation of several UEs under the same SID list. For example, in
the case of stationary residential meters that are connected to the the case of stationary residential meters that are connected to the
same cell, all such devices can share the same SID list. This same cell, all such devices can share the same SID list. This
improves scalability compared to Traditional Mode (unique SID per UE) improves scalability compared to Traditional mode (unique SID per UE)
and compared to GTP-U (TEID per UE). and compared to GTP-U (TEID per UE).
5.3. Enhanced mode with unchanged gNB GTP-U behavior 5.3. Enhanced Mode with Unchanged gNB GTP-U Behavior
This section describes two mechanisms for interworking with legacy This section describes two mechanisms for interworking with legacy
gNBs that still use GTP-U: one for IPv4, and another for IPv6. gNBs that still use GTP-U: one for IPv4 and another for IPv6.
In the interworking scenarios as illustrated in Figure 4, the gNB In the interworking scenarios illustrated in Figure 4, the gNB does
does not support SRv6. The gNB supports GTP-U encapsulation over not support SRv6. The gNB supports GTP-U encapsulation over IPv4 or
IPv4 or IPv6. To achieve interworking, an SR Gateway (SRGW) entity IPv6. To achieve interworking, an SR Gateway (SRGW) entity is added.
is added. The SRGW is a new entity that maps the GTP-U traffic into The SRGW is a new entity that maps the GTP-U traffic into SRv6. It
SRv6. It is deployed at the boundary of the SR Domain and performs is deployed at the boundary of the SR domain and performs the mapping
the mapping functionality for inbound/outbound traffic. functionality for inbound and outbound traffic.
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-U SRv6 / \ IP GTP-U SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/ +--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node SR Gateway SRv6 node
Figure 4: Example topology for interworking Figure 4: Example Topology for Interworking
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. the Traditional mode and the Enhanced mode.
5.3.1. Interworking with IPv6 GTP-U 5.3.1. Interworking with IPv6 GTP-U
In this interworking mode the gNB at the N3 interface uses GTP-U over In this interworking mode, the gNB at the N3 interface uses GTP-U
IPv6. over IPv6.
Key points: Key points:
* The gNB is unchanged (control-plane or user-plane) and * The gNB is unchanged (control plane or user plane) and
encapsulates into GTP-U (N3 interface is not modified). encapsulates into GTP-U (N3 interface is not modified).
* The 5G Control-Plane towards the gNB (N2 interface) is unmodified,
though multiple UPF addresses need to be used - one IPv6 address * The 5G control plane towards the gNB (N2 interface) is unmodified,
(i.e. a BSID at the SRGW) is needed per <SLA, PDU session type>. though multiple UPF addresses need to be used. One IPv6 address
(i.e., a BSID at the SRGW) is needed per <SLA, PDU Session Type>.
The SRv6 SID is different depending on the required <SLA, PDU The SRv6 SID is different depending on the required <SLA, PDU
session type> combination. Session Type> combination.
* In the uplink, the SRGW removes GTP-U header, finds the SID list
related to the IPv6 DA, and adds SRH with the SID list. * In the uplink, the SRGW removes the GTP-U header, finds the SID
list related to the IPv6 DA, and adds SRH with the SID list.
* There is no state for the downlink at the SRGW. * There is no state for the downlink at the SRGW.
* There is simple state in the uplink at the SRGW; using Enhanced * There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. An SR policy is mode results in fewer SR Policies on this node. An SR Policy is
shared across UEs as long as they belong to the same context shared across UEs as long as they belong to the same context
(i.e., tenant). A set of many different policies (i.e., different (i.e., tenant). A set of many different policies (i.e., different
SLAs) increases the amount of state required. SLAs) increases the amount of state required.
* When a packet from the UE leaves the gNB, it is SR-routed. This * When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo]. simplifies network slicing [RFC9350].
* In the uplink, the SRv6 BSID steers traffic into an SR policy when
* In the uplink, the SRv6 BSID steers traffic into an SR Policy when
it arrives at the SRGW. it arrives at the SRGW.
An example topology is shown in Figure 5. An example topology is shown in Figure 5.
S1 and C1 are two service segments. S1 represents a VNF in the S1 and C1 are two service segments. S1 represents a VNF in the
network, and C1 represents a router configured for Traffic network, and C1 represents a router configured for traffic
Engineering. engineering.
+----+ +----+
IPv6/GTP-U -| S1 |- ___ IPv6/GTP-U -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP-U \ +------+ / +----+ +------+ \___ GTP-U \ +------+ / +----+ +------+ \___
-| SRGW |- SRv6 SRv6 -| SRGW |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP-U behavior Figure 5: Enhanced Mode with Unchanged gNB IPv6/GTP-U 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::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW SID at the SRGW
S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z) S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::T)(A,Z) -> End with PSP C1_out : (SRGW, U2::T)(A,Z) -> End with PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates bearer for that session. The gNB, which is unmodified, encapsulates
the packet into IPv6, UDP, and GTP-U headers. The IPv6 DA B, and the the packet into IPv6, UDP, and GTP-U headers. The IPv6 DA B and the
GTP-U TEID T are the ones received in the N2 interface. GTP-U 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-U headers, and pushes an IPv6 header with its the IPv6, UDP, and GTP-U 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 at least one instance of the End.M.GTP6.D SID this Binding SID. There is at least one instance of the End.M.GTP6.D
per PDU type. 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.
When the packet arrives at UPF2, the active segment is (U2::T) which When the packet arrives at UPF2, the active segment is (U2::T), 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 DN.
5.3.1.2. Packet flow - Downlink 5.3.1.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 with UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB> <C1, S1, SRGW::TEID,gNB>
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red
C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A)
S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A)
SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A) gNB_out : (Z,A)
skipping to change at page 15, line 28 skipping to change at line 705
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 all its extensions headers. The SRGW generates new IPv6, UDP,
and GTP-U headers. The new IPv6 DA is the gNB which is the last SID and GTP-U headers. The new IPv6 DA is the gNB, which is the last SID
in the received SRH. The TEID in the generated GTP-U header is an in the received SRH. The TEID in the generated GTP-U header is also
argument of the received End.M.GTP6.E SID. The SRGW pushes the an argument of the received End.M.GTP6.E SID. The SRGW pushes the
headers to the packet and forwards the packet toward the gNB. There headers to the packet and forwards the packet toward the gNB. There
is one instance 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/ Once the packet arrives at the gNB, the packet is a regular IPv6/
GTP-U packet. The gNB looks for the specific radio bearer for that GTP-U packet. The gNB looks for the specific radio bearer for that
TEID and forwards it on the bearer. This gNB behavior is not TEID and forwards it on the bearer. This gNB behavior is not
modified from current and previous generations. modified from 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 downlink traffic, the SRGW is stateless. All the state is in the
the SRH pushed by the UPF2. The UPF2 must have the UE states since SRH pushed by the UPF2. The UPF2 must have the UE state since it is
it is the UE's session anchor point. the UE's session anchor point.
For the uplink traffic, the state at the SRGW does not necessarily For uplink traffic, the state at the SRGW does not necessarily need
need to be unique per PDU Session; the SR policy can be shared among to be unique per PDU Session; the SR Policy can be shared among UEs.
UEs. This enables more scalable SRGW deployments compared to a This enables more scalable SRGW deployments compared to a solution
solution holding millions of states, one or more per UE. holding millions of states, one or more per UE.
5.3.2. Interworking with IPv4 GTP-U 5.3.2. Interworking with IPv4 GTP-U
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:
* The gNB is unchanged and encapsulates packets into GTP-U (the N3 * The gNB is unchanged and encapsulates packets into GTP-U (the N3
interface is not modified). interface is not modified).
* N2 signaling is not changed, though multiple UPF addresses need to * N2 signaling is not changed, though multiple UPF addresses need to
be provided - one for each PDU Session Type. be provided -- one for each PDU Session Type.
* In the uplink, traffic is classified by SRGW's classification * In the uplink, traffic is classified by SRGW's classification
engine and steered into an SR policy. The SRGW may be implemented engine and steered into an SR Policy. The SRGW may be implemented
in a UPF or as a separate entity. How the classification engine in a UPF or as a separate entity. How the classification engine
rules are set up is outside the scope of this document, though one rules are set up is outside the scope of this document, though one
example is using BGP signaling from a Mobile User Plane Controller example is using BGP signaling from a Mobile User Plane (MUP)
[I-D.mhkk-dmm-srv6mup-architecture]. Controller [MUP-SR-ARCH].
* SRGW removes GTP-U header, finds the SID list related to DA, and
adds an SRH with the SID list.
An example topology is shown in Figure 6. In this mode the gNB is an * SRGW removes the GTP-U header, finds the SID list related to DA,
unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, and adds an SRH with the SID list.
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,
the SRGW maps the IPv4/GTP-U traffic to SRv6. the SRGW maps the IPv4/GTP-U 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-U -| S1 |- ___ IPv4/GTP-U -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP-U \ +------+ / +----+ +------+ \___ GTP-U \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6 -| UPF1 |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 6: Enhanced mode with unchanged gNB IPv4/GTP-U behavior Figure 6: Enhanced Mode with Unchanged gNB IPv4/GTP-U 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
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-Uheaders. The IPv4 DA, B, the packet into a new IPv4, UDP, and GTP-U headers. The IPv4 DA, B,
and the GTP-UTEID are the ones received at the N2 interface. and the GTP-UTEID are the ones received at the N2 interface.
When the packet arrives at the SRGW for UPF1, the SRGW has an When the packet arrives at the SRGW for UPF1, the SRGW has a
classification engine rule for incoming traffic from the gNB, that classification engine rule for incoming traffic from the gNB that
steers the traffic into an SR policy by using the function steers the traffic into an SR Policy by using the function
H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and
pushes an IPv6 header with its own SRH containing the SIDs related to pushes an IPv6 header with its own SRH containing the SIDs related to
the SR policy associated with this traffic. The SRGW forwards the SR Policy associated with this traffic. The SRGW forwards
according to the new IPv6 DA. 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 DN.
Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U
differs. This is due to the fact that IPv6/GTP-U can leverage the differ. This is due to the fact that IPv6/GTP-U can leverage the
remote steering capabilities provided by the Segment Routing BSID. remote steering capabilities provided by the Segment Routing BSID.
In IPv4 this construct is not available, and building a similar In IPv4, this construct is not available, and building a similar
mechanism would require a significant address consumption. mechanism would require a significant address consumption.
5.3.2.2. Packet flow - Downlink 5.3.2.2. Packet Flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,GW::SA:DA:TEID> <C1, S1,GW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (GW, gNB)(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)
skipping to change at page 18, line 4 skipping to change at line 819
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,GW::SA:DA:TEID> <C1, S1,GW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (GW, gNB)(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 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.
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 IPv4, UDP, and
GTP-U headers. The IPv4 SA and DA are received as SID arguments. GTP-U headers. The IPv4 SA and DA are received as SID arguments.
The TEID in the generated GTP-U header is also the arguments of the The TEID in the generated GTP-U header is the argument 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/ When the packet arrives at the gNB, the packet is a regular IPv4/
GTP-U packet. The gNB looks for the specific radio bearer for that GTP-U packet. The gNB looks for the specific radio bearer for that
TEID and forwards it on the bearer. This gNB behavior is not TEID and forwards it on the bearer. This gNB behavior is not
modified from current and previous generations. modified 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 downlink traffic, the SRGW is stateless. All the state is in the
the SRH pushed by the UPF2. The UPF must have this UE-base state SRH pushed by the UPF2. The UPF must have this UE-base state anyway
anyway (since it is its anchor point). (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per For uplink traffic, the state at the SRGW is dedicated on a per-UE/
UE/session basis according to a classification engine. There is session basis according to a classification engine. There is state
state for steering the different sessions in the form of an SR for steering the different sessions in the form of an SR Policy.
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
This section presents two mechanisms for interworking with gNBs and This section presents two mechanisms for interworking with gNBs and
UPFs that do not support SRv6. These mechanisms are used to support UPFs that do not support SRv6. These mechanisms are used to support
GTP-U over IPv4 and IPv6. GTP-U over IPv4 and IPv6.
Even though these methods are presented as an extension to the Even though these methods are presented as an extension to the
"Enhanced mode", it is straightforward in its applicability to the Enhanced mode, they are also applicable to the Traditional mode.
"Traditional mode".
5.4. SRv6 Drop-in Interworking 5.4. SRv6 Drop-In Interworking
This section introduces another mode useful for legacy gNB and UPFs This section introduces another mode useful for legacy gNB and UPFs
that still operate with GTP-U. This mode provides an SRv6-enabled that still operate with GTP-U. This mode provides an SRv6-enabled
user plane in between two GTP-U tunnel endpoints. user plane in between two GTP-U tunnel endpoints.
This mode employs two SRGWs that map GTP-U traffic to SRv6 and vice- This mode employs two SRGWs that map GTP-U traffic to SRv6 and vice
versa. versa.
Unlike other interworking modes, in this mode both of the mobility Unlike other interworking modes, in this mode, both of the mobility
overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or overlay endpoints use GTP-U. Two SRGWs are deployed in either an N3
N9 interface to realize an intermediate SR policy. or N9 interface to realize an intermediate SR Policy.
+----+ +----+
-| 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
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 is sent to the gNB, which is unmodified When a packet destined to Z is sent to the gNB, which is unmodified
(control-plane and user-plane remain GTP-U), gNB performs (control plane and user plane remain GTP-U), gNB performs
encapsulation into a new IP, UDP, and GTP-U headers. The IPv6 DA, encapsulation into new IP, UDP, and GTP-U headers. The IPv6 DA,
U::1, and the GTP-U TEID are the ones received at the N2 interface. U::1, and GTP-U 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. U::1 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 U::1 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-U headers, and pushes an IPv6 header removes the IPv6, UDP, and GTP-U headers and pushes an IPv6 header
with its own SRH containing the SIDs bound to the SR policy with its own SRH containing the SIDs bound to the SR Policy
associated with this Binding SID. There is one instance of the associated with this Binding SID. There is one instance of the
End.M.GTP6.D.Di 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 all its extensions headers. The SRGW generates new IPv6, UDP, and
GTP 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-U header is an argument received SRH. The TEID in the generated GTP-U header is an argument
of the received End.M.GTP6.E SID. The SRGW pushes the headers to the of the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet toward UPF. There is one instance of packet and forwards the packet toward UPF. There is one instance of
the End.M.GTP6.E SID per PDU type. the End.M.GTP6.E SID per PDU type.
Once the packet arrives at UPF, 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
This section introduces new SRv6 Segment Endpoint Behaviors for the This section introduces new SRv6 Endpoint Behaviors for the mobile
mobile user-plane. The behaviors described in this document are user plane. The behaviors described in this document are compatible
compatible with the NEXT and REPLACE flavors defined in with the NEXT and REPLACE flavors defined in [SRV6-SRH-COMPRESSION].
[I-D.ietf-spring-srv6-srh-compression].
6.1. Args.Mob.Session 6.1. Args.Mob.Session
Args.Mob.Session provide per-session information for charging, Args.Mob.Session provides per-session information for charging,
buffering or other purposes required by some mobile nodes. The buffering, or other purposes required by some mobile nodes. The
Args.Mob.Session argument format is used in combination with End.Map, Args.Mob.Session argument format is used in combination with the
End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 behaviors. Note End.Map, End.DT4/End.DT6/End.DT46, and End.DX4/End.DX6/End.DX2
that proposed format is applicable for 5G networks, while similar behaviors. Note that proposed format is applicable for 5G networks,
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')|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 8: Args.Mob.Session format Figure 8: Args.Mob.Session Format
* QFI: QoS Flow Identifier [TS.38415] QFI: QoS Flow Identifier [TS.38415].
* 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 uplink
Plane traffic to QoS Flows without SMF provided QoS rules. user-plane traffic to QoS flows without SMF-provided QoS rules.
* 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
ignored on receipt. on receipt.
* PDU Session ID: Identifier of PDU Session. The GTP-U equivalent
is TEID.
Args.Mob.Session is required in case that one SID aggregates multiple PDU Session ID: Identifier of PDU Session. The GTP-U equivalent is
PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated TEID.
per PDU session, Args.Mob.Session helps the UPF to perform the
behaviors which require per QFI and/or per PDU Session granularity. Args.Mob.Session is required in case one SID aggregates multiple PDU
Sessions. Since the SRv6 SID is likely NOT to be instantiated per
PDU Session, Args.Mob.Session helps the UPF to perform the behaviors
that require granularity per QFI and/or per PDU Session.
Note that the encoding of user-plane messages (e.g., Echo Request, Note that the encoding of user-plane messages (e.g., Echo Request,
Echo Reply, Error Indication and End Marker) is out of the scope of Echo Reply, Error Indication, and End Marker) is out of the scope of
this draft. [I-D.murakami-dmm-user-plane-message-encoding] defines this document. [SRV6-UP-MSG-ENCODING] defines one possible encoding
one possible encoding. method.
6.2. End.MAP 6.2. End.MAP
The "Endpoint behavior with SID mapping" behavior (End.MAP for short) End.MAP (Endpoint Behavior with SID mapping) is used in several
is used in several scenarios. Particularly in mobility, End.MAP is scenarios. Particularly in mobility, End.MAP is used by the
used by the intermediate UPFs. intermediate UPFs.
When node N receives a packet whose IPv6 DA is D and D is a local When node N receives a packet whose IPv6 DA is D and D is a local
End.MAP SID, N does: End.MAP SID, N does the following:
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 with
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. Update the IPv6 DA with the new mapped SID S05. Update the IPv6 DA with the new mapped SID
S06. Submit the packet to the egress IPv6 FIB lookup for S06. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
Notes: The SRH is not modified (neither the SID, nor the SL value). Note: The SRH is not modified (neither the SID nor the SL value).
6.3. End.M.GTP6.D 6.3. End.M.GTP6.D
The "Endpoint behavior with IPv6/GTP-U decapsulation into SR policy" End.M.GTP6.D (Endpoint Behavior with IPv6/GTP-U decapsulation into SR
behavior (End.M.GTP6.D for short) is used in interworking scenario Policy) is used in the interworking scenario for the uplink towards
for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any SRGW from the legacy gNB using IPv6/GTP. Any SID instance of this
SID instance of this behavior is associated with an SR Policy B and behavior is associated with an SR Policy B and an IPv6 Source Address
an IPv6 Source Address S. S.
When the SR Gateway node N receives a packet destined to D and D is a When the SR Gateway node N receives a packet destined to D, and D is
local End.M.GTP6.D SID, N does: a local End.M.GTP6.D SID, N does the following:
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 with
Code 0 (Erroneous header field encountered), Code 0 (Erroneous header field encountered) and
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 the
following:
S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) { S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) {
S02. Copy the GTP-U TEID and QFI to buffer memory S02. Copy the GTP-U TEID and QFI to buffer memory
S03. Pop the IPv6, UDP, and GTP-U Headers S03. Pop the IPv6, UDP, and GTP-U 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 S S05. Set the outer IPv6 SA to S
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 (NH) fields Hop Limit, and Next Header (NH) fields
S08. Write in the SRH[0] the Args.Mob.Session based on S08. Write in the SRH[0] the Args.Mob.Session based on
the information of buffer memory the information in buffer memory
S09. Submit the packet to the egress IPv6 FIB lookup and S09. Submit the packet to the egress IPv6 FIB lookup for
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: S07. The NH is set based on the SID parameter. There is one Notes:
instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
NH is already known in advance. For the IPv4v6 PDU Session Type, in
addition the router inspects the first nibble of the PDU to know the
NH value.
The last segment SHOULD be followed by an Args.Mob.Session argument * In line S07, the NH is set based on the SID parameter. There is
space which is used to provide the session identifiers, as shown in one instantiation of the End.M.GTP6.D SID per PDU Session Type;
line S08. hence, the NH is already known in advance. In addition, for the
IPv4v6 PDU Session Type, the router inspects the first nibble of
the PDU to know the NH value.
* The last segment SHOULD be followed by an Args.Mob.Session
argument space, which is used to provide the session identifiers,
as shown in line S08.
6.4. End.M.GTP6.D.Di 6.4. End.M.GTP6.D.Di
The "Endpoint behavior with IPv6/GTP-U decapsulation into SR policy End.M.GTP6.D.Di (Endpoint Behavior with IPv6/GTP-U decapsulation into
for Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SR Policy for Drop-in Mode) is used in the SRv6 drop-in interworking
SRv6 drop-in interworking scenario described in Section 5.4. The scenario described in Section 5.4. The difference between
difference between End.M.GTP6.D as another variant of IPv6/GTP End.M.GTP6.D as another variant of the IPv6/GTP decapsulation
decapsulation function is that the original IPv6 DA of the GTP-U function is that the original IPv6 DA of the GTP-U packet is
packet is preserved as the last SID in SRH. preserved as the last SID in SRH.
Any SID instance of this behavior is associated with an SR Policy B Any SID instance of this behavior is associated with an SR Policy B
and an IPv6 Source Address S. and an IPv6 Source Address S.
When the SR Gateway node N receives a packet destined to D and D is a When the SR Gateway node N receives a packet destined to D, and D is
local End.M.GTP6.D.Di SID, N does: a local End.M.GTP6.D.Di SID, N does the following:
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 with
Code 0 (Erroneous header field encountered), Code 0 (Erroneous header field encountered) and
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 the
following:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Copy D to buffer memory S02. Copy D to buffer memory
S03. Pop the IPv6, UDP, and GTP-U Headers S03. Pop the IPv6, UDP, and GTP-U 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 S S05. Set the outer IPv6 SA to S
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. Prepend D to the SRH (as SRH[0]) and set SL accordingly S08. Prepend D to the SRH (as SRH[0]) and set SL accordingly
S09. Submit the packet to the egress IPv6 FIB lookup and S09. Submit the packet to the egress IPv6 FIB lookup for
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: S07. The NH is set based on the SID parameter. There is one Notes:
instantiation of the End.M.GTP6.Di SID per PDU Session Type, hence
the NH is already known in advance. For the IPv4v6 PDU Session Type,
in addition the router inspects the first nibble of the PDU to know
the NH value.
S SHOULD be an End.M.GTP6.E SID instantiated at the SR gateway. * In line S07, the NH is set based on the SID parameter. There is
one instantiation of the End.M.GTP6.Di SID per PDU Session Type;
hence, the NH is already known in advance. In addition, for the
IPv4v6 PDU Session Type, the router inspects the first nibble of
the PDU to know the NH value.
* S SHOULD be an End.M.GTP6.E SID instantiated at the SR Gateway.
6.5. End.M.GTP6.E 6.5. End.M.GTP6.E
The "Endpoint behavior with encapsulation for IPv6/GTP-U tunnel" End.M.GTP6.E (Endpoint Behavior with encapsulation for IPv6/GTP-U
behavior (End.M.GTP6.E for short) is used among others in the tunnel" behavior) is used among others in the interworking scenario
interworking scenario for the downlink toward the legacy gNB using for the downlink toward the legacy gNB using IPv6/GTP.
IPv6/GTP.
The prefix of End.M.GTP6.E SID MUST be followed by the The prefix of End.M.GTP6.E SID MUST be followed by the
Args.Mob.Session argument space which is used to provide the session Args.Mob.Session argument space, which is used to provide the session
identifiers. identifiers.
When the SR Gateway node N receives a packet destined to D, and D is When the SR Gateway node N receives a packet destined to D, and D 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 with
Code 0 (Erroneous header field encountered), Code 0 (Erroneous header field encountered) and
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 the
following:
S01. Copy SRH[0] and D to buffer memory S01. Copy SRH[0] and D to buffer memory
S02. Pop the IPv6 header and all its extension headers S02. Pop the IPv6 header and all its extension headers
S03. Push a new IPv6 header with a UDP/GTP-U Header S03. Push a new IPv6 header with a UDP/GTP-U header
S04. Set the outer IPv6 SA to S S04. Set the outer IPv6 SA to S
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-U TEID (from buffer memory) S07. Set the GTP-U 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 for
transmission to the new destination transmission to the new destination
Notes: An End.M.GTP6.E SID MUST always be the penultimate SID. The Notes:
TEID is extracted from the argument space of the current SID.
The source address S SHOULD be an End.M.GTP6.D SID instantiated at * An End.M.GTP6.E SID MUST always be the penultimate SID. The TEID
the egress SR gateway. is extracted from the argument space of the current SID.
* The source address S SHOULD be an End.M.GTP6.D SID instantiated at
the egress SR Gateway.
6.6. End.M.GTP4.E 6.6. End.M.GTP4.E
The "Endpoint behavior with encapsulation for IPv4/GTP-U tunnel" End.M.GTP4.E (Endpoint Behavior with encapsulation for IPv4/GTP-U
behavior (End.M.GTP4.E for short) is used in the downlink when doing tunnel) is used in the downlink when doing interworking with legacy
interworking with legacy gNB using IPv4/GTP. 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
local End.M.GTP4.E SID, N does: a local End.M.GTP4.E SID, N does the following:
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 with
Code 0 (Erroneous header field encountered), Code 0 (Erroneous header field encountered) and
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 the
following:
S01. Store the IPv6 DA and SA in buffer memory S01. Store the IPv6 DA and SA in buffer memory
S02. Pop the IPv6 header and all its extension headers S02. Pop the IPv6 header and all its extension headers
S03. Push a new IPv4 header with a UDP/GTP-U Header S03. Push a new IPv4 header with a UDP/GTP-U header
S04. Set the outer IPv4 SA and DA (from buffer memory) S04. Set the outer IPv4 SA and DA (from buffer memory)
S05. Set the outer Total Length, DSCP, Time To Live, and S05. Set the outer Total Length, DSCP, Time To Live, and
Next-Header fields Next Header fields
S06. Set the GTP-U TEID (from buffer memory) S06. Set the GTP-U TEID (from buffer memory)
S07. Submit the packet to the egress IPv4 FIB lookup and S07. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination transmission to the new destination
Notes: The End.M.GTP4.E SID in S has the following format: Notes:
0 127 * The End.M.GTP4.E SID in S has the following format:
+-----------------------+-------+----------------+---------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
Figure 9: End.M.GTP4.E SID Encoding 0 127
+-----------------------+-------+----------------+---------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
The IPv6 Source Address has the following format: Figure 9: End.M.GTP4.E SID Encoding
0 127 * The IPv6 Source Address has the following format:
+----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+
128-a-b a b
Figure 10: IPv6 SA Encoding for End.M.GTP4.E 0 127
+----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+
128-a-b a b
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 H.M.GTP4.D (SR Policy Headend with tunnel decapsulation and map to an
policy" behavior (H.M.GTP4.D for short) is used in the direction from SRv6 policy) is used in the direction from the legacy IPv4 user plane
legacy IPv4 user-plane to SRv6 user-plane network. to the SRv6 user-plane network.
When the SR Gateway node N receives a packet destined to a SRGW- When the SR Gateway node N receives a packet destined to a SRGW-
IPv4-Prefix, N does: IPv4-Prefix, N does the following:
S01. IF Payload == UDP/GTP-U THEN S01. IF Payload == UDP/GTP-U THEN
S02. Pop the outer IPv4 header and UDP/GTP-U headers S02. Pop the outer IPv4 header and UDP/GTP-U headers
S03. Copy IPv4 DA, TEID to form SID B S03. Copy IPv4 DA and TEID to form SID B
S04. Copy IPv4 SA to form IPv6 SA B' S04. Copy IPv4 SA to form IPv6 SA B'
S05. Encapsulate the packet into a new IPv6 header S05. Encapsulate the packet into a new IPv6 header
S06. Set the IPv6 DA = B S06. Set the IPv6 DA = B
S07. Forward along the shortest path to B S07. Forward along the shortest path to B
S08. ELSE S08. ELSE
S09. Drop the packet S09. Drop the packet
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
Figure 11: H.M.GTP4.D SID Encoding Figure 11: H.M.GTP4.D SID Encoding
The SID B MAY be an SRv6 Binding SID instantiated at the first UPF The SID B MAY be an SRv6 Binding SID instantiated at the first UPF
(U1) to bind an SR policy [RFC9256]. (U1) to bind an SR Policy [RFC9256].
6.8. End.Limit: Rate Limiting behavior 6.8. End.Limit
The mobile user-plane requires a rate-limit feature. For this The mobile user plane requires a rate-limit feature. For this
purpose, this document defines a new behavior "End.Limit". The purpose, this document defines a new behavior, called "End.Limit".
"End.Limit" behavior encodes in its arguments the rate limiting The "End.Limit" behavior encodes in its arguments the rate-limiting
parameter that should be applied to this packet. Multiple flows of parameter that should be applied to this packet. Multiple flows of
packets should have the same group identifier in the SID when those packets should have the same group identifier in the SID when those
flows are in the same AMBR (Aggregate Maximum Bit Rate) group. The flows are in the same AMBR (Aggregate Maximum Bit Rate) group. The
encoding format of the rate limit segment SID is as follows: encoding format of 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
Figure 12: 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:
* IPv4 * IPv4
* IPv6 * IPv6
* IPv4v6 * IPv4v6
* Ethernet * Ethernet
* 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:
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.DX4 and End.DT4 for IPv4 PDU Sessions
sessions).
* End.DX6, End.DT6, and End.T for IPv6 PDU Sessions
* End.DT46 for IPv4v6 PDU Sessions
* End.DX2 for L2 and Unstructured PDU Sessions
8. Network Slicing Considerations 8. Network Slicing Considerations
A mobile network may be required to implement "network slices", which A mobile network may be required to implement "network slices", which
logically separate network resources within the same SR Domain. logically separate network resources within the same SR domain.
[RFC9256] describes a solution to build basic network slices with SR. [RFC9256] describes a solution to build basic network slices with SR.
Depending on the requirements, these slices can be further refined by Depending on the requirements, these slices can be further refined by
adopting the mechanisms from: adopting the mechanisms from:
* IGP Flex-Algo [I-D.ietf-lsr-flex-algo] * IGP Flex-Algo [RFC9350]
* Inter-Domain policies [RFC9087] * Inter-Domain policies [RFC9087]
Furthermore, these can be combined with ODN/AS (On Demand Nexthop/ Furthermore, these can be combined with ODN/AS (On-Demand Next Hop /
Automated Steering) [RFC9256] for automated slice provisioning and Automated Steering) [RFC9256] for automated slice provisioning and
traffic steering. 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 [NETWORK-SLICE].
[I-D.ali-spring-network-slicing-building-blocks].
9. Control Plane Considerations 9. Control Plane Considerations
This document focuses on user-plane behavior and its independence This document focuses on user-plane behavior and its independence
from the control plane. While the SRv6 mobile user-plane behaviors from the control plane. While the SRv6 mobile user-plane behaviors
may be utilized in emerging architectures, such as may be utilized in emerging architectures (for example, those
[I-D.gundavelli-dmm-mfa], [I-D.mhkk-dmm-srv6mup-architecture] for described in [MFA] and [MUP-SR-ARCH]), this document does not impose
example, require control plane support for the user-plane, this any change to the existent mobility control plane.
document does not impose any change to the existent mobility control
plane.
Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for Section 11 allocates SRv6 Endpoint Behavior codepoints for the new
the new behaviors defined in this document. 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
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. It's important to note the network that is within the SR domain. It's important to note the
ressemblance between the SR Domain and the 3GPP Packet Core Domain. resemblance between the SR domain and the 3GPP Packet Core Domain.
This document introduces new SRv6 Endpoint Behaviors. Those This document introduces new SRv6 Endpoint Behaviors. Those
behaviors operate on control plane information, including information behaviors operate on control plane information, including information
within the received SRH payload on which the behaviors operate. within the received SRH payload on which the behaviors operate.
Altering the behaviors requires that an attacker alter the SR Domain Altering the behaviors requires that an attacker alter the SR domain
as defined in [RFC8754]. Those behaviors do not need any special as defined in [RFC8754]. Those behaviors do not need any special
security consideration given that it is deployed within that SR security consideration given that they are deployed within that SR
Domain. domain.
11. IANA Considerations 11. IANA Considerations
The following values have been allocated within the "SRv6 Endpoint The following values have been allocated in the "SRv6 Endpoint
Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment Behaviors" [RFC8986] subregistry within the top-level "Segment
Routing Parameters" registry: Routing Parameters" registry:
+=======+========+===================+===========+============+ +=======+========+===================+===========+============+
| Value | Hex | Endpoint behavior | Reference | Change | | Value | Hex | Endpoint Behavior | Reference | Change |
| | | | | Controller | | | | | | Controller |
+=======+========+===================+===========+============+ +=======+========+===================+===========+============+
| 40 | 0x0028 | End.MAP | [This.ID] | IETF | | 40 | 0x0028 | End.MAP | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+ +-------+--------+-------------------+-----------+------------+
| 41 | 0x0029 | End.Limit | [This.ID] | IETF | | 41 | 0x0029 | End.Limit | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+ +-------+--------+-------------------+-----------+------------+
| 69 | 0x0045 | End.M.GTP6.D | [This.ID] | IETF | | 69 | 0x0045 | End.M.GTP6.D | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+ +-------+--------+-------------------+-----------+------------+
| 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | IETF | | 70 | 0x0046 | End.M.GTP6.Di | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+ +-------+--------+-------------------+-----------+------------+
| 71 | 0x0047 | End.M.GTP6.E | [This.ID] | IETF | | 71 | 0x0047 | End.M.GTP6.E | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+ +-------+--------+-------------------+-----------+------------+
| 72 | 0x0048 | End.M.GTP4.E | [This.ID] | IETF | | 72 | 0x0048 | End.M.GTP4.E | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+ +-------+--------+-------------------+-----------+------------+
Table 1: SRv6 Mobile User-plane Endpoint Behavior Types Table 1: SRv6 Mobile User-Plane Endpoint Behavior Types
12. Contributors
Kentaro Ebisawa Toyota Motor Corporation Japan
Email: ebisawa@toyota-tokyo.tech
Tetsuya Murakami Arrcus, Inc. United States of America
Email: tetsuya.ietf@gmail.com
Charles E. Perkins Lupin Lodge United States of America
Email: charliep@computer.org
Jakub Horn Cisco Systems, Inc. United States of America
Email: jakuhorn@cisco.com
13. Acknowledgements
The authors would like to thank Daisuke Yokota, Bart Peirens,
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and
Jeffrey Zhang for their useful comments of this work.
14. References 12. References
14.1. Normative References 12.1. Normative References
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 30, line 35 skipping to change at line 1400
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>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture", A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022, RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>. <https://www.rfc-editor.org/info/rfc9256>.
[TS.23501] 3GPP, "System Architecture for the 5G System", 3GPP TS [TS.23501] 3GPP, "System architecture for the 5G System (5GS)",
23.501 15.0.0, November 2017. Version 17.9.0, 3GPP TS 23.501, June 2023.
14.2. Informative References
[I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer,
"Building blocks for Slicing in Segment Routing Network",
Work in Progress, Internet-Draft, draft-ali-spring-
network-slicing-building-blocks-04, 21 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ali-spring-
network-slicing-building-blocks-04>.
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 12.2. Informative References
Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S.,
Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use-
Cases", Work in Progress, Internet-Draft, draft-
camarilloelmalky-springdmm-srv6-mob-usecases-02, 15 August
2019, <https://datatracker.ietf.org/doc/html/draft-
camarilloelmalky-springdmm-srv6-mob-usecases-02>.
[I-D.gundavelli-dmm-mfa] [MFA] Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", Work in Progress, Internet- aware Floating Anchor (MFA)", Work in Progress, Internet-
Draft, draft-gundavelli-dmm-mfa-01, 19 September 2018, Draft, draft-gundavelli-dmm-mfa-01, 19 September 2018,
<https://datatracker.ietf.org/doc/html/draft-gundavelli- <https://datatracker.ietf.org/doc/html/draft-gundavelli-
dmm-mfa-01>. dmm-mfa-01>.
[I-D.ietf-lsr-flex-algo] [MUP-SR-ARCH]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Matsushima, S., Horiba, K., Khan, A., Kawakami, Y.,
A. Gulko, "IGP Flexible Algorithm", Work in Progress, Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo,
Internet-Draft, draft-ietf-lsr-flex-algo-26, 17 October P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal,
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- A., and K. Perumal, "Mobile User Plane Architecture using
lsr-flex-algo-26>. Segment Routing for Distributed Mobility Management", Work
in Progress, Internet-Draft, draft-mhkk-dmm-srv6mup-
architecture-05, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-
srv6mup-architecture-05>.
[I-D.ietf-spring-sr-service-programming] [NETWORK-SLICE]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Ali, Z., Filsfils, C., Camarillo, P., Voyer, D.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and Matsushima, S., Rokui, R., Dhamija, A., and P. Maheshwari,
S. Salsano, "Service Programming with Segment Routing", "Building blocks for Network Slice Realization in Segment
Work in Progress, Internet-Draft, draft-ietf-spring-sr- Routing Network", Work in Progress, Internet-Draft, draft-
service-programming-06, 9 June 2022, ali-teas-spring-ns-building-blocks-03, 7 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring- <https://datatracker.ietf.org/doc/html/draft-ali-teas-
sr-service-programming-06>. spring-ns-building-blocks-03>.
[I-D.ietf-spring-srv6-srh-compression] [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F. and D. Afanasiev, "Segment Routing Centralized BGP Egress
Clad, "Compressed SRv6 Segment List Encoding in SRH", Work Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
in Progress, Internet-Draft, draft-ietf-spring-srv6-srh- 2021, <https://www.rfc-editor.org/info/rfc9087>.
compression-03, 11 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-03>.
[I-D.kohno-dmm-srv6mob-arch] [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
Kohno, M., Clad, F., Camarillo, P., and Z. Ali, and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
"Architecture Discussion on SRv6 Mobile User plane", Work DOI 10.17487/RFC9350, February 2023,
in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch- <https://www.rfc-editor.org/info/rfc9350>.
05, 8 November 2021,
<https://datatracker.ietf.org/doc/html/draft-kohno-dmm-
srv6mob-arch-05>.
[I-D.matsushima-spring-srv6-deployment-status] [SR-SERV-PROG]
Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
and S. Salsano, "Service Programming with Segment
Routing", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-service-programming-07, 15 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-07>.
[SRV6-DEPLOY-STAT]
Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman, Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman,
K., and A. Dhamija, "SRv6 Implementation and Deployment K., and A. Dhamija, "SRv6 Implementation and Deployment
Status", Work in Progress, Internet-Draft, draft- Status", Work in Progress, Internet-Draft, draft-
matsushima-spring-srv6-deployment-status-15, 5 April 2022, matsushima-spring-srv6-deployment-status-15, 5 April 2022,
<https://datatracker.ietf.org/doc/html/draft-matsushima- <https://datatracker.ietf.org/doc/html/draft-matsushima-
spring-srv6-deployment-status-15>. spring-srv6-deployment-status-15>.
[I-D.mhkk-dmm-srv6mup-architecture] [SRV6-MOB-ARCH-DISCUSS]
Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., Kohno, M., Clad, F., Camarillo, P., and Z. Ali,
Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo, "Architecture Discussion on SRv6 Mobile User plane", Work
P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal, in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch-
A., and K. Perumal, "Segment Routing IPv6 Mobile User 06, 9 March 2023, <https://datatracker.ietf.org/doc/html/
Plane Architecture for Distributed Mobility Management", draft-kohno-dmm-srv6mob-arch-06>.
Work in Progress, Internet-Draft, draft-mhkk-dmm-srv6mup-
architecture-04, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-
srv6mup-architecture-04>.
[I-D.murakami-dmm-user-plane-message-encoding] [SRV6-MOB-USECASES]
Camarillo, P., Ed., Filsfils, C., Elmalky, H., Ed.,
Matsushima, S., Voyer, D., Cui, A., and B. Peirens, "SRv6
Mobility Use-Cases", Work in Progress, Internet-Draft,
draft-camarilloelmalky-springdmm-srv6-mob-usecases-02, 15
August 2019, <https://datatracker.ietf.org/doc/html/draft-
camarilloelmalky-springdmm-srv6-mob-usecases-02>.
[SRV6-SRH-COMPRESSION]
Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding in SRH",
Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
srh-compression-05, 20 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-05>.
[SRV6-UP-MSG-ENCODING]
Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P., Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P.,
and R. Shekhar, "User Plane Message Encoding", Work in and R. Shekhar, "User Plane Message Encoding", Work in
Progress, Internet-Draft, draft-murakami-dmm-user-plane- Progress, Internet-Draft, draft-murakami-dmm-user-plane-
message-encoding-05, 5 March 2022, message-encoding-05, 5 March 2022,
<https://datatracker.ietf.org/doc/html/draft-murakami-dmm- <https://datatracker.ietf.org/doc/html/draft-murakami-dmm-
user-plane-message-encoding-05>. user-plane-message-encoding-05>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
[TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, Protocol User Plane (GTPv1-U)", Version 17.4.0, 3GPP
December 2017. TS 29.281, September 2022.
[TS.38415] 3GPP, "Draft Specification for 5GS container (TS 38.415)", [TS.38415] 3GPP, "PDU session user plane protocol", Version 17.0.0,
3GPP R3-174510 0.0.0, August 2017. 3GPP TS 38.415, April 2022.
Appendix A. Implementations Acknowledgements
RFC Editor: Please remove this section prior to publication. The authors would like to thank Daisuke Yokota, Bart Peirens,
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk von Hugo,
and Jeffrey Zhang for their useful comments of this work.
This document introduces new SRv6 Endpoint Behaviors. These Contributors
behaviors have an open-source P4 implementation available in
https://github.com/ebiken/p4srv6.
Additionally, a full open-source implementation of this document is Kentaro Ebisawa
available in Linux Foundation FD.io VPP project since release 20.05. Toyota Motor Corporation
More information available here: https://docs.fd.io/vpp/20.05/d7/d3c/ Japan
srv6_mobile_plugin_doc.html. Email: ebisawa@toyota-tokyo.tech
There are also experimental implementations in M-CORD NGIC and Open Tetsuya Murakami
Air Interface (OAI). Arrcus, Inc.
United States of America
Email: tetsuya.ietf@gmail.com
Charles E. Perkins
Lupin Lodge
United States of America
Email: charliep@computer.org
Jakub Horn
Cisco Systems, Inc.
United States of America
Email: jakuhorn@cisco.com
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.
 End of changes. 260 change blocks. 
590 lines changed or deleted 628 lines changed or added

This html diff was produced by rfcdiff 1.48.