RFC 9188

Generic Multi-Access (GMA) Encapsulation Protocol

📅 published February 2022, from ietf

Title Block 🎀

Independent Submission 📮 This RFC came in from outside the IETF's main stream, and it's Experimental 🧪, so it's a test drive, not a finished standard.

  • RFC number: 9188 ✨
  • Title: Generic Multi-Access (GMA) Encapsulation Protocol
  • Authors: J. Zhu (Intel) and S. Kanugovi (Nokia) 🫶
  • Category: Experimental
  • ISSN: 2070-1721
  • Date: February 2022 🗓️
  • Obsoletes / Updates: the header doesn't list either one, so there's nothing to report here 💅

Abstract 💜

Picture a device connected to Wi-Fi, LTE, 5G, and DSL all at once 📶. It would be amazing to blend those connections together below the transport layer (L4), so apps without built-in multi-path can still feel smooth ✨. That takes extra control info in every packet, like a sequence number 🔢. This doc introduces a lightweight, flexible encapsulation protocol built for exactly that.

The authors built it from their experience in multiple standards bodies, including the IETF and 3GPP. But, and this is a big but 🙈, it's not an Internet Standard, and it doesn't represent the IETF's consensus. The goal is to help other devs build interoperable implementations so they can experiment with the protocol 🧑‍💻.

Status of This Memo 📋

This isn't an Internet Standards Track spec. It's published so people can examine it, try out implementations, and evaluate it 🔍.

It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves aren't candidates for any level of Internet Standard; see Section 2 of RFC 7841.

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

Copyright (c) 2022 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) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🗂️

1.  Introduction
  1.1.  Scope of Experiment
2.  Conventions Used in This Document
3.  Use Case
4.  GMA Encapsulation Methods
  4.1.  Trailer-Based IP Encapsulation
  4.2.  Header-Based IP Encapsulation
  4.3.  Header-Based Non-IP Encapsulation
  4.4.  IP Protocol Identifier
5.  Fragmentation
6.  Concatenation
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Authors' Addresses

1. Introduction ✨

Picture a device connected to several networks at once, like Wi-Fi, LTE, 5G, and DSL 📶. The dream is to blend those connections together below the transport layer (L4) so apps that can't do multi-path on their own still get a better experience 💖.

Figure 1 shows the Multi-Access Management Service (MAMS) user-plane protocol stack [MAMS]. It's been the base for today's multi-access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2] 🧩. It has two layers: convergence and adaptation.

The convergence layer handles the multi-access stuff: multi-link (path) aggregation, splitting and reordering, lossless switching and retransmission, fragmentation, concatenation, and more 🪄. It sits on top of the adaptation layer. On the sending side, a User Payload (like an IP packet) goes through the convergence layer first, then the adaptation layer, and then gets sent over a delivery connection. On the receiving side it's the reverse: the adaptation layer goes first, then the convergence layer 🔄.

      +-----------------------------------------------------+
      |   User Payload, e.g., IP Protocol Data Unit (PDU)   |
      +-----------------------------------------------------+
   +-----------------------------------------------------------+
   |  +-----------------------------------------------------+  |
   |  | Multi-Access (MX) Convergence Layer                 |  |
   |  +-----------------------------------------------------+  |
   |  +-----------------------------------------------------+  |
   |  | MX Adaptation   | MX Adaptation   | MX Adaptation   |  |
   |  | Layer           | Layer           | Layer           |  |
   |  +-----------------+-----------------+-----------------+  |
   |  | Access #1 IP    | Access #2 IP    | Access #3 IP    |  |
   |  +-----------------------------------------------------+  |
   |                            MAMS User-Plane Protocol Stack |
   +-----------------------------------------------------------+

              Figure 1: MAMS User-Plane Protocol Stack

GRE (Generic Routing Encapsulation) [LWIPEP] [GRE1] [GRE2] can be used as the encapsulation protocol at the convergence layer to carry extra control info, like a key and a sequence number 🔑. But it has two big problems 😬:

  • It's hard to add new control fields, because the GRE header formats are already defined.
  • IP-over-IP tunneling (which GRE requires) adds lots of overhead, especially for small packets 📦.

For example, IP-over-IP/GRE tunneling with both a key and a sequence Number costs 32 bytes (20-byte IP header + 12-byte GRE header). That's 80% of a 40-byte TCP ACK packet. Yikes 💀.

This document presents a lightweight Generic Multi-Access (GMA) encapsulation protocol for the convergence layer 🦋. It supports three encapsulation methods: trailer-based IP encapsulation, header-based IP encapsulation, and non-IP encapsulation. The IP methods skip IP-over-IP tunneling, which saves 20 bytes. That's 50% of a 40-byte TCP ACK packet, and it's a glow-up 🌸. It also adds new control fields for fragmentation and concatenation, which GRE-based solutions don't have [LWIPEP] [GRE1] [GRE2].

GMA only works between endpoints that have been configured to use it. That configuration can come from any control messages and procedures, for example Multi-Access Management Services [MAMS]. UDP or IPsec tunneling can also be used at the adaptation sublayer to protect GMA operation from intermediate nodes 🛡️.

The solution in this document was developed by the authors from their experience in multiple standards bodies, including the IETF and 3GPP. But again, it's not an Internet Standard and doesn't represent IETF consensus. This document gives the protocol specification so people can run the experiment described in Section 1.1 and build interoperable implementations 🧪.

1.1. Scope of Experiment 🔬

This protocol is an experiment 🧪. The point is to find out whether it meets the requirements, whether it can be used safely, and whether it's ready for deployment.

Section 4 describes three encapsulation methods this protocol enables. Part of the experiment is figuring out whether all three are needed, or whether, for example, every implementation can just support the main "trailer-based" IP encapsulation method. The experiment will also look at the relative merits of the IP and non-IP methods 🤔.

This experiment can run on the Internet, because GMA packets are identified by an IP protocol number and the protocol is meant for single-hop propagation. Devices shouldn't be forwarding packets. If they do, they won't need to look at the payload. Destination systems that don't support this protocol shouldn't receive these packets, and they'll handle them as unknown payloads under normal IP processing. So the experiment happens between consenting end systems that have been mutually configured to join it, as described in Section 7 💌.

Heads up, this experiment "reuses" the IP protocol identifier 114, as described in Section 4.4 ⚠️. Part of the experiment is checking whether that's safe. The experiment should consider these safety mechanisms:

  • GMA endpoints SHOULD detect non-GMA IP packets that also use 114 and log an error to report the situation (although such error logging MUST be subject to rate limits).
  • GMA endpoints SHOULD stop using 114 and switch to non-IP encapsulation, i.e., UDP encapsulation (Figure 7), after detecting any non-GMA usage of 114.

The experiment SHOULD use a packet tracing tool, like WireShark or TCPDUMP, to monitor ingress and egress traffic at GMA endpoints. That makes sure the safety mechanisms above are actually in place 🕵️‍♀️.

Path quality measurements (one-way delay, loss, and so on) and congestion detection are done by the receiver, using GMA control fields like Sequence Number and Timestamp ⏱️. The receiver then decides how to split or steer traffic across multiple delivery connections. The GMA control protocol [GMAC] MAY be used for signaling between GMA endpoints 📡. Another goal is to see how various receiver-based algorithms [GCC] [MPIP] handle multi-path traffic management, and what that does to end-to-end (E2E) performance (throughput, delay, and so on) for higher-layer transport protocols like TCP, QUIC, and WebRTC 🚀.

The authors will keep tracking the experiment's progress, and they encourage other implementers to get in touch to share their implementation status and experiences with the protocol 💬.

2. Conventions Used in This Document 📜

Here's the deal with the key words 💅. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what BCP 14 [RFC2119] [RFC8174] says they mean. That only applies when they appear in all capitals, like in this list. Lowercase versions are just regular words 🩷.

3. Use Case 🎀

okay so picture this, bestie 💅 a client device (smartphone, laptop, whatever you've got) can be online over Wi-Fi AND LTE at the same time 📱✨. One of those links, say LTE, is the anchor connection. It hands over the IP address and keeps end-to-end Internet access working. The other one, say Wi-Fi, is the delivery connection, which is basically an extra lane between the client and the Multi-Access Gateway for multi-access optimizations 🛣️🦋. Main character energy, no cap.

Here's the layout (Figure 2) 👀

                    Multi-Access Aggregation

                +---+                        +---+
                | |A|--- LTE Connection -----|C| |
                |U|-|                        |-|S| Internet
                | |B|--- Wi-Fi Connection ---|D| |
                +---+                        +---+
               client                Multi-Access Gateway

Figure 2: GMA-Based Multi-Access Aggregation

and here's who's who 🫶

  • A: The adaptation-layer endpoint of the LTE connection resides in the client.
  • B: The adaptation-layer endpoint of the Wi-Fi connection resides in the client.
  • C: The adaptation-layer endpoint of the LTE connection resides in the Multi-Access Gateway, aka N-MADP (Network Multi-Access Data Proxy) in [MAMS].
  • D: The adaptation-layer endpoint of the Wi-Fi connection resides in the Multi-Access Gateway.
  • U: The convergence-layer endpoint resides in the client.
  • S: The convergence-layer endpoint resides in the Multi-Access Gateway.

so what does this actually get you? 🤩 per-packet aggregation lets a single IP flow use the combined bandwidth of both connections (iconic). If a packet gets lost during a temporary link outage, it can be retransmitted 🔁. Packets can also be duplicated over multiple connections for high reliability and low latency, and the receiving side gets rid of the duplicates 🙌. All of this needs extra control info in each packet, like a sequence number, and the GMA encapsulation protocol in this document can carry that 💜.

The GMA protocol is built for multiple connections, but it's also fine to use when there's only one connection between two endpoints 🌸. For example, it can be used for loss detection and recovery. It can also be used to concatenate multiple small packets, which cuts down on per-packet overhead ✨.

4. GMA Encapsulation Methods 🧚

the GMA encapsulation protocol supports these three methods:

  • Trailer-based IP Encapsulation (Section 4.1)
  • Header-based IP Encapsulation (Section 4.2)
  • Header-based non-IP Encapsulation (Section 4.3)

okay now the rules, and they're kinda strict 😭

Non-IP encapsulation MUST be used if the original IP packet is IPv6. 🫣

Trailer-based IP encapsulation MUST be used if it is supported by GMA endpoints and the original IP packet is IPv4. 💖

Header-based encapsulation MUST be used if the trailer-based method is not supported by either the client or the Multi-Access Gateway. In this case, if the adaptation layer (e.g., UDP tunneling) supports non-IP packet format, non-IP encapsulation MUST be used. Otherwise, header-based IP encapsulation MUST be used. 🔄

If non-IP encapsulation is configured, a GMA header MUST be present in every packet. 🎀 If IP encapsulation is configured instead, a GMA header or trailer may be added dynamically on a per-packet basis. Either way, it signals that a GMA header (or trailer) is there by setting the protocol type of the GMA PDU to "114" (see Section 4.4) 🔢.

The GMA endpoints MAY configure the GMA encapsulation method through control signaling or pre-configuration. For example, the "MX UP Setup Configuration Request" message from Multi-Access Management Service [MAMS] includes "MX Convergence Method Parameters". That field gives the list of parameters for configuring the convergence layer, and it can be extended to indicate the GMA encapsulation method 🧩.

⚠️ bestie, this one's serious. A GMA endpoint MUST discard a received packet under any of the following conditions. It MAY also log an error to report the situation, although that error logging MUST be subject to rate limits 🚨
  • The GMA version number in the GMA header (or trailer) is not understood or supported by the GMA endpoint.
  • A flag bit in the GMA header (or trailer) not understood or supported by the GMA endpoint is set to "1".

4.1. Trailer-Based IP Encapsulation 🎀

Okay bestie, this is the trailer method, and it's giving tidy 💅. Here's the layout:

          |<---------------------GMA PDU ----------------------->|
          +------------------------------------------------------+
          | IP hdr |        IP payload             | GMA Trailer |
          +------------------------------------------------------+
          |<------- GMA SDU (user payload)-------->|

        Figure 3: GMA PDU Format with Trailer-based IP Encapsulation

This method SHALL NOT be used if the original IP packet (GMA service data unit (GMA SDU)) is IPv6. So no IPv6 here, periodt 🙅‍♀️

Figure 3 shows the trailer-based IP encapsulation GMA protocol data unit (GMA PDU) format. A (GMA) PDU can carry one or multiple IP packets, aka (GMA) SDUs, in its payload, or a fragment of the SDU. Cute and flexible 🦋

The protocol type field in the IP header of the GMA PDU MUST be changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to show that a GMA trailer is there. That's the signal 🚩

The following three IP header fields MUST be changed:

  • IP Length: Add the length of "GMA Trailer" to the length of the original IP packet.
  • Time To Live (TTL): Set to "1".
  • IP checksum: Recalculate after changing "protocol type", "TTL", and "IP Length". Don't forget the checksum, it's the bestie that keeps everything honest 🫶

The GMA (Generic Multi-Access) trailer MUST consist of two mandatory fields (the last 3 bytes): Next Header and Flags. These two are non-negotiable ✨

Here's how they work:

  • Next Header (1 byte): This is the IP protocol type of the (first) SDU in a PDU. It stores the value from before it got overwritten to 114. Main character memory energy 🧠
  • Flags (2 bytes): Bit 0 is the most significant bit (MSB), and bit 15 is the least significant bit (LSB). The flags are basically a little menu of which optional fields are hanging around 🍓

Each flag bit does its own thing:

  • Checksum Present (bit 0): If the Checksum Present bit is set to 1, then the Checksum field is present.
  • Concatenation Present (bit 1): If the Concatenation Present bit is set to 1, then the PDU carries multiple SDUs, and the First SDU Length field is present.
  • Connection ID Present (bit 2): If the Connection ID Present bit is set to 1, then the Connection ID field is present.
  • Flow ID Present (bit 3): If the Flow ID Present bit is set to 1, then the Flow ID field is present.
  • Fragmentation Present (bit 4): If the Fragmentation Present bit is set to 1, then the PDU carries a fragment of the SDU and the Fragmentation Control field is present.
  • Delivery SN Present (bit 5): If the Delivery SN (Sequence Number) Present bit is set to 1, then the Delivery SN field is present and contains the valid information.
  • Flow SN Present (bit 6): If the Flow SN Present bit is set to 1, then the Sequence Number field is present.
  • Timestamp Present (bit 7): If the Timestamp Present bit is set to 1, then the Timestamp field is present.
  • TTL Present (bit 8): If the TTL Present bit is set to 1, then the TTL field is present.
  • Reserved (bit 9-12): This is set to "0" and ignored on receipt. Reserved means hands off 🙈
  • Version (bit 13~15): This is the GMA version number. It is set to 0 for the GMA encapsulation protocol specified in this document. Version 0, iconic ✨

The Flags field sits at the end of the PDU, and the Next Header field is the second last. The receiver SHOULD first decode the Flags field to figure out the length of the GMA trailer, and then decode each optional field accordingly. Flags first, then the rest, that's the order 💖

The Generic Multi-Access (GMA) trailer MAY consist of the following optional fields:

  • Checksum (1 byte): This contains the (one's complement) checksum sum of all 8 bits in the trailer. For purposes of computing the checksum, the value of the Checksum field is zero. This field is present only if the Checksum Present bit is set to 1.
  • First SDU Length (2 bytes): This is the length of the first IP packet in the PDU, only included if a PDU contains multiple IP packets. This field is present only if the Concatenation Present bit is set to 1.
  • Connection ID (1 byte): This contains an unsigned integer to identify the anchor and delivery connection of the GMA PDU. This field is present only if the Connection ID Present bit is set to 1.
    • Anchor Connection ID (MSB 4 bits): This contains an unsigned integer to identify the anchor connection.
    • Delivery Connection ID (LSB 4 bits): This contains an unsigned integer to identify the delivery connection.
  • Flow ID (1 byte): This contains an unsigned integer to identify the IP flow that a PDU belongs to, for example Data Radio Bearer (DRB) ID [LWIPEP] for a cellular (e.g., LTE) connection. This field is present only if the Flow ID Present bit is set to 1.
  • Fragmentation Control (FC) (1 byte): This provides necessary information for reassembly, only needed if a PDU carries fragments. This field is present only if the Fragmentation Present bit is set to 1. Please refer to Section 5 for its detailed format and usage. Go check Section 5 if you're curious 👀
  • Delivery SN (1 byte): This contains an auto-incremented integer to indicate the GMA PDU transmission order on a delivery connection. Delivery SN is needed to measure packet loss of each delivery connection and is therefore generated per delivery connection per flow. This field is present only if the Delivery SN Present bit is set to 1. Tracking the drip 📉
  • Flow SN (3 bytes): This contains an auto-incremented integer to indicate the GMA SDU (IP packet) order of a flow. Flow SN is needed for retransmission, reordering, and fragmentation. It SHALL be generated per flow. This field is present only if the Flow SN Present bit is set to 1.
  • Timestamp (4 bytes): This contains the current value of the timestamp clock of the transmitter in the unit of 1 millisecond. This field is present only if the Timestamp Present bit is set to 1. Time-stamped and unbothered ⏰
  • TTL (1 byte): This contains the TTL value of the original IP header if the GMA SDU is IPv4, or the Hop-Limit value of the IP header if the GMA SDU is IPv6. This field is present only if the TTL Present bit is set to 1.

Figure 4 shows the GMA trailer format with all the fields present. The order of the GMA control fields SHALL follow the bit order in the Flags field. Note that the bits in the Flags field are ordered with the first bit transmitted being bit 0 (MSB). All fields are transmitted in regular network byte order and appear in reverse order to their corresponding flag bits. If a flag bit is clear, the corresponding optional field is absent. Reverse order, but make it make sense 🔄

For example, bit 0 (the MSB) of the Flags field is the Checksum Present bit, and the Checksum field is the last in the trailer with the exception of the two mandatory fields. Bit 1 is the Concatenation Present bit, and the FSL field is the second last. The layout is literally a little puzzle, and it's so satisfying once it clicks 🧩

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TTL       |                   Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                   Flow SN                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Delivery SN  |    FC         |   Flow ID     | Connection ID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      First SDU Length (FSL)   |   Checksum    |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Flags                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: GMA Trailer Format with All Optional Fields Present

4.2. Header-Based IP Encapsulation 🦋

This method SHALL NOT be used if the original IP packet (GMA SDU) is IPv6. Same vibe as before: IPv6 is not invited to this one 🙅

Figure 5 shows the header-based IP encapsulation format. Here, the GMA header is inserted right after the IP header of the GMA SDU, and the IP header fields of the GMA PDU MUST be changed the same way as in trailer-based IP encapsulation. Same fields, same glow-up ✨

      +-----------------------------------------------+
      |IP hdr | GMA Header  |       IP payload        |
      +-----------------------------------------------+

    Figure 5: GMA PDU Format with Header-Based IP Encapsulation

Figure 6 shows the GMA header format. Compared to the GMA trailer, the only difference is that the Flags field is now in the front, so the receiver can decode the Flags field first to figure out the GMA header length. Flags up front, like a little cover letter 💌

The "TTL" field MUST be included, and the "TTL" bit in the GMA header (or Trailer) MUST be set to 1 if (trailer- or header-based) IP encapsulation is used. Non-negotiable, bestie 💀

   +------------------------------------------------------+
   | Flags | other fields (TTL, Timestamp, Flow SN, etc.) |
   +------------------------------------------------------+

                    Figure 6: GMA Header Format

4.3. Header-Based Non-IP Encapsulation 🌈

Figure 7 shows the header-based non-IP encapsulation format. Here, "UDP Tunneling" is configured at the MX adaptation layer. The ports for "UDP Tunneling" at the client are chosen from the Dynamic Port range, and the ports for "UDP Tunneling" at the Multi-Access Gateway are configured and provided to the client through additional control messages, e.g., [MAMS]. Control messages do the matchmaking 💜

"TTL", "FSL", and "Next Header" are no longer needed and MUST not be included. Moreover, the IP header fields of the GMA SDU remain unchanged. Bye bye, TTL, FSL, and Next Header 👋

+-------------------------------------------------------------+
| IP hdr | UDP hdr  | GMA Header | IP hdr |    IP payload     |
+-------------------------------------------------------------+
                                |<------- GMA SDU------------>|
                    |<------------------- GMA PDU------------>|

         Figure 7: GMA PDU Format with Non-IP Encapsulation

4.4. IP Protocol Identifier 🔥

As described in Section 4.1, IP-encapsulated GMA PDUs are indicated using the IP protocol type 114. This is designated and recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No reference is given in the IANA registry for the definition of this protocol type, and IANA has no record of why the assignment was made or how it is used, although it was probably assigned before 1999 [IANA1999]. A mystery number with a whole vintage backstory 🕰️

There is some risk associated with "reusing" protocol type 114, because there may be implementations of other protocols also using this protocol type. However, because the protocol described in this document is used only between adjacent devices specifically configured for this purpose, the use of protocol type 114 should be safe. Contained, controlled, and chill 🧊

Heads up: as described in Section 1.1, one of the purposes of the experiment described in this document is to verify the safety of using this protocol type. Deployments should be aware of the risk of a clash with other uses of this protocol type. Keep an eye out for clashes, it's the one thing that could be messy 😭

5. Fragmentation ✨

okay bestie, so picture this 🧚: the anchor connection's MTU is set up so that the GMA PDU length, once you add the GMA header (or trailer) and the other overhead (UDP tunneling), MAY go over the MTU of a delivery connection 😭. when that happens, GMA endpoints MUST be configured to support fragmentation through extra control messages [MAMS]. no skipping this one, periodt 💅

the fragmentation procedure at the convergence sublayer is basically giving IP fragmentation [RFC0791] vibes 🦋, but with two differences so it costs less overhead:

  • the fragment offset field is counted in number of fragments, not bytes 🍓
  • the max number of fragments per SDU is 2^7 (=128) 👑

the Fragmentation Control (FC) field in the GMA trailer (or header) holds these bits:

  • Bit 7: the More Fragment (MF) flag. it's 0 if the fragment is the last one, and 1 if it's not 🌸
  • Bits 0-6: the Fragment Offset (in units of fragments), which tells you where this fragment sits relative to the start of the SDU 💜

a PDU carries a whole SDU with no fragmenting if the FC field is set to all "0"s, or if the FC field isn't in the trailer at all. otherwise the PDU holds a fragment of the SDU ✨

the Flow SN field in the trailer is how you tell the fragments of one SDU apart from another's 🎀. the Fragment Offset (FO) field tells the receiver where a fragment lives in the original SDU, and the More Fragment (MF) flag marks the last fragment 🫶.

how the transmitter splits a long SDU: it creates n PDUs and copies the IP header fields from the long PDU into the IP header of every one of them 🌈. the length field in the IP header of each PDU SHOULD be changed to the length of that PDU, and the protocol type SHOULD be changed to 114 🔥.

the data of the long SDU gets cut into n portions based on the MTU of the delivery connection. the first portion goes in the first PDU, with MF set to "1" and FO set to "0" 🧚. the i-th portion goes in the i-th PDU. MF is set to "0" if it's the last fragment and "1" otherwise, and FO is set to i-1 💖.

how the receiver puts it back together: it combines PDUs that all have the same Flow SN 🦋. it places each fragment's data in the relative order given by the Fragment Offset in that fragment's GMA trailer (or header) ✨. the first fragment has Fragment Offset "0", and the last fragment has More Fragment set to "0" 💅.

GMA fragmentation works above the IP layer of each individual access connection (Wi-Fi, LTE), and between the two endpoints of the convergence layer 🌸. the convergence layer endpoints (client, Multi-access Gateway) SHOULD find out the MTU of each connection either by manual configuration or by implementing Path MTU Discovery (PMTUD) as suggested in [RFC8900] 🎀.

6. Concatenation 🍓

the convergence sublayer MAY support concatenation if a delivery connection has a bigger MTU than the original IP packet (SDU) 💜. only SDUs with the same client IP address and the same Flow ID MAY be concatenated 🌈.

if the trailer- or header-based IP encapsulation method is used, the First SDU Length (FSL) field SHOULD be included in the GMA trailer (or header) to say how long the first SDU is 🧚. otherwise, the FSL field SHOULD not be included 🙈.

here's what it looks like, Figure 8 💅:

  +-----------------------------------------------------------+
  |IP hdr| IP payload    |IP hdr|   IP payload  | GMA Trailer |
  +-----------------------------------------------------------+

      Figure 8: Example of GMA PDU Format with Concatenation and
                    Trailer-Based IP Encapsulation

to concatenate two or more SDUs, the transmitter creates ONE PDU and copies the IP header field from the first SDU into the IP header of that PDU 🦋. the data of the first SDU goes in the first portion of the PDU's data, and then the whole second SDU goes in the second portion (see Figure 8) ✨. this keeps going until the PDU size hits the MTU of the delivery connection 👑.

if the FSL field is present, the IP Length field of the PDU SHOULD be updated to cover all the concatenated SDUs and the trailer (or header), and the IP checksum field SHOULD be recalculated if the packet is IPv4 🔥.

how the receiver splits it apart: if the header- or trailer-based IP encapsulation method is used, the receiver first gets the length of the first SDU from the FSL field and decodes it 🌸. then it gets the length of the second SDU from the length field in the second SDU's IP header and decodes that one too 💜. this keeps going until there are no bytes left in the PDU 🫶.

if the non-IP encapsulation method (Figure 7) is used, the IP header of the first SDU does NOT change during encapsulation, so the receiver SHOULD get the length of the first SDU straight from its IP header (see Figure 9) 🎀.

                                 |<-------1st GMA SDU------------
+---------------------------------------------------------------+
| IP hdr | UDP hdr  | GMA Header | IP hdr |       IP payload    |
+---------------------------------------------------------------+
         | IP hdr |           IP payload    |
+-------------------------------------------+
-------->|<-------2nd GMA SDU--------------->

      Figure 9: Example of GMA PDU Format with Concatenation and
               Header-Based Non-IP (UDP) Encapsulation

if a PDU has multiple SDUs, the Flow SN field is for the LAST SDU, and the Flow SN of the others can be worked out from their order in the PDU 🌈. for example, if the SN field is 6 and a PDU has 3 SDUs (IP packets), the SNs are 4, 5, and 6 for the first, second, and last SDU 💖.

GMA concatenation can be used to pack small packets from a single application (like TCP ACKs) or from multiple applications 🧚. notice that a single GMA flow can carry multiple application flows (TCP, UDP, etc.) 💅.

GMA endpoints MUST NOT perform concatenation and fragmentation in a single PDU 🙅‍♀️. if a GMA PDU carries a fragmented SDU, it MUST NOT carry any other SDU, fragmented or whole 😭.

7. Security Considerations 💀

okay this section is SERIOUS bestie, so read it like it's your group chat's most important text 🔥.

security in a network using GMA should be pretty similar to security in a normal IP network 🦋. GMA doesn't know about IP- or higher-layer end-to-end security, because it just carries the IP packets as an opaque payload 🙈. deployers are encouraged NOT to think GMA adds any kind of security 🚫, and to keep using IP- or higher-layer security as well as link-layer security 🫶.

the GMA protocol at the convergence sublayer is a 0-hop protocol, and it relies on the security of the underlying network transport paths 🌸. when you can't assume that, appropriate security protocols (IPsec, DTLS, etc.) SHOULD be configured at the adaptation sublayer 🔒. packet filtering needs either a firewall that looks inside the GMA packet, or filtering done on the GMA endpoints 👀. in environments where that's a security issue, it may be a good idea to terminate GMA operation at the firewall 💜.

local-only packet leak prevention (HL=0, TTL=1) SHOULD be in place to stop local-only GMA PDUs from leaking outside the "local domain" to the Internet, or to another domain that could use the same IP protocol type, i.e., 114 🚨✨.

8. IANA Considerations 🎀

this document has no IANA actions 🌷. nothing to do here, bestie 💅.

9. References 📚

9.1. Normative References 🌟

[GRE1]     Dommety, G., "Key and Sequence Number Extensions to GRE",
           RFC 2890, DOI 10.17487/RFC2890, September 2000,
           <https://www.rfc-editor.org/info/rfc2890>.

[GRE2]     Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and
           M. Cullen, "Huawei's GRE Tunnel Bonding Protocol",
           RFC 8157, DOI 10.17487/RFC8157, May 2017,
           <https://www.rfc-editor.org/info/rfc8157>.

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

9.2. Informative References 🌈

[ATSSS]    3GPP, "Study on access traffic steering, switch and
           splitting support in the 5G System (5GS) architecture",
           Release 16, 3GPP TR 23.793, December 2018,
           <https://portal.3gpp.org/desktopmodules/Specifications/
           SpecificationDetails.aspx?specificationId=3254>.

[GCC]      Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S.
           Mascolo, "A Google Congestion Control Algorithm for Real-
           Time Communication", Work in Progress, Internet-Draft,
           draft-ietf-rmcat-gcc-02, 8 July 2016,
           <https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-
           gcc-02>.

[GMAC]     Zhu, J. and M. Zhang, "UDP-based Generic Multi-Access
           (GMA) Control Protocol", Work in Progress, Internet-Draft,
           draft-zhu-intarea-gma-control-00, 13 October 2021,
           <https://datatracker.ietf.org/doc/html/draft-zhu-intarea-
           gma-control-00>.

[IANA]     IANA, "Protocol Numbers",
           <https://www.iana.org/assignments/protocol-numbers>.

[IANA1999] IANA, Wayback Machine archive of "Protocol Numbers",
           February 1999,
           <https://web.archive.org/web/19990203044112/
           http://www.isi.edu:80/in-notes/iana/assignments/protocol-
           numbers>.

[LWIPEP]   3GPP, "Evolved Universal Terrestrial Radio Access
           (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec
           Tunnel (LWIP) encapsulation; Protocol specification",
           Release 13, 3GPP TS 36.361, July 2020,
           <https://portal.3gpp.org/desktopmodules/Specifications/
           SpecificationDetails.aspx?specificationId=3037>.

[MAMS]     Kanugovi, S., Baboescu, F., Zhu, J., and S. Seo, "Multiple
           Access Management Services Multi-Access Management
           Services (MAMS)", RFC 8743, DOI 10.17487/RFC8743, March
           2020, <https://www.rfc-editor.org/info/rfc8743>.

[MPIP]     Sun, L., Tian, G., Zhu, G., Liu, Y., Shi, H., and D. Dai,
           "Multipath IP Routing on End Devices: Motivation, Design,
           and Performance", 2017,
           <https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/
           MPIP_Tech.pdf>.

[RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
           DOI 10.17487/RFC0791, September 1981,
           <https://www.rfc-editor.org/info/rfc791>.

[RFC8900]  Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
           and F. Gont, "IP Fragmentation Considered Fragile",
           BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
           <https://www.rfc-editor.org/info/rfc8900>.

Authors' Addresses 💌

Jing Zhu
Intel

Email: jing.z.zhu@intel.com


Satish Kanugovi
Nokia

Email: satish.k@nokia.com
📦 where this page comes from