<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> zwsp   "&#8203;">
  <!ENTITY RFC2890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8743 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8743.xml">
<!ENTITY RFC0791 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC8900 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml">
<!ENTITY I-D.ietf-rmcat-gcc SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-gcc.xml">
<!ENTITY I-D.zhu-intarea-gma-control SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.zhu-intarea-gma-control.xml"> wj     "&#8288;">
]>

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-zhu-intarea-gma-14" number="9188" submissionType="independent" category="exp" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2021-12-03T01:59:19Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc text-list-symbols="o+*-"?>
	<?rfc toc="yes"?> ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true"
tocInclude="true" version="3">

	<front>
    <title abbrev="GMA Encapsulation Protocol">Generic Multi-Access (GMA) Encapsulation Protocol</title>
    <seriesInfo name="RFC" value="9188"/>
    <author initials="J." surname="Zhu" fullname="Jing Zhu">
      <organization>Intel</organization>
	<address><email>jing.z.zhu@intel.com</email>
      <address>
        <email>jing.z.zhu@intel.com</email>
      </address>
    </author>
    <author initials="S." surname="Kanugovi" fullname="Satish Kanugovi">
      <organization>Nokia</organization>
	<address><email>satish.k@nokia.com</email>
      <address>
        <email>satish.k@nokia.com</email>
      </address>
    </author>

    <date year="2021" month="December"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

	<abstract><t> year="2022" month="February"/>

    <abstract>
      <t>
   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 built-in multi-path
   capabilities. Such optimization requires additional control information,
   e.g., a sequence number, in each packet. This document presents a new light weight
   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, 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.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   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 built-in multi-path capabilities.</t>
      <t>
   Figure 1
   <xref target="Fig1"/> shows the Multi-Access Management Service (MAMS) user-plane
   protocol stack <xref target="MAMS"/>, target="RFC8743" format="default"/>, which has been used in today's
   multi-access solutions [ATSSS] [LWIPEP] <xref target="GRE1"/> [GRE2]. target="ATSSS"/> <xref target="LWIPEP"/> <xref target="RFC2890" format="default"/> <xref target="RFC8157"/>. It
   consists of two layers: convergence and adaptation.</t>
      <t>
   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, 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, first and then by the convergence layer.</t>
      <figure title="MAMS anchor="Fig1">
        <name>MAMS User-Plane Protocol Stack [MAMS]" anchor="Fig1"><artwork><![CDATA[ Stack</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
       +-----------------------------------------------------+
       |   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 |
    +-----------------------------------------------------------+
]]></artwork>
      </figure>
      <t>
   GRE (Generic Routing Encapsulation) <xref target="LWIPEP"/> <xref
   target="RFC2890" format="default"/> <xref target="RFC8157"/> can be used [LWIPEP] <xref target="GRE1"/>
   [GRE2] as
   the encapsulation protocol at the convergence layer to encode additional
   control information, e.g., Key, Sequence Number. key and sequence number.  However, there are two
   main drawbacks with this approach:</t>

   <t><list style="symbols">

     <t>It
      <ul spacing="normal">
        <li>It is difficult to introduce new control fields because the
     GRE header formats are already defined,</t>

     <t>IP-over-IP tunnelling defined, and</li>
        <li>IP-over-IP tunneling (required for GRE) leads to higher
     overhead especially for small packet.</t>

	</list>
	</t> packets.</li>
      </ul>
      <t>
   For example, the overhead of IP-over-IP/GRE tunnelling tunneling with both
   Key
   key and Sequence sequence Number is 32 Bytes (20 Bytes bytes (20-byte IP header + 12 Bytes 12-byte
   GRE header), which is 80% of a 40 Bytes 40-byte TCP ACK packet.</t>

   <t>
   This document presents a light-weight GMA (Generic Multi-Access) 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), bytes), which
   is 50% of a 40 Bytes 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] <xref target="GRE1"/> [GRE2].</t> target="LWIPEP"/> <xref target="RFC2890"
   format="default"/> <xref target="RFC8157"/>.</t>
      <t>
   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 <xref
   target="MAMS"/>.
   target="RFC8743" format="default"/>. Moreover, UDP or IPSec IPsec tunneling can
   be used at the adaptation sublayer to protect GMA operation from
   intermediate nodes.</t>
      <t>
   The solution described in this document was been developed by the authors based
   on their experiences in multiple standards bodies including the IETF and
   3GPP. However, it 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 <xref target="sect-1.1"/>
   target="sect-1.1" format="default"/> and to facilitate other interoperable
   implementations.</t>
      <section title="Scope anchor="sect-1.1" numbered="true" toc="default">
        <name>Scope of Experiment" anchor="sect-1.1"><t> Experiment</name>
        <t>
   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.</t>
        <t>
   <xref target="sect-4"/> target="sect-4" format="default"/> describes three possible encapsulation methods that are
   enabled by this protocol. Part of this experiment is to assess
   whether all three mechanisms are necessary, 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.</t>
        <t>
   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: single-hop propagation; devices should not be
   forwarding packet packets, and if they
   do 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 <xref target="sect-7"/>.</t> target="sect-7" format="default"/>.</t>
        <t>
   Note that this experiment "re-uses" "reuses" the IP protocol identifier 114
   as described in <xref target="sect-4.4"/>. target="sect-4.4" format="default"/>. Part of this experiment is to assess
   the safety of doing this. The experiment should consider the
   following safety mechanisms:</t>

   <t><list style="symbols">
     <t>GMA
        <ul spacing="normal">
          <li>GMA endpoints SHOULD <bcp14>SHOULD</bcp14> detect non-GMA IP packets that also use
     114 and log an error to report the situation (although such
     error logging MUST <bcp14>MUST</bcp14> be subject to rate limits).</t>

     <t>GMA limits).</li>

<li>GMA endpoints SHOULD <bcp14>SHOULD</bcp14> stop using 114 and switch to non-IP
     (UDP) based encapsulation,
i.e., UDP encapsulation (Sec 4.3, Figure 7) (<xref target="Fig7"/>), after detecting any non-GMA usage of 114.</t>

	</list>
	</t> 114.
</li>

        </ul>
        <t>
   The experiment SHOULD <bcp14>SHOULD</bcp14> use a packet tracing tool, e.g., WireShark,
   WireShark or TCPDUMP, to monitor both ingress and egress traffic at GMA
   endpoints and ensure the above safety mechanisms are implemented.</t>
        <t>
   Path quality measurements (one-way-delay, (one-way delay, loss, etc.) and congestion
   detection are performed by the receiver based on the GMA control fields,
   e.g., sequence number, timestamp, Sequence Number, Timestamp, etc. Receiver The receiver will then dynamically
   control how to split or steer traffic over multiple delivery connections
   accordingly. The GMA control protocol <xref target="I-D.zhu-intarea-gma-control"/> MAY
   target="I-D.zhu-intarea-gma-control" format="default"/> <bcp14>MAY</bcp14>
   be used for signaling between GMA endpoints. Another objective of the
   experiment is to evaluate the usage of various receiver-based algorithms
   <xref target="I-D.ietf-rmcat-gcc"/> [MPIP] target="GCC" format="default"/> <xref target="MPIP"/>
   in multi-path traffic
   management, management and the impact on the e2e End-to-End (E2E)
   performance (throughput, delay, etc.) of higher layer higher-layer (transport)
   protocols, e.g., TCP, QUIC, WebRTC, etc.</t>
        <t>
   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.</t>
      </section>
    </section>
    <section title="Conventions used anchor="sect-2" numbered="true" toc="default">
      <name>Conventions Used in this document" anchor="sect-2"><t> This Document</name>
              <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>
    </section>
    <section title="Use Case" anchor="sect-3"><t> anchor="sect-3" numbered="true" toc="default">
      <name>Use Case</name>
      <t>
   As shown in Figure 2, <xref target="Fig2"/>, a client device (e.g., Smartphone, Laptop, 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.</t>
      <figure title="GMA-based Multi-Access Aggregation" anchor="Fig2">
   <artwork><![CDATA[
        <name>GMA-Based Multi-Access Aggregation</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                     Multi-Access Aggregation

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

	A:
]]></artwork>
      </figure>
<dl indent="4">
<dt>A:</dt><dd> The adaptation layer adaptation-layer endpoint of the LTE connection
	resides in the client

	B: client.</dd>

	<dt>B:</dt><dd> The adaptation layer adaptation-layer endpoint of the Wi-Fi connection
	resides in the client

	C: client.</dd>

	<dt>C:</dt><dd> The adaptation layer adaptation-layer endpoint of the LTE connection
	resides in the Multi-Access Gateway, aka N-MADP (Network
	Multi-Access Data Proxy) in [MAMS]

	D: <xref target="RFC8743"/>.</dd>

	<dt>D:</dt><dd> The adaptation layer adaptation-layer endpoint of the Wi-Fi connection
	resides in the Multi-Access Gateway

	U: Gateway.</dd>

	<dt>U:</dt><dd> The convergence layer convergence-layer endpoint resides in the client

	S: client.</dd>

	<dt>S:</dt><dd> The convergence layer convergence-layer endpoint resides in the Multi-Access
	Gateway

]]></artwork>
</figure>
	Gateway.</dd>
    </dl>
      <t>
   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 temporarily 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.</t>
      <t>
   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 per-packet overhead.</t>
    </section>

    <section title="GMA anchor="sect-4" numbered="true" toc="default">
      <name>GMA Encapsulation Methods" anchor="sect-4"><t> Methods</name>
      <t>
   The GMA encapsulation protocol supports the following three
   methods:</t>

   <t><list style="symbols">

     <t>Trailer-based
      <ul spacing="normal">
        <li>Trailer-based IP Encapsulation (4.1)</t>

     <t>Header-based (<xref target="sect-4.1"/>)</li>
        <li>Header-based IP Encapsulation (4.2)</t>

     <t>(Header-based) (<xref target="sect-4.2"/>)</li>
        <li>Header-based non-IP Encapsulation (4.3)</t>

	</list>
	</t> (<xref target="sect-4.3"/>)</li>
      </ul>
      <t>
   Non-IP encapsulation MUST <bcp14>MUST</bcp14> be used if the original IP packet is
   IPv6.</t>
      <t>
   Trailer-based IP encapsulation MUST <bcp14>MUST</bcp14> be used if it is supported by
   GMA endpoints and the original IP packet is IPv4.</t>
      <t>
   Header-based encapsulation MUST <bcp14>MUST</bcp14> be used if the trailer-based
   method is not supported by either Client the client or Multi-Access Gateway.
   In this case, if the adaptation layer, e.g., UDP tunnelling, tunneling,
   supports non-IP packet format, non-IP encapsulation MUST <bcp14>MUST</bcp14> be used;
   otherwise, header-based IP encapsulation MUST <bcp14>MUST</bcp14> be used.</t>
      <t>
   If non-IP encapsulation is configured, a GMA header MUST <bcp14>MUST</bcp14> 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 <xref target="sect-4.4"/>).</t> target="sect-4.4"
   format="default"/>).</t>
      <t>
   The GMA endpoints MAY <bcp14>MAY</bcp14> configure the GMA encapsulation method through
   control signalling signaling or pre-configuration. For example, the "MX UP Setup
   Configuration Request" message as specified in Multi-Access Management
   Service <xref target="MAMS"/> target="RFC8743" format="default"/> 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.</t>
      <t>
   GMA endpoint MUST <bcp14>MUST</bcp14> discard a received packet and MAY <bcp14>MAY</bcp14> log an error
   to report the situation (although such error logging MUST <bcp14>MUST</bcp14> be
   subject to rate limits) under any of the following conditions:</t>

   <t><list style="symbols">

     <t>the
      <ul spacing="normal">
        <li>The GMA version number in the GMA header (or trailer) is not
     understood or supported by the GMA endpoint</t>

     <t>a Flag endpoint.</li>
        <li>A flag bit in the GMA header (or trailer) not understood or
     supported by the GMA endpoint is set to "1"</t>

	</list>
	</t> "1".</li>
      </ul>
      <section title="Trailer-based anchor="sect-4.1" numbered="true" toc="default">
        <name>Trailer-Based IP Encapsulation" anchor="sect-4.1"> Encapsulation</name>
        <figure title="GMA anchor="Fig3">
          <name>GMA PDU Format with Trailer-based IP Encapsulation" anchor="Fig3">
	    <artwork><![CDATA[ Encapsulation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       |<---------------------GMA PDU ----------------------->|
       +------------------------------------------------------+
       | IP hdr |        IP payload             | GMA Trailer |
       +------------------------------------------------------+
       |<------- GMA SDU (user payload)-------->|
]]></artwork>
        </figure>
        <t>
   This method SHALL NOT <bcp14>SHALL NOT</bcp14> be used if the original IP packet (GMA SDU)
   service data unit (GMA SDU)) is IPv6.</t>
        <t>
   Figure 3
   <xref target="Fig3"/> shows the trailer-based IP encapsulation GMA PDU
   (protocol protocol
   data unit) unit (GMA PDU) format. A (GMA) PDU may carry one or multiple IP
   packets, aka (GMA) SDUs (service data unit), SDUs, in the payload, or a fragment of the SDU.</t>
        <t>
   The Protocol Type protocol type field in the IP header of the GMA PDU MUST <bcp14>MUST</bcp14> be
   changed to 114 (Any 0-Hop Protocol) (see <xref target="sect-4.4"/>) target="sect-4.4" format="default"/>) to indicate
   the presence of the GMA trailer.</t>
        <t>
   The following three IP header fields MUST <bcp14>MUST</bcp14> be changed:</t>

   <t><list style="symbols">

     <t>IP Length: add
<dl>
          <dt>IP Length:</dt><dd> Add the length of "GMA Trailer" to the length of the
     original IP packet</t>

     <t>Time packet.</dd>
          <dt>Time To Live (TTL): set (TTL):</dt><dd> Set to "1"</t>

     <t>IP checksum: recalculate "1".</dd>
          <dt>IP checksum:</dt><dd> Recalculate after changing "Protocol Type", "TTL" "protocol
          type", "TTL", and "IP Length"</t>

	</list>
	</t> Length".</dd>
        </dl>
        <t>
   The GMA (Generic Multi-Access) trailer MUST <bcp14>MUST</bcp14> consist of two
   mandatory fields (the last 3 bytes): Next Header and Flags, Flags.
	</t>
   <t>
   This is defined as follows:</t>

   <t><list style="symbols">
     <t>Next

   <dl>
          <dt>Next Header (1 Byte): byte):</dt><dd> This is the IP protocol type of the (first) SDU
     in a PDU, and PDU; it stores the value before it was overwritten to
     114.</t>

     <t>Flags
     114.</dd>

            <dt>Flags (2 Bytes): bytes):</dt><dd><t> Bit 0 is the most significant bit (MSB), and
     Bit
	    bit 15 is the least significant bit (LSB)

     <list style="symbols">

       <t>Checksum (LSB).
	  </t>
     <dl>
              <dt>Checksum Present (bit 0): 0):</dt><dd> If the Checksum Present
              bit is set to 1, then the Checksum field is present</t>

       <t>Concatenation present.</dd>
              <dt>Concatenation Present (bit 1): 1):</dt><dd> If the Concatenation
              Present bit is set to 1, then the PDU carries multiple SDUs, and
              the First SDU Length field is present</t>

       <t>Connection present.</dd>
              <dt>Connection ID Present (bit 2): 2):</dt><dd> If the Connection ID
              Present bit is set to 1, then the Connection ID field is present</t>

       <t>Flow
              present.</dd>
              <dt>Flow ID Present (bit 3): 3):</dt><dd> If the Flow ID Present bit
              is set to 1, then the Flow ID field is present</t>

       <t>Fragmentation present.</dd>
              <dt>Fragmentation Present (bit 4): If 4):</dt><dd>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</t>

       <t>Delivery present.</dd>
              <dt>Delivery SN Present (bit 5): 5):</dt><dd> If the Delivery SN
              (Sequence Number) Present bit is set to 1, then the Delivery SN
              field is present and contains the valid information</t>

       <t>Flow information.</dd>
              <dt>Flow SN Present (bit 6): 6):</dt><dd> If the Flow SN Present bit
              is set to 1, then the Sequence Number field is present</t>

       <t>Timestamp present.</dd>
              <dt>Timestamp Present (bit 7): 7):</dt><dd> If the Timestamp Present
              bit is set to 1, then the Timestamp field is present</t>

       <t>TTL present.</dd>
              <dt>TTL Present (bit 8): 8):</dt><dd> If the TTL Present bit is set
              to 1, then the TTL field is present</t>

       <t>Reserved present.</dd>
              <dt>Reserved (bit 9-12): 9-12):</dt><dd> This is set to "0" and ignored
              on receipt</t>

       <t>Version receipt.</dd>
              <dt>Version (bit 13~15): 13~15):</dt><dd> This is the GMA version number,
              number; it is set to 0 for the GMA encapsulation protocol specified in
              this document.</t>

     </list>
     </t>

   </list>
   </t> document.</dd>
            </dl>
          </dd>
        </dl>
        <t>
   The Flags field is at the end of the PDU, and the Next Header field is the
   second last. The Receiver SHOULD receiver <bcp14>SHOULD</bcp14> first decode the Flags
   field to determine the length of the GMA trailer, trailer and then decode each
   optional field accordingly. The GMA (Generic Multi-Access) Generic Multi-Access (GMA) trailer MAY
   <bcp14>MAY</bcp14> consist of the following optional fields:</t>

	<t><list style="symbols"><t>Checksum
   <dl>

          <dt>Checksum (1 Byte): to contain byte):</dt><dd> This contains the (one's
          complement) checksum sum of all the 8 bits in the trailer. For purposes
          of computing the checksum, the value of the checksum Checksum field is
          zero. This field is present only if the Checksum Present bit is set
          to one.</t>

	<t>First 1.</dd>
          <dt>First SDU Length (2 Bytes): bytes):</dt><dd> 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 one.</t>

	<t>Connection 1.</dd>

            <dt>Connection ID (1 Byte): byte):</dt><dd><t> 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 one.

     <list style="symbols">

       <t>Anchor 1.
   </t>

            <dl>
              <dt>Anchor Connection ID (MSB 4 Bits): bits):</dt><dd> This contains an
              unsigned integer to identify the anchor connection</t>

       <t>Delivery connection.</dd>
              <dt>Delivery Connection ID (LSB 4 Bits): bits):</dt><dd> This contains
              an unsigned integer to identify the delivery connection</t>

	</list>
	</t>

	<t>Flow connection.</dd>
            </dl>
          </dd>
          <dt>Flow ID (1 Byte): byte):</dt><dd> This contains an unsigned integer to identify the
          IP flow that a PDU belongs to, for example Data Radio Bearer (DRB)
          ID
     [LWIPEP] <xref target="LWIPEP"/> for a cellular (e.g., LTE)
          connection. This field is present only if the Flow ID Present bit is
          set to one.</t>

	<t>Fragmentation 1.</dd>
          <dt>Fragmentation Control (FC) (1 Byte): to provide byte):</dt><dd> This provides
          necessary information for re-assembly, reassembly, only needed if a PDU carries
          fragments. This field is present only if the Fragmentation Present
          bit is set to one. 1. Please refer to section 5 <xref target="sect-5"/> for its
          detailed format and usage.</t>

	<t>Delivery usage.</dd>
          <dt>Delivery SN (1 Byte): byte):</dt><dd> 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 one.</t>

	<t>Flow 1.</dd>
          <dt>Flow SN (3 Bytes): bytes):</dt><dd> 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
          <bcp14>SHALL</bcp14> be generated per flow. This field is present
          only if the Flow SN Present bit is set to one.</t>

	<t>Timestamp 1.</dd>
          <dt>Timestamp (4 Bytes): to contain bytes):</dt><dd> 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 one.</t>

	<t>TTL 1.</dd>
          <dt>TTL (1 Byte): to contain byte):</dt><dd> 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 one.</t>

	</list>
	</t> 1.</dd>
        </dl>
        <t>
   Figure 4
   <xref target="Fig4"/> shows the GMA trailer format with all the fields present,
   and the order of the GMA control fields SHALL <bcp14>SHALL</bcp14> 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.</t>
        <t>
   For example, Bit bit 0 (the MSB) of the Flags field is the Checksum Present
   bit, and the Checksum field is the last in the trailer
   except with the exception
   of the two mandatory fields. Bit 1 is the Concatenation
   present Present bit, and
   the FSL field is the second last.</t>
        <figure title="GMA anchor="Fig4">
          <name>GMA Trailer Format with all All Optional Fields Present" anchor="Fig4"><artwork><![CDATA[ Present</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
      </section>
      <section title="Header-based anchor="sect-4.2" numbered="true" toc="default">
        <name>Header-Based IP Encapsulation" anchor="sect-4.2"><t> Encapsulation</name>
        <t>
   This method SHALL NOT <bcp14>SHALL NOT</bcp14> be used if the original IP packet (GMA SDU)
   is IPv6.</t>
        <t>
   Figure 5
   <xref target="Fig5"/> 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 <bcp14>MUST</bcp14> be changed the same
   way as in trailered-based trailer-based IP encapsulation.</t>
        <figure title="GMA anchor="Fig5">
          <name>GMA PDU Format with Header-based Header-Based IP Encapsulation" anchor="Fig5"><artwork><![CDATA[ Encapsulation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       +-----------------------------------------------+
       |IP hdr | GMA Header  |       IP payload        |
       +-----------------------------------------------+
]]></artwork>
        </figure>
        <t>
   Figure 6
   <xref target="Fig6"/> 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 receiver can first decode the Flags field to determine the GMA
   header length.</t>
        <t>
   The "TTL" field MUST <bcp14>MUST</bcp14> be included and the "TTL" bit in the
   GMA header (or Trailer) MUST <bcp14>MUST</bcp14> be set to 1 if (Trailer (trailer- or Header based)
   header-based) IP
   Encapsulation encapsulation is used.</t>
        <figure title="GMA anchor="Fig6">
          <name>GMA Header Format" anchor="Fig6"><artwork><![CDATA[ Format</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    +------------------------------------------------------+
    | Flags | other fields (TTL, Timestamp, Flow SN, etc.) |
    +------------------------------------------------------+
]]></artwork>
        </figure>
      </section>

      <section title="(Header-based) non-IP Encapsulation" anchor="sect-4.3"><t>
   Figure 7 anchor="sect-4.3" numbered="true" toc="default">

        <name>Header-Based Non-IP Encapsulation</name>
        <t>
   <xref target="Fig7"/> shows the header-based non-IP encapsulation format. Here,
   "UDP Tunnelling" Tunneling" is configured at the MX adaptation layer. The
   ports for "UDP Tunnelling" Tunneling" at Client the client are chosen from the Dynamic
   Port range, and the ports for "UDP Tunnelling" Tunneling" at the Multi-Access
   Gateway are configured and provided to Client the client through additional
   control messages, e.g., <xref target="MAMS"/>.</t> target="RFC8743" format="default"/>.</t>
        <t>
   "TTL", "FSL", and "Next Header" are no longer needed, needed and MUST <bcp14>MUST</bcp14> not
   be included. Moreover, the IP header fields of the GMA SDU remain
   unchanged.</t>
        <figure title="GMA anchor="Fig7">
          <name>GMA PDU Format with Non-IP Encapsulation" anchor="Fig7"><artwork><![CDATA[ Encapsulation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 +-------------------------------------------------------------+
 | IP hdr | UDP hdr  | GMA Header | IP hdr |    IP payload     |
 +-------------------------------------------------------------+
                                 |<------- GMA SDU------------>|
                     |<------------------- GMA PDU------------>|
]]></artwork>
        </figure>
      </section>
      <section title="IP anchor="sect-4.4" numbered="true" toc="default">
        <name>IP Protocol Identifier" anchor="sect-4.4"><t> Identifier</name>
        <t>
   As described in <xref target="sect-4.1"/>, IP encapsulated target="sect-4.1" format="default"/>, IP-encapsulated GMA PDUs are
   indicated using the IP Protocol Type protocol type 114. This is designated and
   recorded by IANA <xref target="IANA"/> target="IANA" format="default"/> to indicate "any 0-Hop Protocol". No
   reference is given in the IANA registry for the definition of this
   Protocol Type,
   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 <xref target="IANA1999"/>.</t> target="IANA1999" format="default"/>.</t>
        <t>
   There is some risk associated with "re-using" Protocol Type "reusing" protocol type 114
   because there may be implementations of other protocols also using
   this Protocol Type. 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 protocol type 114 should
   be safe.</t>
        <t>
   As described in <xref target="sect-1.1"/>, target="sect-1.1" format="default"/>, one of the purposes of the experiment
   described in this document is to verify the safety of using this
   Protocol Type.
   protocol type. Deployments should be aware of the risk of a clash
   with other uses of this Protocol Type.</t> protocol type.</t>
      </section>
    </section>
    <section title="Fragmentation" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>Fragmentation</name>
      <t>
   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 <bcp14>MAY</bcp14> exceed the MTU of a
   delivery connection, GMA endpoints MUST <bcp14>MUST</bcp14> be configured to
   support fragmentation through additional control messages <xref target="MAMS"/>.</t>
   target="RFC8743" format="default"/>.</t>
      <t>
   The fragmentation procedure at the convergence sublayer is similar
   to IP fragmentation <xref target="RFC0791"/> target="RFC0791" format="default"/> in principle, but with the following
   two differences for less overhead:</t>

   <t><list style="symbols">

     <t>The
      <ul spacing="normal">
        <li>The fragment offset field is expressed in number of fragments</t>

     <t>The fragments.</li>
        <li>The maximum number of fragments per SDU is 2^7 (=128)</t>

	</list>
	</t> 2<sup>7</sup> (=128).</li>
      </ul>
      <t>
   The Fragmentation Control (FC) field in the GMA trailer (or
   header) contains the following bits:</t>

   <t><list style="symbols">

     <t>Bit #7:

   <dl>
        <dt>Bit 7:</dt><dd> a More Fragment (MF) flag to indicate if the fragment
     is the last one (0) or not (1)</t>

     <t>Bit #0~#6: (1)</dd>
        <dt>Bit 0-6:</dt><dd> Fragment Offset (in units of fragments) to specify
     the offset of a particular fragment relative to the beginning
     of the SDU</t>

	</list>
	</t> SDU</dd>
      </dl>
      <t>
   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.</t>
      <t>
   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.</t>
      <t>
   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
   <bcp14>SHOULD</bcp14> be changed to the length of the PDU, and the protocol
   type
   SHOULD <bcp14>SHOULD</bcp14> be changed to 114.</t>
      <t>
   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.</t>
      <t>
   To assemble the fragments of a 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-Fragments More Fragment flag set to "0".</t>
      <t>
   GMA fragmentation operates above the IP layer of individual access
   connection (Wi-Fi, LTE) and between the two end points endpoints of convergence
   layer. The convergence layer end points endpoints (client,
   multi-access gateway) SHOULD Multi-access Gateway)
   <bcp14>SHOULD</bcp14> obtain the MTU of individual connection through
   either manual configuration or implementing
   PMTUD Path MTU Discovery (PMTUD) as
   suggested in <xref target="RFC8900"/>.</t> target="RFC8900" format="default"/>.</t>
    </section>
    <section title="Concatenation" anchor="sect-6"><t> anchor="sect-6" numbered="true" toc="default">
      <name>Concatenation</name>
      <t>
   The convergence sublayer MAY <bcp14>MAY</bcp14> 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,
   address and the same Flow ID MAY <bcp14>MAY</bcp14> be concatenated.</t>
      <t>
   If the (trailer (trailer- or header based) header-based) IP encapsulation method is used,
   the First SDU Length (FSL) field SHOULD <bcp14>SHOULD</bcp14> be included in the GMA
   trailer (or header) to indicate the length of the first SDU.
   Otherwise, the FSL field SHOULD <bcp14>SHOULD</bcp14> not be included.</t>
      <figure title="Example anchor="Fig8">
        <name>Example of GMA PDU Format with Concatenation and Trailer-based Trailer-Based IP Encapsulation" anchor="Fig8">
     <artwork><![CDATA[ Encapsulation</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +-----------------------------------------------------------+
  |IP hdr| IP payload    |IP hdr|   IP payload  | GMA Trailer |
  +-----------------------------------------------------------+
]]></artwork>
      </figure>
      <t>
   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).
   (<xref target="Fig8"/>). The procedure continues till until the PDU size reaches the
   MTU of the delivery connection. If the FSL field is present, the
   IP length Length field of the PDU SHOULD <bcp14>SHOULD</bcp14> be updated to include all
   concatenated SDUs and the trailer (or header), and the IP checksum
   field SHOULD <bcp14>SHOULD</bcp14> be recalculated if the packet is IPv4.</t>
      <t>
   To disaggregate a PDU, if the (header (header- or trailer based) 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 till until no byte is left in the
   PDU. If the non-IP encapsulation method (Figure 7) (<xref target="Fig7"/>) is used, the IP
   header of the first SDU will not change during the encapsulation
   process, and the receiver SHOULD <bcp14>SHOULD</bcp14> obtain the length of the first
   SDU directly from its IP header (Figure 9).</t> (<xref target="Fig9"/>).</t>
      <figure title="Example anchor="Fig9">
        <name>Example of GMA PDU Format with Concatenation and Header-based Header-Based Non-IP (UDP) Encapsulation" anchor="Fig9">
     <artwork><![CDATA[ Encapsulation</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                                 |<-------1st GMA SDU------------
+---------------------------------------------------------------+
| IP hdr | UDP hdr  | GMA Header | IP hdr |       IP payload    |
+---------------------------------------------------------------+
         | IP hdr |           IP payload    |
+-------------------------------------------+
-------->|<-------2nd GMA SDU--------------->
]]></artwork>
      </figure>
      <t>
   If a PDU contains multiple SDUs, the Flow SN field is for the last
   SDU, and the Flow SN of other SDU 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 SDU, respectively.</t>
      <t>
   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.).</t>
      <t>
   GMA endpoint MUST NOT endpoints <bcp14>MUST NOT</bcp14> perform concatenation and
   fragmentation in a single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT
   <bcp14>MUST NOT</bcp14> carry any other (fragmented or whole) SDU.</t>
    </section>
    <section title="Security Considerations" anchor="sect-7"><t> anchor="sect-7" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   Security in a network using GMA should be relatively similar to security in
   a normal IP network. GMA is unaware of IP IP- or higher
   layer 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 IP- or higher layer higher-layer security as well as link-layer
   security.</t>
      <t>
   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
   <bcp14>SHOULD</bcp14> 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 issue, it may be
   desirable to terminate the GMA operation at the firewall.</t>
      <t>
   Local-only packet leak prevention (HL=0, TTL=1) SHOULD <bcp14>SHOULD</bcp14> be on
   preventing the leak of the local-only GMA PDUs outside the "local domain"
   to the Internet or to another domain which that could use the same IP protocol
   type, i.e. i.e., 114.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-8"><t> anchor="sect-8" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	This document makes has no requests of IANA</t> IANA actions.
      </t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC8174;
	<reference anchor="GRE1" target="https://www.rfc-editor.org/info/rfc2890"><front>
	<title>Key and Sequence Number Extensions to GRE</title>
	<author initials="G." surname="Dommety" fullname="G. Dommety">
	</author>

	<date month="September" year="2000"/>
	</front>

	<seriesInfo name="RFC" value="2890"/>
	<seriesInfo name="DOI" value="10.17487/RFC2890"/>
	</reference>

<displayreference target="RFC2890" to="GRE1"/>
<displayreference target="RFC8157" to="GRE2"/>
<displayreference target="I-D.zhu-intarea-gma-control" to="GMAC"/>

<displayreference target="RFC8743" to="MAMS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8157.xml"/>

      </references>

	<references title="Informative References">

	<reference anchor="MAMS" target="https://www.rfc-editor.org/info/rfc8743"><front>
	<title>Multiple Access Management Services Multi-Access Management Services (MAMS)</title>
	<author initials="S." surname="Kanugovi" fullname="S. Kanugovi">
	</author>

	<author initials="F." surname="Baboescu" fullname="F. Baboescu">
	</author>

	<author initials="J." surname="Zhu" fullname="J. Zhu">
	</author>

	<author initials="S." surname="Seo" fullname="S. Seo">
	</author>

	<date month="March" year="2020"/>
	</front>

	<seriesInfo name="RFC" value="8743"/>
	<seriesInfo name="DOI" value="10.17487/RFC8743"/>
	</reference>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8743.xml"/>

        <reference anchor="IANA" target="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"><front>
	<title/> target="https://www.iana.org/assignments/protocol-numbers">
          <front>
            <title>Protocol Numbers
	    </title>
            <author>
	      <organization>IANA</organization>
	</author>

	<date/>
          </front>
        </reference>

	<!--
   draft-zhu-intarea-gma-14-manual.txt(762): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [LWIPEP] 3GPP TS 36.361, "Evolved

   <reference anchor="LWIPEP" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3037">
          <front>
            <title>Evolved Universal Terrestrial Radio Access (E-UTRA);
            LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP)
            encapsulation; Protocol
            specification"
   -->

	&RFC0791;

	<!--
   draft-zhu-intarea-gma-14-manual.txt(771): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [ATSSS] 3GPP TR 23.793, Study specification
            </title>
            <author>
              <organization>3GPP</organization>
        </author>
<date month="July" year="2020"/>
          </front>
         <seriesInfo name="3GPP TS" value="36.361"/>
	  <refcontent>Release 13</refcontent>
   </reference>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>

 <reference anchor="ATSSS" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3254">
          <front>
            <title>Study on access traffic steering, switch and splitting
            support in the 5G system architecture.
   -->

	&RFC8900; System (5GS) architecture
	    </title>
<author>
              <organization>3GPP</organization>
            </author>
            <date month="December" year="2018"/>
         </front>
         <seriesInfo name="3GPP TR" value="23.793"/>
         <refcontent>Release 16</refcontent>
	</reference>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/>

        <reference anchor="IANA1999" target="https://web.archive.org/web/19990203044112/http://www"><front>
	<title/> quote-title="false"  target="https://web.archive.org/web/19990203044112/http://www.isi.edu:80/in-notes/iana/assignments/protocol-numbers">
          <front>
            <title>Wayback Machine archive of "Protocol Numbers"
	    </title>
            <author>
	      <organization>IANA
	      </organization>
	</author>

	<date/>
	<date month="February" year="1999"/>
          </front>
        </reference>

	&I-D.ietf-rmcat-gcc;

	<!--
   draft-zhu-intarea-gma-14-manual.txt(786): Warning: Failed parsing a reference.
   Are all elements separated by commas (not periods, not just spaces)?:
   [MPIP] L. Sun, et al. Multipath

	<reference anchor="GCC"
target="https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02" derivedAnchor="Google-GCC">
          <front>
            <title>A Google Congestion Control Algorithm for Real-Time Communication</title>
            <author initials="S" surname="Holmer" fullname="Stefan Holmer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Lundin" fullname="Henrik Lundin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G" surname="Carlucci" fullname="Gaetano Carlucci">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L" surname="De Cicco" fullname="Luca De Cicco">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Mascolo" fullname="Saverio Mascolo">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" day="8" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rmcat-gcc-02"/>
        </reference>

  <reference anchor="MPIP" target="https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/MPIP_Tech.pdf">
          <front>
            <title>Multipath IP Routing on End Devices: Motivation, Design,
            and Performance, https://eeweb.engineering.nyu.edu/faculty/
          yongliu/docs/MPIP_Tech.pdf
   -->

	&I-D.zhu-intarea-gma-control; Performance
	    </title>
            <author initials="L." surname="Sun" fullname="Liyang Sun"/>
	    <author initials="G." surname="Tian" fullname="Guibin Tian"/>
	    <author initials="G." surname="Zhu" fullname="Guanyu Zhu"/>
	    <author initials="Y." surname="Liu" fullname="Yong Liu"/>
	    <author initials="H." surname="Shi" fullname="Hang Shi"/>
	    <author initials="D." surname="Dai" fullname="David Dai"/>
            <date year="2017"/>
          </front>
        </reference>

	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.zhu-intarea-gma-control.xml"/>
      </references>
    </references>

  </back>
</rfc>