Internet-Draft End.M.GTP6.E.Red March 2024
Kawakami, et al. Expires 3 September 2024 [Page]
Intended Status:
Y. Kawakami
S. Matsushima
S. Zadok
D. Yeung
Arrcus, Inc.
D. Voyer
Bell Canada

SRH Reduction for SRv6 End.M.GTP6.E Behavior


Segment Routing over IPv6 for the Mobile User Plane specifies interworking between SRv6 networks and GTP-U networks including required behaviors. This document specifies a new behavior named End.M.GTP6.E.Red which improves the End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Distributed Mobility Management Working Group mailing list (, which is archived at

Source for this draft and an issue tracker can be found at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 September 2024.

Table of Contents

1. Introduction

Segment Routing over IPv6 for the Mobile User Plane [RFC9433] defines interworking between SRv6 [RFC8986] networks and GTP-U [TS.29281] networks including required behaviors such as End.M.GTP6.E. This End.M.GTP6.E behavior converts SRv6 packets to GTP-U packets for downlink(DL) traffic at an egress MUP-PE [I-D.mhkk-dmm-srv6mup-architecture] when a gNB [TS.23501] is using IPv6/GTP.

In End.M.GTP6.E behavior, an ingress MUP-PE needs two SIDs in an SRH with the remote endpoint information (IP address and TEID) in different places in the SRH and an egress MUP-PE also needs to fetch the last SID next to the active SID before outer IPv6 and SRH decapsulation to restore the IPv6/GTP-U header from those SIDs, in which current hardware pipelines may be unfamiliar or insufficient to implement.

This document specifies a new behavior named End.M.GTP6.E.Red which makes End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID. This behavior utilizes an Interwork Segment Discovery (ISD) Route and Type 1 Session Transformed (ST) Route of MUP SAFI [I-D.mpmz-bess-mup-safi], specified in [I-D.mhkk-dmm-srv6mup-architecture] to restore the gNB address from the reduced SRH [RFC8754].

2. Conventions and Definitions

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

Terminology used in this document is given by [RFC9433] and [I-D.mhkk-dmm-srv6mup-architecture].

3. End.M.GTP6.E.Red Behavior

End.M.GTP6.E.Red (Endpoint Behavior with encapsulation for IPv6/GTP-U tunnel with reduced SRH) is used in the interworking scenarios described in [RFC9433] for the downlink toward the legacy gNB using IPv6/GTP.

Figure 1 depicts a topology used for the example. This topology is the same as Figure 4 described in Section 5.3 of [RFC9433] but terminology is replaced by one used in [I-D.mhkk-dmm-srv6mup-architecture].

              Interwork Segment             Direct Segment _______
                 IP GTP-U          SRv6                   /       \
+--+      +-----+ [N3] +--------+        +--------+ [N6] /         \
|UE|------| gNB |------| MUP-PE |--------| MUP-PE |------\   DN    /
+--+      +-----+      +--------+        +--------+       \_______/
                     Egress PE for DL   Ingress PE for DL
Figure 1: Example Topology for Interworking

In this topology, we assume the addressing as below:

Figure 2 shows the relationship between RAN IP Prefix, gNB address and End.M.GTP6.E.Red SID.

| NLRI in ISD Route                    40+b
|   advertised RAN IP Prefix             |
|   actual RAN IP Prefix   | stuff field |
|          a bits          | 40-a+b bits |
:                          :             :
: gNB address              :             :                128
|                       IPv6 address                       |
:                                       /:                 :
:                         -------------- :                 :
: End.M.GTP6.E.Red SID   /               :                 :
|  SRGW-IPv6-LOC-FUNC   |Args.Mob.Session| remainder bits  |
|        b bits         |     40 bits    |   128-40-b bits |
Figure 2: Relationship between RAN IP Prefix and gNB address and SID

In one of deployment scenarios, the length of actual RAN IP Prefixrd can be 64 bits (a=64) or shorter (a<64) and the length of SRGW-IPv6-LOC-FUNC can be 48 bits (b=48) in both cases of full SID and uSID. These are given by the addressing design of the RAN and the SRv6 domain. In this case, the stuff field is 24 bits (or more) and then, the prefix length of advertised RAN IP Prefix (the NLRI in in the ISD Route) is 88 bits.

3.1. Control Plane Specification

3.1.1. Egress PE

If the actual RAN IP Prefix is shorter than b+40 bit-length, then the Egress PE makes up the missing 40-a+b bits(stuff field) from the gNB address so that the Egress PE can generate a prefix of b+40 bit length (advertised RAN IP Prefix).

The Egress PE generates SID prefixes of End.M.GTP6.E.Red behavior ('b' bits of SRGW-IPv6-LOC-FUNC field) for each advertised RAN IP Prefixes and holds the mapping.

The Egress PE MUST advertise an Interwork Segment Discovery (ISD) Route [I-D.mhkk-dmm-srv6mup-architecture] which NLRI contains the advertised RAN IP Prefix with the corresponding SID information.

3.1.2. Ingress PE

The Ingress PE receives a Type 1 Session Transformed (ST) Route [I-D.mhkk-dmm-srv6mup-architecture] for the UE from the MUP Controller and an ISD Route for the gNB from the Egress PE. When the Type 1 ST Route can be resolved with the RAN IP Prefix in the NLRI field of the ISD Route, the Ingress PE MUST generate a complete SID value by merging b+40 bit-length SID value stored in the ISD Route and the last 128-40-b bits of the Endpoint Address (the IPv6 address of the gNB) then store the complete SID as H.Encaps(.Red) behavior for the host route of the UE in the FIB.

3.2. Data Plane Specification

3.2.1. Ingress PE

When the Ingress PE receives a packet toward the UE and finds the corresponding local SID in the FIB, then just perform H.Encaps(.Red) behavior.

3.2.2. Egress PE

When Egress PE node N receives a packet destined to D, and D is a local End.M.GTP6.E.Red 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 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 and mapping)
   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


  • The source address S SHOULD be an End.M.GTP6.D SID instantiated at N or IPv6 address of the UPF.

  • The higher b+40 bits IPv6 DA can be restored from the advertised RAN IP Prefix corresponding to the SID in the mapping, and lower 128-40-b bits can be restored from lower 128-40-b bits of the End.M.GTP6.E.Red SID (remainder bits field in Figure 2).

  • GTP-U TEID is restored from Args.Mob.Session field in the SID as defined in [RFC9433].

4. 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.

5. IANA Considerations

IANA is requested to allocate, within the "SRv6 Endpoint Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment Routing Parameters" registry, the following values:

Table 1: New SRv6 Mobile User-plane Endpoint Behavior Types
Value Hex Endpoint behavior Reference
TBA TBA End.M.GTP6.E.Red This.ID

6. References

6.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <>.
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, , <>.
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, , <>.
Matsushima, S., Ed., Filsfils, C., Kohno, M., Camarillo, P., Ed., and D. Voyer, "Segment Routing over IPv6 for the Mobile User Plane", RFC 9433, DOI 10.17487/RFC9433, , <>.
3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", Version 17.4.0, 3GPP TS 29.281, , <>.

6.2. Informative References

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-06, , <>.
Murakami, T., Patel, K., Matsushima, S., Zhang, Z. J., Agrawal, S., and D. Voyer, "BGP Extensions for the Mobile User Plane (MUP) SAFI", Work in Progress, Internet-Draft, draft-mpmz-bess-mup-safi-03, , <>.
3GPP, "System architecture for the 5G System (5GS)", Version 17.0.0, 3GPP TS 23.501, , <>.

Authors' Addresses

Yuya Kawakami
Satoru Matsushima
Shay Zadok
Derek Yeung
Arrcus, Inc.
Daniel Voyer
Bell Canada