RFC 9433

Segment Routing over IPv6 for the Mobile User Plane

📅 published July 2023, from ietf

Segment Routing over IPv6 for the Mobile User Plane 💖

Okay bestie, this is RFC 9433 📄🦋 It's written by S. Matsushima (Ed., SoftBank), C. Filsfils, M. Kohno, P. Camarillo (Ed., Cisco Systems, Inc.), and D. Voyer (Bell Canada). It's labelled Informational and was published in July 2023, with ISSN 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it's a standalone doc 🌸

Abstract ✨

Okay so this doc looks at how SRv6 (Segment Routing over IPv6) could work on the user plane of mobile networks 📱 SRv6 does mobile user-plane functions in a really simple way because of its network programming nature 💅 Its statelessness, plus the fact that it can control both the service-layer path and the underlying transport, is lowkey perfect for the mobile user plane. You get flexibility, end-to-end network slicing, and Service Level Agreement (SLA) control for all kinds of apps 🔥

The doc also lays out the SRv6 Endpoint Behaviors that mobility use cases need 🧚

Status of This Memo

Not an Internet Standards Track spec, just published for info 🎀

This is an IETF product 🌈 It reflects IETF community consensus, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard. See Section 2 of RFC 7841 for the deets ✨

For current status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9433 🔗

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled from this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 🧚

Okay so in mobile networks, mobility systems give connectivity over a wireless link to both stationary and non-stationary nodes 📶 The user plane sets up a tunnel between the mobile node and its anchor node, running over IP-based backhaul and core networks 🛣️

This doc specifies how SRv6 [RFC8754] [RFC8986] applies 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, whether it's topological or service based 🦋

So SRv6 in mobile networks gives you a source-routing mobile architecture 🔥 Operators can explicitly say which route packets take to and from the mobile node, and the SRv6 Endpoint nodes act as the mobile user-plane anchors 👑

2. Conventions and Terminology 🎀

Here's the important part 🫶 When this doc uses the BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", they're 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 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 are defined in [RFC8754]: Segment Routing Header (SRH) and Reduced SRH 🍓

The following terms 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 gets resolved to a SID list. A SID list is written as <S1, S2, S3>, where S1 is the first SID to visit, S2 is the second, and S3 is the last SID to visit along the SR path 🛤️

A packet with Source Address SA, Destination Address DA, and an SRH as its next header is written as:

(SA,DA) (S3, S2, S1; SL)

Here the SRH holds the SID list <S1, S2, S3> with Segments Left = SL 🌸

  • Source Address is SA, Destination Address is DA, and next header is SRH.
  • SRH with SID list <S1, S2, S3> with Segments Left = SL.
  • The payload of the packet is omitted.

Heads up, <> and () mean different things 👀 <S1, S2, S3> is a SID list where S1 is the first SID and S3 is the last one to traverse. (S3, S2, S1; SL) is the same SID list, but encoded in SRH format, where the rightmost SID in the SRH is the first SID and the leftmost is the last. When you're talking about an SR Policy at a high level, <S1, S2, S3> is easier. When you're looking at a detailed packet behavior diagram, (S3, S2, S1; SL) is more convenient ✨

A packet with Source Address SA1, Destination Address DA1, and next header IP is written as (SA1,DA1). It also carries Source Address SA2 and Destination Address DA2, written as (SA2, DA2) 🦋

Across the whole doc, SRH[n] is a shorter way of saying Segment List[n], as defined in [RFC8754] 💖

Throughout the examples, this doc uses these conventions:

  • 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 🌟

These SRv6 Endpoint Behaviors show up all over the doc. They're 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 doc defines new SRv6 Endpoint Behaviors in Section 6 👑

3. Motivation 💭

Mobile networks are getting way harder to run 😭 Traffic keeps growing and latency requirements keep getting tighter 📈 Then there are new use cases, like distributed NFV Infrastructure, that make network operations even trickier 🧩 On top of that, the number of connected devices keeps climbing, so mobile entities hit scalability problems because the state they have to keep keeps growing 💀

The current mobile architecture doesn't account for the underlying transport 🙈 The user plane is rigidly split into radio access, core, and service networks, which are connected by tunneling based on user-plane roles like access and anchor nodes 🧱 All of that makes it hard for operators to optimize and run the data path 😤

Meanwhile, apps have moved to IPv6, and network operators have started adopting IPv6 as their IP transport 🌐 SRv6, which is the IPv6 data plane instantiation of Segment Routing [RFC8402], brings the application data path and the underlying transport layer together into one protocol ✨ That lets operators optimize the network in a simpler way and removes forwarding state from the network 🦋 It's also a good fit 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 that mobility management needs 💜 It takes advantage of underlying transport awareness and flexibility, and it can also include services, so the end-to-end mobile data plane gets optimized 🔥

The use cases for SRv6 mobility are covered in [SRV6-MOB-USECASES], and the architectural benefits are discussed in [SRV6-MOB-ARCH-DISCUSS] 🌸

4. 3GPP Reference Architecture ✨

Okay, bestie, this section is the 3GPP reference architecture plus the deployment scenarios that could show up in real life 📡🌸

Figure 1 is a reference diagram from the 5G packet core architecture [TS.23501]. 💅

The user plane described in this document doesn't depend on any specific architecture 🫶 The 5G packet core architecture shown here 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

Here's the cast of characters 🎀

  • 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 doesn't show a UPF that's only connected to N9 interfaces, but the mechanisms in this document also work in that case 👀

Each session from a UE gets assigned to a UPF 🦋 Sometimes multiple UPFs get used, which gives you 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, so return traffic gets routed to the right UPF. It's giving routing queen energy 👑

5. User-Plane Modes

Okay, this section introduces an SRv6-based mobile user plane 🧚 It presents two different "modes" that vary in how they use SRv6.

The first one is the "Traditional mode", which inherits the current 3GPP mobile architecture. In this mode, SRv6 replaces the GTP-U protocol [TS.29281]. The N3, N9, and N6 interfaces are still point-to-point interfaces with no intermediate waypoints, just like in the current mobile network architecture 🌈

The second one is the "Enhanced mode", which is an evolution of the "Traditional mode" ✨ In this mode, the N3, N9, or N6 interfaces can have intermediate waypoints (SIDs) that are used for traffic engineering or VNF purposes, and 3GPP functionalities don't see them. The end result is optimal end-to-end policies across the mobile network, with transport and services awareness. Iconic 💅

In both the Traditional and the Enhanced modes, this document assumes that the gNB and the UPFs are SR-aware (N3, N9, and potentially N6 interfaces are SRv6) 🫶

On top of those two modes, this document introduces three mechanisms for interworking with legacy access networks (the ones where the N3 interface is unmodified) 🔥 Here they're introduced as a variant of the Enhanced mode, but they're equally applicable to the Traditional mode too.

The first mechanism is designed to interwork with legacy gNBs using GTP-U/IPv4. The second is designed to interwork with legacy gNBs using GTP-U/IPv6. The third is another mode that lets you deploy SRv6 when legacy gNBs and UPFs still run GTP-U 🦋

This document uses the SRv6 Endpoint Behaviors defined in [RFC8986], plus 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 stay unchanged, with the one exception of using SRv6 as the data plane instead of GTP-U. There's no impact on the rest of the mobile system. Low-drama, high-impact 🌸

In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 to a specific GTP-U tunnel (Tunnel Endpoint Identifier (TEID)). This 1-for-1 mapping gets mirrored here: the SRv6 encapsulation replaces the GTP-U encapsulation, and nothing else changes 🍓 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 changes needed in the mobile system, which makes it a great starting point for building 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 whether 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, the QFI (QoS Flow Identifier), and the IPv6 Destination Address 🎀

Our example topology is in Figure 2. The gNB and the UPFs are SR-aware. In the uplink and downlink packet flow descriptions, A is an IPv6 address of the UE, and Z is an IPv6 address reachable within the DN. The new SRv6 Endpoint Behavior End.MAP, 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

Here's the uplink packet flow 📤

     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's only one SID, there's no need to push an SRH (reduced SRH). The gNB just adds an outer IPv6 header with IPv6 DA U1::1. The gNB gets the SID U1::1 from the existing control plane (N2 interface). U1::1 represents an anchoring SID specific to that session at UPF1 💖

When the packet reaches 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 reaches UPF2, the SID U2::1 corresponds to an End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates the packet, does a lookup in a specific table associated with that mobile network, and forwards the packet toward the DN 🚀

Now the downlink packet flow 📥

    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 UPF2, 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 in a new IPv6 header with no SRH, since there's only one SID 🌸

When the packet arrives 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 🦋

When the packet arrives on the 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 extension headers, and forwards the traffic toward the UE. Main character energy 🎬

5.2. Enhanced Mode

Enhanced mode improves scalability, gives you traffic engineering capabilities, and allows service programming [SR-SERV-PROG]. It does this by using multiple SIDs in the SID list, instead of the direct connectivity between UPFs with no intermediate waypoints that the Traditional mode has 🌈

So the main difference is that the SR Policy MAY include SIDs for traffic engineering and service programming in addition to the anchoring SIDs at the UPFs 👑

Also, in this mode, the operator may choose to aggregate several devices under the same SID list (for example, stationary residential meters for 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 tells the gNB to use SRv6 🫶

The gNB resolves the IP address it gets via the control plane into a SID list. The resolution mechanism is out of scope for this document 🙈

Note that the SIDs MAY use the argument Args.Mob.Session (Section 6.1) if the UPFs require it 💜

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, to enforce a low-latency path in the network. Neither S1 nor C1 needs 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

Here's the uplink packet flow for Enhanced mode 📤

   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

The UE sends its packet (A,Z) on a specific bearer to its gNB. The gNB's control plane associates that session from the UE (A) with the IPv6 address B. The gNB resolves B into a SID list <S1, C1, U1::1> 🔍

When the 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 the packet toward the DN. Bestie, we made it through the whole network 🌈

okay bestie, here's the downlink flow 🦋 It goes like this:

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

So when the packet shows up at UPF1, UPF1 sorts that flow into a UE PDU Session 🎀 That session is tied to the policy <C1, S1, gNB>. Then UPF1 does an H.Encaps.Red, which wraps the packet in a brand-new IPv6 header with its matching SRH. Iconic wrapping, honestly 🎁

C1 and S1 then do their own Endpoint processing, like the good little service-segment queens they are 👑

Once the packet reaches the gNB, the IPv6 DA maps to an End.DX4, End.DX6, or End.DX2 behavior at the gNB (it depends on what kind of traffic is inside). The gNB decapsulates the packet, peels off the IPv6 header, and forwards the traffic toward the UE. gNB::1 is just one example of a SID for this service 🌸

Quick side note 💅 There are a few different ways to do UE session aggregation. Which one you pick is a local decision made by the operator, so it's their call. One option is Args.Mob.Session (Section 6.1). The other option is for the gNB to do an IP lookup on the inner packet using the End.DT4, End.DT6, and End.DT2U behaviors ✨

5.2.3. Scalability ⭐

Enhanced mode is seriously scalable, no cap 🌈 It lets a bunch of UEs share the same SID list. Picture stationary residential meters hanging out in the same cell. They can all share one SID list, which is so efficient 🙈 Compared to Traditional mode (one unique SID per UE) and GTP-U (one TEID per UE), this is a huge glow-up for scale 📈

5.3. Enhanced Mode with Unchanged gNB GTP-U Behavior 🧚

This section covers two ways to interwork with legacy gNBs that still speak GTP-U: one for IPv4 and one for IPv6 💜

In the interworking scenarios shown in Figure 4, the gNB does not support SRv6. It does support GTP-U encapsulation over IPv4 or IPv6, though. To make the interworking happen, we add an SR Gateway (SRGW) entity. The SRGW is a new entity that maps GTP-U traffic into SRv6. It sits at the edge of the SR domain and handles the mapping for both inbound and outbound traffic 🫶

The SRGW is not an anchor point and keeps very little state, which is the whole vibe. That's why both the IPv4 and IPv6 methods can 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 mechanisms in this section apply 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, bestie 📝

  • The gNB is unchanged (control plane or user plane) and encapsulates into GTP-U. The N3 interface is not modified.
  • The 5G control plane toward 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 an SRH with the SID list.
  • There is no state for the downlink at the SRGW. Literally zero 🙌
  • There is simple state in the uplink at the SRGW. Using Enhanced mode means 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.

Here's the example topology in Figure 5 ✨ S1 and C1 are two service segments. S1 is a VNF in the network, and C1 is a router set up 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

The uplink packet flow goes like this:

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, wraps the packet in IPv6, UDP, and GTP-U headers. The IPv6 DA B and the GTP-U TEID T are the ones it received over the N2 interface 🌸

The IPv6 address that got signaled over N2 for that UE PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the SRGW, so the packet gets routed right to the SRGW 💌

When the packet arrives at the SRGW, it recognizes B as an End.M.GTP6.D Binding SID (see Section 6.3). So the SRGW strips the IPv6, UDP, and GTP-U headers and pushes on an IPv6 header with its own SRH. That SRH holds the SIDs bound to the SR Policy linked to this Binding SID. There is at least one instance of the End.M.GTP6.D SID per PDU type 🧚

S1 and C1 do their Endpoint functionality and forward the packet along 🏃‍♀️

When the packet reaches UPF2, the active segment is (U2::T), which is bound to End.DT4/6. UPF2 then decapsulates the packet (removing the outer IPv6 header along with all its extension headers) and forwards it toward the DN 🎉

The downlink packet flow goes like this:

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 shows up at UPF2, UPF2 looks up the table tied to A and finds the SID list <C1, S1, SRGW::TEID, gNB>. Then it does an H.Encaps.Red, wrapping the packet in a new IPv6 header with its matching SRH 🎁

C1 and S1 do their Endpoint processing, as usual 💅

Once the packet reaches the SRGW, the SRGW identifies the active SID as an End.M.GTP6.E function. It removes the IPv6 header and all its extension headers, then 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 those headers onto the packet and forwards it toward the gNB. There is one instance of the End.M.GTP6.E SID per PDU type 🌈

Once the packet reaches the gNB, it's just a regular IPv6/GTP-U packet. The gNB looks up the specific radio bearer for that TEID and forwards the packet on that bearer. This gNB behavior isn't modified from current or previous generations, so the gNB doesn't have to change 🙌

5.3.1.3. Scalability ⭐

For downlink traffic, the SRGW is stateless. All the state lives in the SRH that UPF2 pushes. UPF2 must have the UE state since it's the UE's session anchor point 🫶

For uplink traffic, the state at the SRGW doesn't necessarily have to be unique per PDU Session, because the SR Policy can be shared among UEs. That makes SRGW deployments way more scalable than 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 on 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 the 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].
  • The SRGW removes the GTP-U header, finds the SID list related to the DA, and adds an SRH with the SID list.

Here's the example topology 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 is a VNF in the network, and C1 is a router set up 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

okay so the uplink packet flow goes like this 💖

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

bestie, the UE sends a packet destined to Z toward the gNB on a specific bearer for that session 🦋. The gNB is unmodified, so it wraps the packet in new IPv4, UDP, and GTP-U headers. The IPv4 DA (B) and the GTP-U TEID (T) are the ones it received at the N2 interface ✨.

When the packet hits the SRGW for UPF1, the SRGW uses a classification engine rule for traffic coming from the gNB. That rule steers the traffic into an SR Policy by using the function H.M.GTP4.D 🎀. The SRGW strips the IPv4, UDP, and GTP headers, then pushes an IPv6 header with its own SRH. That SRH holds the SIDs related to the SR Policy for this traffic. The SRGW forwards based on the new IPv6 DA 💅.

S1 and C1 do their own 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. That one performs the decapsulation (removing the outer IPv6 header along with all its extension headers) and forwards toward the DN 👑.

Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U are different 🙈. That's because IPv6/GTP-U can use the remote steering capabilities that the Segment Routing BSID provides. In IPv4, this construct isn't available, and building a similar mechanism would take a significant amount of address space. so IPv6 gets the cute shortcut and IPv4 doesn't ngl.

the downlink flow is next, and it's giving mirror image 🪞

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 shows up at UPF2, UPF2 looks up the table tied to A and finds the SID list <C1, S1, SRGW::SA:DA:TEID> 🌸. UPF2 then runs an H.Encaps.Red operation, wrapping the packet in a new IPv6 header with its matching SRH.

C1 and S1 handle their related Endpoint processing 🦋.

Once the packet reaches the SRGW, the SRGW sees that the active SID is an End.M.GTP4.E function 💜. It removes the IPv6 header and all of its extension headers. Then it generates IPv4, UDP, and GTP-U headers. The IPv4 SA and DA come in as SID arguments, and the TEID in the new GTP-U header is the argument of the received End.M.GTP4.E SID. The SRGW pushes those headers onto the packet and sends it toward the gNB 🍓.

When the packet gets to the gNB, it's a regular IPv4/GTP-U packet. The gNB looks for the radio bearer that matches that TEID and forwards the packet on that bearer. This gNB behavior hasn't changed from current or previous generations, which is so reassuring 🫶.

5.3.2.3. Scalability

let's talk scale 📈. For downlink traffic, the SRGW is stateless ✨. All the state lives in the SRH that UPF2 pushes. UPF2 needs this UE-based state anyway, since it's the anchor point.

For uplink traffic, the state at the SRGW is kept per UE/session, based on a classification engine. There is state for steering the different sessions in the form of an SR Policy. But SR Policies are shared among several UE/sessions, which is a very efficient glow-up 💅.

5.3.3. Extensions to the Interworking Mechanisms

this section covers two mechanisms for interworking with gNBs and UPFs that don't 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 also apply to the Traditional mode 🌈.

5.4. SRv6 Drop-In Interworking

this is the mode for legacy gNBs and UPFs that still run GTP-U 🧚. It gives you an SRv6-enabled user plane sitting between two GTP-U tunnel endpoints. The whole vibe is drop-in 🦋.

This mode uses two SRGWs that map GTP-U traffic to SRv6 and back again 💖.

Unlike the other interworking modes, both of the mobility overlay endpoints here use GTP-U 😭. Two SRGWs get deployed on 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 for Figure 7 goes like this 🎀:

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 gets sent to the gNB, the gNB is unmodified (the control plane and user plane both stay GTP-U) 🍓. It wraps the packet in new IP, UDP, and GTP-U headers. The IPv6 DA U::1 and the GTP-U TEID are the ones it received over 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, so the packet gets 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) ✨. So the SRGW removes the IPv6, UDP, and GTP-U headers and pushes an IPv6 header with its own SRH. That SRH contains the SIDs bound to the SR Policy tied to this Binding SID. There is one instance of the End.M.GTP6.D.Di SID per PDU type.

S1 and C1 do their related Endpoint functionality and forward the packet 🧚.

Once the packet reaches SRGW-B, the SRGW sees the active SID as an End.M.GTP6.E function 💅. It removes the IPv6 header and all its extension headers. Then it 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 onto the packet and forwards it toward the UPF. There is one instance of the End.M.GTP6.E SID per PDU type.

Once the packet reaches the UPF, it's a regular IPv6/GTP packet. The UPF looks for the specific rule for that TEID and forwards the packet accordingly. This UPF behavior also hasn't changed from current or 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 that some mobile nodes need 💰. The Args.Mob.Session argument format gets used in combination with the End.Map, End.DT4/End.DT6/End.DT46, and End.DX4/End.DX6/End.DX2 behaviors. Note that this proposed format applies to 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

here's what each field does 🎀:

  • 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 lets the UE map uplink user-plane traffic to QoS flows without SMF-provided QoS rules 💖.
  • U: Unused and for future use. It MUST be 0 on transmission and ignored on receipt 🙈.
  • PDU Session ID: Identifier of the PDU Session. The GTP-U equivalent is TEID.

Args.Mob.Session is required when 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 perform the behaviors that need granularity per QFI and/or per PDU Session 👑.

Note that the encoding of user-plane messages (for example, Echo Request, Echo Reply, Error Indication, and End Marker) is out of scope for this document. [SRV6-UP-MSG-ENCODING] defines one possible encoding method 🌈.

6.2. End.MAP

End.MAP (Endpoint Behavior with SID mapping) gets 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 ✨

okay bestie, End.M.GTP6.D (Endpoint Behavior with IPv6/GTP-U decapsulation into SR Policy) is the one 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, which is another variant of the IPv6/GTP decapsulation function, and this one 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 a 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 ✨

okay so a mobile network might need to run "network slices" 🍰, which just means it splits up its network resources logically inside the same SR domain. Think of it like having a bunch of separate lanes on the same highway 🛣️

[RFC9256] shows how to build basic network slices with SR. Depending on what you need, you can level them up with these tools:

And you can combine all of that with ODN/AS (On-Demand Next Hop / Automated Steering) [RFC9256] for automated slice provisioning and traffic steering. Automation era, bestie 🤖💅

If you want the full end-to-end slice details, they live in [NETWORK-SLICE] 🧚

9. Control Plane Considerations

okay this doc is all about the user plane and how it stays independent from the control plane 🫶 The SRv6 mobile user-plane behaviors could show up in newer setups like the ones in [MFA] and [MUP-SR-ARCH], but this document does not change the existing mobility control plane at all. Hands off, control plane 🙅‍♀️

Also, Section 11 is where the SRv6 Endpoint Behavior codepoints for all the new behaviors in here get allocated 🎀

10. Security Considerations

okay this section is SERIOUS, so pay attention 😭🔐

The security stuff for Segment Routing is covered in [RFC8402]. For SRv6 specifically, the security considerations and the ways to secure an SR domain are in [RFC8754]. Together they lay out the required security mechanisms that set up an SR domain of trust 🏰 That way SRv6-based services can run for internal traffic while external traffic gets kept from accessing or exploiting them. Main character protection energy 👑

The tech in this document gets applied to a mobile network sitting inside the SR domain. And it's worth noticing how much the SR domain looks like the 3GPP Packet Core Domain. Lowkey iconic overlap 🌈

This document brings in new SRv6 Endpoint Behaviors. These behaviors work on control plane information, including the info inside the received SRH payload they operate on. So if an attacker wants to mess with the behaviors, they'd first have to alter the SR domain itself, as defined in [RFC8754] 🕵️‍♀️

Ngl this is the whole point: the behaviors don't need any special security consideration of their own, because they're deployed inside that SR domain already 🛡️

11. IANA Considerations

okay so IANA gets some new values 🦋 The following values were allocated in the "SRv6 Endpoint Behaviors" [RFC8986] subregistry, which lives inside 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

Every single one of these is a RFC 9433 🎀 with the Change Controller set to IETF. Iconic consistency 💖

12. References

12.1. Normative References

12.2. Informative References

Acknowledgements

the authors wanna give a huge shoutout to 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 on 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
📦 where this page comes from