Generic Multi-Access (GMA) Encapsulation ProtocolInteljing.z.zhu@intel.comNokiasatish.k@nokia.com
A device can be simultaneously connected to multiple networks, e.g., Wi-Fi,
LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity
over these networks below the transport layer (L4) to improve the quality
of experience for applications that do not have built-in multi-path
capabilities. Such optimization requires additional control information,
e.g., a sequence number, in each packet. This document presents a new
lightweight and flexible encapsulation protocol for this need. The solution
has been developed by the authors based on their experiences in multiple
standards bodies including the IETF and 3GPP. However, this document is not
an Internet Standard and does not represent the consensus opinion of
the IETF. This document will enable other developers to build interoperable
implementations in order to experiment with the protocol.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series,
independently of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for publication
by the RFC Editor are not candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Scope of Experiment
. Conventions Used in This Document
. Use Case
. GMA Encapsulation Methods
. Trailer-Based IP Encapsulation
. Header-Based IP Encapsulation
. Header-Based Non-IP Encapsulation
. IP Protocol Identifier
. Fragmentation
. Concatenation
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Authors' Addresses
Introduction
A device can be simultaneously connected to multiple networks,
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly
combine the connectivity over these networks below the transport
layer (L4) to improve the quality of experience for applications that
do not have built-in multi-path capabilities. shows the Multi-Access Management Service (MAMS) user-plane
protocol stack , which has been used in today's
multi-access solutions . It
consists of two layers: convergence and adaptation.
The convergence layer is responsible for multi-access operations, including
multi-link (path) aggregation, splitting/reordering, lossless
switching/retransmission, fragmentation, concatenation, etc. It operates on
top of the adaptation layer in the protocol stack. From the perspective of
a transmitter, a User Payload (e.g., IP packet) is processed by the
convergence layer first and then by the adaptation layer before being
transported over a delivery connection; from the receiver's perspective, an
IP packet received over a delivery connection is processed by the
adaptation layer first and then by the convergence layer.
GRE (Generic Routing Encapsulation) can be used as
the encapsulation protocol at the convergence layer to encode additional
control information, e.g., key and sequence number. However, there are two
main drawbacks with this approach:
It is difficult to introduce new control fields because the
GRE header formats are already defined, and
IP-over-IP tunneling (required for GRE) leads to higher
overhead especially for small packets.
For example, the overhead of IP-over-IP/GRE tunneling with both
key and sequence Number is 32 bytes (20-byte IP header + 12-byte
GRE header), which is 80% of a 40-byte TCP ACK packet.
This document presents a lightweight Generic Multi-Access (GMA)
encapsulation protocol for the convergence layer. It supports three
encapsulation methods: trailer-based IP encapsulation, header-based IP
encapsulation, and non-IP encapsulation. Particularly, the IP
encapsulation methods avoid IP-over-IP tunneling overhead (20 bytes), which
is 50% of a 40-byte TCP ACK packet. Moreover, it introduces new control
fields to support fragmentation and concatenation, which are not available
in GRE-based solutions .
The GMA protocol only operates between endpoints that have been configured
to use GMA. This configuration can be through any control messages and
procedures, including, for example, Multi-Access Management Services . Moreover, UDP or IPsec tunneling can
be used at the adaptation sublayer to protect GMA operation from
intermediate nodes.
The solution described in this document was developed by the authors based
on their experiences in multiple standards bodies including the IETF and
3GPP. However, this document is not an Internet Standard and does not
represent the consensus opinion of the IETF. This document presents the
protocol specification to enable experimentation as described in and to facilitate other interoperable
implementations.Scope of Experiment
The protocol described in this document is an experiment. The
objective of the experiment is to determine whether the protocol
meets the requirements, can be safely used, and has support for
deployment. describes three possible encapsulation methods that are
enabled by this protocol. Part of this experiment is to assess
whether all three mechanisms are necessary or whether, for
example, all implementations are able to support the main
"trailer-based" IP encapsulation method. Similarly, the experiment
will investigate the relative merits of the IP and non-IP
encapsulation methods.
It is expected that this protocol experiment can be conducted on the
Internet since the GMA packets are identified by an IP protocol number and
the protocol is intended for single-hop propagation; devices should not be
forwarding packets, and if they do, they will not need to examine the payload,
while destination systems that do not support this protocol should not
receive such packets and will handle them as unknown payloads according to
normal IP processing. Thus, experimentation is conducted between consenting
end systems that have been mutually configured to participate in the
experiment as described in .
Note that this experiment "reuses" the IP protocol identifier 114
as described in . Part of this experiment is to assess
the safety of doing this. The experiment should consider the
following safety mechanisms:
GMA endpoints SHOULD detect non-GMA IP packets that also use
114 and log an error to report the situation (although such
error logging MUST be subject to rate limits).
GMA endpoints SHOULD stop using 114 and switch to non-IP encapsulation,
i.e., UDP encapsulation (), after detecting any non-GMA usage of 114.
The experiment SHOULD use a packet tracing tool, e.g.,
WireShark or TCPDUMP, to monitor both ingress and egress traffic at GMA
endpoints and ensure the above safety mechanisms are implemented.
Path quality measurements (one-way delay, loss, etc.) and congestion
detection are performed by the receiver based on the GMA control fields,
e.g., Sequence Number, Timestamp, etc. The receiver will then dynamically
control how to split or steer traffic over multiple delivery connections
accordingly. The GMA control protocol MAY
be used for signaling between GMA endpoints. Another objective of the
experiment is to evaluate the usage of various receiver-based algorithms
in multi-path traffic management and the impact on the End-to-End (E2E)
performance (throughput, delay, etc.) of higher-layer (transport)
protocols, e.g., TCP, QUIC, WebRTC, etc.
The authors will continually assess the progress of this
experiment and encourage other implementers to contact them to
report the status of their implementations and their experiences
with the protocol.Conventions Used in This Document
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as described in BCP 14 when, and only when, they appear in all capitals,
as shown here.
Use Case
As shown in , 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.
A:
The adaptation-layer endpoint of the LTE connection
resides in the client.
B:
The adaptation-layer endpoint of the Wi-Fi connection
resides in the client.
C:
The adaptation-layer endpoint of the LTE connection
resides in the Multi-Access Gateway, aka N-MADP (Network
Multi-Access Data Proxy) in .
D:
The adaptation-layer endpoint of the Wi-Fi connection
resides in the Multi-Access Gateway.
U:
The convergence-layer endpoint resides in the client.
S:
The convergence-layer endpoint resides in the Multi-Access
Gateway.
For example, per-packet aggregation allows a single IP flow to use the
combined bandwidth of the two connections. In another example, packets lost
due to a temporary link outage may be retransmitted. Moreover, packets may
be duplicated over multiple connections to achieve high reliability and low
latency, where duplicated packets are eliminated by the receiving
side. Such multi-access optimization requires additional control
information, e.g., a sequence number, in each packet, which can be
supported by the GMA encapsulation protocol described in this document.
The GMA protocol described in this document is designed for multiple
connections, but it may also be used when there is only one connection
between two endpoints. For example, it may be used for loss detection and
recovery. In another example, it may be used to concatenate multiple small
packets and reduce per-packet overhead.GMA Encapsulation Methods
The GMA encapsulation protocol supports the following three
methods:
Trailer-based IP Encapsulation ()
Header-based IP Encapsulation ()
Header-based non-IP Encapsulation ()
Non-IP encapsulation MUST be used if the original IP packet is
IPv6.
Trailer-based IP encapsulation MUST be used if it is supported by
GMA endpoints and the original IP packet is IPv4.
Header-based encapsulation MUST be used if the trailer-based
method is not supported by either the client or Multi-Access Gateway.
In this case, if the adaptation layer, e.g., UDP tunneling,
supports non-IP packet format, non-IP encapsulation MUST be used;
otherwise, header-based IP encapsulation MUST be used.
If non-IP encapsulation is configured, a GMA header MUST be
present in every packet. In comparison, if IP encapsulation is configured,
a GMA header or trailer may be added dynamically on a per-packet basis, and
it indicates the presence of a GMA header (or trailer) to set the protocol
type of the GMA PDU to "114" (see ).
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 includes "MX Convergence Method Parameters",
which provides the list of parameters to configure the convergence layer,
and can be extended to indicate the GMA encapsulation method.
GMA endpoint MUST discard a received packet and MAY log an error
to report the situation (although such error logging MUST be
subject to rate limits) under any of the following conditions:
The GMA version number in the GMA header (or trailer) is not
understood or supported by the GMA endpoint.
A flag bit in the GMA header (or trailer) not understood or
supported by the GMA endpoint is set to "1".
Trailer-Based IP Encapsulation
This method SHALL NOT be used if the original IP packet (GMA
service data unit (GMA SDU)) is IPv6. shows the trailer-based IP encapsulation GMA protocol
data unit (GMA PDU) format. A (GMA) PDU may carry one or multiple IP
packets, aka (GMA) SDUs, in the payload, or a fragment of the SDU.
The protocol type field in the IP header of the GMA PDU MUST be
changed to 114 (Any 0-Hop Protocol) (see ) to indicate
the presence of the GMA trailer.
The following three IP header fields MUST be changed:
IP Length:
Add the length of "GMA Trailer" to the length of the
original IP packet.
Time To Live (TTL):
Set to "1".
IP checksum:
Recalculate after changing "protocol
type", "TTL", and "IP Length".
The GMA (Generic Multi-Access) trailer MUST consist of two
mandatory fields (the last 3 bytes): Next Header and Flags.
This is defined as follows:
Next Header (1 byte):
This is the IP protocol type of the (first) SDU
in a PDU; it stores the value before it was overwritten to
114.
Flags (2 bytes):
Bit 0 is the most significant bit (MSB), and
bit 15 is the least significant bit (LSB).
Checksum Present (bit 0):
If the Checksum Present
bit is set to 1, then the Checksum field is present.
Concatenation Present (bit 1):
If the Concatenation
Present bit is set to 1, then the PDU carries multiple SDUs, and
the First SDU Length field is present.
Connection ID Present (bit 2):
If the Connection ID
Present bit is set to 1, then the Connection ID field is
present.
Flow ID Present (bit 3):
If the Flow ID Present bit
is set to 1, then the Flow ID field is present.
Fragmentation Present (bit 4):
If the Fragmentation
Present bit is set to 1, then the PDU carry a fragment of the
SDU and the Fragmentation Control field is present.
Delivery SN Present (bit 5):
If the Delivery SN
(Sequence Number) Present bit is set to 1, then the Delivery SN
field is present and contains the valid information.
Flow SN Present (bit 6):
If the Flow SN Present bit
is set to 1, then the Sequence Number field is present.
Timestamp Present (bit 7):
If the Timestamp Present
bit is set to 1, then the Timestamp field is present.
TTL Present (bit 8):
If the TTL Present bit is set
to 1, then the TTL field is present.
Reserved (bit 9-12):
This is set to "0" and ignored
on receipt.
Version (bit 13~15):
This is the GMA version
number; it is set to 0 for the GMA encapsulation protocol specified in
this document.
The Flags field is at the end of the PDU, and the Next Header field is the
second last. The receiver SHOULD first decode the Flags
field to determine the length of the GMA trailer and then decode each
optional field accordingly. The Generic Multi-Access (GMA) trailer
MAY consist of the following optional fields:
Checksum (1 byte):
This contains the (one's
complement) checksum sum of all 8 bits in the trailer. For purposes
of computing the checksum, the value of the Checksum field is
zero. This field is present only if the Checksum Present bit is set
to 1.
First SDU Length (2 bytes):
This is the length of the
first IP packet in the PDU, only included if a PDU contains multiple
IP packets. This field is present only if the Concatenation Present
bit is set to 1.
Connection ID (1 byte):
This contains an unsigned integer to identify the
anchor and delivery connection of the GMA PDU. This field is
present only if the Connection ID Present bit is set to 1.
Anchor Connection ID (MSB 4 bits):
This contains an
unsigned integer to identify the anchor connection.
Delivery Connection ID (LSB 4 bits):
This contains
an unsigned integer to identify the delivery connection.
Flow ID (1 byte):
This contains an unsigned integer to identify the
IP flow that a PDU belongs to, for example Data Radio Bearer (DRB)
ID 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 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.
shows the GMA trailer format with all the fields present,
and the order of the GMA control fields SHALL follow the bit order
in the Flags field. Note that the bits in the Flags field are
ordered with the first bit transmitted being bit 0 (MSB). All
fields are transmitted in regular network byte order and appear in
reverse order to their corresponding flag bits. If a flag bit is
clear, the corresponding optional field is absent.
For example, bit 0 (the MSB) of the Flags field is the Checksum Present
bit, and the Checksum field is the last in the trailer with the exception
of the two mandatory fields. Bit 1 is the Concatenation Present bit, and
the FSL field is the second last.Header-Based IP Encapsulation
This method SHALL NOT be used if the original IP packet (GMA SDU)
is IPv6. shows the header-based IP encapsulation format. Here, the
GMA header is inserted right after the IP header of the GMA SDU,
and the IP header fields of the GMA PDU MUST be changed the same
way as in trailer-based IP encapsulation. shows the GMA header format. In comparison to the GMA
trailer, the only difference is that the Flags field is now in the front so
that the receiver can first decode the Flags field to determine the GMA
header length.
The "TTL" field MUST be included and the "TTL" bit in the
GMA header (or Trailer) MUST be set to 1 if (trailer- or
header-based) IP encapsulation is used.Header-Based Non-IP Encapsulation shows the header-based non-IP encapsulation format. Here,
"UDP Tunneling" is configured at the MX adaptation layer. The
ports for "UDP Tunneling" at the client are chosen from the Dynamic
Port range, and the ports for "UDP Tunneling" at the Multi-Access
Gateway are configured and provided to the client through additional
control messages, e.g., .
"TTL", "FSL", and "Next Header" are no longer needed and MUST not
be included. Moreover, the IP header fields of the GMA SDU remain
unchanged.IP Protocol Identifier
As described in , IP-encapsulated GMA PDUs are
indicated using the IP protocol type 114. This is designated and
recorded by IANA to indicate "any 0-Hop Protocol". No
reference is given in the IANA registry for the definition of this
protocol type, and IANA has no record of why the assignment was
made or how it is used, although it was probably assigned before
1999 .
There is some risk associated with "reusing" protocol type 114
because there may be implementations of other protocols also using
this protocol type. However, because the protocol described in
this document is used only between adjacent devices specifically
configured for this purpose, the use of protocol type 114 should
be safe.
As described in , one of the purposes of the experiment
described in this document is to verify the safety of using this
protocol type. Deployments should be aware of the risk of a clash
with other uses of this protocol type.Fragmentation
If the MTU size of the anchor connection (for GMA SDU) is configured such
that the corresponding GMA PDU length adding the GMA header (or trailer)
and other overhead (UDP tunneling) MAY exceed the MTU of a
delivery connection, GMA endpoints MUST be configured to
support fragmentation through additional control messages .
The fragmentation procedure at the convergence sublayer is similar
to IP fragmentation in principle, but with the following
two differences for less overhead:
The fragment offset field is expressed in number of fragments.
The maximum number of fragments per SDU is 27 (=128).
The Fragmentation Control (FC) field in the GMA trailer (or
header) contains the following bits:
Bit 7:
a More Fragment (MF) flag to indicate if the fragment
is the last one (0) or not (1)
Bit 0-6:
Fragment Offset (in units of fragments) to specify
the offset of a particular fragment relative to the beginning
of the SDU
A PDU carries a whole SDU without fragmentation if the FC field is
set to all "0"s or the FC field is not present in the trailer.
Otherwise, the PDU contains a fragment of the SDU.
The Flow SN field in the trailer is used to distinguish the
fragments of one SDU from those of another. The Fragment Offset
(FO) field tells the receiver the position of a fragment in the
original SDU. The More Fragment (MF) flag indicates the last
fragment.
To fragment a long SDU, the transmitter creates n PDUs and copies the
content of the IP header fields from the long PDU into the IP header of all
the PDUs. The length field in the IP header of the PDU
SHOULD be changed to the length of the PDU, and the protocol
type SHOULD be changed to 114.
The data of the long SDU is divided into n portions based on the
MTU size of the delivery connection. The first portion of the data
is placed in the first PDU. The MF flag is set to "1", and the FO
field is set to "0". The i-th portion of the data is placed in the
i-th PDU. The MF flag is set to "0" if it is the last fragment and
set to "1" otherwise. The FO field is set to i-1.
To assemble the fragments of an SDU, the receiver combines PDUs
that all have the same Flow SN. The combination is done by placing
the data portion of each fragment in the relative order indicated
by the Fragment Offset in that fragment's GMA trailer (or header).
The first fragment will have the Fragment Offset set to "0", and
the last fragment will have the More Fragment flag set to "0".
GMA fragmentation operates above the IP layer of individual access
connection (Wi-Fi, LTE) and between the two endpoints of convergence
layer. The convergence layer endpoints (client, Multi-access Gateway)
SHOULD obtain the MTU of individual connection through
either manual configuration or implementing Path MTU Discovery (PMTUD) as
suggested in .Concatenation
The convergence sublayer MAY support concatenation if a delivery
connection has a larger maximum transmission unit (MTU) than the
original IP packet (SDU). Only the SDUs with the same client IP
address and the same Flow ID MAY be concatenated.
If the (trailer- or header-based) IP encapsulation method is used,
the First SDU Length (FSL) field SHOULD be included in the GMA
trailer (or header) to indicate the length of the first SDU.
Otherwise, the FSL field SHOULD not be included.
To concatenate two or more SDUs, the transmitter creates one PDU
and copies the content of the IP header field from the first SDU
into the IP header of the PDU. The data of the first SDU is placed
in the first portion of the data of the PDU. The whole second SDU
is then placed in the second portion of the data of the PDU
(). The procedure continues until the PDU size reaches the
MTU of the delivery connection. If the FSL field is present, the
IP Length field of the PDU SHOULD be updated to include all
concatenated SDUs and the trailer (or header), and the IP checksum
field SHOULD be recalculated if the packet is IPv4.
To disaggregate a PDU, if the (header- or trailer-based) IP
encapsulation method is used, the receiver first obtains the
length of the first SDU from the FSL field and decodes the first
SDU. The receiver then obtains the length of the second SDU based
on the length field in the second SDU IP header and decodes the
second SDU. The procedure continues until no byte is left in the
PDU. If the non-IP encapsulation method () 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 ().
If a PDU contains multiple SDUs, the Flow SN field is for the last
SDU, and the Flow SN of other SDUs carried by the same PDU can be
obtained according to its order in the PDU. For example, if the SN
field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5,
and 6 for the first, second, and last SDU, respectively.
GMA concatenation can be used for packing small packets of a
single application, e.g., TCP ACKs, or from multiple applications.
Notice that a single GMA flow may carry multiple application flows
(TCP, UDP, etc.).
GMA endpoints MUST NOT perform concatenation and
fragmentation in a single PDU. If a GMA PDU carries a fragmented SDU, it
MUST NOT carry any other (fragmented or whole) SDU.Security Considerations
Security in a network using GMA should be relatively similar to security in
a normal IP network. GMA is unaware of IP- or higher-layer end-to-end
security as it carries the IP packets as opaque payload. Deployers are
encouraged to not consider that GMA adds any form of security and to
continue to use IP- or higher-layer security as well as link-layer
security.
The GMA protocol at the convergence sublayer is a 0-hop protocol and relies
on the security of the underlying network transport paths. When this cannot
be assumed, appropriate security protocols (IPsec, DTLS, etc.)
SHOULD be configured at the adaptation sublayer. On the
other hand, packet filtering requires either that a firewall looks inside
the GMA packet or that the filtering is done on the GMA endpoints. In those
environments in which this is considered to be a security issue, it may be
desirable to terminate the GMA operation at the firewall.
Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on
preventing the leak of the local-only GMA PDUs outside the "local domain"
to the Internet or to another domain that could use the same IP protocol
type, i.e., 114.IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesKey and Sequence Number Extensions to GREThis document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]Huawei's GRE Tunnel Bonding ProtocolThere is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesStudy on access traffic steering, switch and splitting support in the 5G System (5GS) architecture3GPPRelease 16A Google Congestion Control Algorithm for Real-Time CommunicationWork in ProgressUDP-based Generic Multi-Access (GMA) Control ProtocolIntelIntel 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 quality of experience for applications that
do not have built in multi-path capabilities. This document
presents a new control protocol to manage traffic steering,
splitting, and duplicating across multiple connections. The
solution has been developed by the authors based on their
experiences in multiple standards bodies including the IETF and
3GPP, 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.
Work in ProgressProtocol NumbersIANAWayback Machine archive of "Protocol Numbers"IANAEvolved Universal Terrestrial Radio Access (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP) encapsulation; Protocol specification3GPPRelease 13Multiple Access Management Services Multi-Access Management Services (MAMS)In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.Multipath IP Routing on End Devices: Motivation, Design, and PerformanceInternet ProtocolIP Fragmentation Considered FragileThis document describes IP fragmentation and explains how it introduces fragility to Internet communication.This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.Authors' AddressesInteljing.z.zhu@intel.comNokiasatish.k@nokia.com