rfc9188.original   rfc9188.txt 
Network Working Group J. Zhu
Internet Draft Intel
Intended status: Experimental S. Kanugovi
Expires: May 24,2022 Nokia
November 24, 2021
Generic Multi-Access (GMA) Encapsulation Protocol Independent Submission J. Zhu
draft-zhu-intarea-gma-14 Request for Comments: 9188 Intel
Category: Experimental S. Kanugovi
ISSN: 2070-1721 Nokia
February 2022
Generic Multi-Access (GMA) Encapsulation Protocol
Abstract Abstract
A device can be simultaneously connected to multiple networks, A device can be simultaneously connected to multiple networks, e.g.,
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the
combine the connectivity over these networks below the transport connectivity over these networks below the transport layer (L4) to
layer (L4) to improve quality of experience for applications that improve the quality of experience for applications that do not have
do not have built in multi-path capabilities. Such optimization built-in multi-path capabilities. Such optimization requires
requires additional control information, e.g., a sequence number, additional control information, e.g., a sequence number, in each
in each packet. This document presents a new light weight and packet. This document presents a new lightweight and flexible
flexible encapsulation protocol for this need. The solution has encapsulation protocol for this need. The solution has been
been developed by the authors based on their experiences in developed by the authors based on their experiences in multiple
multiple standards bodies including the IETF and 3GPP, is not an standards bodies including the IETF and 3GPP. However, this document
Internet Standard and does not represent the consensus opinion of is not an Internet Standard and does not represent the consensus
the IETF. This document will enable other developers to build opinion of the IETF. This document will enable other developers to
interoperable implementations in order to experiment with the build interoperable implementations in order to experiment with the
protocol. protocol.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document is not an Internet Standards Track specification; it is
months and may be updated, replaced, or obsoleted by other published for examination, experimental implementation, and
documents at any time. It is inappropriate to use Internet-Drafts evaluation.
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/ietf/1id-abstracts.txt community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
This Internet-Draft will expire on May 24, 2022. https://www.rfc-editor.org/info/rfc9188.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document.
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 2 1. Introduction
1.1. Scope of Experiment ....................................4 1.1. Scope of Experiment
2. Conventions used in this document ............................ 5 2. Conventions Used in This Document
3. Use Case ..................................................... 5 3. Use Case
4. GMA Encapsulation Methods .................................... 7 4. GMA Encapsulation Methods
4.1. Trailer-based IP Encapsulation .........................8 4.1. Trailer-Based IP Encapsulation
4.2. Header-based IP Encapsulation .........................11 4.2. Header-Based IP Encapsulation
4.3. (Header-based) non-IP Encapsulation ...................11 4.3. Header-Based Non-IP Encapsulation
4.4. IP Protocol Identifier ................................12 4.4. IP Protocol Identifier
5. Fragmentation ............................................... 12 5. Fragmentation
6. Concatenation ............................................... 14 6. Concatenation
7. Security Considerations ..................................... 15 7. Security Considerations
8. IANA Considerations ......................................... 15 8. IANA Considerations
9. References .................................................. 16 9. References
9.1. Normative References ..................................16 9.1. Normative References
9.2. Informative References ................................16 9.2. Informative References
Authors' Addresses
1. Introduction 1. Introduction
A device can be simultaneously connected to multiple networks, A device can be simultaneously connected to multiple networks, e.g.,
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the
combine the connectivity over these networks below the transport connectivity over these networks below the transport layer (L4) to
layer (L4) to improve quality of experience for applications that improve the quality of experience for applications that do not have
do not have built in multi-path capabilities. built-in multi-path capabilities.
Figure 1 shows the Multi-Access Management Service (MAMS) user- Figure 1 shows the Multi-Access Management Service (MAMS) user-plane
plane protocol stack [MAMS], which has been used in today's multi- protocol stack [MAMS], which has been used in today's multi-access
access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. It consists of solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. It consists of two layers:
two layers: convergence and adaptation. convergence and adaptation.
The convergence layer is responsible for multi-access operations, The convergence layer is responsible for multi-access operations,
including multi-link (path) aggregation, splitting/reordering, including multi-link (path) aggregation, splitting/reordering,
lossless switching/retransmission, fragmentation, concatenation, lossless switching/retransmission, fragmentation, concatenation, etc.
etc. It operates on top of the adaptation layer in the protocol It operates on top of the adaptation layer in the protocol stack.
stack. From the perspective of a transmitter, a User Payload From the perspective of a transmitter, a User Payload (e.g., IP
(e.g., IP packet) is processed by the convergence layer first, and packet) is processed by the convergence layer first and then by the
then by the adaptation layer before being transported over a adaptation layer before being transported over a delivery connection;
delivery connection; from the receiver's perspective, an IP packet from the receiver's perspective, an IP packet received over a
received over a delivery connection is processed by the adaptation delivery connection is processed by the adaptation layer first and
layer first, and then by the convergence layer. then by the convergence layer.
+-----------------------------------------------------+ +-----------------------------------------------------+
| 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 |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 1: MAMS User-Plane Protocol Stack [MAMS] Figure 1: MAMS User-Plane Protocol Stack
GRE (Generic Routing Encapsulation) can be used [LWIPEP] [GRE1] GRE (Generic Routing Encapsulation) [LWIPEP] [GRE1] [GRE2] can be
[GRE2] as the encapsulation protocol at the convergence layer to used as the encapsulation protocol at the convergence layer to encode
encode additional control information, e.g., Key, Sequence Number. additional control information, e.g., key and sequence number.
However, there are two main drawbacks with this approach: However, there are two main drawbacks with this approach:
o It is difficult to introduce new control fields because the * It is difficult to introduce new control fields because the GRE
GRE header formats are already defined, header formats are already defined, and
o IP-over-IP tunnelling (required for GRE) leads to higher
overhead especially for small packet.
For example, the overhead of IP-over-IP/GRE tunnelling with both * IP-over-IP tunneling (required for GRE) leads to higher overhead
Key and Sequence Number is 32 Bytes (20 Bytes IP header + 12 Bytes especially for small packets.
GRE header), which is 80% of a 40 Bytes TCP ACK packet.
This document presents a light-weight GMA (Generic Multi-Access) For example, the overhead of IP-over-IP/GRE tunneling with both key
encapsulation protocol for the convergence layer. It supports and sequence Number is 32 bytes (20-byte IP header + 12-byte GRE
three encapsulation methods: trailer-based IP encapsulation, header), which is 80% of a 40-byte TCP ACK packet.
header-based IP encapsulation, and non-IP encapsulation.
Particularly, the IP encapsulation methods avoid IP-over-IP This document presents a lightweight Generic Multi-Access (GMA)
tunneling overhead (20 Bytes), which is 50% of a 40 Bytes TCP ACK encapsulation protocol for the convergence layer. It supports three
packet. Moreover, it introduces new control fields to support encapsulation methods: trailer-based IP encapsulation, header-based
fragmentation and concatenation, which are not available in GRE- IP encapsulation, and non-IP encapsulation. Particularly, the IP
based solutions [LWIPEP] [GRE1] [GRE2]. encapsulation methods avoid IP-over-IP tunneling overhead (20 bytes),
which is 50% of a 40-byte TCP ACK packet. Moreover, it introduces
new control fields to support fragmentation and concatenation, which
are not available in GRE-based solutions [LWIPEP] [GRE1] [GRE2].
The GMA protocol only operates between endpoints that have been The GMA protocol only operates between endpoints that have been
configured to use GMA. This configuration can be through any configured to use GMA. This configuration can be through any control
control messages and procedures, including, for example, Multi- messages and procedures, including, for example, Multi-Access
Access Management Services [MAMS]. Moreover, UDP or IPSec Management Services [MAMS]. Moreover, UDP or IPsec tunneling can be
tunneling can be used at the adaptation sublayer to protect GMA used at the adaptation sublayer to protect GMA operation from
operation from intermediate nodes. intermediate nodes.
The solution described in this document was been developed by the The solution described in this document was developed by the authors
authors based on their experiences in multiple standards bodies based on their experiences in multiple standards bodies including the
including the IETF and 3GPP. However, it is not an Internet IETF and 3GPP. However, this document is not an Internet Standard
Standard and does not represent the consensus opinion of the IETF. and does not represent the consensus opinion of the IETF. This
This document presents the protocol specification to enable document presents the protocol specification to enable
experimentation as described in Section 1.1 and to facilitate experimentation as described in Section 1.1 and to facilitate other
other interoperable implementations. interoperable implementations.
1.1. Scope of Experiment 1.1. Scope of Experiment
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. deployment.
Section 4 describes three possible encapsulation methods that are Section 4 describes three possible encapsulation methods that are
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,
example, all implementations are able to support the main all implementations are able to support the main "trailer-based" IP
"trailer-based" IP encapsulation method. Similarly, the experiment encapsulation method. Similarly, the experiment will investigate the
will investigate the relative merits of the IP and non-IP relative merits of the IP and non-IP encapsulation methods.
encapsulation methods.
It is expected that this protocol experiment can be conducted on It is expected that this protocol experiment can be conducted on the
the Internet since the GMA packets are identified by an IP Internet since the GMA packets are identified by an IP protocol
protocol number and the protocol is intended for single hop number and the protocol is intended for single-hop propagation;
propagation: devices should not be forwarding packet and if they devices should not be forwarding packets, and if they do, they will
do they will not need to examine the payload, while destination not need to examine the payload, while destination systems that do
systems that do not support this protocol should not receive such not support this protocol should not receive such packets and will
packets and will handle them as unknown payloads according to handle them as unknown payloads according to normal IP processing.
normal IP processing. Thus, experimentation is conducted between Thus, experimentation is conducted between consenting end systems
consenting end systems that have been mutually configured to that have been mutually configured to participate in the experiment
participate in the experiment as described in Section 7. as described in Section 7.
Note that this experiment "re-uses" the IP protocol identifier 114 Note that this experiment "reuses" the IP protocol identifier 114 as
as described in Section 4.4. Part of this experiment is to assess described in Section 4.4. Part of this experiment is to assess the
the safety of doing this. The experiment should consider the safety of doing this. The experiment should consider the following
following safety mechanisms: safety mechanisms:
o GMA endpoints SHOULD detect non-GMA IP packets that also use * GMA endpoints SHOULD detect non-GMA IP packets that also use 114
114 and log an error to report the situation (although such and log an error to report the situation (although such error
error logging MUST be subject to rate limits). logging MUST be subject to rate limits).
o 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.
The experiment SHOULD use packet tracing tool, e.g., WireShark, * GMA endpoints SHOULD stop using 114 and switch to non-IP
TCPDUMP, to monitor both ingress and egress traffic at GMA encapsulation, i.e., UDP encapsulation (Figure 7), after detecting
endpoints and ensure the above safety mechanisms are implemented. any non-GMA usage of 114.
Path quality measurements (one-way-delay, loss, etc.) and The experiment SHOULD use a packet tracing tool, e.g., WireShark or
congestion detection are performed by receiver based on the GMA TCPDUMP, to monitor both ingress and egress traffic at GMA endpoints
control fields, e.g., sequence number, timestamp, etc. Receiver and ensure the above safety mechanisms are implemented.
will then dynamically control how to split or steer traffic over
multiple delivery connections accordingly. GMA control protocol
[GMAC] MAY be used for signaling between GMA endpoints. Another
objective of the experiment is to evaluate the usage of various
receiver-based algorithms [GCC] [MPIP] in multi-path traffic
management, and the impact on the e2e performance (throughput,
delay, etc.) of higher layer (transport) protocols, e.g., TCP,
QUIC, WebRTC, etc.
The authors will continually assess the progress of this Path quality measurements (one-way delay, loss, etc.) and congestion
experiment and encourage other implementers to contact them to detection are performed by the receiver based on the GMA control
report the status of their implementations and their experiences fields, e.g., Sequence Number, Timestamp, etc. The receiver will
with the protocol. then dynamically control how to split or steer traffic over multiple
delivery connections accordingly. The GMA control protocol [GMAC]
MAY be used for signaling between GMA endpoints. Another objective
of the experiment is to evaluate the usage of various receiver-based
algorithms [GCC] [MPIP] in multi-path traffic management and the
impact on the End-to-End (E2E) performance (throughput, delay, etc.)
of higher-layer (transport) protocols, e.g., TCP, QUIC, WebRTC, etc.
2. Conventions used in this document 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 2. Conventions Used in This Document
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
3. Use Case The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
As shown in Figure 2, a client device (e.g., Smartphone, Laptop, 3. Use Case
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 client and Multi-
Access Gateway for multi-access optimizations.
Multi-Access Aggregation As shown in Figure 2, a client device (e.g., smartphone, laptop,
etc.) may connect to the Internet via both Wi-Fi and LTE connections,
one of which (e.g., LTE) may operate as the anchor connection, and
the other (e.g., Wi-Fi) may operate as the delivery connection. The
anchor connection provides the IP address and connectivity for end-
to-end Internet access, and the delivery connection provides an
additional path between the client and Multi-Access Gateway for
multi-access optimizations.
Multi-Access Aggregation
+---+ +---+ +---+ +---+
| |A|--- LTE Connection -----|C| | | |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
A: The adaptation layer endpoint of the LTE connection Figure 2: GMA-Based Multi-Access Aggregation
resides in the client
B: The adaptation layer endpoint of the Wi-Fi connection A: The adaptation-layer endpoint of the LTE connection resides in
resides in the client the client.
C: The adaptation layer endpoint of the LTE connection B: The adaptation-layer endpoint of the Wi-Fi connection resides in
resides in the Multi-Access Gateway, aka N-MADP (Network the client.
Multi-Access Data Proxy) in [MAMS]
D: The adaptation layer endpoint of the Wi-Fi connection C: The adaptation-layer endpoint of the LTE connection resides in
resides in the Multi-Access Gateway the Multi-Access Gateway, aka N-MADP (Network Multi-Access Data
Proxy) in [MAMS].
U: The convergence layer endpoint resides in the client D: The adaptation-layer endpoint of the Wi-Fi connection resides in
the Multi-Access Gateway.
S: The convergence layer endpoint resides in the Multi- U: The convergence-layer endpoint resides in the client.
Access Gateway
Figure 2: GMA-based Multi-Access Aggregation S: The convergence-layer endpoint resides in the Multi-Access
Gateway.
For example, per-packet aggregation allows a single IP flow to use For example, per-packet aggregation allows a single IP flow to use
the combined bandwidth of the two connections. In another example, the combined bandwidth of the two connections. In another example,
packets lost due to a temporarily link outage may be packets lost due to a temporary link outage may be retransmitted.
retransmitted. Moreover, packets may be duplicated over multiple Moreover, packets may be duplicated over multiple connections to
connections to achieve high reliability and low latency, where achieve high reliability and low latency, where duplicated packets
duplicated packets are eliminated by the receiving side. Such are eliminated by the receiving side. Such multi-access optimization
multi-access optimization requires additional control information, requires additional control information, e.g., a sequence number, in
e.g., a sequence number, in each packet, which can be supported by each packet, which can be supported by the GMA encapsulation protocol
the GMA encapsulation protocol described in this document. described in this document.
The GMA protocol described in this document is designed for The GMA protocol described in this document is designed for multiple
multiple connections, but it may also be used when there is only connections, but it may also be used when there is only one
one connection between two endpoints. For example, it may be used connection between two endpoints. For example, it may be used for
for loss detection and recovery. In another example, it may be loss detection and recovery. In another example, it may be used to
used to concatenate multiple small packets and reduce per packet concatenate multiple small packets and reduce per-packet overhead.
overhead.
4. GMA Encapsulation Methods 4. GMA Encapsulation Methods
The GMA encapsulation protocol supports the following three The GMA encapsulation protocol supports the following three methods:
methods:
o Trailer-based IP Encapsulation (4.1) * Trailer-based IP Encapsulation (Section 4.1)
o Header-based IP Encapsulation (4.2)
o (Header-based) non-IP Encapsulation (4.3)
Non-IP encapsulation MUST be used if the original IP packet is * Header-based IP Encapsulation (Section 4.2)
IPv6.
Trailer-based IP encapsulation MUST be used if it is supported by * Header-based non-IP Encapsulation (Section 4.3)
GMA endpoints and the original IP packet is IPv4.
Header-based encapsulation MUST be used if the trailer-based Non-IP encapsulation MUST be used if the original IP packet is IPv6.
method is not supported by either Client or Multi-Access Gateway.
In this case, if the adaptation layer, e.g., UDP tunnelling,
supports non-IP packet format, non-IP encapsulation MUST be used;
otherwise, header-based IP encapsulation MUST be used.
If non-IP encapsulation is configured, a GMA header MUST be Trailer-based IP encapsulation MUST be used if it is supported by GMA
present in every packet. In comparison, if IP encapsulation is endpoints and the original IP packet is IPv4.
configured, a GMA header or trailer may be added dynamically on
per-packet basis, and it indicates the presence of GMA header (or
trailer) to set the protocol type of the GMA PDU to "114" (see
Section 4.4).
The GMA endpoints MAY configure the GMA encapsulation method Header-based encapsulation MUST be used if the trailer-based method
through control signalling or pre-configuration. For example, the is not supported by either the client or Multi-Access Gateway. In
"MX UP Setup Configuration Request" message as specified in Multi- this case, if the adaptation layer, e.g., UDP tunneling, supports
Access Management Service [MAMS] includes "MX Convergence Method non-IP packet format, non-IP encapsulation MUST be used; otherwise,
Parameters", which provides the list of parameters to configure header-based IP encapsulation MUST be used.
the convergence layer, and can be extended to indicate the GMA
If non-IP encapsulation is configured, a GMA header MUST be present
in every packet. In comparison, if IP encapsulation is configured, a
GMA header or trailer may be added dynamically on a per-packet basis,
and it indicates the presence of a GMA header (or trailer) to set the
protocol type of the GMA PDU to "114" (see Section 4.4).
The GMA endpoints MAY configure the GMA encapsulation method through
control signaling or pre-configuration. For example, the "MX UP
Setup Configuration Request" message as specified in Multi-Access
Management Service [MAMS] includes "MX Convergence Method
Parameters", which provides the list of parameters to configure the
convergence layer, and can be extended to indicate the GMA
encapsulation method. encapsulation method.
GMA endpoint MUST discard a received packet and MAY log an error GMA endpoint MUST discard a received packet and MAY log an error to
to report the situation (although such error logging MUST be report the situation (although such error logging MUST be subject to
subject to rate limits) under any of the following conditions: rate limits) under any of the following conditions:
. the GMA version number in the GMA header (or trailer) is not * The GMA version number in the GMA header (or trailer) is not
understood or supported by the GMA endpoint understood or supported by the GMA endpoint.
. a Flag bit in the GMA header (or trailer) not understood or
supported by the GMA endpoint is set to "1"
4.1. Trailer-based IP Encapsulation * A flag bit in the GMA header (or trailer) not understood or
supported by the GMA endpoint is set to "1".
4.1. Trailer-Based IP Encapsulation
|<---------------------GMA PDU ----------------------->| |<---------------------GMA PDU ----------------------->|
+------------------------------------------------------+ +------------------------------------------------------+
| IP hdr | IP payload | GMA Trailer | | IP hdr | IP payload | GMA Trailer |
+------------------------------------------------------+ +------------------------------------------------------+
|<------- GMA SDU (user payload)-------->| |<------- GMA SDU (user payload)-------->|
Figure 3: GMA PDU Format with Trailer-based IP Encapsulation Figure 3: GMA PDU Format with Trailer-based IP Encapsulation
This method SHALL NOT be used if the original IP packet (GMA SDU) This method SHALL NOT be used if the original IP packet (GMA service
is IPv6. data unit (GMA SDU)) is IPv6.
Figure 3 shows the trailer-based IP encapsulation GMA PDU Figure 3 shows the trailer-based IP encapsulation GMA protocol data
(protocol data unit) format. A (GMA) PDU may carry one or multiple unit (GMA PDU) format. A (GMA) PDU may carry one or multiple IP
IP packets, aka (GMA) SDUs (service data unit), in the payload, or packets, aka (GMA) SDUs, in the payload, or a fragment of the SDU.
a fragment of the SDU.
The Protocol Type field in the IP header of the GMA PDU MUST be The protocol type field in the IP header of the GMA PDU MUST be
changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to indicate changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to indicate the
the presence of the GMA trailer. presence of the GMA trailer.
The following three IP header fields MUST be changed: The following three IP header fields MUST be changed:
o IP Length: add the length of "GMA Trailer" to the length of IP Length: Add the length of "GMA Trailer" to the length of the
the original IP packet original IP packet.
o Time To Live (TTL): set to "1"
o IP checksum: recalculate after changing "Protocol Type", "TTL"
and "IP Length"
The GMA (Generic Multi-Access) trailer MUST consist of two Time To Live (TTL): Set to "1".
mandatory fields (the last 3 bytes): Next Header and Flags,
defined as follows:
o Next Header (1 Byte): the IP protocol type of the (first) SDU IP checksum: Recalculate after changing "protocol type", "TTL", and
in a PDU, and it stores the value before it was overwritten to "IP Length".
114.
o Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and
Bit 15 is the least significant bit (LSB)
+ Checksum Present (bit 0): If the Checksum Present bit is set
to 1, then the Checksum field is present
+ Concatenation Present (bit 1): If the Concatenation Present
bit is set to 1, then the PDU carries multiple SDUs, and the
First SDU Length field is present
+ Connection ID Present (bit 2): If the Connection ID Present
bit is set to 1, then the Connection ID field is present
+ Flow ID Present (bit 3): If the Flow ID Present bit is set
to 1, then the Flow ID field is present
+ Fragmentation Present (bit 4): If the Fragmentation Present
bit is set to 1, then the PDU carry a fragment of the SDU and
the Fragmentation Control field is present
+ Delivery SN Present (bit 5): If the Delivery SN (Sequence
Number) Present bit is set to 1, then the Delivery SN field is
present and contains the valid information
+ Flow SN Present (bit 6): If the Flow SN Present bit is set
to 1, then the Sequence Number field is present
+ Timestamp Present (bit 7): If the Timestamp Present bit is
set to 1, then the Timestamp field is present
+ TTL Present (bit 8): If the TTL Present bit is set to 1,
then the TTL field is present
+ Reserved (bit 9-12): set to "0" and ignored on receipt
+ Version (bit 13~15): GMA version number, set to 0 for the
GMA encapsulation protocol specified in this document.
The Flags field is at the end of the PDU, and the Next Header The GMA (Generic Multi-Access) trailer MUST consist of two mandatory
field is the second last. The Receiver SHOULD first decode the fields (the last 3 bytes): Next Header and Flags.
Flags field to determine the length of the GMA trailer, and then
decode each optional field accordingly. The GMA (Generic Multi-
Access) trailer MAY consist of the following optional fields:
o Checksum (1 Byte): to contain the (one's complement) checksum This is defined as follows:
sum of all the 8 bits in the trailer. For purposes of
computing the checksum, the value of the checksum field is Next Header (1 byte): This is the IP protocol type of the (first)
zero. This field is present only if the Checksum Present bit SDU in a PDU; it stores the value before it was overwritten to
is set to one. 114.
o First SDU Length (2 Bytes): the length of the first IP packet
in the PDU, only included if a PDU contains multiple IP Flags (2 bytes): Bit 0 is the most significant bit (MSB), and bit 15
packets. This field is present only if the Concatenation is the least significant bit (LSB).
Present bit is set to one.
o Connection ID (1 Byte): an unsigned integer to identify the Checksum Present (bit 0): If the Checksum Present bit is set to
anchor and delivery connection of the GMA PDU. This field is 1, then the Checksum field is present.
present only if the Connection ID Present bit is set to one.
+ Anchor Connection ID (MSB 4 Bits): an unsigned integer to Concatenation Present (bit 1): If the Concatenation Present bit
identify the anchor connection is set to 1, then the PDU carries multiple SDUs, and the First
+ Delivery Connection ID (LSB 4 Bits): an unsigned integer to SDU Length field is present.
identify the delivery connection
o Flow ID (1 Byte): an unsigned integer to identify the IP flow Connection ID Present (bit 2): If the Connection ID Present bit
that a PDU belongs to, for example Data Radio Bearer (DRB) ID is set to 1, then the Connection ID field is present.
[LWIPEP] for a cellular (e.g., LTE) connection. This field is
present only if the Flow ID Present bit is set to one. Flow ID Present (bit 3): If the Flow ID Present bit is set to 1,
o Fragmentation Control (FC) (1 Byte): to provide necessary then the Flow ID field is present.
information for re-assembly, only needed if a PDU carries
fragments. This field is present only if the Fragmentation Fragmentation Present (bit 4): If the Fragmentation Present bit
Present bit is set to one. Please refer to section 5 for its is set to 1, then the PDU carry a fragment of the SDU and the
detailed format and usage. Fragmentation Control field is present.
o Delivery SN (1 Byte): an auto-incremented integer to indicate
the GMA PDU transmission order on a delivery connection. Delivery SN Present (bit 5): If the Delivery SN (Sequence Number)
Delivery SN is needed to measure packet loss of each delivery Present bit is set to 1, then the Delivery SN field is present
connection and therefore generated per delivery connection per and contains the valid information.
flow. This field is present only if the Delivery SN Present
bit is set to one. Flow SN Present (bit 6): If the Flow SN Present bit is set to 1,
o Flow SN (3 Bytes): an auto-incremented integer to indicate the then the Sequence Number field is present.
GMA SDU (IP packet) order of a flow. Flow SN is needed for
retransmission, reordering, and fragmentation. It SHALL be Timestamp Present (bit 7): If the Timestamp Present bit is set to
generated per flow. This field is present only if the Flow SN 1, then the Timestamp field is present.
Present bit is set to one.
o Timestamp (4 Bytes): to contain the current value of the TTL Present (bit 8): If the TTL Present bit is set to 1, then the
timestamp clock of the transmitter in the unit of 1 TTL field is present.
millisecond. This field is present only if the Timestamp
Present bit is set to one. Reserved (bit 9-12): This is set to "0" and ignored on receipt.
o 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 Version (bit 13~15): This is the GMA version number; it is set to
IP header if the GMA SDU is IPv6. This field is present only 0 for the GMA encapsulation protocol specified in this
if the TTL Present bit is set to one. document.
The Flags field is at the end of the PDU, and the Next Header field
is the second last. The receiver SHOULD first decode the Flags field
to determine the length of the GMA trailer and then decode each
optional field accordingly. The Generic Multi-Access (GMA) trailer
MAY consist of the following optional fields:
Checksum (1 byte): This contains the (one's complement) checksum sum
of all 8 bits in the trailer. For purposes of computing the
checksum, the value of the Checksum field is zero. This field is
present only if the Checksum Present bit is set to 1.
First SDU Length (2 bytes): This is the length of the first IP
packet in the PDU, only included if a PDU contains multiple IP
packets. This field is present only if the Concatenation Present
bit is set to 1.
Connection ID (1 byte): This contains an unsigned integer to
identify the anchor and delivery connection of the GMA PDU. This
field is present only if the Connection ID Present bit is set to
1.
Anchor Connection ID (MSB 4 bits): This contains an unsigned
integer to identify the anchor connection.
Delivery Connection ID (LSB 4 bits): This contains an unsigned
integer to identify the delivery connection.
Flow ID (1 byte): This contains an unsigned integer to identify the
IP flow that a PDU belongs to, for example Data Radio Bearer (DRB)
ID [LWIPEP] for a cellular (e.g., LTE) connection. This field is
present only if the Flow ID Present bit is set to 1.
Fragmentation Control (FC) (1 byte): This provides necessary
information for reassembly, only needed if a PDU carries
fragments. This field is present only if the Fragmentation
Present bit is set to 1. Please refer to Section 5 for its
detailed format and usage.
Delivery SN (1 byte): This contains an auto-incremented integer to
indicate the GMA PDU transmission order on a delivery connection.
Delivery SN is needed to measure packet loss of each delivery
connection and therefore generated per delivery connection per
flow. This field is present only if the Delivery SN Present bit
is set to 1.
Flow SN (3 bytes): This contains an auto-incremented integer to
indicate the GMA SDU (IP packet) order of a flow. Flow SN is
needed for retransmission, reordering, and fragmentation. It
SHALL be generated per flow. This field is present only if the
Flow SN Present bit is set to 1.
Timestamp (4 bytes): This contains the current value of the
timestamp clock of the transmitter in the unit of 1 millisecond.
This field is present only if the Timestamp Present bit is set to
1.
TTL (1 byte): This contains the TTL value of the original IP header
if the GMA SDU is IPv4, or the Hop-Limit value of the IP header if
the GMA SDU is IPv6. This field is present only if the TTL
Present bit is set to 1.
Figure 4 shows the GMA trailer format with all the fields present, Figure 4 shows the GMA trailer format with all the fields present,
and the order of the GMA control fields SHALL follow the bit order and the order of the GMA control fields SHALL follow the bit order in
in the Flags field. Note that the bits in the Flags field are the Flags field. Note that the bits in the Flags field are ordered
ordered with the first bit transmitted being bit 0 (MSB). All with the first bit transmitted being bit 0 (MSB). All fields are
fields are transmitted in regular network byte order and appear in transmitted in regular network byte order and appear in reverse order
reverse order to their corresponding flag bits. If a flag bit is to their corresponding flag bits. If a flag bit is clear, the
clear, the corresponding optional field is absent. corresponding optional field is absent.
For example, Bit 0 (the MSB) of the Flags field is the Checksum For example, bit 0 (the MSB) of the Flags field is the Checksum
Present bit, and the Checksum field is the last in the trailer Present bit, and the Checksum field is the last in the trailer with
except of the two mandatory fields. Bit 1 is the Concatenation the exception of the two mandatory fields. Bit 1 is the
present bit, and the FSL field is the second last. Concatenation Present bit, and the FSL field is the second last.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: GMA Trailer Format with all Optional Fields Present Figure 4: GMA Trailer Format with All Optional Fields Present
4.2. Header-based IP Encapsulation 4.2. Header-Based IP Encapsulation
This method SHALL NOT be used if the original IP packet (GMA SDU) This method SHALL NOT be used if the original IP packet (GMA SDU) is
is IPv6. IPv6.
Figure 5 shows the header-based IP encapsulation format. Here, the Figure 5 shows the header-based IP encapsulation format. Here, the
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
and the IP header fields of the GMA PDU MUST be changed the same the IP header fields of the GMA PDU MUST be changed the same way as
way as in trailered-based IP encapsulation. in trailer-based IP encapsulation.
+-----------------------------------------------+ +-----------------------------------------------+
|IP hdr | GMA Header | IP payload | |IP hdr | GMA Header | IP payload |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 5: GMA PDU Format with Header-based IP Encapsulation
Figure 6 shows the GMA header format. In comparison to GMA Figure 5: GMA PDU Format with Header-Based IP Encapsulation
Figure 6 shows the GMA header format. In comparison to the GMA
trailer, the only difference is that the Flags field is now in the trailer, the only difference is that the Flags field is now in the
front so that the Receiver can first decode the Flags field to front so that the receiver can first decode the Flags field to
determine the GMA header length. determine the GMA header length.
"TTL" field MUST be included and the "TTL" bit in the GMA header The "TTL" field MUST be included and the "TTL" bit in the GMA header
(or Trailer) MUST be set to 1 if (Trailer or Header based) IP (or Trailer) MUST be set to 1 if (trailer- or header-based) IP
Encapsulation is used. encapsulation is used.
+------------------------------------------------------+ +------------------------------------------------------+
| Flags | other fields (TTL, Timestamp, Flow SN, etc.) | | Flags | other fields (TTL, Timestamp, Flow SN, etc.) |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 6: GMA Header Format
4.3. (Header-based) non-IP Encapsulation Figure 6: GMA Header Format
Figure 7 shows the header-based non-IP encapsulation format. Here, 4.3. Header-Based Non-IP Encapsulation
"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., [MAMS].
"TTL", "FSL", and "Next Header" are no longer needed, and MUST not Figure 7 shows the header-based non-IP encapsulation format. Here,
be included. Moreover, the IP header fields of the GMA SDU remain "UDP Tunneling" is configured at the MX adaptation layer. The ports
for "UDP Tunneling" at the client are chosen from the Dynamic Port
range, and the ports for "UDP Tunneling" at the Multi-Access Gateway
are configured and provided to the client through additional control
messages, e.g., [MAMS].
"TTL", "FSL", and "Next Header" are no longer needed and MUST not be
included. Moreover, the IP header fields of the GMA SDU remain
unchanged. unchanged.
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| 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------------>|
Figure 7: GMA PDU Format with Non-IP Encapsulation Figure 7: GMA PDU Format with Non-IP Encapsulation
4.4. IP Protocol Identifier 4.4. IP Protocol Identifier
As described in Section 4.1, IP encapsulated GMA PDUs are As described in Section 4.1, IP-encapsulated GMA PDUs are indicated
indicated using the IP Protocol Type 114. This is designated and using the IP protocol type 114. This is designated and recorded by
recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No IANA [IANA] to indicate "any 0-Hop Protocol". No reference is given
reference is given in the IANA registry for the definition of this in the IANA registry for the definition of this protocol type, and
Protocol Type, and IANA has no record of why the assignment was IANA has no record of why the assignment was made or how it is used,
made or how it is used, although it was probably assigned before although it was probably assigned before 1999 [IANA1999].
1999 [IANA1999].
There is some risk associated with "re-using" Protocol Type 114 There is some risk associated with "reusing" 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
this document is used only between adjacent devices specifically 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
be safe. safe.
As described in Section 1.1, one of the purposes of the experiment As described in Section 1.1, one of the purposes of the experiment
described in this document is to verify the safety of using this 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. with other uses of this protocol type.
5. Fragmentation 5. Fragmentation
If the MTU size of the anchor connection (for GMA SDU) is If the MTU size of the anchor connection (for GMA SDU) is configured
configured such that the corresponding GMA PDU length adding GMA such that the corresponding GMA PDU length adding the GMA header (or
header (or trailer) and other overhead (UDP tunneling) MAY exceed trailer) and other overhead (UDP tunneling) MAY exceed the MTU of a
the MTU of a delivery connection, GMA endpoints MUST be configured delivery connection, GMA endpoints MUST be configured to support
to support fragmentation through additional control messages fragmentation through additional control messages [MAMS].
[MAMS].
The fragmentation procedure at the convergence sublayer is similar The fragmentation procedure at the convergence sublayer is similar to
to IP fragmentation [RFC791] in principle, but with the following IP fragmentation [RFC0791] in principle, but with the following two
two differences for less overhead: differences for less overhead:
o The fragment offset field is expressed in number of fragments * The fragment offset field is expressed in number of fragments.
o The maximum number of fragments per SDU is 2^7 (=128)
The Fragmentation Control (FC) field in the GMA trailer (or * The maximum number of fragments per SDU is 2^7 (=128).
header) contains the following bits:
o Bit #7: a More Fragment (MF) flag to indicate if the fragment The Fragmentation Control (FC) field in the GMA trailer (or header)
is the last one (0) or not (1) contains the following bits:
o Bit #0~#6: Fragment Offset (in units of fragments) to specify
the offset of a particular fragment relative to the beginning Bit 7: a More Fragment (MF) flag to indicate if the fragment is the
of the SDU last one (0) or not (1)
Bit 0-6: Fragment Offset (in units of fragments) to specify the
offset of a particular fragment relative to the beginning of the
SDU
A PDU carries a whole SDU without fragmentation if the FC field is 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. Otherwise, the PDU contains a fragment of the SDU.
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
fragments of one SDU from those of another. The Fragment Offset of one SDU from those of another. The Fragment Offset (FO) field
(FO) field tells the receiver the position of a fragment in the tells the receiver the position of a fragment in the original SDU.
original SDU. The More Fragment (MF) flag indicates the last The More Fragment (MF) flag indicates the last fragment.
fragment.
To fragment a long SDU, the transmitter creates n PDUs and copies To fragment a long SDU, the transmitter creates n PDUs and copies the
the content of the IP header fields from the long PDU into the IP content of the IP header fields from the long PDU into the IP header
header of all the PDUs. The length field in the IP header of PDU of all the PDUs. The length field in the IP header of the PDU SHOULD
SHOULD be changed to the length of the PDU, and the protocol type be changed to the length of the PDU, and the protocol type SHOULD be
SHOULD be changed to 114. changed to 114.
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
MTU size of the delivery connection. The first portion of the data size of the delivery connection. The first portion of the data is
is placed in the first PDU. The MF flag is set to "1", and the FO placed in the first PDU. The MF flag is set to "1", and the FO field
field is set to "0". The i-th portion of the data is placed in the is set to "0". The i-th portion of the data is placed in the i-th
i-th PDU. The MF flag is set to "0" if it is the last fragment and PDU. The MF flag is set to "0" if it is the last fragment and set to
set to "1" otherwise. The FO field is set to i-1. "1" otherwise. The FO field is set to i-1.
To assemble the fragments of a SDU, the receiver combines PDUs To assemble the fragments of an SDU, the receiver combines PDUs that
that all have the same Flow SN. The combination is done by placing all have the same Flow SN. The combination is done by placing the
the data portion of each fragment in the relative order indicated data portion of each fragment in the relative order indicated by the
by the Fragment Offset in that fragment's GMA trailer (or header). Fragment Offset in that fragment's GMA trailer (or header). The
The first fragment will have the Fragment Offset set to "0", and first fragment will have the Fragment Offset set to "0", and the last
the last fragment will have the More-Fragments flag set to "0". fragment will have the More Fragment flag set to "0".
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
multi-access gateway) SHOULD obtain the MTU of individual Gateway) SHOULD obtain the MTU of individual connection through
connection through either manual configuration or implementing either manual configuration or implementing Path MTU Discovery
PMTUD as suggested in [RFC8900]. (PMTUD) as suggested in [RFC8900].
6. Concatenation 6. Concatenation
The convergence sublayer MAY support concatenation if a delivery The convergence sublayer MAY support concatenation if a delivery
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. address and the same Flow ID MAY be concatenated.
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 SHOULD 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. Otherwise, the FSL field SHOULD not be included.
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 8: Example of GMA PDU Format with Concatenation and
Trailer-based IP Encapsulation
To concatenate two or more SDUs, the transmitter creates one PDU Figure 8: Example of GMA PDU Format with Concatenation and
and copies the content of the IP header field from the first SDU Trailer-Based IP Encapsulation
into the IP header of the PDU. The data of the first SDU is placed
in the first portion of the data of the PDU. The whole second SDU
is then placed in the second portion of the data of the PDU
(Figure 8). The procedure continues till the PDU size reaches the
MTU of the delivery connection. If the FSL field is present, the
IP length field of the PDU SHOULD be updated to include all
concatenated SDUs and the trailer (or header), and the IP checksum
field SHOULD be recalculated if the packet is IPv4.
To disaggregate a PDU, if the (header or trailer based) IP To concatenate two or more SDUs, the transmitter creates one PDU and
encapsulation method is used, the receiver first obtains the copies the content of the IP header field from the first SDU into the
length of the first SDU from the FSL field and decodes the first IP header of the PDU. The data of the first SDU is placed in the
SDU. The receiver then obtains the length of the second SDU based first portion of the data of the PDU. The whole second SDU is then
on the length field in the second SDU IP header and decodes the placed in the second portion of the data of the PDU (Figure 8). The
second SDU. The procedure continues till no byte is left in the procedure continues until the PDU size reaches the MTU of the
PDU. If the non-IP encapsulation method (Figure 7) is used, the IP delivery connection. If the FSL field is present, the IP Length
header of the first SDU will not change during the encapsulation field of the PDU SHOULD be updated to include all concatenated SDUs
process, and the receiver SHOULD obtain the length of the first and the trailer (or header), and the IP checksum field SHOULD be
SDU directly from its IP header (Figure 9). recalculated if the packet is IPv4.
To disaggregate a PDU, if the (header- or trailer-based) IP
encapsulation method is used, the receiver first obtains the length
of the first SDU from the FSL field and decodes the first SDU. The
receiver then obtains the length of the second SDU based on the
length field in the second SDU IP header and decodes the second SDU.
The procedure continues until no byte is left in the PDU. If the
non-IP encapsulation method (Figure 7) is used, the IP header of the
first SDU will not change during the encapsulation process, and the
receiver SHOULD obtain the length of the first SDU directly from its
IP header (Figure 9).
|<-------1st GMA SDU------------ |<-------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--------------->
Figure 9: Example of GMA PDU Format with Concatenation and Header-
based Non-IP (UDP) Encapsulation Figure 9: Example of GMA PDU Format with Concatenation and
Header-Based Non-IP (UDP) Encapsulation
If a PDU contains multiple SDUs, the Flow SN field is for the last 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. and 6 for the first, second, and last SDU, respectively.
GMA concatenation can be used for packing small packets of a GMA concatenation can be used for packing small packets of a single
single application, e.g., TCP ACKs, or from multiple applications. application, e.g., TCP ACKs, or from multiple applications. Notice
Notice that a single GMA flow may carry multiple application flows that a single GMA flow may carry multiple application flows (TCP,
(TCP, UDP, etc.). UDP, etc.).
GMA endpoint MUST NOT perform concatenation and fragmentation in a GMA endpoints MUST NOT perform concatenation and fragmentation in a
single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT carry
carry any other (fragmented or whole) SDU. any other (fragmented or whole) SDU.
7. Security Considerations 7. Security Considerations
Security in a network using GMA should be relatively similar to Security in a network using GMA should be relatively similar to
security in a normal IP network. GMA is unaware of IP or higher 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 layer end-to-end security as it carries the IP packets as opaque
payload. Deployers are encouraged to not consider that GMA adds payload. Deployers are encouraged to not consider that GMA adds any
any form of security and to continue to use IP or higher layer form of security and to continue to use IP- or higher-layer security
security as well as link-layer security. as well as link-layer security.
The GMA protocol at the convergence sublayer is a 0-hop protocol The GMA protocol at the convergence sublayer is a 0-hop protocol and
and relies on the security of the underlying network transport relies on the security of the underlying network transport paths.
paths. When this cannot be assumed, appropriate security protocols When this cannot be assumed, appropriate security protocols (IPsec,
(IPsec, DTLS, etc.) SHOULD be configured at the adaptation DTLS, etc.) SHOULD be configured at the adaptation sublayer. On the
sublayer. On the other hand, packet filtering requires either that other hand, packet filtering requires either that a firewall looks
a firewall looks inside the GMA packet or that the filtering is inside the GMA packet or that the filtering is done on the GMA
done on the GMA endpoints. In those environments in which this is endpoints. In those environments in which this is considered to be a
considered to be a security issue it may be desirable to terminate security issue, it may be desirable to terminate the GMA operation at
the GMA operation at the firewall. the firewall.
Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on
preventing the leak of the local-only GMA PDUs outside the "local preventing the leak of the local-only GMA PDUs outside the "local
domain" to the Internet or to another domain which could use the domain" to the Internet or to another domain that could use the same
same IP protocol type, i.e. 114. IP protocol type, i.e., 114.
8. IANA Considerations 8. IANA Considerations
This document makes no requests of IANA This document has no IANA actions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE",
Requirement Levels", BCP 14, RFC 2119, DOI RFC 2890, DOI 10.17487/RFC2890, September 2000,
10.17487/RFC2119, March 1997, <https://www.rfc- <https://www.rfc-editor.org/info/rfc2890>.
editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [GRE2] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 M. Cullen, "Huawei's GRE Tunnel Bonding Protocol",
May 2017, <https://www.rfc-editor.org/info/rfc8174>. RFC 8157, DOI 10.17487/RFC8157, May 2017,
<https://www.rfc-editor.org/info/rfc8157>.
[GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
<https://www.rfc-editor.org/info/rfc2890> . Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 9.2. Informative References
Management Services
(MAMS)https://tools.ietf.org/rfc/rfc8743.txt
[IANA] https://www.iana.org/assignments/protocol- [ATSSS] 3GPP, "Study on access traffic steering, switch and
numbers/protocol-numbers.xhtml splitting support in the 5G System (5GS) architecture",
Release 16, 3GPP TR 23.793, December 2018,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3254>.
[LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio [GCC] Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S.
Access (E-UTRA); LTE-WLAN Radio Level Integration Using Mascolo, "A Google Congestion Control Algorithm for Real-
Ipsec Tunnel (LWIP) encapsulation; Protocol Time Communication", Work in Progress, Internet-Draft,
specification" draft-ietf-rmcat-gcc-02, 8 July 2016,
<https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-
gcc-02>.
[RFC791] Internet Protocol, September 1981 [GMAC] Zhu, J. and M. Zhang, "UDP-based Generic Multi-Access
(GMA) Control Protocol", Work in Progress, Internet-Draft,
draft-zhu-intarea-gma-control-00, 13 October 2021,
<https://datatracker.ietf.org/doc/html/draft-zhu-intarea-
gma-control-00>.
[ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch [IANA] IANA, "Protocol Numbers",
and splitting support in the 5G system architecture. <https://www.iana.org/assignments/protocol-numbers>.
[GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 [IANA1999] IANA, Wayback Machine archive of "Protocol Numbers",
February 1999,
<https://web.archive.org/web/19990203044112/
http://www.isi.edu:80/in-notes/iana/assignments/protocol-
numbers>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, [LWIPEP] 3GPP, "Evolved Universal Terrestrial Radio Access
O., and F. Gont, "IP Fragmentation Considered Fragile", (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, Tunnel (LWIP) encapsulation; Protocol specification",
<https://www.rfc-editor.org/info/rfc8900>. Release 13, 3GPP TS 36.361, July 2020,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3037>.
[IANA1999]https://web.archive.org/web/19990203044112/http://www.is [MAMS] Kanugovi, S., Baboescu, F., Zhu, J., and S. Seo, "Multiple
i.edu:80/in-notes/iana/assignments/protocol-numbers Access Management Services Multi-Access Management
Services (MAMS)", RFC 8743, DOI 10.17487/RFC8743, March
2020, <https://www.rfc-editor.org/info/rfc8743>.
[GCC] S. Holmer, et al. A Google Congestion Control Algorithm for [MPIP] Sun, L., Tian, G., Zhu, G., Liu, Y., Shi, H., and D. Dai,
Real-Time Communication, "Multipath IP Routing on End Devices: Motivation, Design,
https://www.ietf.org/archive/id/draft-ietf-rmcat-gcc- and Performance", 2017,
02.txt <https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/
MPIP_Tech.pdf>.
[MPIP] L. Sun, et al. Multipath IP Routing on End Devices: [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
Motivation, Design, and DOI 10.17487/RFC0791, September 1981,
Performance, https://eeweb.engineering.nyu.edu/faculty/ <https://www.rfc-editor.org/info/rfc791>.
yongliu/docs/MPIP_Tech.pdf
[GMAC] J. Zhu M. Zhang, UDP-based GMA Control [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
Protocol, https://www.ietf.org/archive/id/draft-zhu- and F. Gont, "IP Fragmentation Considered Fragile",
intarea-gma-control-00.txt BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
Authors' Addresses Authors' Addresses
Jing Zhu Jing Zhu
Intel Intel
Email: jing.z.zhu@intel.com Email: jing.z.zhu@intel.com
Satish Kanugovi Satish Kanugovi
Nokia Nokia
Email: satish.k@nokia.com Email: satish.k@nokia.com
 End of changes. 134 change blocks. 
544 lines changed or deleted 580 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/