Skip to main content

SRH Reduction for SRv6 End.M.GTP6.E Behavior
draft-kawakami-dmm-srv6-gtp6e-reduced-01

Document Type Active Internet-Draft (individual)
Authors Yuya Kawakami , Satoru Matsushima , Shay Zadok , Derek M. Yeung , Daniel Voyer
Last updated 2024-03-01
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kawakami-dmm-srv6-gtp6e-reduced-01
dmm                                                          Y. Kawakami
Internet-Draft                                             S. Matsushima
Intended status: Informational                                  SoftBank
Expires: 3 September 2024                                       S. Zadok
                                                                Broadcom
                                                                D. Yeung
                                                            Arrcus, Inc.
                                                                D. Voyer
                                                             Bell Canada
                                                            2 March 2024

              SRH Reduction for SRv6 End.M.GTP6.E Behavior
                draft-kawakami-dmm-srv6-gtp6e-reduced-01

Abstract

   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 (dmm@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/dmm/.

   Source for this draft and an issue tracker can be found at
   https://github.com/yuyarin/draft-kawakami-dmm-srv6-gtp6e-reduced.

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 https://datatracker.ietf.org/drafts/current/.

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

Kawakami, et al.        Expires 3 September 2024                [Page 1]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

   This Internet-Draft will expire on 3 September 2024.

Copyright Notice

   Copyright (c) 2024 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
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  End.M.GTP6.E.Red Behavior . . . . . . . . . . . . . . . . . .   3
     3.1.  Control Plane Specification . . . . . . . . . . . . . . .   4
       3.1.1.  Egress PE . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.2.  Ingress PE  . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Data Plane Specification  . . . . . . . . . . . . . . . .   5
       3.2.1.  Ingress PE  . . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Egress PE . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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

Kawakami, et al.        Expires 3 September 2024                [Page 2]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

   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:

Kawakami, et al.        Expires 3 September 2024                [Page 3]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

   *  The prefix length of the Interwork Segment, that is, actual RAN IP
      Prefix is 'a'.

   *  The length of the LOC+FUNCT field of the SID for End.M.GTP6.E.Red
      behavior on the Egress PE is 'b'.

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

   0
   |
   | 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

Kawakami, et al.        Expires 3 September 2024                [Page 4]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

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:

Kawakami, et al.        Expires 3 September 2024                [Page 5]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

      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

   Notes:

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

Kawakami, et al.        Expires 3 September 2024                [Page 6]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

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:

              +=======+=====+===================+===========+
              | Value | Hex | Endpoint behavior | Reference |
              +=======+=====+===================+===========+
              | TBA   | TBA | End.M.GTP6.E.Red  | This.ID   |
              +-------+-----+-------------------+-----------+

                    Table 1: New SRv6 Mobile User-plane
                          Endpoint Behavior Types

6.  References

6.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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8986>.

   [RFC9433]  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, July
              2023, <https://www.rfc-editor.org/rfc/rfc9433>.

Kawakami, et al.        Expires 3 September 2024                [Page 7]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

   [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", Version 17.4.0, 3GPP
              TS 29.281, September 2022,
              <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.

6.2.  Informative References

   [I-D.mhkk-dmm-srv6mup-architecture]
              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, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-
              srv6mup-architecture-06>.

   [I-D.mpmz-bess-mup-safi]
              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, 5 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-mpmz-bess-
              mup-safi-03>.

   [TS.23501] 3GPP, "System architecture for the 5G System (5GS)",
              Version 17.0.0, 3GPP TS 23.501, September 2021,
              <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.

Authors' Addresses

   Yuya Kawakami
   SoftBank
   Email: yuya.kawakami01@g.softbank.co.jp

   Satoru Matsushima
   SoftBank
   Email: satoru.matsushima@g.softbank.co.jp

   Shay Zadok
   Broadcom
   Email: shay.zadok@broadcom.com

Kawakami, et al.        Expires 3 September 2024                [Page 8]
Internet-Draft              End.M.GTP6.E.Red                  March 2024

   Derek Yeung
   Arrcus, Inc.
   Email: derek@arrcus.com

   Daniel Voyer
   Bell Canada
   Email: daniel.voyer@bell.ca

Kawakami, et al.        Expires 3 September 2024                [Page 9]