rfc9188xml2.original.xml   rfc9188.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbsp "&#160;">
C.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.8174.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC2890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2890.xml">
<!ENTITY RFC8743 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8743.xml">
<!ENTITY RFC0791 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0791.xml">
<!ENTITY RFC8900 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.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">
]> ]>
<rfc submissionType="IETF" docName="draft-zhu-intarea-gma-14" 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"?>
<front>
<title abbrev="GMA Encapsulation Protocol">Generic Multi-Access (GMA) Enc
apsulation Protocol</title>
<author initials="J." surname="Zhu" fullname="Jing Zhu">
<organization>Intel</organization>
<address><email>jing.z.zhu@intel.com</email>
</address>
</author>
<author initials="S." surname="Kanugovi" fullname="Satish Kanugovi"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-zhu-intarea-gma-1
<organization>Nokia</organization> 4" number="9188" submissionType="independent" category="exp" ipr="trust200902" o
<address><email>satish.k@nokia.com</email> bsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true"
</address> tocInclude="true" version="3">
</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> <front>
A device can be simultaneously connected to multiple networks, <title abbrev="GMA Encapsulation Protocol">Generic Multi-Access (GMA) Encaps
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly ulation Protocol</title>
combine the connectivity over these networks below the transport <seriesInfo name="RFC" value="9188"/>
layer (L4) to improve quality of experience for applications that <author initials="J." surname="Zhu" fullname="Jing Zhu">
do not have built in multi-path capabilities. Such optimization <organization>Intel</organization>
requires additional control information, e.g., a sequence number, <address>
in each packet. This document presents a new light weight and <email>jing.z.zhu@intel.com</email>
flexible encapsulation protocol for this need. The solution has </address>
been developed by the authors based on their experiences in </author>
multiple standards bodies including the IETF and 3GPP, is not an <author initials="S." surname="Kanugovi" fullname="Satish Kanugovi">
Internet Standard and does not represent the consensus opinion of <organization>Nokia</organization>
the IETF. This document will enable other developers to build <address>
interoperable implementations in order to experiment with the <email>satish.k@nokia.com</email>
protocol.</t> </address>
</author>
</abstract> <date year="2022" month="February"/>
</front>
<middle> <abstract>
<section title="Introduction" anchor="sect-1"><t> <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 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.</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
A device can be simultaneously connected to multiple networks, A device can be simultaneously connected to multiple networks,
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly
combine the connectivity over these networks below the transport combine the connectivity over these networks below the transport
layer (L4) to improve quality of experience for applications that layer (L4) to improve the quality of experience for applications that
do not have built in multi-path capabilities.</t> do not have built-in multi-path capabilities.</t>
<t>
<t> <xref target="Fig1"/> shows the Multi-Access Management Service (MAMS) user-p
Figure 1 shows the Multi-Access Management Service (MAMS) user-plane lane
protocol stack <xref target="MAMS"/>, which has been used in today's protocol stack <xref target="RFC8743" format="default"/>, which has been used
multi-access solutions [ATSSS] [LWIPEP] <xref target="GRE1"/> [GRE2]. It in today's
multi-access solutions <xref target="ATSSS"/> <xref target="LWIPEP"/> <xref t
arget="RFC2890" format="default"/> <xref target="RFC8157"/>. It
consists of two layers: convergence and adaptation.</t> consists of two layers: convergence and adaptation.</t>
<t>
<t> The convergence layer is responsible for multi-access operations, including
The convergence layer is responsible for multi-access operations, multi-link (path) aggregation, splitting/reordering, lossless
including multi-link (path) aggregation, splitting/reordering, switching/retransmission, fragmentation, concatenation, etc. It operates on
lossless switching/retransmission, fragmentation, concatenation, top of the adaptation layer in the protocol stack. From the perspective of
etc. It operates on top of the adaptation layer in the protocol a transmitter, a User Payload (e.g., IP packet) is processed by the
stack. From the perspective of a transmitter, a User Payload convergence layer first and then by the adaptation layer before being
(e.g., IP packet) is processed by the convergence layer first, and transported over a delivery connection; from the receiver's perspective, an
then by the adaptation layer before being transported over a IP packet received over a delivery connection is processed by the
delivery connection; from the receiver's perspective, an IP packet adaptation layer first and then by the convergence layer.</t>
received over a delivery connection is processed by the adaptation <figure anchor="Fig1">
layer first, and then by the convergence layer.</t> <name>MAMS User-Plane Protocol Stack</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="MAMS User-Plane Protocol Stack [MAMS]" anchor="Fig1"><artw
ork><![CDATA[
+-----------------------------------------------------+ +-----------------------------------------------------+
| User Payload, e.g., IP Protocol Data Unit (PDU) | | User Payload, e.g., IP Protocol Data Unit (PDU) |
+-----------------------------------------------------+ +-----------------------------------------------------+
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | Multi-Access (MX) Convergence Layer | | | | Multi-Access (MX) Convergence Layer | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | MX Adaptation | MX Adaptation | MX Adaptation | | | | MX Adaptation | MX Adaptation | MX Adaptation | |
| | Layer | Layer | Layer | | | | Layer | Layer | Layer | |
| +-----------------+-----------------+-----------------+ | | +-----------------+-----------------+-----------------+ |
| | Access #1 IP | Access #2 IP | Access #3 IP | | | | Access #1 IP | Access #2 IP | Access #3 IP | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| MAMS User-Plane Protocol Stack | | MAMS User-Plane Protocol Stack |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
GRE (Generic Routing Encapsulation) can be used [LWIPEP] <xref target="GRE1"/ GRE (Generic Routing Encapsulation) <xref target="LWIPEP"/> <xref
> target="RFC2890" format="default"/> <xref target="RFC8157"/> can be used as
[GRE2] as the encapsulation protocol at the convergence layer to the encapsulation protocol at the convergence layer to encode additional
encode additional control information, e.g., Key, Sequence Number. control information, e.g., key and sequence number. However, there are two
However, there are two main drawbacks with this approach:</t> main drawbacks with this approach:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>It is difficult to introduce new control fields because the
GRE header formats are already defined, and</li>
<t>It is difficult to introduce new control fields because the <li>IP-over-IP tunneling (required for GRE) leads to higher
GRE header formats are already defined,</t> overhead especially for small packets.</li>
</ul>
<t>IP-over-IP tunnelling (required for GRE) leads to higher <t>
overhead especially for small packet.</t> 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
</list> GRE header), which is 80% of a 40-byte TCP ACK packet.</t>
</t>
<t>
For example, the overhead of IP-over-IP/GRE tunnelling with both
Key and Sequence Number is 32 Bytes (20 Bytes IP header + 12 Bytes
GRE header), which is 80% of a 40 Bytes TCP ACK packet.</t>
<t> <t>
This document presents a light-weight GMA (Generic Multi-Access) This document presents a lightweight Generic Multi-Access (GMA)
encapsulation protocol for the convergence layer. It supports three encapsulation protocol for the convergence layer. It supports three
encapsulation methods: trailer-based IP encapsulation, header-based IP encapsulation methods: trailer-based IP encapsulation, header-based IP
encapsulation, and non-IP encapsulation. Particularly, the IP encapsulation, and non-IP encapsulation. Particularly, the IP
encapsulation methods avoid IP-over-IP tunneling overhead (20 Bytes), which encapsulation methods avoid IP-over-IP tunneling overhead (20 bytes), which
is 50% of a 40 Bytes TCP ACK packet. Moreover, it introduces new control is 50% of a 40-byte TCP ACK packet. Moreover, it introduces new control
fields to support fragmentation and concatenation, which are not available fields to support fragmentation and concatenation, which are not available
in GRE-based solutions [LWIPEP] <xref target="GRE1"/> [GRE2].</t> in GRE-based solutions <xref target="LWIPEP"/> <xref target="RFC2890"
format="default"/> <xref target="RFC8157"/>.</t>
<t> <t>
The GMA protocol only operates between endpoints that have been configured The GMA protocol only operates between endpoints that have been configured
to use GMA. This configuration can be through any control messages and to use GMA. This configuration can be through any control messages and
procedures, including, for example, Multi-Access Management Services <xref procedures, including, for example, Multi-Access Management Services <xref
target="MAMS"/>. Moreover, UDP or IPSec tunneling can be used at the target="RFC8743" format="default"/>. Moreover, UDP or IPsec tunneling can
adaptation sublayer to protect GMA operation from intermediate nodes.</t> be used at the adaptation sublayer to protect GMA operation from
intermediate nodes.</t>
<t> <t>
The solution described in this document was been developed by the The solution described in this document was developed by the authors based
authors based on their experiences in multiple standards bodies on their experiences in multiple standards bodies including the IETF and
including the IETF and 3GPP. However, it is not an Internet 3GPP. However, this document is not an Internet Standard and does not
Standard and does not represent the consensus opinion of the IETF. represent the consensus opinion of the IETF. This document presents the
This document presents the protocol specification to enable protocol specification to enable experimentation as described in <xref
experimentation as described in <xref target="sect-1.1"/> and to facilitate target="sect-1.1" format="default"/> and to facilitate other interoperable
other interoperable implementations.</t> implementations.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="Scope of Experiment" anchor="sect-1.1"><t> <name>Scope of Experiment</name>
<t>
The protocol described in this document is an experiment. The The protocol described in this document is an experiment. The
objective of the experiment is to determine whether the protocol objective of the experiment is to determine whether the protocol
meets the requirements, can be safely used, and has support for meets the requirements, can be safely used, and has support for
deployment.</t> deployment.</t>
<t>
<t> <xref target="sect-4" format="default"/> describes three possible encapsulati
<xref target="sect-4"/> describes three possible encapsulation methods that a on methods that are
re
enabled by this protocol. Part of this experiment is to assess enabled by this protocol. Part of this experiment is to assess
whether all three mechanisms are necessary, or whether, for whether all three mechanisms are necessary or whether, for
example, all implementations are able to support the main example, all implementations are able to support the main
"trailer-based" IP encapsulation method. Similarly, the experiment "trailer-based" IP encapsulation method. Similarly, the experiment
will investigate the relative merits of the IP and non-IP will investigate the relative merits of the IP and non-IP
encapsulation methods.</t> encapsulation methods.</t>
<t>
<t> It is expected that this protocol experiment can be conducted on the
It is expected that this protocol experiment can be conducted on Internet since the GMA packets are identified by an IP protocol number and
the Internet since the GMA packets are identified by an IP the protocol is intended for single-hop propagation; devices should not be
protocol number and the protocol is intended for single hop forwarding packets, and if they do, they will not need to examine the payload
propagation: devices should not be forwarding packet and if they ,
do they will not need to examine the payload, while destination while destination systems that do not support this protocol should not
systems that do not support this protocol should not receive such receive such packets and will handle them as unknown payloads according to
packets and will handle them as unknown payloads according to normal IP processing. Thus, experimentation is conducted between consenting
normal IP processing. Thus, experimentation is conducted between end systems that have been mutually configured to participate in the
consenting end systems that have been mutually configured to experiment as described in <xref target="sect-7" format="default"/>.</t>
participate in the experiment as described in <xref target="sect-7"/>.</t> <t>
Note that this experiment "reuses" the IP protocol identifier 114
<t> as described in <xref target="sect-4.4" format="default"/>. Part of this expe
Note that this experiment "re-uses" the IP protocol identifier 114 riment is to assess
as described in <xref target="sect-4.4"/>. Part of this experiment is to asse
ss
the safety of doing this. The experiment should consider the the safety of doing this. The experiment should consider the
following safety mechanisms:</t> following safety mechanisms:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>GMA endpoints <bcp14>SHOULD</bcp14> detect non-GMA IP packets that
<t>GMA endpoints SHOULD detect non-GMA IP packets that also use also use
114 and log an error to report the situation (although such 114 and log an error to report the situation (although such
error logging MUST be subject to rate limits).</t> error logging <bcp14>MUST</bcp14> be subject to rate limits).</li>
<t>GMA endpoints SHOULD stop using 114 and switch to non-IP
(UDP) based encapsulation (Sec 4.3, Figure 7) after detecting
any non-GMA usage of 114.</t>
</list> <li>GMA endpoints <bcp14>SHOULD</bcp14> stop using 114 and switch to non-IP enca
</t> psulation,
i.e., UDP encapsulation (<xref target="Fig7"/>), after detecting any non-GMA usa
ge of 114.
</li>
<t> </ul>
The experiment SHOULD use packet tracing tool, e.g., WireShark, <t>
TCPDUMP, to monitor both ingress and egress traffic at GMA The experiment <bcp14>SHOULD</bcp14> 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.</t> endpoints and ensure the above safety mechanisms are implemented.</t>
<t>
<t> Path quality measurements (one-way delay, loss, etc.) and congestion
Path quality measurements (one-way-delay, loss, etc.) and detection are performed by the receiver based on the GMA control fields,
congestion detection are performed by receiver based on the GMA e.g., Sequence Number, Timestamp, etc. The receiver will then dynamically
control fields, e.g., sequence number, timestamp, etc. Receiver control how to split or steer traffic over multiple delivery connections
will then dynamically control how to split or steer traffic over accordingly. The GMA control protocol <xref
multiple delivery connections accordingly. GMA control protocol target="I-D.zhu-intarea-gma-control" format="default"/> <bcp14>MAY</bcp14>
<xref target="I-D.zhu-intarea-gma-control"/> MAY be used for signaling betwee be used for signaling between GMA endpoints. Another objective of the
n GMA endpoints. Another experiment is to evaluate the usage of various receiver-based algorithms
objective of the experiment is to evaluate the usage of various <xref target="GCC" format="default"/> <xref target="MPIP"/>
receiver-based algorithms <xref target="I-D.ietf-rmcat-gcc"/> [MPIP] in multi in multi-path traffic management and the impact on the End-to-End (E2E)
-path traffic performance (throughput, delay, etc.) of higher-layer (transport)
management, and the impact on the e2e performance (throughput, protocols, e.g., TCP, QUIC, WebRTC, etc.</t>
delay, etc.) of higher layer (transport) protocols, e.g., TCP, <t>
QUIC, WebRTC, etc.</t>
<t>
The authors will continually assess the progress of this The authors will continually assess the progress of this
experiment and encourage other implementers to contact them to experiment and encourage other implementers to contact them to
report the status of their implementations and their experiences report the status of their implementations and their experiences
with the protocol.</t> with the protocol.</t>
</section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>Conventions Used in This Document</name>
<t>
<section title="Conventions used in this document" anchor="sect-2"><t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, a "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
nd only when, they to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
appear in all capitals, as shown here.</t> <xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</section> </t>
</section>
<section title="Use Case" anchor="sect-3"><t> <section anchor="sect-3" numbered="true" toc="default">
As shown in Figure 2, a client device (e.g., Smartphone, Laptop, <name>Use Case</name>
etc.) may connect to the Internet via both Wi-Fi and LTE <t>
connections, one of which (e.g., LTE) may operate as the anchor As shown in <xref target="Fig2"/>, a client device (e.g., smartphone,
connection, and the other (e.g., Wi-Fi) may operate as the laptop, etc.) may connect to the Internet via both Wi-Fi and LTE
delivery connection. The anchor connection provides the IP address connections, one of which (e.g., LTE) may operate as the anchor connection,
and connectivity for end-to-end Internet access, and the delivery and the other (e.g., Wi-Fi) may operate as the delivery connection. The
connection provides an additional path between client and Multi-Access anchor connection provides the IP address and connectivity for end-to-end
Gateway for multi-access optimizations.</t> Internet access, and the delivery connection provides an additional path
between the client and Multi-Access Gateway for multi-access optimizations.</
<figure title="GMA-based Multi-Access Aggregation" anchor="Fig2"> t>
<artwork><![CDATA[ <figure anchor="Fig2">
<name>GMA-Based Multi-Access Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Multi-Access Aggregation Multi-Access Aggregation
+---+ +---+ +---+ +---+
| |A|--- LTE Connection -----|C| | | |A|--- LTE Connection -----|C| |
|U|-| |-|S| Internet |U|-| |-|S| Internet
| |B|--- Wi-Fi Connection ---|D| | | |B|--- Wi-Fi Connection ---|D| |
+---+ +---+ +---+ +---+
Client Multi-Access Gateway client Multi-Access Gateway
]]></artwork>
A: The adaptation layer endpoint of the LTE connection </figure>
resides in the client <dl indent="4">
<dt>A:</dt><dd> The adaptation-layer endpoint of the LTE connection
resides in the client.</dd>
B: The adaptation layer endpoint of the Wi-Fi connection <dt>B:</dt><dd> The adaptation-layer endpoint of the Wi-Fi connection
resides in the client resides in the client.</dd>
C: The adaptation layer endpoint of the LTE connection <dt>C:</dt><dd> The adaptation-layer endpoint of the LTE connection
resides in the Multi-Access Gateway, aka N-MADP (Network resides in the Multi-Access Gateway, aka N-MADP (Network
Multi-Access Data Proxy) in [MAMS] Multi-Access Data Proxy) in <xref target="RFC8743"/>.</dd>
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
]]></artwork>
</figure>
<t> <dt>D:</dt><dd> The adaptation-layer endpoint of the Wi-Fi connection
For example, per-packet aggregation allows a single IP flow to use resides in the Multi-Access Gateway.</dd>
the combined bandwidth of the two connections. In another example,
packets lost due to a temporarily 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> <dt>U:</dt><dd> The convergence-layer endpoint resides in the client.</dd
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.</t>
</section> <dt>S:</dt><dd> The convergence-layer endpoint resides in the Multi-Acces
s
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 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 overhead.</t>
</section>
<section title="GMA Encapsulation Methods" anchor="sect-4"><t> <section anchor="sect-4" numbered="true" toc="default">
<name>GMA Encapsulation Methods</name>
<t>
The GMA encapsulation protocol supports the following three The GMA encapsulation protocol supports the following three
methods:</t> methods:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Trailer-based IP Encapsulation (<xref target="sect-4.1"/>)</li>
<li>Header-based IP Encapsulation (<xref target="sect-4.2"/>)</li>
<t>Trailer-based IP Encapsulation (4.1)</t> <li>Header-based non-IP Encapsulation (<xref target="sect-4.3"/>)</li>
</ul>
<t>Header-based IP Encapsulation (4.2)</t> <t>
Non-IP encapsulation <bcp14>MUST</bcp14> be used if the original IP packet is
<t>(Header-based) non-IP Encapsulation (4.3)</t>
</list>
</t>
<t>
Non-IP encapsulation MUST be used if the original IP packet is
IPv6.</t> IPv6.</t>
<t>
<t> Trailer-based IP encapsulation <bcp14>MUST</bcp14> be used if it is supported
Trailer-based IP encapsulation MUST be used if it is supported by by
GMA endpoints and the original IP packet is IPv4.</t> GMA endpoints and the original IP packet is IPv4.</t>
<t>
<t> Header-based encapsulation <bcp14>MUST</bcp14> be used if the trailer-based
Header-based encapsulation MUST be used if the trailer-based method is not supported by either the client or Multi-Access Gateway.
method is not supported by either Client or Multi-Access Gateway. In this case, if the adaptation layer, e.g., UDP tunneling,
In this case, if the adaptation layer, e.g., UDP tunnelling, supports non-IP packet format, non-IP encapsulation <bcp14>MUST</bcp14> be us
supports non-IP packet format, non-IP encapsulation MUST be used; ed;
otherwise, header-based IP encapsulation MUST be used.</t> otherwise, header-based IP encapsulation <bcp14>MUST</bcp14> be used.</t>
<t>
<t> If non-IP encapsulation is configured, a GMA header <bcp14>MUST</bcp14> be
If non-IP encapsulation is configured, a GMA header MUST be present in every packet. In comparison, if IP encapsulation is configured,
present in every packet. In comparison, if IP encapsulation is a GMA header or trailer may be added dynamically on a per-packet basis, and
configured, a GMA header or trailer may be added dynamically on it indicates the presence of a GMA header (or trailer) to set the protocol
per-packet basis, and it indicates the presence of GMA header (or type of the GMA PDU to "114" (see <xref target="sect-4.4"
trailer) to set the protocol type of the GMA PDU to "114" (see format="default"/>).</t>
<xref target="sect-4.4"/>).</t> <t>
The GMA endpoints <bcp14>MAY</bcp14> configure the GMA encapsulation method t
<t> hrough
The GMA endpoints MAY configure the GMA encapsulation method through control signaling or pre-configuration. For example, the "MX UP Setup
control signalling or pre-configuration. For example, the "MX UP Setup
Configuration Request" message as specified in Multi-Access Management Configuration Request" message as specified in Multi-Access Management
Service <xref target="MAMS"/> includes "MX Convergence Method Parameters", Service <xref target="RFC8743" format="default"/> includes "MX Convergence Me thod Parameters",
which provides the list of parameters to configure the convergence layer, which provides the list of parameters to configure the convergence layer,
and can be extended to indicate the GMA encapsulation method.</t> and can be extended to indicate the GMA encapsulation method.</t>
<t>
<t> GMA endpoint <bcp14>MUST</bcp14> discard a received packet and <bcp14>MAY</bc
GMA endpoint MUST discard a received packet and MAY log an error p14> log an error
to report the situation (although such error logging MUST be to report the situation (although such error logging <bcp14>MUST</bcp14> be
subject to rate limits) under any of the following conditions:</t> subject to rate limits) under any of the following conditions:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The GMA version number in the GMA header (or trailer) is not
understood or supported by the GMA endpoint.</li>
<t>the GMA version number in the GMA header (or trailer) is not <li>A flag bit in the GMA header (or trailer) not understood or
understood or supported by the GMA endpoint</t> supported by the GMA endpoint is set to "1".</li>
</ul>
<t>a Flag bit in the GMA header (or trailer) not understood or <section anchor="sect-4.1" numbered="true" toc="default">
supported by the GMA endpoint is set to "1"</t> <name>Trailer-Based IP Encapsulation</name>
<figure anchor="Fig3">
</list> <name>GMA PDU Format with Trailer-based IP Encapsulation</name>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<section title="Trailer-based IP Encapsulation" anchor="sect-4.1">
<figure title="GMA PDU Format with Trailer-based IP Encapsulation" anch
or="Fig3">
<artwork><![CDATA[
|<---------------------GMA PDU ----------------------->| |<---------------------GMA PDU ----------------------->|
+------------------------------------------------------+ +------------------------------------------------------+
| IP hdr | IP payload | GMA Trailer | | IP hdr | IP payload | GMA Trailer |
+------------------------------------------------------+ +------------------------------------------------------+
|<------- GMA SDU (user payload)-------->| |<------- GMA SDU (user payload)-------->|
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
This method SHALL NOT be used if the original IP packet (GMA SDU) This method <bcp14>SHALL NOT</bcp14> be used if the original IP packet (GMA
is IPv6.</t> service data unit (GMA SDU)) is IPv6.</t>
<t>
<t> <xref target="Fig3"/> shows the trailer-based IP encapsulation GMA protocol
Figure 3 shows the trailer-based IP encapsulation GMA PDU data unit (GMA PDU) format. A (GMA) PDU may carry one or multiple IP
(protocol data unit) format. A (GMA) PDU may carry one or multiple packets, aka (GMA) SDUs, in the payload, or a fragment of the SDU.</t>
IP packets, aka (GMA) SDUs (service data unit), in the payload, or <t>
a fragment of the SDU.</t> The protocol type field in the IP header of the GMA PDU <bcp14>MUST</bcp14> b
e
<t> changed to 114 (Any 0-Hop Protocol) (see <xref target="sect-4.4" format="defa
The Protocol Type field in the IP header of the GMA PDU MUST be ult"/>) to indicate
changed to 114 (Any 0-Hop Protocol) (see <xref target="sect-4.4"/>) to indica
te
the presence of the GMA trailer.</t> the presence of the GMA trailer.</t>
<t>
<t> The following three IP header fields <bcp14>MUST</bcp14> be changed:</t>
The following three IP header fields MUST be changed:</t> <dl>
<dt>IP Length:</dt><dd> Add the length of "GMA Trailer" to the length
<t><list style="symbols"> of the
original IP packet.</dd>
<t>IP Length: add the length of "GMA Trailer" to the length of the <dt>Time To Live (TTL):</dt><dd> Set to "1".</dd>
original IP packet</t> <dt>IP checksum:</dt><dd> Recalculate after changing "protocol
type", "TTL", and "IP Length".</dd>
<t>Time To Live (TTL): set to "1"</t> </dl>
<t>
<t>IP checksum: recalculate after changing "Protocol Type", "TTL" The GMA (Generic Multi-Access) trailer <bcp14>MUST</bcp14> consist of two
and "IP Length"</t> mandatory fields (the last 3 bytes): Next Header and Flags.
</list>
</t> </t>
<t>
This is defined as follows:</t>
<t> <dl>
The GMA (Generic Multi-Access) trailer MUST consist of two <dt>Next Header (1 byte):</dt><dd> This is the IP protocol type of the
mandatory fields (the last 3 bytes): Next Header and Flags, (first) SDU
defined as follows:</t> in a PDU; it stores the value before it was overwritten to
114.</dd>
<t><list style="symbols">
<t>Next Header (1 Byte): the IP protocol type of the (first) SDU
in a PDU, and it stores the value before it was overwritten to
114.</t>
<t>Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and
Bit 15 is the least significant bit (LSB)
<list style="symbols">
<t>Checksum Present (bit 0): If the Checksum Present bit is set
to 1, then the Checksum field is present</t>
<t>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</t>
<t>Connection ID Present (bit 2): If the Connection ID Present
bit is set to 1, then the Connection ID field is present</t>
<t>Flow ID Present (bit 3): If the Flow ID Present bit is set
to 1, then the Flow ID field is present</t>
<t>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</t>
<t>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</t>
<t>Flow SN Present (bit 6): If the Flow SN Present bit is set
to 1, then the Sequence Number field is present</t>
<t>Timestamp Present (bit 7): If the Timestamp Present bit is
set to 1, then the Timestamp field is present</t>
<t>TTL Present (bit 8): If the TTL Present bit is set to 1,
then the TTL field is present</t>
<t>Reserved (bit 9-12): set to "0" and ignored on receipt</t>
<t>Version (bit 13~15): GMA version number, set to 0 for the
GMA encapsulation protocol specified in this document.</t>
</list>
</t>
</list>
</t>
<t> <dt>Flags (2 bytes):</dt><dd><t> Bit 0 is the most significant bit (
MSB), and
bit 15 is the least significant bit (LSB).
</t>
<dl>
<dt>Checksum Present (bit 0):</dt><dd> If the Checksum Present
bit is set to 1, then the Checksum field is present.</dd>
<dt>Concatenation Present (bit 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.</dd>
<dt>Connection ID Present (bit 2):</dt><dd> If the Connection ID
Present bit is set to 1, then the Connection ID field is
present.</dd>
<dt>Flow ID Present (bit 3):</dt><dd> If the Flow ID Present bit
is set to 1, then the Flow ID field is present.</dd>
<dt>Fragmentation Present (bit 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.</dd>
<dt>Delivery SN Present (bit 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.</dd>
<dt>Flow SN Present (bit 6):</dt><dd> If the Flow SN Present bit
is set to 1, then the Sequence Number field is present.</dd>
<dt>Timestamp Present (bit 7):</dt><dd> If the Timestamp Present
bit is set to 1, then the Timestamp field is present.</dd>
<dt>TTL Present (bit 8):</dt><dd> If the TTL Present bit is set
to 1, then the TTL field is present.</dd>
<dt>Reserved (bit 9-12):</dt><dd> This is set to "0" and ignored
on receipt.</dd>
<dt>Version (bit 13~15):</dt><dd> This is the GMA version
number; it is set to 0 for the GMA encapsulation protocol specifie
d in
this document.</dd>
</dl>
</dd>
</dl>
<t>
The Flags field is at the end of the PDU, and the Next Header field is the 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 second last. The receiver <bcp14>SHOULD</bcp14> first decode the Flags
the length of the GMA trailer, and then decode each optional field field to determine the length of the GMA trailer and then decode each
accordingly. The GMA (Generic Multi-Access) trailer MAY consist of the optional field accordingly. The Generic Multi-Access (GMA) trailer
following optional fields:</t> <bcp14>MAY</bcp14> consist of the following optional fields:</t>
<dl>
<t><list style="symbols"><t>Checksum (1 Byte): to contain the (one's comp
lement) checksum
sum of all the 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 one.</t>
<t>First SDU Length (2 Bytes): the length of the first IP packet <dt>Checksum (1 byte):</dt><dd> This contains the (one's
in the PDU, only included if a PDU contains multiple IP complement) checksum sum of all 8 bits in the trailer. For purposes
packets. This field is present only if the Concatenation of computing the checksum, the value of the Checksum field is
Present bit is set to one.</t> zero. This field is present only if the Checksum Present bit is set
to 1.</dd>
<dt>First SDU Length (2 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 1.</dd>
<t>Connection ID (1 Byte): an unsigned integer to identify the <dt>Connection ID (1 byte):</dt><dd><t> This contains an unsigned in teger to identify the
anchor and delivery connection of the GMA PDU. This field is anchor and delivery connection of the GMA PDU. This field is
present only if the Connection ID Present bit is set to one. present only if the Connection ID Present bit is set to 1.
</t>
<list style="symbols">
<t>Anchor Connection ID (MSB 4 Bits): an unsigned integer to
identify the anchor connection</t>
<t>Delivery Connection ID (LSB 4 Bits): an unsigned integer to
identify the delivery connection</t>
</list>
</t>
<t>Flow ID (1 Byte): 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 one.</t>
<t>Fragmentation Control (FC) (1 Byte): to provide necessary
information for re-assembly, only needed if a PDU carries
fragments. This field is present only if the Fragmentation
Present bit is set to one. Please refer to section 5 for its
detailed format and usage.</t>
<t>Delivery SN (1 Byte): 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 SN (3 Bytes): 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 one.</t>
<t>Timestamp (4 Bytes): to contain 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 Byte): to contain 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>
<t> <dl>
Figure 4 shows the GMA trailer format with all the fields present, <dt>Anchor Connection ID (MSB 4 bits):</dt><dd> This contains an
and the order of the GMA control fields SHALL follow the bit order unsigned integer to identify the anchor connection.</dd>
<dt>Delivery Connection ID (LSB 4 bits):</dt><dd> This contains
an unsigned integer to identify the delivery connection.</dd>
</dl>
</dd>
<dt>Flow ID (1 byte):</dt><dd> This contains an unsigned integer to id
entify the
IP flow that a PDU belongs to, for example Data Radio Bearer (DRB)
ID <xref target="LWIPEP"/> for a cellular (e.g., LTE)
connection. This field is present only if the Flow ID Present bit is
set to 1.</dd>
<dt>Fragmentation Control (FC) (1 byte):</dt><dd> 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 <xref target="sect-5"/> for its
detailed format and usage.</dd>
<dt>Delivery SN (1 byte):</dt><dd> This contains an auto-incremented i
nteger 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.</dd>
<dt>Flow SN (3 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
<bcp14>SHALL</bcp14> be generated per flow. This field is present
only if the Flow SN Present bit is set to 1.</dd>
<dt>Timestamp (4 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 1.</dd>
<dt>TTL (1 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 1.</dd>
</dl>
<t>
<xref target="Fig4"/> shows the GMA trailer format with all the fields presen
t,
and the order of the GMA control fields <bcp14>SHALL</bcp14> follow the bit o
rder
in the Flags field. Note that the bits in the Flags field are in the Flags field. Note that the bits in the Flags field are
ordered with the first bit transmitted being bit 0 (MSB). All ordered with the first bit transmitted being bit 0 (MSB). All
fields are transmitted in regular network byte order and appear in fields are transmitted in regular network byte order and appear in
reverse order to their corresponding flag bits. If a flag bit is reverse order to their corresponding flag bits. If a flag bit is
clear, the corresponding optional field is absent.</t> clear, the corresponding optional field is absent.</t>
<t>
<t> For example, bit 0 (the MSB) of the Flags field is the Checksum Present
For example, Bit 0 (the MSB) of the Flags field is the Checksum bit, and the Checksum field is the last in the trailer with the exception
Present bit, and the Checksum field is the last in the trailer of the two mandatory fields. Bit 1 is the Concatenation Present bit, and
except of the two mandatory fields. Bit 1 is the Concatenation the FSL field is the second last.</t>
present bit, and the FSL field is the second last.</t> <figure anchor="Fig4">
<name>GMA Trailer Format with All Optional Fields Present</name>
<figure title="GMA Trailer Format with all Optional Fields Present" ancho <artwork name="" type="" align="left" alt=""><![CDATA[
r="Fig4"><artwork><![CDATA[ 0 1 2 3
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
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 | TTL | Timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow SN | | Flow SN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery SN | FC | Flow ID | Connection ID | | Delivery SN | FC | Flow ID | Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First SDU Length (FSL) | Checksum | Next Header | | First SDU Length (FSL) | Checksum | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section title="Header-based IP Encapsulation" anchor="sect-4.2"><t> <name>Header-Based IP Encapsulation</name>
This method SHALL NOT be used if the original IP packet (GMA SDU) <t>
This method <bcp14>SHALL NOT</bcp14> be used if the original IP packet (GMA S
DU)
is IPv6.</t> is IPv6.</t>
<t>
<t> <xref target="Fig5"/> shows the header-based IP encapsulation format. Here, t
Figure 5 shows the header-based IP encapsulation format. Here, the he
GMA header is inserted right after the IP header of the GMA SDU, 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 and the IP header fields of the GMA PDU <bcp14>MUST</bcp14> be changed the sa
way as in trailered-based IP encapsulation.</t> me
way as in trailer-based IP encapsulation.</t>
<figure title="GMA PDU Format with Header-based IP Encapsulation" anchor= <figure anchor="Fig5">
"Fig5"><artwork><![CDATA[ <name>GMA PDU Format with Header-Based IP Encapsulation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------------------+ +-----------------------------------------------+
|IP hdr | GMA Header | IP payload | |IP hdr | GMA Header | IP payload |
+-----------------------------------------------+ +-----------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Figure 6 shows the GMA header format. In comparison to GMA <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 trailer, the only difference is that the Flags field is now in the front so
front so that the Receiver can first decode the Flags field to that the receiver can first decode the Flags field to determine the GMA
determine the GMA header length.</t> header length.</t>
<t>
<t> The "TTL" field <bcp14>MUST</bcp14> be included and the "TTL" bit in the
"TTL" field MUST be included and the "TTL" bit in the GMA header GMA header (or Trailer) <bcp14>MUST</bcp14> be set to 1 if (trailer- or
(or Trailer) MUST be set to 1 if (Trailer or Header based) IP header-based) IP encapsulation is used.</t>
Encapsulation is used.</t> <figure anchor="Fig6">
<name>GMA Header Format</name>
<figure title="GMA Header Format" anchor="Fig6"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------------+ +------------------------------------------------------+
| Flags | other fields (TTL, Timestamp, Flow SN, etc.) | | Flags | other fields (TTL, Timestamp, Flow SN, etc.) |
+------------------------------------------------------+ +------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section title="(Header-based) non-IP Encapsulation" anchor="sect-4.3"><t <section anchor="sect-4.3" numbered="true" toc="default">
>
Figure 7 shows the header-based non-IP encapsulation format. Here,
"UDP Tunnelling" is configured at the MX adaptation layer. The
ports for "UDP Tunnelling" at Client are chosen from the Dynamic
Port range, and the ports for "UDP Tunnelling" at Multi-Access
Gateway are configured and provided to Client through additional
control messages, e.g., <xref target="MAMS"/>.</t>
<t> <name>Header-Based Non-IP Encapsulation</name>
"TTL", "FSL", and "Next Header" are no longer needed, and MUST not <t>
<xref target="Fig7"/> shows the header-based non-IP encapsulation format. Her
e,
"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., <xref target="RFC8743" format="default"/>.</t>
<t>
"TTL", "FSL", and "Next Header" are no longer needed and <bcp14>MUST</bcp14>
not
be included. Moreover, the IP header fields of the GMA SDU remain be included. Moreover, the IP header fields of the GMA SDU remain
unchanged.</t> unchanged.</t>
<figure anchor="Fig7">
<figure title="GMA PDU Format with Non-IP Encapsulation" anchor="Fig7"><a <name>GMA PDU Format with Non-IP Encapsulation</name>
rtwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
|<------- GMA SDU------------>| |<------- GMA SDU------------>|
|<------------------- GMA PDU------------>| |<------------------- GMA PDU------------>|
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="default">
<section title="IP Protocol Identifier" anchor="sect-4.4"><t> <name>IP Protocol Identifier</name>
As described in <xref target="sect-4.1"/>, IP encapsulated GMA PDUs are <t>
indicated using the IP Protocol Type 114. This is designated and As described in <xref target="sect-4.1" format="default"/>, IP-encapsulated G
recorded by IANA <xref target="IANA"/> to indicate "any 0-Hop Protocol". No MA PDUs are
indicated using the IP protocol type 114. This is designated and
recorded by IANA <xref target="IANA" format="default"/> to indicate "any 0-Ho
p Protocol". No
reference is given in the IANA registry for the definition of this reference is given in the IANA registry for the definition of this
Protocol Type, and IANA has no record of why the assignment was protocol type, and IANA has no record of why the assignment was
made or how it is used, although it was probably assigned before made or how it is used, although it was probably assigned before
1999 <xref target="IANA1999"/>.</t> 1999 <xref target="IANA1999" format="default"/>.</t>
<t>
<t> There is some risk associated with "reusing" protocol type 114
There is some risk associated with "re-using" Protocol Type 114
because there may be implementations of other protocols also using because there may be implementations of other protocols also using
this Protocol Type. However, because the protocol described in this protocol type. However, because the protocol described in
this document is used only between adjacent devices specifically this document is used only between adjacent devices specifically
configured for this purpose, the use of Protocol Type 114 should configured for this purpose, the use of protocol type 114 should
be safe.</t> be safe.</t>
<t>
<t> As described in <xref target="sect-1.1" format="default"/>, one of the purpos
As described in <xref target="sect-1.1"/>, one of the purposes of the experim es of the experiment
ent
described in this document is to verify the safety of using this described in this document is to verify the safety of using this
Protocol Type. Deployments should be aware of the risk of a clash protocol type. Deployments should be aware of the risk of a clash
with other uses of this Protocol Type.</t> with other uses of this protocol type.</t>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
</section> <name>Fragmentation</name>
<t>
<section title="Fragmentation" anchor="sect-5"><t> If the MTU size of the anchor connection (for GMA SDU) is configured such
If the MTU size of the anchor connection (for GMA SDU) is that the corresponding GMA PDU length adding the GMA header (or trailer)
configured such that the corresponding GMA PDU length adding GMA and other overhead (UDP tunneling) <bcp14>MAY</bcp14> exceed the MTU of a
header (or trailer) and other overhead (UDP tunneling) MAY exceed delivery connection, GMA endpoints <bcp14>MUST</bcp14> be configured to
the MTU of a delivery connection, GMA endpoints MUST be configured support fragmentation through additional control messages <xref
to support fragmentation through additional control messages target="RFC8743" format="default"/>.</t>
<xref target="MAMS"/>.</t> <t>
<t>
The fragmentation procedure at the convergence sublayer is similar The fragmentation procedure at the convergence sublayer is similar
to IP fragmentation <xref target="RFC0791"/> in principle, but with the follo wing to IP fragmentation <xref target="RFC0791" format="default"/> in principle, b ut with the following
two differences for less overhead:</t> two differences for less overhead:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The fragment offset field is expressed in number of fragments.</li>
<li>The maximum number of fragments per SDU is 2<sup>7</sup> (=128).</li
<t>The fragment offset field is expressed in number of fragments</t> >
</ul>
<t>The maximum number of fragments per SDU is 2^7 (=128)</t> <t>
</list>
</t>
<t>
The Fragmentation Control (FC) field in the GMA trailer (or The Fragmentation Control (FC) field in the GMA trailer (or
header) contains the following bits:</t> header) contains the following bits:</t>
<t><list style="symbols"> <dl>
<dt>Bit 7:</dt><dd> a More Fragment (MF) flag to indicate if the fragmen
<t>Bit #7: a More Fragment (MF) flag to indicate if the fragment t
is the last one (0) or not (1)</t> is the last one (0) or not (1)</dd>
<dt>Bit 0-6:</dt><dd> Fragment Offset (in units of fragments) to specify
<t>Bit #0~#6: Fragment Offset (in units of fragments) to specify
the offset of a particular fragment relative to the beginning the offset of a particular fragment relative to the beginning
of the SDU</t> of the SDU</dd>
</dl>
</list> <t>
</t>
<t>
A PDU carries a whole SDU without fragmentation if the FC field is 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. 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> Otherwise, the PDU contains a fragment of the SDU.</t>
<t>
<t>
The Flow SN field in the trailer is used to distinguish the The Flow SN field in the trailer is used to distinguish the
fragments of one SDU from those of another. The Fragment Offset fragments of one SDU from those of another. The Fragment Offset
(FO) field tells the receiver the position of a fragment in the (FO) field tells the receiver the position of a fragment in the
original SDU. The More Fragment (MF) flag indicates the last original SDU. The More Fragment (MF) flag indicates the last
fragment.</t> fragment.</t>
<t>
<t> To fragment a long SDU, the transmitter creates n PDUs and copies the
To fragment a long SDU, the transmitter creates n PDUs and copies content of the IP header fields from the long PDU into the IP header of all
the content of the IP header fields from the long PDU into the IP the PDUs. The length field in the IP header of the PDU
header of all the PDUs. The length field in the IP header of PDU <bcp14>SHOULD</bcp14> be changed to the length of the PDU, and the protocol
SHOULD be changed to the length of the PDU, and the protocol type type <bcp14>SHOULD</bcp14> be changed to 114.</t>
SHOULD be changed to 114.</t> <t>
<t>
The data of the long SDU is divided into n portions based on the 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 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 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 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 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> set to "1" otherwise. The FO field is set to i-1.</t>
<t>
<t> To assemble the fragments of an SDU, the receiver combines PDUs
To assemble the fragments of a SDU, the receiver combines PDUs
that all have the same Flow SN. The combination is done by placing that all have the same Flow SN. The combination is done by placing
the data portion of each fragment in the relative order indicated the data portion of each fragment in the relative order indicated
by the Fragment Offset in that fragment's GMA trailer (or header). 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 first fragment will have the Fragment Offset set to "0", and
the last fragment will have the More-Fragments flag set to "0".</t> the last fragment will have the More Fragment flag set to "0".</t>
<t>
<t>
GMA fragmentation operates above the IP layer of individual access GMA fragmentation operates above the IP layer of individual access
connection (Wi-Fi, LTE) and between the two end points of connection (Wi-Fi, LTE) and between the two endpoints of convergence
convergence layer. The convergence layer end points (client, layer. The convergence layer endpoints (client, Multi-access Gateway)
multi-access gateway) SHOULD obtain the MTU of individual <bcp14>SHOULD</bcp14> obtain the MTU of individual connection through
connection through either manual configuration or implementing either manual configuration or implementing Path MTU Discovery (PMTUD) as
PMTUD as suggested in <xref target="RFC8900"/>.</t> suggested in <xref target="RFC8900" format="default"/>.</t>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>Concatenation</name>
<section title="Concatenation" anchor="sect-6"><t> <t>
The convergence sublayer MAY support concatenation if a delivery The convergence sublayer <bcp14>MAY</bcp14> support concatenation if a delive
ry
connection has a larger maximum transmission unit (MTU) than the connection has a larger maximum transmission unit (MTU) than the
original IP packet (SDU). Only the SDUs with the same client IP original IP packet (SDU). Only the SDUs with the same client IP
address, and the same Flow ID MAY be concatenated.</t> address and the same Flow ID <bcp14>MAY</bcp14> be concatenated.</t>
<t>
<t> If the (trailer- or header-based) IP encapsulation method is used,
If the (trailer or header based) IP encapsulation method is used, the First SDU Length (FSL) field <bcp14>SHOULD</bcp14> be included in the GMA
the First SDU Length (FSL) field SHOULD be included in the GMA
trailer (or header) to indicate the length of the first SDU. trailer (or header) to indicate the length of the first SDU.
Otherwise, the FSL field SHOULD not be included.</t> Otherwise, the FSL field <bcp14>SHOULD</bcp14> not be included.</t>
<figure anchor="Fig8">
<figure title="Example of GMA PDU Format with Concatenation and Trailer-based <name>Example of GMA PDU Format with Concatenation and Trailer-Based IP
IP Encapsulation" anchor="Fig8"> Encapsulation</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
To concatenate two or more SDUs, the transmitter creates one PDU To concatenate two or more SDUs, the transmitter creates one PDU
and copies the content of the IP header field from the first SDU 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 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 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 is then placed in the second portion of the data of the PDU
(Figure 8). The procedure continues till the PDU size reaches the (<xref target="Fig8"/>). The procedure continues until the PDU size reaches t he
MTU of the delivery connection. If the FSL field is present, 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 IP Length field of the PDU <bcp14>SHOULD</bcp14> be updated to include all
concatenated SDUs and the trailer (or header), and the IP checksum concatenated SDUs and the trailer (or header), and the IP checksum
field SHOULD be recalculated if the packet is IPv4.</t> field <bcp14>SHOULD</bcp14> be recalculated if the packet is IPv4.</t>
<t>
<t> To disaggregate a PDU, if the (header- or trailer-based) IP
To disaggregate a PDU, if the (header or trailer based) IP
encapsulation method is used, the receiver first obtains the encapsulation method is used, the receiver first obtains the
length of the first SDU from the FSL field and decodes the first 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 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 on the length field in the second SDU IP header and decodes the
second SDU. The procedure continues till no byte is left in 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 PDU. If the non-IP encapsulation method (<xref target="Fig7"/>) is used, the
IP
header of the first SDU will not change during the encapsulation header of the first SDU will not change during the encapsulation
process, and the receiver SHOULD obtain the length of the first process, and the receiver <bcp14>SHOULD</bcp14> obtain the length of the firs
SDU directly from its IP header (Figure 9).</t> t
SDU directly from its IP header (<xref target="Fig9"/>).</t>
<figure title="Example of GMA PDU Format with Concatenation and Header-based <figure anchor="Fig9">
Non-IP (UDP) Encapsulation" anchor="Fig9"> <name>Example of GMA PDU Format with Concatenation and Header-Based Non-
<artwork><![CDATA[ IP (UDP) Encapsulation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|<-------1st GMA SDU------------ |<-------1st GMA SDU------------
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP hdr | IP payload | | IP hdr | IP payload |
+-------------------------------------------+ +-------------------------------------------+
-------->|<-------2nd GMA SDU---------------> -------->|<-------2nd GMA SDU--------------->
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
If a PDU contains multiple SDUs, the Flow SN field is for the last If a PDU contains multiple SDUs, the Flow SN field is for the last
SDU, and the Flow SN of other SDU carried by the same PDU can be 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 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, 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.</t> and 6 for the first, second, and last SDU, respectively.</t>
<t>
<t>
GMA concatenation can be used for packing small packets of a GMA concatenation can be used for packing small packets of a
single application, e.g., TCP ACKs, or from multiple applications. single application, e.g., TCP ACKs, or from multiple applications.
Notice that a single GMA flow may carry multiple application flows Notice that a single GMA flow may carry multiple application flows
(TCP, UDP, etc.).</t> (TCP, UDP, etc.).</t>
<t>
GMA endpoints <bcp14>MUST NOT</bcp14> perform concatenation and
fragmentation in a single PDU. If a GMA PDU carries a fragmented SDU, it
<bcp14>MUST NOT</bcp14> carry any other (fragmented or whole) SDU.</t>
</section>
<section 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- 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.</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.)
<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, it may be
desirable to terminate the GMA operation at the firewall.</t>
<t>
Local-only packet leak prevention (HL=0, TTL=1) <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 that could use the same IP protocol
type, i.e., 114.</t>
</section>
<section anchor="sect-8" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.
</t>
</section>
</middle>
<back>
<t> <displayreference target="RFC2890" to="GRE1"/>
GMA endpoint MUST NOT perform concatenation and fragmentation in a <displayreference target="RFC8157" to="GRE2"/>
single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT <displayreference target="I-D.zhu-intarea-gma-control" to="GMAC"/>
carry any other (fragmented or whole) SDU.</t>
</section>
<section title="Security Considerations" anchor="sect-7"><t>
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.</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 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.</t>
<t>
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 which could use the
same IP protocol type, i.e. 114.</t>
</section>
<section title="IANA Considerations" anchor="sect-8"><t>
This document makes no requests of IANA</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>
</references>
<references title="Informative References">
<reference anchor="MAMS" target="https://www.rfc-editor.org/info/rfc8743" <displayreference target="RFC8743" to="MAMS"/>
><front>
<title>Multiple Access Management Services Multi-Access Management Servic
es (MAMS)</title>
<author initials="S." surname="Kanugovi" fullname="S. Kanugovi">
</author>
<author initials="F." surname="Baboescu" fullname="F. Baboescu"> <references>
</author> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8157.xml"/>
<author initials="J." surname="Zhu" fullname="J. Zhu"> </references>
</author> <references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8743.xml"/>
<author initials="S." surname="Seo" fullname="S. Seo"> <reference anchor="IANA" target="https://www.iana.org/assignments/protoc
ol-numbers">
<front>
<title>Protocol Numbers
</title>
<author>
<organization>IANA</organization>
</author> </author>
</front>
</reference>
<date month="March" year="2020"/> <reference anchor="LWIPEP" target="https://portal.3gpp.org/desktopmodules/Spe
</front> cifications/SpecificationDetails.aspx?specificationId=3037">
<front>
<seriesInfo name="RFC" value="8743"/> <title>Evolved Universal Terrestrial Radio Access (E-UTRA);
<seriesInfo name="DOI" value="10.17487/RFC8743"/> LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP)
</reference> encapsulation; Protocol specification
<reference anchor="IANA" target="https://www.iana.org/assignments/protoco </title>
l-numbers/protocol-numbers.xhtml"><front> <author>
<title/> <organization>3GPP</organization>
<author> </author>
</author> <date month="July" year="2020"/>
</front>
<seriesInfo name="3GPP TS" value="36.361"/>
<refcontent>Release 13</refcontent>
</reference>
<date/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</front> C.0791.xml"/>
<reference anchor="ATSSS" target="https://portal.3gpp.org/desktopmodules/Specif
ications/SpecificationDetails.aspx?specificationId=3254">
<front>
<title>Study on access traffic steering, switch and splitting
support in the 5G 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> </reference>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
draft-zhu-intarea-gma-14-manual.txt(762): Warning: Failed parsing a reference C.8900.xml"/>
.
Are all elements separated by commas (not periods, not just spaces)?:
[LWIPEP] 3GPP TS 36.361, "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 on access traffic steering, switch
and splitting support in the 5G system architecture.
-->
&RFC8900; <reference anchor="IANA1999" quote-title="false" target="https://web.ar
<reference anchor="IANA1999" target="https://web.archive.org/web/19990203 chive.org/web/19990203044112/http://www.isi.edu:80/in-notes/iana/assignments/pro
044112/http://www"><front> tocol-numbers">
<title/> <front>
<author> <title>Wayback Machine archive of "Protocol Numbers"
</title>
<author>
<organization>IANA
</organization>
</author> </author>
<date month="February" year="1999"/>
</front>
</reference>
<date/> <reference anchor="GCC"
</front> target="https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02" derivedAn
chor="Google-GCC">
</reference> <front>
<title>A Google Congestion Control Algorithm for Real-Time Communica
&I-D.ietf-rmcat-gcc; tion</title>
<author initials="S" surname="Holmer" fullname="Stefan Holmer">
<!-- <organization showOnFrontPage="true"/>
draft-zhu-intarea-gma-14-manual.txt(786): Warning: Failed parsing a reference </author>
. <author initials="H" surname="Lundin" fullname="Henrik Lundin">
Are all elements separated by commas (not periods, not just spaces)?: <organization showOnFrontPage="true"/>
[MPIP] L. Sun, et al. Multipath IP Routing on End Devices: Motivation, </author>
Design, and Performance, https://eeweb.engineering.nyu.edu/faculty/ <author initials="G" surname="Carlucci" fullname="Gaetano Carlucci">
yongliu/docs/MPIP_Tech.pdf <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>
&I-D.zhu-intarea-gma-control; <reference anchor="MPIP" target="https://eeweb.engineering.nyu.edu/faculty/yon
gliu/docs/MPIP_Tech.pdf">
<front>
<title>Multipath IP Routing on End Devices: Motivation, Design,
and 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>
</references> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
</back> zhu-intarea-gma-control.xml"/>
</references>
</references>
</rfc> </back>
</rfc>
 End of changes. 99 change blocks. 
756 lines changed or deleted 708 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/