doc: Add RFC documents

1 files changed, 817 insertions, 0 deletions

diff --git a/doc/rfc/rfc9188.txt b/doc/rfc/rfc9188.txt
new file mode 100644
index 0000000..d3d1a98
--- /dev/null
+++ b/doc/rfc/rfc9188.txt
@@ -0,0 +1,817 @@
+
+
+
+
+Independent Submission                                            J. Zhu
+Request for Comments: 9188                                         Intel
+Category: Experimental                                       S. Kanugovi
+ISSN: 2070-1721                                                    Nokia
+                                                           February 2022
+
+
+           Generic Multi-Access (GMA) Encapsulation Protocol
+
+Abstract
+
+   A device can be simultaneously connected to multiple networks, e.g.,
+   Wi-Fi, LTE, 5G, and DSL.  It is desirable to seamlessly combine the
+   connectivity over these networks below the transport layer (L4) to
+   improve the quality of experience for applications that do not have
+   built-in multi-path capabilities.  Such optimization requires
+   additional control information, e.g., a sequence number, in each
+   packet.  This document presents a new lightweight and flexible
+   encapsulation protocol for this need.  The solution has been
+   developed by the authors based on their experiences in multiple
+   standards bodies including the IETF and 3GPP.  However, this document
+   is not an Internet Standard and does not represent the consensus
+   opinion of the IETF.  This document will enable other developers to
+   build interoperable implementations in order to experiment with the
+   protocol.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9188.
+
+Copyright Notice
+
+   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) 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.
+
+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
+
+   A device can be simultaneously connected to multiple networks, e.g.,
+   Wi-Fi, LTE, 5G, and DSL.  It is desirable to seamlessly combine the
+   connectivity over these networks below the transport layer (L4) to
+   improve the quality of experience for applications that do not have
+   built-in multi-path capabilities.
+
+   Figure 1 shows the Multi-Access Management Service (MAMS) user-plane
+   protocol stack [MAMS], which has been used in today's multi-access
+   solutions [ATSSS] [LWIPEP] [GRE1] [GRE2].  It consists of two layers:
+   convergence and adaptation.
+
+   The convergence layer is responsible for multi-access operations,
+   including multi-link (path) aggregation, splitting/reordering,
+   lossless switching/retransmission, fragmentation, concatenation, etc.
+   It operates on top of the adaptation layer in the protocol stack.
+   From the perspective of a transmitter, a User Payload (e.g., IP
+   packet) is processed by the convergence layer first and then by the
+   adaptation layer before being transported over a delivery connection;
+   from the receiver's perspective, an IP packet received over a
+   delivery connection is processed by the adaptation layer first and
+   then by 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 encode
+   additional control information, e.g., key and sequence number.
+   However, there are two main drawbacks with this approach:
+
+   *  It is difficult to introduce new control fields because the GRE
+      header formats are already defined, and
+
+   *  IP-over-IP tunneling (required for GRE) leads to higher overhead
+      especially for small packets.
+
+   For example, the overhead of IP-over-IP/GRE tunneling with both key
+   and sequence Number is 32 bytes (20-byte IP header + 12-byte GRE
+   header), which is 80% of a 40-byte TCP ACK packet.
+
+   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.  Particularly, the IP
+   encapsulation methods avoid IP-over-IP tunneling overhead (20 bytes),
+   which is 50% of a 40-byte TCP ACK packet.  Moreover, it introduces
+   new control fields to support fragmentation and concatenation, which
+   are not available in GRE-based solutions [LWIPEP] [GRE1] [GRE2].
+
+   The GMA protocol only operates between endpoints that have been
+   configured to use GMA.  This configuration can be through any control
+   messages and procedures, including, for example, Multi-Access
+   Management Services [MAMS].  Moreover, UDP or IPsec tunneling can be
+   used at the adaptation sublayer to protect GMA operation from
+   intermediate nodes.
+
+   The solution described in this document was developed by the authors
+   based on their experiences in multiple standards bodies including the
+   IETF and 3GPP.  However, this document is not an Internet Standard
+   and does not represent the consensus opinion of the IETF.  This
+   document presents the protocol specification to enable
+   experimentation as described in Section 1.1 and to facilitate other
+   interoperable implementations.
+
+1.1.  Scope of Experiment
+
+   The protocol described in this document is an experiment.  The
+   objective of the experiment is to determine whether the protocol
+   meets the requirements, can be safely used, and has support for
+   deployment.
+
+   Section 4 describes three possible encapsulation methods that are
+   enabled by this protocol.  Part of this experiment is to assess
+   whether all three mechanisms are necessary or whether, for example,
+   all implementations are able to support the main "trailer-based" IP
+   encapsulation method.  Similarly, the experiment will investigate the
+   relative merits of the IP and non-IP encapsulation methods.
+
+   It is expected that this protocol experiment can be conducted on the
+   Internet since the GMA packets are identified by an IP protocol
+   number and the protocol is intended for single-hop propagation;
+   devices should not be forwarding packets, and if they do, they will
+   not need to examine the payload, while destination systems that do
+   not support this protocol should not receive such packets and will
+   handle them as unknown payloads according to normal IP processing.
+   Thus, experimentation is conducted between consenting end systems
+   that have been mutually configured to participate in the experiment
+   as described in Section 7.
+
+   Note that this experiment "reuses" the IP protocol identifier 114 as
+   described in Section 4.4.  Part of this experiment is to assess the
+   safety of doing this.  The experiment should consider the following
+   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, e.g., WireShark or
+   TCPDUMP, to monitor both ingress and egress traffic at GMA endpoints
+   and ensure the above safety mechanisms are implemented.
+
+   Path quality measurements (one-way delay, loss, etc.) and congestion
+   detection are performed by the receiver based on the GMA control
+   fields, e.g., Sequence Number, Timestamp, etc.  The receiver will
+   then dynamically control how to split or steer traffic over multiple
+   delivery connections accordingly.  The GMA control protocol [GMAC]
+   MAY be used for signaling between GMA endpoints.  Another objective
+   of the experiment is to evaluate the usage of various receiver-based
+   algorithms [GCC] [MPIP] in multi-path traffic management and the
+   impact on the End-to-End (E2E) performance (throughput, delay, etc.)
+   of higher-layer (transport) protocols, e.g., TCP, QUIC, WebRTC, etc.
+
+   The authors will continually assess the progress of this experiment
+   and encourage other implementers to contact them to report the status
+   of their implementations and their experiences with the protocol.
+
+2.  Conventions Used in This Document
+
+   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.
+
+3.  Use Case
+
+   As shown in Figure 2, a client device (e.g., smartphone, laptop,
+   etc.) may connect to the Internet via both Wi-Fi and LTE connections,
+   one of which (e.g., LTE) may operate as the anchor connection, and
+   the other (e.g., Wi-Fi) may operate as the delivery connection.  The
+   anchor connection provides the IP address and connectivity for end-
+   to-end Internet access, and the delivery connection provides an
+   additional path between the client and Multi-Access Gateway for
+   multi-access optimizations.
+
+                        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
+
+   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.
+
+   For example, per-packet aggregation allows a single IP flow to use
+   the combined bandwidth of the two connections.  In another example,
+   packets lost due to a temporary link outage may be retransmitted.
+   Moreover, packets may be duplicated over multiple connections to
+   achieve high reliability and low latency, where duplicated packets
+   are eliminated by the receiving side.  Such multi-access optimization
+   requires additional control information, e.g., a sequence number, in
+   each packet, which can be supported by the GMA encapsulation protocol
+   described in this document.
+
+   The GMA protocol described in this document is designed for multiple
+   connections, but it may also be used when there is only one
+   connection between two endpoints.  For example, it may be used for
+   loss detection and recovery.  In another example, it may be used to
+   concatenate multiple small packets and reduce per-packet overhead.
+
+4.  GMA Encapsulation Methods
+
+   The GMA encapsulation protocol supports the following three methods:
+
+   *  Trailer-based IP Encapsulation (Section 4.1)
+
+   *  Header-based IP Encapsulation (Section 4.2)
+
+   *  Header-based non-IP Encapsulation (Section 4.3)
+
+   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 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.  In comparison, if IP encapsulation is configured, a
+   GMA header or trailer may be added dynamically on a per-packet basis,
+   and it indicates the presence of a GMA header (or trailer) to set 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 as specified in Multi-Access
+   Management Service [MAMS] includes "MX Convergence Method
+   Parameters", which provides the list of parameters to configure the
+   convergence layer, and can be extended to indicate the GMA
+   encapsulation method.
+
+   GMA endpoint MUST discard a received packet and MAY log an error to
+   report the situation (although such error logging MUST be subject to
+   rate limits) under any of the following conditions:
+
+   *  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
+
+          |<---------------------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.
+
+   Figure 3 shows the trailer-based IP encapsulation GMA protocol data
+   unit (GMA PDU) format.  A (GMA) PDU may carry one or multiple IP
+   packets, aka (GMA) SDUs, in the payload, or a fragment of the SDU.
+
+   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 indicate the
+   presence of the GMA trailer.
+
+   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".
+
+   The GMA (Generic Multi-Access) trailer MUST consist of two mandatory
+   fields (the last 3 bytes): Next Header and Flags.
+
+   This is defined as follows:
+
+   Next Header (1 byte):  This is the IP protocol type of the (first)
+      SDU in a PDU; it stores the value before it was overwritten to
+      114.
+
+   Flags (2 bytes):  Bit 0 is the most significant bit (MSB), and bit 15
+      is the least significant bit (LSB).
+
+      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 carry 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.
+
+      Version (bit 13~15):  This is the GMA version number; it is set to
+         0 for the GMA encapsulation protocol specified in this
+         document.
+
+   The Flags field is at the end of the PDU, and the Next Header field
+   is the second last.  The receiver SHOULD first decode the Flags field
+   to determine the length of the GMA trailer and then decode each
+   optional field accordingly.  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.
+
+   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 therefore generated per delivery connection per
+      flow.  This field is present only if the Delivery SN Present bit
+      is set to 1.
+
+   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.
+
+   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,
+   and 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.
+
+   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.
+
+    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.
+
+   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.
+
+          +-----------------------------------------------+
+          |IP hdr | GMA Header  |       IP payload        |
+          +-----------------------------------------------+
+
+        Figure 5: GMA PDU Format with Header-Based IP Encapsulation
+
+   Figure 6 shows the GMA header format.  In comparison to the GMA
+   trailer, the only difference is that the Flags field is now in the
+   front so that the receiver can first decode the Flags field to
+   determine the GMA header length.
+
+   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.
+
+       +------------------------------------------------------+
+       | 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].
+
+   "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.
+
+    +-------------------------------------------------------------+
+    | 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].
+
+   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.
+
+   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.
+
+5.  Fragmentation
+
+   If the MTU size of the anchor connection (for GMA SDU) is configured
+   such that the corresponding GMA PDU length adding the GMA header (or
+   trailer) and other overhead (UDP tunneling) MAY exceed the MTU of a
+   delivery connection, GMA endpoints MUST be configured to support
+   fragmentation through additional control messages [MAMS].
+
+   The fragmentation procedure at the convergence sublayer is similar to
+   IP fragmentation [RFC0791] in principle, but with the following two
+   differences for less overhead:
+
+   *  The fragment offset field is expressed in number of fragments.
+
+   *  The maximum number of fragments per SDU is 2^7 (=128).
+
+   The Fragmentation Control (FC) field in the GMA trailer (or header)
+   contains the following bits:
+
+   Bit 7:  a More Fragment (MF) flag to indicate if the fragment is the
+      last one (0) or not (1)
+
+   Bit 0-6:  Fragment Offset (in units of fragments) to specify the
+      offset of a particular fragment relative to the beginning of the
+      SDU
+
+   A PDU carries a whole SDU without fragmentation if the FC field is
+   set to all "0"s or the FC field is not present in the trailer.
+   Otherwise, the PDU contains a fragment of the SDU.
+
+   The Flow SN field in the trailer is used to distinguish the fragments
+   of one SDU from those of another.  The Fragment Offset (FO) field
+   tells the receiver the position of a fragment in the original SDU.
+   The More Fragment (MF) flag indicates the last fragment.
+
+   To fragment a long SDU, the transmitter creates n PDUs and copies the
+   content of the IP header fields from the long PDU into the IP header
+   of all the PDUs.  The length field in the IP header of the PDU SHOULD
+   be changed to the length of the PDU, and the protocol type SHOULD be
+   changed to 114.
+
+   The data of the long SDU is divided into n portions based on the MTU
+   size of the delivery connection.  The first portion of the data is
+   placed in the first PDU.  The MF flag is set to "1", and the FO field
+   is set to "0".  The i-th portion of the data is placed in the i-th
+   PDU.  The MF flag is set to "0" if it is the last fragment and set to
+   "1" otherwise.  The FO field is set to i-1.
+
+   To assemble the fragments of an SDU, the receiver combines PDUs that
+   all have the same Flow SN.  The combination is done by placing the
+   data portion of each fragment in the relative order indicated by the
+   Fragment Offset in that fragment's GMA trailer (or header).  The
+   first fragment will have the Fragment Offset set to "0", and the last
+   fragment will have the More Fragment flag set to "0".
+
+   GMA fragmentation operates above the IP layer of individual access
+   connection (Wi-Fi, LTE) and between the two endpoints of convergence
+   layer.  The convergence layer endpoints (client, Multi-access
+   Gateway) SHOULD obtain the MTU of individual connection through
+   either manual configuration or implementing Path MTU Discovery
+   (PMTUD) as suggested in [RFC8900].
+
+6.  Concatenation
+
+   The convergence sublayer MAY support concatenation if a delivery
+   connection has a larger maximum transmission unit (MTU) than the
+   original IP packet (SDU).  Only the 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 indicate the length of the first SDU.
+   Otherwise, the FSL field SHOULD not be included.
+
+     +-----------------------------------------------------------+
+     |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 content of the IP header field from the first SDU into the
+   IP header of the PDU.  The data of the first SDU is placed in the
+   first portion of the data of the PDU.  The whole second SDU is then
+   placed in the second portion of the data of the PDU (Figure 8).  The
+   procedure continues until the PDU size reaches the MTU of the
+   delivery connection.  If the FSL field is present, the IP Length
+   field of the PDU SHOULD be updated to include all concatenated SDUs
+   and the trailer (or header), and the IP checksum field SHOULD be
+   recalculated if the packet is IPv4.
+
+   To disaggregate a PDU, if the (header- or trailer-based) IP
+   encapsulation method is used, the receiver first obtains the length
+   of the first SDU from the FSL field and decodes the first SDU.  The
+   receiver then obtains the length of the second SDU based on the
+   length field in the second SDU IP header and decodes the second SDU.
+   The procedure continues until no byte is left in the PDU.  If the
+   non-IP encapsulation method (Figure 7) is used, the IP header of the
+   first SDU will not change during the encapsulation process, and the
+   receiver SHOULD obtain the length of the first SDU directly from its
+   IP header (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 contains multiple SDUs, the Flow SN field is for the last
+   SDU, and the Flow SN of other SDUs carried by the same PDU can be
+   obtained according to its order in the PDU.  For example, if the SN
+   field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5,
+   and 6 for the first, second, and last SDU, respectively.
+
+   GMA concatenation can be used for packing small packets of a single
+   application, e.g., TCP ACKs, or from multiple applications.  Notice
+   that a single GMA flow may 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 (fragmented or whole) SDU.
+
+7.  Security Considerations
+
+   Security in a network using GMA should be relatively similar to
+   security in a normal IP network.  GMA is unaware of IP- or higher-
+   layer end-to-end security as it carries the IP packets as opaque
+   payload.  Deployers are encouraged to not consider that GMA adds any
+   form of security and to continue to use IP- or higher-layer security
+   as well as link-layer security.
+
+   The GMA protocol at the convergence sublayer is a 0-hop protocol and
+   relies on the security of the underlying network transport paths.
+   When this cannot be assumed, appropriate security protocols (IPsec,
+   DTLS, etc.)  SHOULD be configured at the adaptation sublayer.  On the
+   other hand, packet filtering requires either that a firewall looks
+   inside the GMA packet or that the filtering is done on the GMA
+   endpoints.  In those environments in which this is considered to be a
+   security issue, it may be desirable to terminate the GMA operation at
+   the firewall.
+
+   Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on
+   preventing the leak of the local-only GMA PDUs 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.
+
+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