< draft-zhu-intarea-gma-control-00.txt   draft-zhu-intarea-gma-control-01.txt >
Network Working Group J. Zhu Network Working Group J. Zhu
Internet Draft M. Zhang Internet Draft M. Zhang
Intended status: Experimental Intel Intended status: Experimental Intel
Expires: April 13,2022 Expires: October 11,2022
October 13, 2021 April 11, 2022
UDP-based Generic Multi-Access (GMA) Control Protocol UDP-based Generic Multi-Access (GMA) Control Protocol
draft-zhu-intarea-gma-control-00 draft-zhu-intarea-gma-control-01
Abstract Abstract
A device can be simultaneously connected to multiple networks, A device can be simultaneously connected to multiple networks,
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly
combine the connectivity over these networks below the transport combine the connectivity over these networks below the transport
layer (L4) to improve quality of experience for applications that layer (L4) to improve quality of experience for applications that
do not have built in multi-path capabilities. This document do not have built in multi-path capabilities. This document
presents a new control protocol to manage traffic steering, presents a new control protocol to manage traffic steering,
splitting, and duplicating across multiple connections. The splitting, and duplicating across multiple connections. The
skipping to change at page 2, line 4 skipping to change at page 2, line 4
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 13, 2022. This Internet-Draft will expire on October 11, 2022.
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 (http://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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 2 1. Introduction ................................................. 2
1.1. Scope of Experiment ....................................4 1.1. Scope of Experiment ....................................4
2. Conventions used in this document ............................ 5 2. Conventions used in this document ............................ 5
3. Use Case ..................................................... 5 3. Use Case ..................................................... 5
4. UDP-based GMA Encapsulation Protocol ......................... 6 4. UDP-based GMA Encapsulation Protocol ......................... 6
5. GMA Control Messages ......................................... 9 5. GMA Control Messages ......................................... 9
5.1 Probe Message ........................................10 5.1 Probe Message .........................................9
5.2 Acknowledgement (ACK) Message ........................11 5.2 Acknowledgement (ACK) Message ........................10
5.3 Traffic Splitting Update (TSU) Message ...............11 5.3 Traffic Splitting Update (TSU) Message ...............11
5.4 Traffic Splitting Acknowledgement (TSA) Message ......13 5.4 Traffic Splitting Acknowledgement (TSA) Message ......12
5.5 Timestamp Reset Request (TSR) Message ................14 5.5 Timestamp Reset Request (TSR) Message ................14
6. GMA Control Flows ........................................... 15 6. GMA Control Flows ........................................... 14
6.1. Initialization ........................................15 6.1. Initialization ........................................14
6.2. GMA Operation .........................................16 6.2. GMA Operation .........................................15
6.3. Termination ...........................................17 6.3. Termination ...........................................17
7. Security Considerations ..................................... 18 7. Security Considerations ..................................... 17
8. IANA Considerations ......................................... 18 8. IANA Considerations ......................................... 18
9. References .................................................. 18 9. References .................................................. 18
9.1. Normative References ..................................18 9.1. Normative References ..................................18
9.2. Informative References ................................18 9.2. Informative References ................................18
1. Introduction 1. Introduction
A device can be simultaneously connected to multiple networks, A device can be simultaneously connected to multiple networks,
e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly
combine the connectivity over these networks below the transport combine the connectivity over these networks below the transport
skipping to change at page 7, line 15 skipping to change at page 7, line 15
the MAMS message (MX UP Setup Config) [MAMS]. the MAMS message (MX UP Setup Config) [MAMS].
+------------------------------------------------+ +------------------------------------------------+
| IP hdr | UDP hdr | GMA Header | Payload | | IP hdr | UDP hdr | GMA Header | Payload |
+------------------------------------------------+ +------------------------------------------------+
Figure 4: UDP-based GMA PDU Format Figure 4: UDP-based GMA PDU Format
The GMA (Generic Multi-Access) header MUST consist of the The GMA (Generic Multi-Access) header MUST consist of the
mandatory "Flags" field (the first two bytes), defined as follows: mandatory "Flags" field (the first two bytes), defined as follows:
o Payload Type (bit 0): to indicate the GMA PDU payload type o Client ID Present (bit 0): If the Client ID Present bit is set
+ 0: control message
+ 1: user-plane message
o Client ID Present (bit 1): If the Client ID Present bit is set
to 1, then the Client ID field is present to 1, then the Client ID field is present
o Slice ID Present (bit 2): if the Slice ID Present bit is set, to o Flow ID Present (bit 1): If the Flow ID Present bit is set to 1,
1, then the Slice ID field is present
o Connection ID Present (bit 3): If the Connection ID Present bit
is set to 1, then the Connection ID field is present
o Flow ID Present (bit 4): If the Flow ID Present bit is set to 1,
then the Flow ID field is present then the Flow ID field is present
o Per-Packet Priority (PPP) Present (bit 5): If the PPP Present o Per-Packet Priority (PPP) Present (bit 2): If the PPP Present
bit is set to 1, then the PPP field is present bit is set to 1, then the PPP field is present
o Delivery SN Present (bit 6): If the Delivery SN (Sequence o SN Present (bit 3): If the SN (Sequence Number) Present bit is
Number) Present bit is set to 1, then the Delivery SN field is set to 1, then the Delivery and Flow SN fields are present and
present and contains the valid information contains the valid information
o Flow SN Present (bit 7): If the Flow SN Present bit is set to 1, o Timestamp Present (bit 4): If the Timestamp Present bit is set
then the Sequence Number field is present
o Timestamp Present (bit 8): If the Timestamp Present bit is set
to 1, then the Timestamp field is present to 1, then the Timestamp field is present
o Concatenation Present (bit 9): If the Concatenation Present bit o Reserved (bit 5-15): set to "0" and ignored on receipt
is set to 1, then the PDU carries multiple SDUs
o Reserved (bit 10-15): set to "0" and ignored on receipt
Bit 0 is the most significant bit (MSB), and Bit 15 is the least Bit 0 is the most significant bit (MSB), and Bit 15 is the least
significant bit (LSB). significant bit (LSB).
The Receiver SHOULD first decode the Flags field to determine the The Receiver SHOULD first decode the Flags field to determine the
length of the GMA header, and then decode each optional field length of the GMA header, and then decode each optional field
accordingly. The GMA (Generic Multi-Access) header MAY consist of accordingly. The GMA (Generic Multi-Access) header MAY consist of
the following optional fields: the following optional fields:
o Client ID (2 Byte): an unsigned integer to identify the client o Client ID (2 Byte): an unsigned integer to identify the client
o Slice ID (1 Byte): an unsigned integer to identify the network
slice of the GMA SDU
o Connection ID (1 Byte): an unsigned integer to identify the
anchor connection of the GMA SDU.
o Flow ID (1 Byte): an unsigned integer to identify the IP flow o Flow ID (1 Byte): an unsigned integer to identify the IP flow
of the GMA SDU. of the GMA SDU.
o Per-Packet Priority (1 Byte): an unsigned integer to identify o Per-Packet Priority (1 Byte): an unsigned integer to identify
the relative priority of the GMA SDU in the flow (smaller the relative priority of the GMA SDU in the flow (smaller
value means higher priority). value means higher priority).
o Delivery SN (1 Byte): an auto-incremented integer to indicate o Delivery SN (1 Byte): an auto-incremented integer to indicate
the GMA PDU transmission order on a delivery connection. the GMA PDU transmission order on a delivery connection.
Delivery SN is used to measure packet loss of each delivery Delivery SN is used to measure packet loss of each delivery
connection and therefore generated per delivery connection connection and therefore generated per delivery connection
per flow. This field is present only if the Delivery SN per flow. This field is present only if the Delivery SN
skipping to change at page 8, line 38 skipping to change at page 8, line 22
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 the Flags field. Note that the bits in the Flags field are in the Flags field. Note that the bits in the Flags field are
ordered with the first bit transmitted being bit 0 (MSB). All ordered with the first bit transmitted being bit 0 (MSB). All
fields are transmitted in regular network byte order and appear in fields are transmitted in regular network byte order and appear in
order to their corresponding flag bits. If a flag bit is clear, order to their corresponding flag bits. If a flag bit is clear,
the corresponding optional field is absent. the corresponding optional field is absent.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | reserved | Client ID | | Flags | reserved | Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slice ID | Conn ID | Flow ID | PPP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery SN | Flow SN | | Flow ID | PPP | Delivery SN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | Flow SN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GMA Header Format with all Optional Fields Present Figure 5: GMA Header Format with all Optional Fields Present
Some GMA header fields, e.g. Slice ID, Conn ID, Flow ID, and PPP Some GMA header fields, e.g. Client ID, Flow ID, and PPP are
are designed to support hierarchical QoS (hQoS) and fine granular designed to support hierarchical QoS (hQoS) and fine granular
packet classification. Notice that GMA header fields (unlike IP packet classification. Notice that GMA header fields (unlike IP
header field) won't change regardless how a GMA PDU is delivered header field) won't change regardless how a GMA PDU is delivered
on the way, since they are encapsulated as part of UDP payload. on the way, since they are encapsulated as part of UDP payload.
Therefore, an intermediate node, e.g. router, Access Point, Base Therefore, an intermediate node, e.g. router, Access Point, Base
Station, etc., can perform hQoS scheduling and active queue Station, etc., can perform hQoS scheduling and active queue
management (AQM) directly based on these GMA header fields without management (AQM) directly based on these GMA header fields without
additional packet classification processing. additional packet classification processing.
Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp, Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp,
are designed to support multi-access traffic management. For are designed to support multi-access traffic management. For
example, Flow SN allows reordering at the receiver when a flow is example, Flow SN allows reordering at the receiver when a flow is
split over multiple connections. In the meantime, Delivery SN is split over multiple connections. In the meantime, Delivery SN is
needed for packet loss measurement per delivery connection, and needed for packet loss measurement per delivery connection, and
Timestamp allows one-way-delay measurement, which can then be used Timestamp allows one-way-delay measurement, which can then be used
to detect congestion and buffer overflow at intermediate nodes. to detect congestion and buffer overflow at intermediate nodes.
If concatenation is supported, a GMA PDU MAY carry multiple GMA
SDUs with the same Slice ID, Connection ID, Flow ID, and PPP.
However, concatenation is only applicable to IP-based virtual
(anchor) connection. Please refer to [GMAE] for more details on
concatenation.
5. GMA Control Messages 5. GMA Control Messages
A GMA control message is encapsulated as the payload of a GMA PDU A GMA control message is encapsulated as the payload of a GMA PDU
(see Figure 4) and indicated by setting Bit 0 in the Flags field (see Figure 4) and the GMA header MUST include the Client ID
of the GMA header to 0. Moreover, the GMA header MUST include the field, but not any other optional fields. As a result, the Flag in
Client ID field, but not any other optional fields. As a result, the GMA header is always set to 0x8000 for a GMA control message.
the Flag in the GMA header is always set to 0x4000 for a GMA
control message.
GMA control message MAY be encrypted with a symmetric key cipher, GMA control message MAY be encrypted with a symmetric key cipher,
e.g. AES256-GCM. If a GMA control message is encrypted, the e.g. AES256-GCM. If a GMA control message is encrypted, the
receiver will use the Client ID field to obtain the corresponding receiver will use the Client ID field to obtain the corresponding
key for decryption. Notice that only the GMA control message is key for decryption. Notice that only the GMA control message is
encrypted. The GMA header is authenticated but not encrypted. encrypted. The GMA header is authenticated but not encrypted.
Figure 6 shows the format of an encrypted GMA control message, Figure 6 shows the format of an encrypted GMA control message,
where IV (initialization vector) is 12 bytes long and GCM Tag is where IV (initialization vector) is 12 bytes long and GCM Tag is
16 bytes long. The GMA header (Flag (2B) + Client ID (2B)) is used 16 bytes long. The GMA header (Flag (2B) + Client ID (2B)) is used
as additional authenticated data (AAD). as additional authenticated data (AAD).
+---------------------------------------------------------------+ +---------------------------------------------------------------+
|Flag(0x4000) | Client ID | GMA control message | GCM Tag | IV | |Flag(0x8000) | Client ID | GMA control message | GCM Tag | IV |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
|<------authenticated---->|<----encrypted ----->| |<------authenticated---->|<----encrypted ----->|
Figure 6: Encrypted GMA Control Message Figure 6: Encrypted GMA Control Message
A GMA control message consists of the following fields: A GMA control message consists of the following fields:
o Header (2 Bytes) o Header (2 Bytes)
+ Type (1 Byte): the GMA control message type + Type (1 Byte): the GMA control message type
+ Connection ID (1 Byte): an unsigned integer to identify + Connection ID (1 Byte): an unsigned integer to identify
the anchor connection for the GMA control message the anchor connection for the GMA control message
o Payload (variable): the payload of the GMA control message o Payload (variable): the payload of the GMA control message
5.1 Probe Message 5.1 Probe Message
The "Type" field is set to "1" for Probe messages. The "Type" field is set to "1" for Probe messages.
Client (or multi-access gateway) may send out Probe message for Client (or multi-access gateway) may send out Probe message for
path quality estimation or keepalive. In response, multi-access path quality estimation or keepalive. In response, multi-access
gateway (or client) may send back the ACK message. gateway (or client) may send back the ACK message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | LS Bitmap | Probing Flag | | Sequence Number | LS Bitmap | Probing Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Probe Message Format Figure 7: Probe Message Format
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Probe message consists of the following fields: A Probe message consists of the following fields:
o Sequence Number (2 Bytes): the sequence number of the message o Sequence Number (2 Bytes): the sequence number of the message
o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0: o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0:
not connected; 1: connected) of the i-th delivery connection, not connected; 1: connected) of the i-th delivery connection,
where connections are ordered according to their Connection ID, where connections are ordered according to their Connection ID,
bit #7 (LSB) corresponds to the 1st delivery connection and bit bit #7 (LSB) corresponds to the 1st delivery connection and bit
#0 (MSB) corresponds to the 8th delivery connection. #0 (MSB) corresponds to the 8th delivery connection.
 End of changes. 25 change blocks. 
65 lines changed or deleted 42 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/