diff options
Diffstat (limited to 'doc/rfc/rfc9433.txt')
| -rw-r--r-- | doc/rfc/rfc9433.txt | 1563 |
1 files changed, 1563 insertions, 0 deletions
diff --git a/doc/rfc/rfc9433.txt b/doc/rfc/rfc9433.txt new file mode 100644 index 0000000..2ef9af9 --- /dev/null +++ b/doc/rfc/rfc9433.txt @@ -0,0 +1,1563 @@ + + + + +Internet Engineering Task Force (IETF) S. Matsushima, Ed. +Request for Comments: 9433 SoftBank +Category: Informational C. Filsfils +ISSN: 2070-1721 M. Kohno + P. Camarillo, Ed. + Cisco Systems, Inc. + D. Voyer + Bell Canada + July 2023 + + + Segment Routing over IPv6 for the Mobile User Plane + +Abstract + + This document discusses the applicability of Segment Routing over + IPv6 (SRv6) to the user plane of mobile networks. The network + programming nature of SRv6 accomplishes mobile user-plane functions + in a simple manner. The statelessness of SRv6 and its ability to + control both service layer path and underlying transport can be + beneficial to the mobile user plane, providing flexibility, end-to- + end network slicing, and Service Level Agreement (SLA) control for + various applications. + + This document discusses how SRv6 could be used as the user plane of + mobile networks. This document also specifies the SRv6 Endpoint + Behaviors required for mobility use cases. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + 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. + + 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 (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions and Terminology + 2.1. Terminology + 2.2. Conventions + 2.3. Predefined SRv6 Endpoint Behaviors + 3. Motivation + 4. 3GPP Reference Architecture + 5. User-Plane Modes + 5.1. Traditional Mode + 5.1.1. Packet Flow - Uplink + 5.1.2. Packet Flow - Downlink + 5.2. Enhanced Mode + 5.2.1. Packet Flow - Uplink + 5.2.2. Packet Flow - Downlink + 5.2.3. Scalability + 5.3. Enhanced Mode with Unchanged gNB GTP-U Behavior + 5.3.1. Interworking with IPv6 GTP-U + 5.3.2. Interworking with IPv4 GTP-U + 5.3.3. Extensions to the Interworking Mechanisms + 5.4. SRv6 Drop-In Interworking + 6. SRv6 Segment Endpoint Mobility Behaviors + 6.1. Args.Mob.Session + 6.2. End.MAP + 6.3. End.M.GTP6.D + 6.4. End.M.GTP6.D.Di + 6.5. End.M.GTP6.E + 6.6. End.M.GTP4.E + 6.7. H.M.GTP4.D + 6.8. End.Limit + 7. SRv6-Supported 3GPP PDU Session Types + 8. Network Slicing Considerations + 9. Control Plane Considerations + 10. Security Considerations + 11. IANA Considerations + 12. References + 12.1. Normative References + 12.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + In mobile networks, mobility systems provide connectivity over a + wireless link to stationary and non-stationary nodes. The user plane + establishes a tunnel between the mobile node and its anchor node over + IP-based backhaul and core networks. + + This document specifies the applicability of SRv6 [RFC8754] [RFC8986] + to mobile networks. + + Segment Routing (SR) [RFC8402] is a source-routing architecture: a + node steers a packet through an ordered list of instructions called + "segments". A segment can represent any instruction, topological or + service based. + + SRv6 applied to mobile networks enables a mobile architecture based + on source routing, where operators can explicitly indicate a route + for the packets to and from the mobile node. The SRv6 Endpoint nodes + serve as mobile user-plane anchors. + +2. Conventions and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.1. Terminology + + CNF: Cloud-native Network Function + + NFV: Network Function Virtualization + + PDU: Packet Data Unit + + PDU Session: Context of a UE connected to a mobile network + + UE: User Equipment + + 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 + [RFC8402]: Segment Routing, SR domain, Segment ID (SID), SRv6, SRv6 + SID, Active Segment, SR Policy, and Binding SID (BSID). + + The following terms used within this document are defined in + [RFC8754]: Segment Routing Header (SRH) and Reduced SRH. + + The following terms used within this document are defined in + [RFC8986]: NH (next header), SL (the Segments Left field of the SRH), + FIB (Forwarding Information Base), SA (Source Address), DA + (Destination Address), and SRv6 Endpoint Behavior. + +2.2. Conventions + + 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 + to visit, and S3 is the last SID to visit along the SR path. + + (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet where: + + * Source Address is SA, Destination Address is DA, and next header + is SRH + + * SRH with SID list <S1, S2, S3> with Segments Left = SL + + 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 + SID to traverse. (S3, S2, S1; SL) represents the same SID list + but encoded in the SRH format where the rightmost SID in the SRH + is the 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 + simpler to use the <S1, S2, S3> notation. When referring to an + illustration of the detailed packet behavior, the (S3, S2, S1; SL) + notation is more convenient. + + * The payload of the packet is omitted. + + (SA1,DA1) (SA2, DA2) represents an IPv6 packet where: + + * Source Address is SA1, Destination Address is DA1, and next header + is IP. + + * Source Address is SA2, and Destination Address is DA2. + + 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 + examples: + + * gNB::1 is an IPv6 address (SID) assigned to the gNB. + + * U1::1 is an IPv6 address (SID) assigned to UPF1. + + * U2::1 is an IPv6 address (SID) assigned to UPF2. + + * U2:: is the Locator of UPF2. + +2.3. Predefined SRv6 Endpoint Behaviors + + The following SRv6 Endpoint Behaviors are used throughout this + document. They are defined in [RFC8986]. + + * End.DT4: Decapsulation and Specific IPv4 Table Lookup + + * End.DT6: Decapsulation and Specific IPv6 Table Lookup + + * End.DT46: Decapsulation and Specific IP Table Lookup + + * End.DX4: Decapsulation and IPv4 Cross-Connect + + * End.DX6: Decapsulation and IPv6 Cross-Connect + + * End.DX2: Decapsulation and L2 Cross-Connect + + * End.T: Endpoint with specific IPv6 Table Lookup + + This document defines new SRv6 Endpoint Behaviors in Section 6. + +3. Motivation + + Mobile networks are becoming more challenging to operate. On one + hand, traffic is constantly growing, and latency requirements are + tighter; on the other hand, there are new use cases like distributed + NFV Infrastructure that are also challenging network operations. On + top of this, the number of devices connected is steadily growing, + causing scalability problems in mobile entities as the state to + maintain keeps increasing. + + The current architecture of mobile networks does not take into + account the underlying transport. The user plane is rigidly + fragmented into radio access, core, and service networks that + connected by tunneling according to user-plane roles such as access + and anchor nodes. These factors have made it difficult for the + operator to optimize and operate the data path. + + In the meantime, applications have shifted to use IPv6, and network + operators have started adopting IPv6 as their IP transport. SRv6, + the IPv6 data plane instantiation of Segment Routing [RFC8402], + integrates both the application data path and the underlying + transport layer into a single protocol, allowing operators to + optimize the network in a simplified manner and removing forwarding + state from the network. It is also suitable for virtualized + environments, like VNF/CNF-to-VNF/CNF networking. SRv6 has been + deployed in dozens of networks [SRV6-DEPLOY-STAT]. + + SRv6 defines the network programming concept [RFC8986]. Applied to + mobility, SRv6 can provide the user-plane behaviors needed for + mobility management. SRv6 takes advantage of the underlying + transport awareness and flexibility together with the ability to also + include services to optimize the end-to-end mobile data plane. + + The use cases for SRv6 mobility are discussed in [SRV6-MOB-USECASES], + and the architectural benefits are discussed in + [SRV6-MOB-ARCH-DISCUSS]. + +4. 3GPP Reference Architecture + + This section presents the 3GPP reference architecture and possible + deployment scenarios. + + Figure 1 shows a reference diagram from the 5G packet core + architecture [TS.23501]. + + The user plane described in this document does not depend on any + specific architecture. The 5G packet core architecture as shown is + based on the 3GPP standards. + + +-----+ + | AMF | + /+-----+ + / | [N11] + [N2] / +-----+ + +------/ | SMF | + / +-----+ + / / \ + / / \ [N4] + / / \ ________ + / / \ / \ + +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ + |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / + +--+ +-----+ +------+ +------+ \________/ + + Figure 1: 3GPP 5G Reference Architecture + + UE: User Equipment + + gNB: gNodeB with N3 interface towards packet core (and N2 for + 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) + + 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 + to N9 interfaces, although the mechanisms defined in this document + also work in such a case. + + Each session from a UE gets assigned to a UPF. Sometimes multiple + 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 + UPF advertises that IP address block toward the Internet, ensuring + that return traffic is routed to the right UPF. + +5. User-Plane Modes + + This section introduces an SRv6-based mobile user plane. It presents + two different "modes" that vary with respect to the use of SRv6. + + The first mode is the "Traditional mode", which inherits the current + 3GPP mobile architecture. In this mode, the GTP-U protocol + [TS.29281] is replaced by SRv6. However, the N3, N9, and N6 + 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 "Traditional mode". In this mode, the N3, N9, or N6 interfaces + have intermediate waypoints (SIDs) that are used for traffic + engineering or VNF purposes transparent to 3GPP functionalities. + This results in optimal end-to-end policies across the mobile network + with transport and services awareness. + + In both the Traditional and the Enhanced modes, this document assumes + that the gNB as well as the UPFs are SR-aware (N3, N9, and + potentially N6 interfaces are SRv6). + + In addition to those two modes, this document introduces three + mechanisms for interworking with legacy access networks (those where + the N3 interface is unmodified). In this document, they are + introduced as a variant to the Enhanced mode, but they are equally + applicable to the Traditional mode. + + One of these mechanisms is designed to interwork with legacy gNBs + using GTP-U/IPv4. The second mechanism is designed to interwork with + legacy gNBs using GTP-U/IPv6. The third mechanism is another mode + that allows deploying SRv6 when legacy gNBs and UPFs still run GTP-U. + + This document uses the SRv6 Endpoint Behaviors defined in [RFC8986] + as well as the new SRv6 Endpoint Behaviors designed for the mobile + user plane that are defined in Section 6 of this document. + +5.1. Traditional Mode + + In the Traditional mode, the existing mobile UPFs remain unchanged + 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. + + In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 + with a specific GTP-U tunnel (Tunnel Endpoint Identifier (TEID)). + This 1-for-1 mapping is mirrored here to replace GTP-U encapsulation + with the SRv6 encapsulation, while not changing anything else. There + will be a unique SRv6 SID associated with each PDU Session, and the + SID list only contains a single SID. + + The Traditional mode minimizes the required changes to the mobile + system; hence, it is a good starting point for forming common ground. + + The gNB/UPF control plane (N2/N4 interface) is unchanged; + specifically, a single IPv6 address is provided to the gNB. The same + control plane signaling is used, and the gNB/UPF decides to use SRv6 + based on signaled GTP-U parameters per local policy. The only + information from the GTP-U parameters used for the SRv6 policy is the + TEID, QFI (QoS Flow Identifier), and the IPv6 Destination Address. + + 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 + flow, A is an IPv6 address of the UE, and Z is an IPv6 address + reachable within the DN. End.MAP, a new SRv6 Endpoint Behavior + defined in Section 6.2, is used. + + ________ + SRv6 SRv6 / \ + +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ + |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / + +--+ +-----+ +------+ +------+ \________/ + SRv6 node SRv6 node SRv6 node + + Figure 2: Traditional Mode - Example Topology + +5.1.1. Packet Flow - Uplink + + The uplink packet flow is as follows: + + UE_out : (A,Z) + gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1> + UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP + UPF2_out: (A,Z) -> End.DT4 or End.DT6 + + 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 + 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 + control plane (N2 interface). U1::1 represents an anchoring SID + specific for that session at UPF1. + + When the packet arrives at UPF1, the SID U1::1 is associated with the + End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 with U2::1, + which belongs to the next UPF (U2). + + When the packet arrives at UPF2, the SID U2::1 corresponds to an + End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates + the packet, performs a lookup in a specific table associated with + that mobile network, and forwards the packet toward the DN. + +5.1.2. Packet Flow - Downlink + + The downlink packet flow is as follows: + + UPF2_in : (Z,A) + UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2> + UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP + gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 + + When the packet arrives at the UPF2, the UPF2 maps that flow into a + PDU Session. This PDU Session is associated with the segment + endpoint <U1::2>. UPF2 performs an H.Encaps.Red operation, + encapsulating the packet into a new IPv6 header with no SRH since + there is only one SID. + + 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 + anchoring point and replaces U1::2 with gNB::1, which belongs to the + next hop. + + 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 gNB decapsulates the packet, removing the IPv6 header and all its + extensions headers, and forwards the traffic toward the UE. + +5.2. Enhanced Mode + + Enhanced mode improves scalability, provides traffic engineering + capabilities, and allows service programming [SR-SERV-PROG], thanks + to the use of multiple SIDs in the SID list (instead of a direct + connectivity in between UPFs with no intermediate waypoints as in + Traditional mode). + + Thus, the main difference is that the SR Policy MAY include SIDs for + traffic engineering and service programming in addition to the + anchoring SIDs at UPFs. + + Additionally, in this mode, the operator may choose to aggregate + several devices under the same SID list (e.g., stationary residential + meters (water and energy) connected to the same cell) to improve + scalability. + + The gNB/UPF control plane (N2/N4 interface) is unchanged; + specifically, a single IPv6 address is provided to the gNB. A local + policy instructs the gNB to use SRv6. + + 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 + document. + + Note that the SIDs MAY use the argument Args.Mob.Session + (Section 6.1) if required by the UPFs. + + 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 + represents a VNF in the network, and C1 represents an intermediate + router used for traffic engineering purposes to enforce a low-latency + path in the network. Note that neither S1 nor C1 are required to + have an N4 interface. + + +----+ SRv6 _______ + SRv6 --| C1 |--[N3] / \ + +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ + |UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / + +--+ +-----+ \ [N3]/ TE +------+ \_______/ + SRv6 node \ +----+ / SRv6 node + -| S1 |- + +----+ + SRv6 node + VNF + + Figure 3: Enhanced Mode - Example Topology + +5.2.1. Packet Flow - Uplink + + The uplink packet flow is as follows: + + UE_out : (A,Z) + 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) + C1_out : (gNB, U1::1)(A,Z) ->End with PSP + 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 + 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>. + + When gNB transmits the packet, it contains all the segments of the SR + Policy. The SR Policy includes segments for traffic engineering (C1) + and for service programming (S1). + + Nodes S1 and C1 perform their related Endpoint functionality and + forward the packet. The "End with PSP" functionality refers to the + Endpoint Behavior with Penultimate Segment Popping as defined in + [RFC8986]. + + When the packet arrives at UPF1, the active segment (U1::1) is an + End.DT4/End.DT6/End.DT2U, which performs the decapsulation (removing + the IPv6 header with all its extension headers) and forwards toward + the DN. + +5.2.2. Packet Flow - Downlink + + The downlink packet flow is as follows: + + UPF1_in : (Z,A) ->UPF1 maps the flow w/ + SID list <C1,S1, gNB> + 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) + S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP + gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 + + 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 + the policy <C1, S1, gNB>. The UPF1 performs a H.Encaps.Red + operation, encapsulating the packet into a new IPv6 header with its + corresponding SRH. + + The nodes C1 and S1 perform their related Endpoint processing. + + 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 + underlying traffic). The gNB decapsulates the packet, removing the + IPv6 header, and forwards the traffic towards the UE. The SID gNB::1 + is one example of a SID associated to this service. + + Note that there are several means to provide the UE session + aggregation. The decision about which one to use is a local decision + made by the operator. One option is to use Args.Mob.Session + (Section 6.1). Another option comprises the gNB performing an IP + lookup on the inner packet by using the End.DT4, End.DT6, and + End.DT2U behaviors. + +5.2.3. Scalability + + The Enhanced mode improves scalability since it allows the + aggregation of several UEs under the same SID list. For example, in + the case of stationary residential meters that are connected to the + same cell, all such devices can share the same SID list. This + improves scalability compared to Traditional mode (unique SID per UE) + and compared to GTP-U (TEID per UE). + +5.3. Enhanced Mode with Unchanged gNB GTP-U Behavior + + This section describes two mechanisms for interworking with legacy + gNBs that still use GTP-U: one for IPv4 and another for IPv6. + + In the interworking scenarios illustrated in Figure 4, the gNB does + not support SRv6. The gNB supports GTP-U encapsulation over IPv4 or + IPv6. To achieve interworking, an SR Gateway (SRGW) entity is added. + The SRGW is a new entity that maps the GTP-U traffic into SRv6. It + is deployed at the boundary of the SR domain and performs the mapping + functionality for inbound and outbound traffic. + + 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. + + _______ + IP GTP-U SRv6 / \ + +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ + |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / + +--+ +-----+ +------+ +------+ \_______/ + SR Gateway SRv6 node + + Figure 4: Example Topology for Interworking + + Both of the mechanisms described in this section are applicable to + the Traditional mode and the Enhanced mode. + +5.3.1. Interworking with IPv6 GTP-U + + In this interworking mode, the gNB at the N3 interface uses GTP-U + over IPv6. + + Key points: + + * The gNB is unchanged (control plane or user plane) and + 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 + (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 + Session Type> combination. + + * 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 simple state in the uplink at the SRGW; using Enhanced + 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 + (i.e., tenant). A set of many different policies (i.e., different + SLAs) increases the amount of state required. + + * When a packet from the UE leaves the gNB, it is SR-routed. This + simplifies network slicing [RFC9350]. + + * In the uplink, the SRv6 BSID steers traffic into an SR Policy when + it arrives at the SRGW. + + An example topology is shown in Figure 5. + + S1 and C1 are two service segments. S1 represents a VNF in the + network, and C1 represents a router configured for traffic + engineering. + + +----+ + IPv6/GTP-U -| S1 |- ___ + +--+ +-----+ [N3] / +----+ \ / + |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / + +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN + GTP-U \ +------+ / +----+ +------+ \___ + -| SRGW |- SRv6 SRv6 + +------+ TE + SR Gateway + + Figure 5: Enhanced Mode with Unchanged gNB IPv6/GTP-U Behavior + +5.3.1.1. Packet Flow - Uplink + + The uplink packet flow is as follows: + + UE_out : (A,Z) + gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified + (IPv6/GTP) + SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D + SID at the SRGW + S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z) + C1_out : (SRGW, U2::T)(A,Z) -> End with PSP + UPF2_out: (A,Z) -> End.DT4 or End.DT6 + + The UE sends a packet destined to Z toward the gNB on a specific + 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 + 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 + 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. + + 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 + 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 + this Binding SID. There is at least one instance of the End.M.GTP6.D + SID per PDU type. + + S1 and C1 perform their related Endpoint functionality and forward + the packet. + + 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 + IPv6 header with all its extension headers) and forwards the packet + toward the DN. + +5.3.1.2. Packet Flow - Downlink + + The downlink packet flow is as follows: + + UPF2_in : (Z,A) -> UPF2 maps the flow with + <C1, S1, SRGW::TEID,gNB> + 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) + 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 + gNB_out : (Z,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, + SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation, + encapsulating the packet into a new IPv6 header with its + corresponding SRH. + + C1 and S1 perform their related Endpoint processing. + + 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 + 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 + in the received SRH. The TEID in the generated GTP-U header is also + 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 + is one instance of the End.M.GTP6.E SID per PDU type. + + Once the packet arrives at the gNB, the packet is a regular IPv6/ + GTP-U packet. The gNB looks for the specific radio bearer for that + TEID and forwards it on the bearer. This gNB behavior is not + modified from current and previous generations. + +5.3.1.3. Scalability + + For downlink traffic, the SRGW is stateless. All the state is in the + SRH pushed by the UPF2. The UPF2 must have the UE state since it is + the UE's session anchor point. + + For uplink traffic, the state at the SRGW does not necessarily need + to be unique per PDU Session; the SR Policy can be shared among UEs. + This enables more scalable SRGW deployments compared to a solution + holding millions of states, one or more per UE. + +5.3.2. Interworking with IPv4 GTP-U + + In this interworking mode, the gNB uses GTP over IPv4 in the N3 + interface. + + Key points: + + * The gNB is unchanged and encapsulates packets into GTP-U (the N3 + interface is not modified). + + * N2 signaling is not changed, though multiple UPF addresses need to + be provided -- one for each PDU Session Type. + + * In the uplink, traffic is classified by SRGW's classification + engine and steered into an SR Policy. The SRGW may be implemented + 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 + example is using BGP signaling from a Mobile User Plane (MUP) + Controller [MUP-SR-ARCH]. + + * SRGW removes the 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 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, + the SRGW maps the IPv4/GTP-U traffic to SRv6. + + S1 and C1 are two service segment endpoints. S1 represents a VNF in + the network, and C1 represents a router configured for traffic + engineering. + + +----+ + IPv4/GTP-U -| S1 |- ___ + +--+ +-----+ [N3] / +----+ \ / + |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / + +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN + GTP-U \ +------+ / +----+ +------+ \___ + -| UPF1 |- SRv6 SRv6 + +------+ TE + SR Gateway + + Figure 6: Enhanced Mode with Unchanged gNB IPv4/GTP-U Behavior + +5.3.2.1. Packet Flow - Uplink + + The uplink packet flow is as follows: + + gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 + unchanged IPv4/GTP + 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) + C1_out : (SRGW, U2::1) (A,Z) -> PSP + UPF2_out: (A,Z) -> End.DT4 or End.DT6 + + The UE sends a packet destined to Z toward the gNB on a specific + bearer for that session. The gNB, which is unmodified, encapsulates + 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. + + When the packet arrives at the SRGW for UPF1, the SRGW has a + classification engine rule for incoming traffic from the gNB that + steers the traffic into an SR Policy by using the function + H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and + pushes an IPv6 header with its own SRH containing the SIDs related to + the SR Policy associated with this traffic. The SRGW forwards + according to the new IPv6 DA. + + S1 and C1 perform their related Endpoint functionality and forward + the packet. + + 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 + outer IPv6 header with all its extension headers) and forwards toward + the DN. + + Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U + differ. This is due to the fact that IPv6/GTP-U can leverage the + remote steering capabilities provided by the Segment Routing BSID. + In IPv4, this construct is not available, and building a similar + mechanism would require a significant address consumption. + +5.3.2.2. Packet Flow - Downlink + + The downlink packet flow is as follows: + + UPF2_in : (Z,A) -> UPF2 maps flow with SID + <C1, S1,GW::SA:DA:TEID> + 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) + S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) + SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E + gNB_out : (Z,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, + SRGW::SA:DA:TEID>. The UPF2 performs an H.Encaps.Red operation, + encapsulating the packet into a new IPv6 header with its + corresponding SRH. + + The nodes C1 and S1 perform their related Endpoint processing. + + 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 + and all its extensions headers. The SRGW generates IPv4, UDP, and + GTP-U headers. The IPv4 SA and DA are received as SID arguments. + 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 + and forwards the packet toward the gNB. + + 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 + TEID and forwards it on the bearer. This gNB behavior is not + modified from current and previous generations. + +5.3.2.3. Scalability + + For downlink traffic, the SRGW is stateless. All the state is in the + SRH pushed by the UPF2. The UPF must have this UE-base state anyway + (since it is its anchor point). + + For uplink traffic, the state at the SRGW is dedicated on a per-UE/ + session basis according to a classification engine. There is state + for steering the different sessions in the form of an SR Policy. + However, SR Policies are shared among several UE/sessions. + +5.3.3. Extensions to the Interworking Mechanisms + + This section presents two mechanisms for interworking with gNBs and + UPFs that do not support SRv6. These mechanisms are used to support + GTP-U over IPv4 and IPv6. + + Even though these methods are presented as an extension to the + Enhanced mode, they are also applicable to the Traditional mode. + +5.4. SRv6 Drop-In Interworking + + This section introduces another mode useful for legacy gNB and UPFs + that still operate with GTP-U. This mode provides an SRv6-enabled + user plane in between two GTP-U tunnel endpoints. + + This mode employs two SRGWs that map GTP-U traffic to SRv6 and vice + versa. + + Unlike other interworking modes, in this mode, both of the mobility + overlay endpoints use GTP-U. Two SRGWs are deployed in either an N3 + or N9 interface to realize an intermediate SR Policy. + + +----+ + -| S1 |- + +-----+ / +----+ \ + | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ + +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | + GTP[N3]\ +--------+ / +----+ +--------+ +-----+ + -| SRGW-A |- SRv6 SR Gateway-B GTP + +--------+ TE + SR Gateway-A + + Figure 7: Example Topology for SRv6 Drop-In Mode + + The packet flow of Figure 7 is as follows: + + 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 + End.M.GTP6.D.Di + SID at SRGW-A + 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) + GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an + End.M.GTP6.E + SID at SRGW-B + UPF_out : (A,Z) + + When a packet destined to Z is sent to the gNB, which is unmodified + (control plane and user plane remain GTP-U), gNB performs + encapsulation into new IP, UDP, and GTP-U headers. The IPv6 DA, + 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 + 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. + + 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 + 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 + associated with this Binding SID. There is one instance of the + End.M.GTP6.D.Di SID per PDU type. + + S1 and C1 perform their related Endpoint functionality and forward + the packet. + + Once the packet arrives at SRGW-B, the SRGW identifies the active SID + as an End.M.GTP6.E function. The SRGW removes the IPv6 header and + all its extensions headers. The SRGW generates new IPv6, UDP, and + GTP headers. The new IPv6 DA is U::1, which is the last SID in the + 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 + packet and forwards the packet toward UPF. There is one instance of + the End.M.GTP6.E SID per PDU type. + + 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 + the packet. This UPF behavior is not modified from current and + previous generations. + +6. SRv6 Segment Endpoint Mobility Behaviors + + This section introduces new SRv6 Endpoint Behaviors for the mobile + user plane. The behaviors described in this document are compatible + with the NEXT and REPLACE flavors defined in [SRV6-SRH-COMPRESSION]. + +6.1. Args.Mob.Session + + Args.Mob.Session provides per-session information for charging, + buffering, or other purposes required by some mobile nodes. The + Args.Mob.Session argument format is used in combination with the + End.Map, End.DT4/End.DT6/End.DT46, and End.DX4/End.DX6/End.DX2 + behaviors. Note that proposed format is applicable for 5G networks, + while similar formats could be used for legacy networks. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | QFI |R|U| PDU Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |PDU Sess(cont')| + +-+-+-+-+-+-+-+-+ + + Figure 8: Args.Mob.Session Format + + QFI: QoS Flow Identifier [TS.38415]. + + R: Reflective QoS Indication [TS.23501]. This parameter indicates + the activation of reflective QoS towards the UE for the + transferred packet. Reflective QoS enables the UE to map uplink + user-plane traffic to QoS flows without SMF-provided QoS rules. + + U: Unused and for future use. MUST be 0 on transmission and ignored + on receipt. + + PDU Session ID: Identifier of PDU Session. The GTP-U equivalent is + TEID. + + 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, + Echo Reply, Error Indication, and End Marker) is out of the scope of + this document. [SRV6-UP-MSG-ENCODING] defines one possible encoding + method. + +6.2. End.MAP + + End.MAP (Endpoint Behavior with SID mapping) is used in several + scenarios. Particularly in mobility, End.MAP is used by the + intermediate UPFs. + + When node N receives a packet whose IPv6 DA is D and D is a local + End.MAP SID, N does the following: + + S01. If (IPv6 Hop Limit <= 1) { + S02. Send an ICMP Time Exceeded message to the Source Address with + Code 0 (Hop limit exceeded in transit), + interrupt packet processing, and discard the packet. + S03. } + S04. Decrement IPv6 Hop Limit by 1 + S05. Update the IPv6 DA with the new mapped SID + S06. Submit the packet to the egress IPv6 FIB lookup for + transmission to the new destination + + Note: The SRH is not modified (neither the SID nor the SL value). + +6.3. End.M.GTP6.D + + End.M.GTP6.D (Endpoint Behavior with IPv6/GTP-U decapsulation into SR + Policy) is used in the interworking scenario for the uplink towards + SRGW from the legacy gNB using IPv6/GTP. Any SID instance of this + behavior is associated with an SR Policy B and an IPv6 Source Address + S. + + When the SR Gateway node N receives a packet destined to D, and D is + a local End.M.GTP6.D SID, N does the following: + + S01. When an SRH is processed { + S02. If (Segments Left != 0) { + S03. Send an ICMP Parameter Problem to the Source Address with + Code 0 (Erroneous header field encountered) and + Pointer set to the Segments Left field, + interrupt packet processing, and discard the packet. + S04. } + S05. Proceed to process the next header in the packet + S06. } + + When processing the Upper-Layer header of a packet matching a FIB + entry locally instantiated as an End.M.GTP6.D SID, N does the + following: + + S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) { + S02. Copy the GTP-U TEID and QFI to buffer memory + S03. Pop the IPv6, UDP, and GTP-U headers + S04. Push a new IPv6 header with its own SRH containing B + S05. Set the outer IPv6 SA to S + S06. Set the outer IPv6 DA to the first SID of B + S07. Set the outer Payload Length, Traffic Class, Flow Label, + Hop Limit, and Next Header (NH) fields + S08. Write in the SRH[0] the Args.Mob.Session based on + the information in buffer memory + S09. Submit the packet to the egress IPv6 FIB lookup for + transmission to the new destination + S10. } Else { + S11. Process as per [RFC8986], Section 4.1.1 + S12. } + + Notes: + + * In line S07, the NH is set based on the SID parameter. There is + one instantiation of the End.M.GTP6.D SID per PDU Session Type; + hence, the NH is already 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 + + End.M.GTP6.D.Di (Endpoint Behavior with IPv6/GTP-U decapsulation into + SR Policy for Drop-in Mode) is used in the SRv6 drop-in interworking + scenario described in Section 5.4. The difference between + End.M.GTP6.D as another variant of the IPv6/GTP decapsulation + function is that the original IPv6 DA of the GTP-U packet is + preserved as the last SID in SRH. + + Any SID instance of this behavior is associated with an SR Policy B + and an IPv6 Source Address S. + + When the SR Gateway node N receives a packet destined to D, and D is + a local End.M.GTP6.D.Di SID, N does the following: + + S01. When an SRH is processed { + S02. If (Segments Left != 0) { + S03. Send an ICMP Parameter Problem to the Source Address with + Code 0 (Erroneous header field encountered) and + Pointer set to the Segments Left field, + interrupt packet processing, and discard the packet. + S04. } + S05. Proceed to process the next header in the packet + S06. } + + When processing the Upper-Layer header of a packet matching a FIB + entry locally instantiated as an End.M.GTP6.Di SID, N does the + following: + + S01. If (Next Header = UDP & UDP_Dest_port = GTP) { + S02. Copy D to buffer memory + S03. Pop the IPv6, UDP, and GTP-U headers + S04. Push a new IPv6 header with its own SRH containing B + S05. Set the outer IPv6 SA to S + S06. Set the outer IPv6 DA to the first SID of B + S07. Set the outer Payload Length, Traffic Class, Flow Label, + Hop Limit, and Next Header fields + S08. Prepend D to the SRH (as SRH[0]) and set SL accordingly + S09. Submit the packet to the egress IPv6 FIB lookup for + transmission to the new destination + S10. } Else { + S11. Process as per [RFC8986], Section 4.1.1 + S12. } + + Notes: + + * 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 + + End.M.GTP6.E (Endpoint Behavior with encapsulation for IPv6/GTP-U + tunnel" behavior) is used among others in the interworking scenario + for the downlink toward the legacy gNB using IPv6/GTP. + + The prefix of End.M.GTP6.E SID MUST be followed by the + Args.Mob.Session argument space, which is used to provide the session + identifiers. + + 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: + + S01. When an SRH is processed { + S02. If (Segments Left != 1) { + S03. Send an ICMP Parameter Problem to the Source Address with + Code 0 (Erroneous header field encountered) and + Pointer set to the Segments Left field, + interrupt packet processing, and discard the packet. + S04. } + S05. Proceed to process the next header in the packet + S06. } + + When processing the Upper-Layer header of a packet matching a FIB + entry locally instantiated as an End.M.GTP6.E SID, N does the + following: + + S01. Copy SRH[0] and D to buffer memory + S02. Pop the IPv6 header and all its extension headers + S03. Push a new IPv6 header with a UDP/GTP-U header + S04. Set the outer IPv6 SA to S + S05. Set the outer IPv6 DA from buffer memory + S06. Set the outer Payload Length, Traffic Class, Flow Label, + Hop Limit, and Next Header fields + S07. Set the GTP-U TEID (from buffer memory) + S08. Submit the packet to the egress IPv6 FIB lookup for + transmission to the new destination + + Notes: + + * An End.M.GTP6.E SID MUST always be the penultimate SID. The TEID + is extracted from the argument space of the current SID. + + * The source address S SHOULD be an End.M.GTP6.D SID instantiated at + the egress SR Gateway. + +6.6. End.M.GTP4.E + + End.M.GTP4.E (Endpoint Behavior with encapsulation for IPv4/GTP-U + tunnel) is used in the downlink when doing interworking with legacy + gNB using IPv4/GTP. + + When the SR Gateway node N receives a packet destined to S, and S is + a local End.M.GTP4.E SID, N does the following: + + S01. When an SRH is processed { + S02. If (Segments Left != 0) { + S03. Send an ICMP Parameter Problem to the Source Address with + Code 0 (Erroneous header field encountered) and + Pointer set to the Segments Left field, + interrupt packet processing, and discard the packet. + S04. } + S05. Proceed to process the next header in the packet + S06. } + + When processing the Upper-Layer header of a packet matching a FIB + entry locally instantiated as an End.M.GTP4.E SID, N does the + following: + + S01. Store the IPv6 DA and SA in buffer memory + S02. Pop the IPv6 header and all its extension headers + S03. Push a new IPv4 header with a UDP/GTP-U header + S04. Set the outer IPv4 SA and DA (from buffer memory) + S05. Set the outer Total Length, DSCP, Time To Live, and + Next Header fields + S06. Set the GTP-U TEID (from buffer memory) + S07. Submit the packet to the egress IPv4 FIB lookup for + transmission to the new destination + + Notes: + + * The End.M.GTP4.E SID in S has the following format: + + 0 127 + +-----------------------+-------+----------------+---------+ + | 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 + + * The IPv6 Source Address has the following format: + + 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 + + H.M.GTP4.D (SR Policy Headend with tunnel decapsulation and map to an + SRv6 policy) is used in the direction from the legacy IPv4 user plane + to the SRv6 user-plane network. + + When the SR Gateway node N receives a packet destined to a SRGW- + IPv4-Prefix, N does the following: + + S01. IF Payload == UDP/GTP-U THEN + S02. Pop the outer IPv4 header and UDP/GTP-U headers + S03. Copy IPv4 DA and TEID to form SID B + S04. Copy IPv4 SA to form IPv6 SA B' + S05. Encapsulate the packet into a new IPv6 header + S06. Set the IPv6 DA = B + S07. Forward along the shortest path to B + S08. ELSE + S09. Drop the packet + + The SID B has the following format: + + 0 127 + +-----------------------+-------+----------------+---------+ + |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | + +-----------------------+-------+----------------+---------+ + 128-a-b-c a b c + + Figure 11: H.M.GTP4.D SID Encoding + + The SID B MAY be an SRv6 Binding SID instantiated at the first UPF + (U1) to bind an SR Policy [RFC9256]. + +6.8. End.Limit + + The mobile user plane requires a rate-limit feature. For this + purpose, this document defines a new behavior, called "End.Limit". + The "End.Limit" behavior encodes in its arguments the rate-limiting + parameter that should be applied to this packet. Multiple flows of + packets should have the same group identifier in the SID when those + flows are in the same AMBR (Aggregate Maximum Bit Rate) group. The + encoding format of the rate-limit segment SID is as follows: + + +----------------------+----------+-----------+ + | LOC+FUNC rate-limit | group-id | limit-rate| + +----------------------+----------+-----------+ + 128-i-j i j + + Figure 12: End.Limit: Rate-Limiting Behavior Argument Format + + 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 + rate associated to the SID. + +7. SRv6-Supported 3GPP PDU Session Types + + The 3GPP [TS.23501] defines the following PDU Session Types: + + * IPv4 + + * IPv6 + + * IPv4v6 + + * Ethernet + + * Unstructured + + SRv6 supports the 3GPP PDU Session Types without any protocol + overhead by using the corresponding SRv6 behaviors: + + * End.DX4 and End.DT4 for IPv4 PDU 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 + + A mobile network may be required to implement "network slices", which + logically separate network resources within the same SR domain. + + [RFC9256] describes a solution to build basic network slices with SR. + Depending on the requirements, these slices can be further refined by + adopting the mechanisms from: + + * IGP Flex-Algo [RFC9350] + + * Inter-Domain policies [RFC9087] + + Furthermore, these can be combined with ODN/AS (On-Demand Next Hop / + Automated Steering) [RFC9256] for automated slice provisioning and + traffic steering. + + Further details on how these tools can be used to create end-to-end + network slices are documented in [NETWORK-SLICE]. + +9. Control Plane Considerations + + This document focuses on user-plane behavior and its independence + from the control plane. While the SRv6 mobile user-plane behaviors + may be utilized in emerging architectures (for example, those + described in [MFA] and [MUP-SR-ARCH]), this document does not impose + any change to the existent mobility control plane. + + Section 11 allocates SRv6 Endpoint Behavior codepoints for the new + behaviors defined in this document. + +10. Security Considerations + + The security considerations for Segment Routing are discussed in + [RFC8402]. More specifically, for SRv6, the security considerations + and the mechanisms for securing an SR domain are discussed in + [RFC8754]. Together, they describe the required security mechanisms + that allow establishment of an SR domain of trust to operate + SRv6-based services for internal traffic while preventing any + external traffic from accessing or exploiting the SRv6-based + services. + + The technology described in this document is applied to a mobile + network that is within the SR domain. It's important to note the + resemblance between the SR domain and the 3GPP Packet Core Domain. + + This document introduces new SRv6 Endpoint Behaviors. Those + behaviors operate on control plane information, including information + within the received SRH payload on which the behaviors operate. + Altering the behaviors requires that an attacker alter the SR domain + as defined in [RFC8754]. Those behaviors do not need any special + security consideration given that they are deployed within that SR + domain. + +11. IANA Considerations + + The following values have been allocated in the "SRv6 Endpoint + Behaviors" [RFC8986] subregistry within the top-level "Segment + Routing Parameters" registry: + + +=======+========+===================+===========+============+ + | Value | Hex | Endpoint Behavior | Reference | Change | + | | | | | Controller | + +=======+========+===================+===========+============+ + | 40 | 0x0028 | End.MAP | RFC 9433 | IETF | + +-------+--------+-------------------+-----------+------------+ + | 41 | 0x0029 | End.Limit | RFC 9433 | IETF | + +-------+--------+-------------------+-----------+------------+ + | 69 | 0x0045 | End.M.GTP6.D | RFC 9433 | IETF | + +-------+--------+-------------------+-----------+------------+ + | 70 | 0x0046 | End.M.GTP6.Di | RFC 9433 | IETF | + +-------+--------+-------------------+-----------+------------+ + | 71 | 0x0047 | End.M.GTP6.E | RFC 9433 | IETF | + +-------+--------+-------------------+-----------+------------+ + | 72 | 0x0048 | End.M.GTP4.E | RFC 9433 | IETF | + +-------+--------+-------------------+-----------+------------+ + + Table 1: SRv6 Mobile User-Plane Endpoint Behavior Types + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, + July 2018, <https://www.rfc-editor.org/info/rfc8402>. + + [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., + Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header + (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, + <https://www.rfc-editor.org/info/rfc8754>. + + [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, + D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 + (SRv6) Network Programming", RFC 8986, + DOI 10.17487/RFC8986, February 2021, + <https://www.rfc-editor.org/info/rfc8986>. + + [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, + A., and P. Mattes, "Segment Routing Policy Architecture", + RFC 9256, DOI 10.17487/RFC9256, July 2022, + <https://www.rfc-editor.org/info/rfc9256>. + + [TS.23501] 3GPP, "System architecture for the 5G System (5GS)", + Version 17.9.0, 3GPP TS 23.501, June 2023. + +12.2. Informative References + + [MFA] Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- + aware Floating Anchor (MFA)", Work in Progress, Internet- + Draft, draft-gundavelli-dmm-mfa-01, 19 September 2018, + <https://datatracker.ietf.org/doc/html/draft-gundavelli- + dmm-mfa-01>. + + [MUP-SR-ARCH] + Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., + Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo, + P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal, + A., and K. Perumal, "Mobile User Plane Architecture using + 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>. + + [NETWORK-SLICE] + Ali, Z., Filsfils, C., Camarillo, P., Voyer, D., + Matsushima, S., Rokui, R., Dhamija, A., and P. Maheshwari, + "Building blocks for Network Slice Realization in Segment + Routing Network", Work in Progress, Internet-Draft, draft- + ali-teas-spring-ns-building-blocks-03, 7 September 2022, + <https://datatracker.ietf.org/doc/html/draft-ali-teas- + spring-ns-building-blocks-03>. + + [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>. + + [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., + and A. Gulko, "IGP Flexible Algorithm", RFC 9350, + DOI 10.17487/RFC9350, February 2023, + <https://www.rfc-editor.org/info/rfc9350>. + + [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, + K., and A. Dhamija, "SRv6 Implementation and Deployment + Status", Work in Progress, Internet-Draft, draft- + matsushima-spring-srv6-deployment-status-15, 5 April 2022, + <https://datatracker.ietf.org/doc/html/draft-matsushima- + spring-srv6-deployment-status-15>. + + [SRV6-MOB-ARCH-DISCUSS] + Kohno, M., Clad, F., Camarillo, P., and Z. Ali, + "Architecture Discussion on SRv6 Mobile User plane", Work + in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch- + 06, 9 March 2023, <https://datatracker.ietf.org/doc/html/ + draft-kohno-dmm-srv6mob-arch-06>. + + [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., + and R. Shekhar, "User Plane Message Encoding", Work in + Progress, Internet-Draft, draft-murakami-dmm-user-plane- + message-encoding-05, 5 March 2022, + <https://datatracker.ietf.org/doc/html/draft-murakami-dmm- + user-plane-message-encoding-05>. + + [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling + Protocol User Plane (GTPv1-U)", Version 17.4.0, 3GPP + TS 29.281, September 2022. + + [TS.38415] 3GPP, "PDU session user plane protocol", Version 17.0.0, + 3GPP TS 38.415, April 2022. + +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 von Hugo, + and Jeffrey Zhang for their useful comments of this work. + +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 + + +Authors' Addresses + + Satoru Matsushima (editor) + SoftBank + Japan + Email: satoru.matsushima@g.softbank.co.jp + + + Clarence Filsfils + Cisco Systems, Inc. + Belgium + Email: cf@cisco.com + + + Miya Kohno + Cisco Systems, Inc. + Japan + Email: mkohno@cisco.com + + + Pablo Camarillo Garvia (editor) + Cisco Systems, Inc. + Spain + Email: pcamaril@cisco.com + + + Daniel Voyer + Bell Canada + Canada + Email: daniel.voyer@bell.ca |