Network Working Group J. Zhu Internet Draft M. Zhang Intended status: Experimental Intel Expires: February 24,2023 August 24, 2023 UDP-based Generic Multi-Access (GMA) Control Protocol draft-zhu-intarea-gma-control-04 Abstract 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 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 to experiment with the protocol. 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 months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 24, 2022. Zhu Expires February 24, 2022 [Page 1] Internet-Draft GMA Control Protocol August 2023 Copyright Notice Copyright (c) 2023 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 (http://trustee.ietf.org/license-info) 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. Code Components extracted from this 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 1 Introduction ...............................................3 1.1 Scope of Experiment ...................................4 2 Conventions used in this document ..........................5 3 Use Case ...................................................5 4 UDP-based GMA Encapsulation Protocol .......................7 5 GMA Control Messages ......................................11 5.1 Probe Message ........................................11 5.2 Acknowledgement (ACK) Message ........................13 5.3 Traffic Splitting Update (TSU) Message ...............14 5.4 Traffic Splitting Acknowledgement (TSA) Message ......15 5.5 Delivery Connection Reconfiguration (DCR) Message ....16 5.6 Key Update Message ...................................17 5.7 Traffic Steering Command (TSC) Message ...............17 5.8 Traffic Splitting Command (TSP) Message ..............18 5.9 QoS Testing Request (QTR) Message ....................18 5.10 QoS Testing Response (QTP) Message ...................19 5.11 QoS Testing Notification (QTN) Message ...............19 5.12 QoS Violation Notification (QVN) Message .............19 5.13 Packet Loss Report (PLR) Message .....................20 5.14 First Sequence Number (FSN) Message ..................20 5.15 Coding Configuration Request (CCR) Message ...........20 5.16 Coded GMA SDU (CGS) Message ..........................21 5.17 Coding Configuration Command (CCC) Message ...........22 6 Basic GMA Control Procedures ..............................23 6.1 Initialization .......................................23 6.2 GMA Operation ........................................25 6.3 Termination ..........................................26 7 Advanced GMA Control Procedure ............................27 7.1 Network-based Traffic Steering .......................27 7.2 QoS-aware Traffic Steering ...........................28 7.3 GMA-based Retransmission .............................30 Zhu Expires February 24, 2021 [Page 2] Internet-Draft GMA Control Protocol August 2023 7.4 Receiver-based Network Coding ........................31 7.5 Network-based Network Coding .........................32 8 Security Considerations ...................................33 9 IANA Considerations .......................................33 10 Contributing Authors ......................................33 11 References ................................................33 11.1 Normative References .................................33 11.2 Informative References ...............................34 1 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 quality of experience for applications that do not have built-in multi-path capabilities. Figure 1 shows the Multi-Access Management Service (MAMS) user- plane protocol stack [MAMS], which has been used in today's multi-access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. 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, 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. +-----------------------------------------------------+ | User Payload, e.g., IP Protocol Data Unit (PDU) | +-----------------------------------------------------+ +-----------------------------------------------------------+ | +-----------------------------------------------------+ | | | Multi-Access (MX) Convergence Layer | | | +-----------------------------------------------------+ | | +-----------------------------------------------------+ | | | MX Adaptation | MX Adaptation | MX Adaptation | | | | Layer | Layer | Layer | | | +-----------------+-----------------+-----------------+ | | | Access #1 IP | Access #2 IP | Access #3 IP | | | +-----------------------------------------------------+ | Zhu Expires February 24, 2021 [Page 3] Internet-Draft GMA Control Protocol August 2023 | MAMS User-Plane Protocol Stack | +-----------------------------------------------------------+ Figure 1: MAMS User-Plane Protocol Stack [MAMS] A new encapsulation protocol [GMAE] has been specified for the convergence layer to encode additional control information, e.g., Timestamp, Sequence Number, required for multi-access traffic management. This document presents a UDP-based GMA control protocol for the convergence layer. The GMA control protocol only operates between endpoints that have been configured to use GMA. This configuration can be through any management messages and procedures, for example, Multi-Access Management Services [MAMS]. From individual access network's perspective, the proposed UDP- based GMA control protocol is a new light-weight transport protocol designed specifically for multi-path operation, removing all the unnecessary complexity and overhead (e.g., end-to-end encryption, congestion control, reliable transmission, etc.) as seen in a modern transport protocol [QUIC]. Moreover, it can be easily extended to support advanced multi-path features, e.g., network coding, network-based traffic steering, in-band QoS monitoring, etc. The solution described in this document has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, it 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 Section 1.1 and to facilitate other interoperable implementations. 1.1 Scope of Experiment The protocol described in this document is an experiment. One objective of the experiment is to determine whether the protocol meets the 3GPP ATSSS [ATSSS2] requirements, can be safely used, and has support for deployment. Particularly, the proposed GMA protocol addresses the following issues of using QUIC for ATSSS: o Encapsulation Overhead: the GMA encapsulation protocol uses a 2-bytes Flag field to control all optional header fields instead of the TLV (Type-Length-Value) based approach. As a result, the minimum encapsulation overhead is 2 bytes, and the maximum is 16 bytes. Zhu Expires February 24, 2021 [Page 4] Internet-Draft GMA Control Protocol August 2023 o Multiple Encryptions: the GMA encapsulation protocol does not mandate encryption to avoid unnecessary encryption overhead when a delivery connection is secure and trusted. o Congestion Control in Congestion Control: the GMA control protocol does not mandate congestion control. All incoming packets (from higher layer) MAY be sent out without any delay due to congestion control. In addition, the GMA protocol does not mandate Acknowledgement (ACK) and reliable delivery for data traffic to avoid any delay due to retransmission as well as ACK overhead on the reverse path. Path quality measurements (e.g. one-way-delay, loss, etc.) and congestion detection are performed by receiver based on the GMA header fields, e.g. sequence number, timestamp, etc. Another objective of the experiment is to evaluate the usage of various receiver-based congestion detection algorithms [GCC] [MPIP] in multi-path traffic management. It is expected that this protocol experiment can be conducted on the Internet since the GMA packets are encapsulated with UDP. Thus, experimentation is conducted between consenting end systems that have been mutually configured to participate in the experiment. An open-source based GMA software implementation [GMAsw] is provided for evaluation. 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. 2 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3 Use Case 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, operating as the delivery connection. In addition, a virtual (e.g. IPv4, IPv6, or Ethernet) connection is established between client and multi-access gateway. The virtual connection is the anchor, providing the IP address and connectivity for end- Zhu Expires February 24, 2021 [Page 5] Internet-Draft GMA Control Protocol August 2023 to-end Internet access, and delivery connection provides multiple paths between client and multi-access gateway for multi-access traffic management, aka Access Traffic Steering, Switching, and Splitting (ATSSS) in 3GPP [ATSSS]. +------- Virtual (anchor) Connection ------+ | | +-+---+ +---+-+ | | |A|--- LTE (delivery) Connection --|C| | | Apps ---|X|U|-| |-|S|Z|--- Internet | | |B|-- Wi-Fi (delivery) Connection--|D| | | +-+---+ +---+-+ Client multi-access Gateway o A: the adaptation layer endpoint of the LTE connection in the client o B: the adaptation layer endpoint of the Wi-Fi connection in the client o C: the adaptation layer endpoint of the LTE connection in the multi-access gateway o D: the adaptation layer endpoint of the Wi-Fi connection in the multi-access gateway o U: the convergence layer endpoint in the client o S: the convergence layer endpoint in the multi-access gateway o X: the virtual connection endpoint in the client o Z: the virtual connection endpoint in the multi-access gateway Figure 2: GMA-based Multi-Access Traffic Management For example, the virtual connection could be a Multi-Access Protocol Data Unit (MA-PDU) connection as specified in 3GPP [ATSSS]. Per-packet aggregation allows the MA-PDU connection to use the combined bandwidth of multiple delivery connections. 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 message exchange between client and multi-access gateway. "UDP" is used for the adaptation layer in this document. Figure 3a and 3b show UDP-based GMA user-plane and control-plane protocol, respectively. +-----------------------------------------------------+ | Virtual Connection (IP, Ethernet, etc.) | Zhu Expires February 24, 2021 [Page 6] Internet-Draft GMA Control Protocol August 2023 +-----------------------------------------------------+ | UDP-based GMA Encapsulation | +-----------------------------------------------------+ | UDP | UDP | UDP | +-----------------+-----------------+-----------------+ | Access #1 IP | Access #2 IP | Access #3 IP | +-----------------------------------------------------+ Figure 3a: UDP-based GMA User-Plane Protocol Stack +-----------------------------------------------------+ | GMA Control Messages | +-----------------------------------------------------+ | UDP-based GMA Encapsulation | +-----------------------------------------------------+ | UDP | UDP | UDP | +-----------------+-----------------+-----------------+ | Access #1 IP | Access #2 IP | Access #3 IP | +-----------------------------------------------------+ Figure 3b: UDP-based GMA Control-Plane Protocol Stack 4 UDP-based GMA Encapsulation Protocol Figure 4 shows the UDP-based GMA encapsulation format as specified in [GMAE]. The ports for "UDP Tunnelling" at Client are chosen from the Dynamic Port range, and the ports and IP addresses for "UDP Tunnelling" at multi-access gateway MAY be configured and provided to client through the MAMS message (MX UP Setup Config) [MAMS]. +----------------------------------------------------+ | IP hdr | UDP hdr | GMA Header | Payload (GMA SDU) | +----------------------------------------------------+ Figure 4: UDP-based GMA PDU Format The GMA (Generic Multi-Access) header MUST consist of the mandatory "Flags" field (the first two bytes), defined as follows: o Client ID Present (bit 0): If the Client ID Present bit is set to 1, then the Client ID field is present. o Payload Type (PT) (bit 1): If the bit is set to 1, the GMA PDU carries a GMA control message or an encrypted GMA SDU (data). Zhu Expires February 24, 2021 [Page 7] Internet-Draft GMA Control Protocol August 2023 Otherwise (default), it carries an unencrypted GMA SDU (data). o Flow ID Present (bit 2): If the Flow ID Present bit is set to 1, then the Flow ID field is present. o Per-Packet Priority (PPP) Present (bit 3): If the PPP Present bit is set to 1, then the PPP field is present. o Packet Group Identification (PGI) Present (bit 4): If the PCI Present bit is set to 1, then the PCI field is present. o 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. o Flow SN Present (bit 6): If the Flow SN (Sequence Number) Present bit is set to 1, then the Flow SN field is present and contains the valid information. o Timestamp Present (bit 7): If the Timestamp Present bit is set to 1, then the Timestamp field is present. o Reserved (bit 8-15): set to "0" and ignored on receipt. Bit 0 is the most significant bit (MSB), and bit 15 is the least significant bit (LSB). The receiver SHOULD first decode the Flags field to determine the length of the GMA header, and then decode each optional field accordingly. The GMA (Generic Multi-Access) header MAY consist of the following optional fields: o Client ID (2 Byte): an unsigned integer to identify the virtual connection. o PT (1 Byte): this field is present only if the Payload Type bit is set to 1. + Bit 0: the Key Phase bit to indicate which key is used to protect the GMA payload. + Bit 1~7: the GMA control message type (set to "0" if the payload is an encrypted GMA SDU) o Flow ID (1 Byte): an unsigned integer to identify the IP flow of a GMA SDU. + 0: default + 1~9: reserved for flows using the redundancy mode, with which a flow is duplicated over all the available delivery connections. + 10~20: reserved for flows using the splitting mode, with which a flow is split over all the available delivery connections. + 21~100: reserved for flows using the steering mode, with which a flow is sent over only one of the available delivery connections. + Others: reserved for future use Zhu Expires February 24, 2021 [Page 8] Internet-Draft GMA Control Protocol August 2023 o Per-Packet Priority (1 Byte): an unsigned integer to identify the relative priority of the GMA SDU in the flow (smaller value means higher priority). o Packet Group ID (1 Byte): an unsigned integer to identify the group of GMA SDUs. If one GMA SDU in the group is dropped, other GMA SDUs in the same group SHOULD also be dropped. For example, all GMA SDUs from a video frame MAY be classified into a same group. o Delivery SN (1 Byte): an auto-incremented unsigned integer to indicate the GMA PDU transmission order on a delivery connection. Delivery SN is used to measure packet loss of each delivery connection and therefore generated per delivery connection per flow. This field is present only if the Delivery SN Present bit is set to one. o Flow SN (3 Bytes): an auto-incremented unsigned integer to indicate the GMA SDU (IP packet) order of a flow. Flow SN is used for reordering, and therefore generated per flow. This field is present only if the Flow SN Present bit is set to one. o Timestamp (4 Bytes): to contain the current value of the timestamp clock of the transmitter in the unit of 100 microseconds. This field is present only if the Timestamp Present bit is set to one. The use of Key Phase bit is similar to QUIC [QUICTLS], and it allows a recipient to detect a change in keying material without needing to receive the first packet that triggered the change. The Key Phase bit is initially set to 0 and toggled to signal each subsequent key update. The Key Phase bit SHALL be ignored if the payload is not protected with any encryption. Figure 5 shows the GMA header 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 order to their corresponding flag bits. If a flag bit is clear, the corresponding optional field is absent. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | reserved | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PT | Flow ID | PPP | PGI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhu Expires February 24, 2021 [Page 9] Internet-Draft GMA Control Protocol August 2023 | Delivery SN | Flow SN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: GMA Header Format with all Optional Fields Present Some GMA header fields, e.g. Client ID, Flow ID, and PPP are designed to support hierarchical QoS (hQoS) and fine granular packet classification. Notice that GMA header fields (unlike IP header field) won't change regardless how a GMA PDU is delivered on the way, since they are encapsulated as part of UDP payload. Therefore, an intermediate node, e.g. router, Access Point, Base Station, etc., can perform hQoS scheduling and active queue management (AQM) directly based on these GMA header fields without additional packet classification processing. Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp, are designed to support multi-path traffic management. For example, Flow SN allows reordering at the receiver when a flow is split over multiple connections. In the meantime, Delivery SN is needed for packet loss measurement per delivery connection especially if a flow uses the splitting mode, and Timestamp allows one-way-delay measurement, which can then be used to detect congestion and buffer overflow at intermediate nodes. GMA payload MAY be protected by a symmetric key cipher, e.g. AES256-GCM. The receiver will use the Client ID field to obtain the corresponding key for decryption. Only GMA payload is encrypted, and GMA header is authenticated but not encrypted. GMA SDU (data) SHOULD be protected if the delivery connection is "untrusted" and subject to malicious attacks. If the encrypted GMA payload carries GMA SDU (data), the PT field MUST be present in the GMA header and the GMA control message type field MUST be set to "0". +-------------------------------------------------------------+ | GMA Header | GMA Payload | GCM Tag | IV | +-------------------------------------------------------------+ |<-authenticated->|<-------encrypted -------->| Figure 6: AES256-GCM Encrypted GMA Message Zhu Expires February 24, 2021 [Page 10] Internet-Draft GMA Control Protocol August 2023 Figure 6 shows the format of an AES256-GCM encrypted GMA message, where IV (initialization vector) is 12 bytes long and GCM Tag is 16 bytes long. GMA header is used as additional authenticated data (AAD). 5 GMA Control Messages The GMA header of a GMA control message consists of Client ID, Payload Type, Flow SN, and Timestamp. All GMA control messages share the same Flow SN space. Notice that Coded GMA SDU (CGS) message (5.16) MAY be protected by the symmetric key only if the delivery connection is untrusted. All other GMA control message SHOULD be protected regardless. 5.1 Probe Message The "Type" field is set to "1" for Probe messages. Client (or multi-access gateway) MAY send out a Probe message for initial connection establishment, path quality estimation, keepalive, time synchronization, and link measurement report. In response, multi-access gateway (or client) MAY send back the ACK message. A delivery connection is established after the successful Probe and ACK handshake, and terminated if any control message exchange fails. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Bitmap | Probing Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Information Elements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Probe Message Format A Probe message consists of the following fields: o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0: not connected; 1: connected) of the i-th delivery connection, where connections are ordered according to their Connection ID, bit #7 (LSB) corresponds to the 1st delivery connection and bit #0 (MSB) corresponds to the 8th delivery connection. o Probing Flag (1 Byte): + Bit #0: a bit flag to indicate if timestamp SHOULD be reset (1) or not (0) Zhu Expires February 24, 2021 [Page 11] Internet-Draft GMA Control Protocol August 2023 + Bit #1: a bit flag to indicate if the ACK message is expected (0) or not (1) + Bit #2: a bit flag to indicate if multi-access gateway SHOULD update the UDP tunnel end-point (0) or not (1) based on the received Probe message + Bit #3: a bit flag to indicate if one or more Link Information Elements (IE) are present. + Bit #4: a bit flag to indicate if the client's local clock is synchronized with the multi-access gateway. + Bit #5~7: reserved A Link IE consists of the following fields: o Type (1B) o Length (1B) o Value (variable) Multi-access gateway SHOULD update the UDP tunnel end-point of the client for the delivery connection based on the received Probe message if the Bit #2 Probing flag is set to 0 (default). A Probe message with the Bit #0 flag set to "1" is also called Probe-Sync. Client SHOULD send out a Probe-Sync message to reset timestamp and prevent it from overflowing for one-way delay measurement due to the limited size (4 Bytes) when its local timestamp timer exceeds a pre-defined value, e.g., 0x7FFF0000. Once receiving a Probe-Sync message, multi-access gateway SHOULD reset the timestamp timer to "0" for the client and respond with an ACK message. The "Request Type" field in the ACK message is set to 0, indicating the corresponding Probe message is Probe-Sync. Client SHOULD reset its timestamp timer to "0" after the Probe-Sync message is successfully acknowledged. As a result, the timestamp field in a GMA PDU indicates the duration between the last successful Probe-Sync message exchange and the transmission of the GMA PDU. However, if the Bit #4 flag is set to "1", indicating the client's local clock is synchronized with the gateway, both client and gateway SHOULD use their local clock directly as the timestamp clock without going through the above "Probe-Sync" procedure. Client MAY use the Probe message to report its link quality, e.g., signal strength and other information, e.g. Wi-Fi channel number. Table 1 list all the supported Link Information Elements. Table 1: Link Information Elements Zhu Expires February 24, 2021 [Page 12] Internet-Draft GMA Control Protocol August 2023 +---------------------------------------------------------------+ | Name | Type | Length | Value | +---------------------------------------------------------------+ | Wi-Fi RSSI | 0 | 1 | -255dBm ~ 0dBm | +---------------------------------------------------------------+ | Wi-Fi Band | 1 | 1 | 0:2.4GHz, 1: 5GHz, 2:6GHz | +---------------------------------------------------------------+ | Wi-Fi Channel | 2 | 1 | 0~255 | +---------------------------------------------------------------+ | Wi-Fi BSSID | 3 | 6 | Wi-Fi AP MAC address | +---------------------------------------------------------------+ | Wi-Fi Bandwidth | 4 | 1 | 0 ~ 255 x 10Mbps | +---------------------------------------------------------------+ | | | | 0: IEEE 802.11 a/b/g/n | | Wi-Fi Type | 5 | 1 | 1: Wi-Fi 6 | | | | | 2: Wi-Fi 7 | +---------------------------------------------------------------+ | Cellular RSRQ | 30 | 1 | -255dB ~ 0dB | +---------------------------------------------------------------+ | Cellular RSRP | 31 | 1 | -255dBm ~ 0dBm | +---------------------------------------------------------------+ | Cellular RSSI | 32 | 1 | -255dBm ~ 0dBm | +---------------------------------------------------------------+ | GSM Cell ID | 33 | 4 | 0 ~ 2^32 - 1 | +---------------------------------------------------------------+ | | | | 0: 3G | | Cellular Type | 34 | 1 | 1: 4G LTE | | | | | 2: 5G NR | +---------------------------------------------------------------+ 5.2 Acknowledgement (ACK) Message The "Type" field is set to "2" for ACK messages. The SN field in the GMA header is set to the sequence number of the corresponding request message. The ACK message consists of the following fields: o Request Type (1 Byte): the corresponding request message type, e.g. Probe, etc. o Padding (variable) 0 1 2 3 Zhu Expires February 24, 2021 [Page 13] Internet-Draft GMA Control Protocol August 2023 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Type | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Ack Message Format 5.3 Traffic Splitting Update (TSU) Message The "Type" field is set to "3" for TSU messages. Client (Gateway) may send out a TSU message to change the traffic splitting/steering/duplicating configuration for downlink (uplink) flows. Let's use N to denote the number of delivery connections. A TSU message consists of the following fields: o Link Status Bitmap (1 Byte): see 5.1 o Number of Flows (1 Byte): the number of flows that are configured by the TSU message. For each flow, the following Traffic Splitting control parameters are included: o Flow ID (1 Byte): an unsigned integer to identify the flow. For a flow using the splitting mode, the following parameters (1 + 2N Bytes) SHOULD be included: o L (1 Byte): the total number of packets per traffic splitting cycle, e.g. L = 32, and each packet is assigned an index from 0 to L-1. o K1[i] (N Bytes): the index of the first packet sent over the i-th delivery connection per traffic splitting cycle, where connections are ordered according to their Connection ID and i = 1, 2, ..., N. o K2[i] (N Bytes): the index of the last packet sent over the i-th delivery connection per traffic splitting cycle, where connections are ordered according to their Connection ID and i = 1, 2, ..., N. For example, with N = 2, i.e. two delivery connections, the configuration of K1[1] = K2[1] = 0, K1[2] = K2[2] = 1 and L = 2 indicates sending one packet of every two packets over the first connection, and the other one over the second connection. Zhu Expires February 24, 2021 [Page 14] Internet-Draft GMA Control Protocol August 2023 For a flow using the steering mode, the following parameter (1 Byte) SHOULD be included: o C (1 Byte): the CID of the delivery connection that the flow should be using. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Bitmap |Number of Flows| Flow ID | L | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K1[1] | K1[2] | K2[1] | K2[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow ID | C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: TSU Message Format (N = 2, Number of Flows = 2) Multi-access gateway SHALL always update the UDP tunnel end-point of the client based on the received TSU message. 5.4 Traffic Splitting Acknowledgement (TSA) Message The "Type" field is set to "4" for TSA messages. Gateway (or client) SHALL send out a TSA message in response to a received TSU message. The SN field in the GMA header is set to the sequence number of the corresponding TSU message. A TSA message consists of the following fields: o Number of Flows (1 Byte): the number of flows that are configured by the TSU message. For each flow, the message further consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow. o StartSN (3 Bytes): the Flow SN of the first GMA SDU using the traffic splitting configuration provided by the corresponding TSU message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Number of Flows| Flow ID | StartSN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhu Expires February 24, 2021 [Page 15] Internet-Draft GMA Control Protocol August 2023 | Flow ID | StartSN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ Figure 10: TSA Message Format (Number of Flows = 2) Figure 11 shows the traffic splitting update procedure for downlink traffic, where client performs path quality measurement based on received packets and determines traffic splitting parameters. Once update is needed, client will send the TSU message carrying the new traffic splitting parameters to multi-access gateway. Multi-access gateway will send back the TSA message in response and perform traffic splitting accordingly. The TSA message carries the "StartSN" parameter to indicate the first packet using the new configuration so that client can perform measurements accordingly. client multi-access gateway | | |<------------------ GMA SDU #1 ------------------| |<------------------ GMA SDU #2 ------------------| +--------------------------+ | | path quality measurement | | +--------------------------+ | |------------------ TSU ------------------------->| |<------------------------- TSA(StartSN: 3) ------| |<------------------ GMA SDU #3 ------------------| |<------------------ GMA SDU #4 ------------------| Figure 11: Downlink Traffic Splitting Update Procedure 5.5 Delivery Connection Reconfiguration (DCR) Message The "Type" field is set to "5" for DCR messages. Gateway MAY send out a DCR message to enable or disable a delivery connection for the client. In response, the client SHALL send out an ACK message and stop sending any traffic to a disabled connection. A DCR message consists of the following fields: o Connection Status Bitmap (1 Byte): to indicate the status (0: disabled; 1: enabled) of the i-th delivery connection, where connections are ordered according to their Connection ID similar to Link Status Bitmap (5.1). Zhu Expires February 24, 2021 [Page 16] Internet-Draft GMA Control Protocol August 2023 5.6 Key Update Message The "Type" field is set to "6" for Key Update messages. Gateway MAY send out a Key Update message to change the symmetric key for the client. In response, the client SHALL send out an ACK message and start using the new key to protect GMA control messages. The gateway SHALL start using the new key after receiving the ACK message or a GMA control message with the toggled Key Phase bit. A Key Update message consists of the following fields: o Key Type (1 Byte): to indicate the type of symmetric key + 0: AES256-GCM + Others: reserved If Key Type == 0 o Key Value (32 Bytes): the AES256-GCM key 5.7 Traffic Steering Command (TSC) Message The "Type" field is set to "7" for TSC messages. Multi-access gateway MAY send out a TSC message to configure network-based traffic steering for flows using the steering mode. Let's use N to denote the number of delivery connections. A TSC message consists of the following fields: o Number of Downlink Flows (1 Byte): the number of downlink flows that are configured in the TSC message. o Number of Uplink Flows (1 Byte): the number of uplink flows that are configured in the TSC message. For each flow, the following (4 Bytes) control parameters are included: o Flow ID (1 Byte): an unsigned integer to identify the flow. o Flag (1 Byte) + 0: disable network-based traffic steering (default) + 1: enable network-based traffic steering + Others: reserved o CID (1 Byte): the CID of the delivery connection that the flow will be using (ignored if Flag == 0) o Reserved (1 Byte) After receiving a TSC message, client SHALL send out an ACK message to confirm the successful reception of the TSC message. Zhu Expires February 24, 2021 [Page 17] Internet-Draft GMA Control Protocol August 2023 5.8 Traffic Splitting Command (TSP) Message The "Type" field is set to "8" for TSP messages. Multi-access gateway MAY send out a TSP message to configure network-based traffic splitting for downlink flows using the splitting mode. Let's use N to denote the number of delivery connections. A TSC message consists of the following fields: o Number of Flows (1 Byte): the number of downlink flows that are configured in the TSP message For each flow, the following control parameters are included: o Flow ID (1 Byte): an unsigned integer to identify the flow o Flag (1 Byte) + 0: disable network-based traffic splitting (default) + 1: enable network-based traffic splitting + Others: reserved If (Flag == 1), include the following parameters: o L (1 Byte): the total number of packets per traffic splitting cycle, e.g. L = 32, and each packet is assigned an index from 0 to L-1. o K1[i] (N Bytes): the index of the first packet sent over the i-th delivery connection per traffic splitting cycle, where connections are ordered according to their Connection ID and i = 1, 2, ..., N. o K2[i] (N Bytes): the index of the last packet sent over the i-th delivery connection per traffic splitting cycle, where connections are ordered according to their Connection ID and i = 1, 2, ..., N. After receiving a TSP message, client SHALL send out an ACK message to confirm the successful reception of the TSP message. 5.9 QoS Testing Request (QTR) Message The "Type" field is set to "9" for QTR messages. Multi-access client MAY send out a QTR message to request QoS testing for a flow. A QTR message consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow for QoS testing. o Traffic Direction (1 Byte): an unsigned integer to indicate the direction of flow (0: downlink, 1: uplink, 2: both) Zhu Expires February 24, 2021 [Page 18] Internet-Draft GMA Control Protocol August 2023 o CID (1 Byte): the CID of the delivery connection that the QoS testing will be performed. o Test Duration (2 Byte): an unsigned integer to indicate the testing duration in ms. 5.10 QoS Testing Response (QTP) Message The "Type" field is set to "10" for QTP messages. Multi-access gateway MAY send out a QTP message to indicate if QoS testing for an uplink flow is successful or not. A QTP message consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow o CID (1 Byte): the CID of the delivery connection that the QoS testing has been performed o Status: an unsigned integer to indicate the result of QoS testing (0: success; 1: failure) 5.11 QoS Testing Notification (QTN) Message The "Type" field is set to "11" for QTN messages. Gateway MAY send out a QTN message to start QoS testing for a flow. A QTN message consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow for QoS testing. o Traffic Direction (1 Byte): an unsigned integer to indicate the direction of flow (0: downlink, 1: uplink, 2: both) o CID (1 Byte): the CID of the delivery connection that the QoS testing will be performed. o Test Duration (2 Byte): an unsigned integer to indicate the testing duration in ms. 5.12 QoS Violation Notification (QVN) Message The "Type" field is set to "12" for QVN messages. Gateway MAY send out a QVN message to indicate that QoS violation has been detected or is expected for a flow. A QVN message consists of the following fields: o N1 (1 Byte): Number of uplink flows with QoS violation o N2 (1 Byte): Number of downlink flows with QoS violation o Uplink Flow ID (1 Byte x N1): an unsigned integer to identify uplink flow with QoS violation. o Downlink Flow ID (1 Byte x N2): an unsigned integer to identify downlink flow with QoS violation. Zhu Expires February 24, 2021 [Page 19] Internet-Draft GMA Control Protocol August 2023 5.13 Packet Loss Report (PLR) Message The "Type" field is set to "13" for PLR messages. Client (Gateway) MAY send out the PLR messages to report lost GMA SDUs for example during handover. In response, gateway (client) may retransmit lost GMA SDUs accordingly. A PLR message consists of the following fields: o Number of Flows (1 Byte): the number of flows For each flow, the following control parameters are included: o Flow ID (1 Byte): an unsigned integer to identify the flow o ACK number (3 Bytes): the next (in-order) sequence number (SN) that the sender of the PLR message is expecting o Number of Loss Bursts (1 Byte) For each loss burst, include the following + Flow SN of the first lost GMA SDU in a burst (3 Bytes) + Number of consecutive lost SDUs in the burst (1 Byte) 5.14 First Sequence Number (FSN) Message The "Type" field is set to "14" for FSN messages. Client (Gateway) MAY send out the FSN messages to indicate the oldest SDU in its buffer if a lost SDU is not found in the buffer after receiving the PLR message from multi-access gateway (client). In response, gateway (client) MUST NOT report packet loss with Flow SN smaller than FSN. A FSN message consists of the following fields: o Number of Flows (1 Byte): the number of flows For each flow, the following control parameters are included: o Flow ID (1 Byte): an unsigned integer to identify the flow o First Sequence Number (3 Bytes): the sequence number (SN) of the oldest SDU in the (retransmission) buffer of the sender of the FSN message. 5.15 Coding Configuration Request (CCR) Message The "Type" field is set to "15" for CCR messages. Zhu Expires February 24, 2021 [Page 20] Internet-Draft GMA Control Protocol August 2023 Client (Gateway) MAY send out the CCR message to support downlink (or uplink) packet loss recovery through systematic network coding, e.g. XOR [CTCP]. In response, gateway (client) SHALL send out the ACK message to indicate the successful reception. It supports XOR and Reed-Solomon currently. Other network coding techniques, e.g. Random Linear Network Code (RLNC) [RLNC], Raptor Code [RC], etc., MAY be added in the future. A CCR message consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow o Coding Type (1 Byte) + 0: None + 1: XOR + 2: (Systematic) Reed-Solomon [RS] + Others: reserved o N (1 Bytes): the number of consecutive (uncoded) GMA SDUs used to generate the coded GMA SDU If Coding Type = (Systematic) Reed-Solomon, include the following: + M (1 Bytes): the number of coded (parity) GMA SDUs generated for every N consecutive uncoded GMA SDUs. + L (1 Bytes): the symbol size for the RS code finite field, i.e., the maximum codeword length (N + M) is given by 2^L- 1. 5.16 Coded GMA SDU (CGS) Message The "Type" field is set to "16" for CGS messages. Client (or gateway) may send out the CGS message to support downlink (or uplink) packet loss recovery through systematic network coding [CTCP]. A coded GMA SDU is generated by applying a network coding method to multiple consecutive (uncoded) GMA SDUs, which are transmitted as is without any changes. It is used for fast recovery without retransmission if any of the GMA SDUs is lost. The Flow SN field (as shown in Figure 5) MUST NOT be included in the GMA header of a CGS message. A CGS message MAY be protected with authentication or encryption only if the delivery connection is untrusted. A Coded GMA SDU message consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow. o Flag (1 Byte) Zhu Expires February 24, 2021 [Page 21] Internet-Draft GMA Control Protocol August 2023 + Bit #0: to indicate if the CGS message uses the same coding configuration as its previous CGS message or not. This bit is flipped whenever a new configuration is used. + Bit #1: to indicate if the FC field is present or not. + Bit #2~7: reserved o Fragmentation Control (FC) (1 Byte): to provide necessary information for re-assembly. + Bit #0: a More Fragment (MF) flag to indicate if the fragment is the last one (0) or not (1). + Bit #1~#7: Fragment Offset (in units of fragments) to specify the offset of a particular fragment relative to the beginning of the SDU. o Flow SN (3 Bytes): the Flow SN of the first (uncoded) GMA SDU used to generate the coded GMA SDU, updated every N GMA SDUs o C-SN (1 Bytes): the sequence number (0 ~ M-1) of the coded GMA SDU carried by the CGS message, reset to "0" every N GMA SDUs. o Coded GMA SDU (variable): if the Coded GMA SDU is too long, it can be fragmented and transported by multiple CGS messages. 5.17 Coding Configuration Command (CCC) Message The "Type" field is set to "17" for CCC messages. Multi-access gateway MAY send out a CCC message to configure network coding for downlink flows. A CCC message consists of the following fields: o Flow ID (1 Byte): an unsigned integer to identify the flow o Flag (1 Byte) + 0: disable network-based network coding (default) + 1: enable network-based network coding + Others: reserved If "Flag == 1", include the following fields o Coding Type (1 Byte) + 0: None + 1: XOR + 2: Reed-Solomon + Others: reserved o N (1 Bytes): the number of consecutive (uncoded) GMA SDUs used to generate the coded GMA SDU If Coding Type = Reed-Solomon, include the following: + M (1 Byte): the number of coded (parity) GMA SDUs generated for every N consecutive uncoded GMA SDUs. Zhu Expires February 24, 2021 [Page 22] Internet-Draft GMA Control Protocol August 2023 + L (1 Byte): the symbol size for the RS code finite field, i.e., the maximum codeword length (N + M) is given by 2^L- 1. After receiving a CCC message, client SHALL send out an ACK message to confirm the successful reception of the CCC message. 6 Basic GMA Control Procedures GMA control sequence consists of the following three phases: o Phase 1 (Initialization): client and gateway exchange MAMS messages [MAMS] to configure the GMA-based multi-access traffic management. o Phase 2 (GMA Operation): client and gateway exchange GMA control messages as defined in this document to manage traffic steering/splitting/duplicating across multiple connections. o Phase 3 (Termination): client and gateway exchange MAMS messages to terminate the GMA operation. 6.1 Initialization Client may trigger the initialization procedure once detecting any one of the delivery connections, e.g. Wi-Fi, LTE, etc., becomes available. Figure 12 shows the MAMS message exchange sequence to activate the GMA operation. Please refer to [MAMS] for more details about the MAMS messages. Client multi-access Gateway | | |------- MX Discover Message ----------------------->| | | |<----------------------------- MX System Info ------| | | |------------------------------ MX Capability REQ -->| |<----- MX Capability RSP ---------------------------| |------------------------------ MX Capability ACK -->| | | |<-------------------- MX UP Setup Config -----------| |-------- MX UP Setup Confirmation ----------------->| | | Figure 12: MAMS-based Initialization Procedure Zhu Expires February 24, 2021 [Page 23] Internet-Draft GMA Control Protocol August 2023 To support the virtual (anchor) connection specified in this document, the MX Capability REQ message SHOULD include the following additional information: o Last IP address: the virtual IP address used in the last MAMS session o Last MAMS session ID: the unique session id of the last MAMS session Moreover, the MX Capability REQ/RSP message SHOULD indicate the following GMA capabilities for downlink and uplink, respectively: o Maximum number of flows with the redundancy mode o Maximum number of flows with the splitting mode o Maximum number of flows with the steering mode o Network-based traffic steering (7.1) o QoS-aware traffic steering (7.2) o GMA-based retransmission (7.3) o Receiver-based network coding (7.4) o Network-based network coding (7.5) o Network coding method (XOR, Reed-Solomon, or others) The MX UP Setup Config message SHOULD include the following additional information: o Client ID: see Figure 5 o Client IP address: the client IP address of the virtual anchor connection. o Gateway IP address: the gateway IP address the virtual anchor connection o DNS server: the DNS server IP address of the virtual anchor connection o Subnet mask: the subnet mask of the virtual anchor connection o MAMS port: the TCP port number at the multi-access Gateway for exchange MAMS messages over the virtual anchor connection o Key: the symmetric encryption (e.g. AES256-GCM) key to protect GMA payload o Untrusted CID List: the list of "untrusted" delivery connections where GMA data SDU MUST be protected by the symmetric encryption key. o Best-Effort CID List: the list of "best-effort" delivery connections where QoS-aware traffic steering procedure (7.2) SHOULD be used for moving a flow with specific QoS requirements (maximum delay or loss rate) to the connection. Zhu Expires February 24, 2021 [Page 24] Internet-Draft GMA Control Protocol August 2023 6.2 GMA Operation After completing the initialization phase successfully, client will start the GMA operation phase by sending out probes to decide if a delivery connection is connected and can be used for data transfer. After successful probing, client will activate the virtual anchor connection based on the information in the MX UP Setup Config message and start (GMA-based) multi-access traffic management. If client's local clock is already synchronized with multi-access gateway, both client and gateway SHOULD use their local clock as the timestamp clock directly. Otherwise, client will send out the Probe-Sync message to reset the timestamp clock. Afterwards, client MAY send out the Probe-Sync message periodically to reset the timestamp clock. During the GMA operation, client SHOULD continuously perform path quality measurements (e.g. one-way delay, loss, etc.) based on probing as well as received data packets, and manage traffic across all available connections accordingly. How and when to trigger probing as well as how to perform path quality measurements are left to implementation, and not considered in this document. Moreover, it is up to client implementation which delivery connection is used to send control messages, e.g. TSU, etc. However, the ACK message SHALL use the same delivery connection as its corresponding control message. If client decides to update the traffic splitting configuration for downlink flows, it SHOULD send out the TSU message to gateway, notifying the updated configuration, and gateway SHOULD send out the TSA message to confirm the update and also indicate the Flow SN Of the first packet with the updated configuration. For uplink flow using the steering mode, client SHOULD control how to steer traffic without any GMA control message exchange with multi-access gateway. For uplink flow using the splitting mode, multi-access gateway SHOULD perform measurements based on received data packets and send the TSU message to client for updating the traffic splitting configuration. Client multi-access Gateway | | +--------------+ | | Link x is up | | +--------------+ | Zhu Expires February 24, 2021 [Page 25] Internet-Draft GMA Control Protocol August 2023 |---------------------------- Probe (over Link x) -->| |<----- ACK (over Link x) ---------------------------| | | +----------------------------------------+ | | activate the virtual anchor connection | | | and start the GMA operation | | +----------------------------------------+ | | | | | |---------------------------- Probe-Sync ----------->| | +----------------+ | |reset timestamp | | +----------------+ |<----- ACK -----------------------------------------| +---------------+ | |reset timestamp| | +---------------+ | | | +----------------------------------------+ | | perform path quality measurement based | | | on probes and data packets, and decide | | | to steer traffic over Link x | | +----------------------------------------+ | |------------------------------ TSU (over Link x)--->| |<----- TSA (over Link x)----------------------------| Figure 13: GMA-based Multi-Access Traffic Management Procedure 6.3 Termination Client may trigger the termination procedure to stop the GMA operation at any time. Figure 14 shows the MAMS message exchange sequence to terminate the GMA operation. Client multi-access Gateway | | |------- MX Termination Request--------------------->| | | |<------------------------ MX Termination Response---| Figure 14: MAMS-based Termination Procedure Zhu Expires February 24, 2021 [Page 26] Internet-Draft GMA Control Protocol August 2023 7 Advanced GMA Control Procedure 7.1 Network-based Traffic Steering Multi-access gateway may trigger steering a flow from one delivery connection to another, aka Network-based Traffic Steering. Figure 15 shows the procedure with the TSC (Traffic Steering Command) message as defined in 5.7. For downlink traffic, client SHALL send out a TSU message to confirm changing the delivery connection. For uplink traffic, no additional control message exchange is required. If the Flag field in the TSC message is set to "0", network-based traffic steering is disabled for the flow and client SHALL decide how to steer the flow based on its local information. If the Flag field in the TSC message is set to "1", network-based traffic steering is enabled for the flow and the delivery connection specified in the TSC message SHOULD be used for the flow. Client multi-access Gateway | | |<-------------- flow #1 over link x --------------->| | +-------------------------------------------+ | |collect measurement from network and decide| | |to steer traffic over link y | | +-------------------------------------------+ |<---------------- TSC (steer flow #1 to link y)-----| |------- ACK --------------------------------------->| +-----------+ | |accept TSC | | +-----------+ | |--------------- flow #1 uplink over link y -------->| | | |------- TSU --------------------------------------->| |<-----------------------------------------TSA ------| | | |<-------------- flow #1 downlink over link y -------| | | Figure 15: Network-based Traffic Steering Procedure Zhu Expires February 24, 2021 [Page 27] Internet-Draft GMA Control Protocol August 2023 Figure 16 shows the similar procedure to support network-based downlink traffic splitting with the TSP message as defined in 5.8. Network-based uplink traffic splitting is always controlled by multi-access gateway using the TSU/TSA message exchange. Client multi-access Gateway | | |<---------- (downlink) flow #1 over link x & y------| | +-------------------------------------------+ | |collect measurement from network and decide| | |to update traffic splitting ratio | | +-------------------------------------------+ |<-------TSP (updated splitting ratio for flow #1)---| |------- ACK --------------------------------------->| +-----------+ | |accept TSP | | +-----------+ | | | |------- TSU --------------------------------------->| |<-----------------------------------------TSA ------| | | |<--------- flow #1 (updated splitting ratio)--------| | | Figure 16: Network-based Downlink Traffic Splitting Procedure 7.2 QoS-aware Traffic Steering Client SHOULD request QoS testing for a flow that has specific QoS requirements, e.g. maximum delay or/and loss rate, over a (best- effort) delivery connection, e.g. Wi-Fi, that can not guarantee QoS, before steering the flow to the connection. Figure 17 shows the QoS-aware traffic steering procedure. At the very beginning, a flow (e.g. uplink flow #1) is delivered over the connection (e.g. Cellular) that can guarantee its QoS requirements. Once a best-effort connection (e.g. Wi-Fi) becomes available, client SHOULD send out the QTR message to request QoS testing. In response, multi-access gateway SHOULD decide when to start the testing and send out the QTN message. During QoS testing, multi-access gateway (or client) SHOULD duplicate downlink (or uplink) traffic of the flow over the testing connection as indicated in the QTN message. All duplicated packets SHALL be discarded by the receiving side, and only used Zhu Expires February 24, 2021 [Page 28] Internet-Draft GMA Control Protocol August 2023 for testing. In the meantime, they SHOULD be marked with low priority to minimize their impact to other flows that have already been steered to the best-effort connection. If uplink testing is performed, multi-access gateway SHALL send out the QTP message to indicate the testing result. If the testing is successful, client SHOULD send out the TSU message to steer the flow to the best-effort connection. Afterwards, multi-access gateway SHOULD continue measuring and monitoring the QoS performance of the flow. Once detecting any QoS violation, multi-access gateway MAY send the QVN message to client. In response, client SHOULD send the TSU message to steer the flow back to the QoS-guaranteed connection. For downlink flow, client SHOULD perform QoS measurement and violation detection, and send the TSU message to steer the flow back to the QoS-guaranteed connection once detecting QoS violation. Client multi-access Gateway | | |-------- (uplink) flow #1 over link x ------------->| +--------------+ | | link y is up | | +--------------+ | | | |------- QTR (req testing flow #1 over link y)------>| |<-------------------- ACK --------------------------| | | |<------ QTN (start testing flow #1 over link y)-----| |--------------------- ACK ------------------------->| | | |----duplicating flow #1 over link y --------------->| | | | +-------------------------------------------+ | |collect measurement and drop all duplicated| | |packets received from link y | | +-------------------------------------------+ | | |<--------------------- QTP (result: success)--------| |--------------------- ACK ------------------------->| | | |--------------------- TSU ------------------------->| Zhu Expires February 24, 2021 [Page 29] Internet-Draft GMA Control Protocol August 2023 |<--------------------- TSA -------------------------| | | |-------- flow #1 over link y ---------------------->| | | | +--------------------------------------------+ | |collect measurement and detect QoS violation| | +--------------------------------------------+ |<-------------------- QVN (flow #1)-----------------| |--------------------- ACK ------------------------->| | | |--------------------- TSU ------------------------->| |<--------------------- TSA -------------------------| |-------- flow #1 over link x ---------------------->| | | Figure 17: QoS-aware Traffic Steering Procedure 7.3 GMA-based Retransmission Figure 7 shows the GMA-based retransmission procedure in an example. The first lost packet is found and retransmitted. However, the second lost packet is not found, and the FSN message is sent out to notify the client. Client Gateway | | |<------------------ GMA SDU (data packets)--| | | +---------------------+ | |Packet Loss detected | | +---------------------+ | | | |----- PLR Message ------------------------->| | +---------------------+ | |Lost packet found | | +---------------------+ |<-------------retransmit(lost)MX SDUs ------| |<------------------ GMA SDU (data packets)--| | | +----------------------+ | |Packet Loss detected | | +----------------------+ | | | Zhu Expires February 24, 2021 [Page 30] Internet-Draft GMA Control Protocol August 2023 |----- PLR Message ------------------------->| | +---------------------+ | |Lost packet not found| | +---------------------+ |<-------------FSN message ------------------| Figure 18: GMA-based Retransmission Procedure 7.4 Receiver-based Network Coding Figure 19 shows the receiver-based network coding procedure (using XOR) for downlink traffic. In this example, client first detects packet loss, and then sends out a CCR message to activate network coding, including all the required parameters, e.g. Network Coding Type, N, and M. In this example, XOR is configured as the coding method with N = 2. In response, gateway starts sending one CGS message carrying the coded GMA SDU for every two (uncoded) GMA SDUs. Afterwards, client MAY send out a CCR message with Network Coding Type set to "None" to deactivate network coding for a downlink flow. Client Gateway | | |<------------------ GMA SDUs(data packets)--| | | +---------------------+ | |Packet Loss detected | | +---------------------+ | | | |------CCR Message (XOR, N=2)--------------->| |<------------------- ACK Message -----------| | | |<------------------ GMA SDU #1 -------------| | lost<-------- GMA SDU #2 -------------| |<-- CGS Message (GMA SDU #1 XOR GMA SDU #2)-| +----------------------+ | | GMA SDU #2 recovered | | +----------------------+ | | | |------CCR Message (None) ------------------>| |<------------------- ACK Message -----------| |<------------------ GMA SDU #3 -------------| |<------------------ GMA SDU #4 -------------| Zhu Expires February 24, 2021 [Page 31] Internet-Draft GMA Control Protocol August 2023 |<------------------ GMA SDU #5 -------------| Figure 19: Receiver-based Network Coding Procedure for Downlink 7.5 Network-based Network Coding Figure 20 shows the network-based network coding procedure (using XOR) for downlink traffic. In this example, gateway first collect measurements and then sends out a CCC message to activate network coding with the required parameters, e.g. Network Coding Type, N, and M. In this example, XOR is configured as the coding method with N = 2. After the CCC message is successfully acknowledged, gateway starts sending one CGS message carrying the coded GMA SDU for every two (uncoded) GMA SDUs. Afterwards, gateway MAY send out a CCC message with Network Coding Type set to "None" to deactivate network coding for the flow. Notice that network-based network coding for uplink follows the receiver-based procedure as in 7.4 using the CCR message, because gateway is the receiver for uplink traffic. Client Gateway | | |<------------------ GMA SDUs(data packets)--| | | | +-------------------------------------------+ | |collect measurement from network and decide| | |to activate network coding | | +-------------------------------------------+ | | |<-----CCC Message (XOR, N=2)----------------| |-------------------- ACK Message ---------->| | | |<------------------ GMA SDU #1 -------------| | lost<-------- GMA SDU #2 -------------| |<-- CGS Message (GMA SDU #1 XOR GMA SDU #2)-| +----------------------+ | | GMA SDU #2 recovered | | +----------------------+ | | | |<-----CCC Message (None) -------------------| |-------------------- ACK Message ---------->| |<------------------ GMA SDU #3 -------------| |<------------------ GMA SDU #4 -------------| Zhu Expires February 24, 2021 [Page 32] Internet-Draft GMA Control Protocol August 2023 |<------------------ GMA SDU #5 -------------| Figure 20: Network-based Network Coding Procedure for Downlink 8 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. 9 IANA Considerations This document makes no requests of IANA. 10 Contributing Authors The editors gratefully acknowledge the following additional contributors in alphabetical order: Wei Mao/Intel, Hosein Nikopour/Intel. 11 References 11.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 May 2017, . [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", . [QUIC] RFC 9000, "QUIC: A UDP-Based Mutiplexed and Secure Transport", Zhu Expires February 24, 2021 [Page 33] Internet-Draft GMA Control Protocol August 2023 11.2 Informative References [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access Management Services (MAMS)https://tools.ietf.org/rfc/rfc8743.txt [IANA] https://www.iana.org/assignments/protocol- numbers/protocol-numbers.xhtml [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP) encapsulation; Protocol specification" [RFC791] Internet Protocol, September 1981 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch and splitting support in the 5G system architecture. [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, . [ATSSS2] M. Boucadair, et al. 3GPP Access Traffic Steering Switching and Splitting (ATSSS) - Overview for IETF Participants, < https://datatracker.ietf.org/doc/html/draft- bonaventure-quic-atsss-overview-00> [GMAE] J. Zhu, et al. Generic Multi-Access (GMA) Encapsulation, Protocolhttps://www.ietf.org/archive/id/draft-zhu- intarea-gma-10.txt [GCC] S. Holmer, et al. A Google Congestion Control Algorithm for Real-Time Communication, https://www.ietf.org/archive/id/draft-ietf-rmcat-gcc- 02.txt [MPIP] L. Sun, et al. Multipath IP Routing on End Devices: Motivation, Design, and Performance, [QUICTLS] M. Thomson and S. Turner, Using TLS to Secure QUIC, https://www.rfc-editor.org/rfc/rfc9001.txt [GMA] https://github.com/IntelLabs/gma Zhu Expires February 24, 2021 [Page 34] Internet-Draft GMA Control Protocol August 2023 [CTCP] Simone Ferlin, et al., MPTCP meets FEC: Supporting Latency-Sensitive Applications over Heterogeneous Networks, IEEE Transactions on Networking, Oct 2018 [RLNC] T. Ho, M. Medard, R. Koetter, D. Karger, M. Effros, J. Shi and B. Leong, "A random linear network coding approach to multicast," IEEE Transactions on Information Theory, vol. 52, no. 10, pp. 4413-4430, 2006. [RC] A. Shokrollahi, "Raptor codes," in IEEE Transactions on Information Theory, vol. 52, no. 6, pp. 2551-2567, June 2006, doi: 10.1109/TIT.2006.874390. [RS] I. Reed and G. Solomon, "Polynomial codes over certain finite fields," Journal of the Society for Industrial and Applied Mathematics, vol. 8, no. 2, pp. 300-304, 1960. Authors' Addresses Jing Zhu Intel Email: jing.z.zhu@intel.com Menglei Zhang Intel Email: menglei.zhang@intel.com Zhu Expires February 24, 2021 [Page 35]