idnits 2.17.1 draft-zhu-intarea-gma-control-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 562 has weird spacing: '... SN of the ...' == Line 586 has weird spacing: '...traffic split...' == Line 621 has weird spacing: '...message is s...' -- The document date (April 11, 2022) is 744 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 535 -- Looks like a reference, but probably isn't: '2' on line 535 == Unused Reference: 'IANA' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC8900' is defined on line 822, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Zhu 2 Internet Draft M. Zhang 3 Intended status: Experimental Intel 4 Expires: October 11,2022 5 April 11, 2022 7 UDP-based Generic Multi-Access (GMA) Control Protocol 9 draft-zhu-intarea-gma-control-01 11 Abstract 13 A device can be simultaneously connected to multiple networks, 14 e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly 15 combine the connectivity over these networks below the transport 16 layer (L4) to improve quality of experience for applications that 17 do not have built in multi-path capabilities. This document 18 presents a new control protocol to manage traffic steering, 19 splitting, and duplicating across multiple connections. The 20 solution has been developed by the authors based on their 21 experiences in multiple standards bodies including the IETF and 22 3GPP, is not an Internet Standard and does not represent the 23 consensus opinion of the IETF. This document will enable other 24 developers to build interoperable implementations in order to 25 experiment with the protocol. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet-Drafts 40 as reference material or to cite them other than as "work in 41 progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on October 11, 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction ................................................. 2 68 1.1. Scope of Experiment ....................................4 69 2. Conventions used in this document ............................ 5 70 3. Use Case ..................................................... 5 71 4. UDP-based GMA Encapsulation Protocol ......................... 6 72 5. GMA Control Messages ......................................... 9 73 5.1 Probe Message .........................................9 74 5.2 Acknowledgement (ACK) Message ........................10 75 5.3 Traffic Splitting Update (TSU) Message ...............11 76 5.4 Traffic Splitting Acknowledgement (TSA) Message ......12 77 5.5 Timestamp Reset Request (TSR) Message ................14 78 6. GMA Control Flows ........................................... 14 79 6.1. Initialization ........................................14 80 6.2. GMA Operation .........................................15 81 6.3. Termination ...........................................17 82 7. Security Considerations ..................................... 17 83 8. IANA Considerations ......................................... 18 84 9. References .................................................. 18 85 9.1. Normative References ..................................18 86 9.2. Informative References ................................18 88 1. Introduction 90 A device can be simultaneously connected to multiple networks, 91 e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly 92 combine the connectivity over these networks below the transport 93 layer (L4) to improve quality of experience for applications that 94 do not have built in multi-path capabilities. 96 Figure 1 shows the Multi-Access Management Service (MAMS) user- 97 plane protocol stack [MAMS], which has been used in today's multi- 98 access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. It consists of 99 two layers: convergence and adaptation. 101 The convergence layer is responsible for multi-access operations, 102 including multi-link (path) aggregation, splitting/reordering, 103 lossless switching/retransmission, etc. It operates on top of the 104 adaptation layer in the protocol stack. From the perspective of a 105 transmitter, a user payload (e.g., IP packet) is processed by the 106 convergence layer first, and then by the adaptation layer before 107 being transported over a delivery connection; from the receiver's 108 perspective, an IP packet received over a delivery connection is 109 processed by the adaptation layer first, and then by the 110 convergence layer. 112 +-----------------------------------------------------+ 113 | User Payload, e.g., IP Protocol Data Unit (PDU) | 114 +-----------------------------------------------------+ 115 +-----------------------------------------------------------+ 116 | +-----------------------------------------------------+ | 117 | | Multi-Access (MX) Convergence Layer | | 118 | +-----------------------------------------------------+ | 119 | +-----------------------------------------------------+ | 120 | | MX Adaptation | MX Adaptation | MX Adaptation | | 121 | | Layer | Layer | Layer | | 122 | +-----------------+-----------------+-----------------+ | 123 | | Access #1 IP | Access #2 IP | Access #3 IP | | 124 | +-----------------------------------------------------+ | 125 | MAMS User-Plane Protocol Stack | 126 +-----------------------------------------------------------+ 128 Figure 1: MAMS User-Plane Protocol Stack [MAMS] 130 A new encapsulation protocol [GMAE] has been specified for the 131 convergence layer to encode additional control information, e.g., 132 Timestamp, Sequence Number, required for multi-access traffic 133 management. This document presents a UDP-based GMA control 134 protocol for the convergence layer. The GMA control protocol only 135 operates between endpoints that have been configured to use GMA. 136 This configuration can be through any management messages and 137 procedures, including, for example, Multi-Access Management 138 Services [MAMS]. 140 The solution described in this document was been developed by the 141 authors based on their experiences in multiple standards bodies 142 including the IETF and 3GPP. However, it is not an Internet 143 Standard and does not represent the consensus opinion of the IETF. 144 This document presents the protocol specification to enable 145 experimentation as described in Section 1.1 and to facilitate 146 other interoperable implementations. 148 1.1. Scope of Experiment 150 The protocol described in this document is an experiment. One 151 objective of the experiment is to determine whether the protocol 152 meets the 3GPP ATSSS Phase 2 [ATSSS2] requirements, can be safely 153 used, and has support for deployment. Particularly, the proposed 154 GMA protocol addresses the following issues of using QUIC for 155 ATSSS Phase 2: 157 o Encapsulation Overhead: the GMA encapsulation protocol uses a 2- 158 bytes Flag field to control all optional header fields instead 159 of the TLV (Type-Length-Value) based approach. As a result, the 160 minimum encapsulation overhead is 2 bytes, and the maximum 161 overhead is 16 bytes. 162 o Multiple Encryptions: the GMA encapsulation protocol does not 163 require encryption and avoids redundant encryption overhead. 164 o Congestion Control in Congestion Control: the GMA control 165 protocol does not require congestion control. All incoming 166 packets (from higher layer) are sent over one of the delivery 167 connections immediately without any delay due to congestion 168 control. 170 In addition, the GMA protocol does not require Acknowledgement 171 (ACK) and reliable delivery for data-plane traffic to avoid any 172 delay due to retransmission as well as any ACK traffic overhead on 173 the reverse path. 175 Path quality measurements (e.g. one-way-delay, loss, etc.) and 176 congestion detection are performed by receiver based on the GMA 177 header fields, e.g. sequence number, timestamp, etc. Another 178 objective of the experiment is to evaluate the usage of various 179 receiver-based congestion detection algorithms [GCC] [MPIP] in 180 multi-access traffic management. 182 It is expected that this protocol experiment can be conducted on 183 the Internet since the GMA packets are encapsulated with UDP. 184 Thus, experimentation is conducted between consenting end systems 185 that have been mutually configured to participate in the 186 experiment. 188 The authors will continually assess the progress of this 189 experiment and encourage other implementers to contact them to 190 report the status of their implementations and their experiences 191 with the protocol. 193 2. Conventions used in this document 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 196 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 197 "MAY", and "OPTIONAL" in this document are to be interpreted as 198 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 199 appear in all capitals, as shown here. 201 3. Use Case 203 As shown in Figure 2, a client device (e.g., Smartphone, Laptop, 204 etc.) may connect to the Internet via both Wi-Fi and LTE 205 connections, operating as the delivery connection. In addition, a 206 virtual (e.g. IPv4, IPv6, or Ethernet) connection is established 207 between client and multi-access gateway. The virtual connection is 208 the anchor, providing the IP address and connectivity for end-to- 209 end Internet access, and delivery connection provides multiple 210 paths between client and multi-access gateway for multi-access 211 traffic management, aka Access Traffic Steering, Switching, and 212 Splitting (ATSSS) in 3GPP [ATSSS]. 214 +------- Virtual (anchor) Connection ------+ 215 | | 216 +-+---+ +---+-+ 217 | | |A|--- LTE (delivery) Connection --|C| | | 218 Apps ---|X|U|-| |-|S|Z|--- Internet 219 | | |B|-- Wi-Fi (delivery) Connection--|D| | | 220 +-+---+ +---+-+ 221 Client multi-access Gateway 223 o A: The adaptation layer endpoint of the LTE connection in the 224 client 225 o B: The adaptation layer endpoint of the Wi-Fi connection in the 226 client 227 o C: The adaptation layer endpoint of the LTE connection in the 228 multi-access gateway 229 o D: The adaptation layer endpoint of the Wi-Fi connection in the 230 multi-access gateway 231 o U: The convergence layer endpoint in the client 232 o S: The convergence layer endpoint in the multi-access gateway 233 o X: The virtual connection endpoint in the client 234 o Z: The virtual connection endpoint in the multi-access gateway 236 Figure 2: GMA-based Multi-Access Traffic Management 238 For example, the virtual connection could be a Multi-Access 239 Protocol Data Unit (MA-PDU) connection as specified in 3GPP 240 [ATSSS]. Per-packet aggregation allows the MA-PDU connection to 241 use the combined bandwidth of the two connections. Moreover, 242 packets may be duplicated over multiple connections to achieve 243 high reliability and low latency, where duplicated packets are 244 eliminated by the receiving side. Such multi-access optimization 245 requires additional control message exchange between client and 246 multi-access gateway. 248 "UDP" is used for the adaptation layer in this document. Figure 3a 249 and 3b show the UDP-based GMA user-plane and control-plane 250 protocol, respectively. 252 +-----------------------------------------------------+ 253 | Virtual Connection (IP, Ethernet, etc.) | 254 +-----------------------------------------------------+ 255 | UDP-based GMA Encapsulation protocol | 256 +-----------------------------------------------------+ 257 | UDP | UDP | UDP | 258 +-----------------+-----------------+-----------------+ 259 | Access #1 IP | Access #2 IP | Access #3 IP | 260 +-----------------------------------------------------+ 262 Figure 3a: UDP-based GMA User-Plane Protocol Stack 264 +-----------------------------------------------------+ 265 | GMA Control Protocol | 266 +-----------------------------------------------------+ 267 | UDP-based GMA Encapsulation protocol | 268 +-----------------------------------------------------+ 269 | UDP | UDP | UDP | 270 +-----------------+-----------------+-----------------+ 271 | Access #1 IP | Access #2 IP | Access #3 IP | 272 +-----------------------------------------------------+ 274 Figure 3b: UDP-based GMA Control-Plane Protocol Stack 276 4. UDP-based GMA Encapsulation Protocol 278 Figure 4 shows the UDP-based GMA encapsulation format as specified 279 in [GMAE]. The ports for "UDP Tunnelling" at Client are chosen 280 from the Dynamic Port range, and the ports for "UDP Tunnelling" at 281 multi-access gateway are configured and provided to client through 282 the MAMS message (MX UP Setup Config) [MAMS]. 284 +------------------------------------------------+ 285 | IP hdr | UDP hdr | GMA Header | Payload | 286 +------------------------------------------------+ 287 Figure 4: UDP-based GMA PDU Format 289 The GMA (Generic Multi-Access) header MUST consist of the 290 mandatory "Flags" field (the first two bytes), defined as follows: 292 o Client ID Present (bit 0): If the Client ID Present bit is set 293 to 1, then the Client ID field is present 294 o Flow ID Present (bit 1): If the Flow ID Present bit is set to 1, 295 then the Flow ID field is present 296 o Per-Packet Priority (PPP) Present (bit 2): If the PPP Present 297 bit is set to 1, then the PPP field is present 298 o SN Present (bit 3): If the SN (Sequence Number) Present bit is 299 set to 1, then the Delivery and Flow SN fields are present and 300 contains the valid information 301 o Timestamp Present (bit 4): If the Timestamp Present bit is set 302 to 1, then the Timestamp field is present 303 o Reserved (bit 5-15): set to "0" and ignored on receipt 305 Bit 0 is the most significant bit (MSB), and Bit 15 is the least 306 significant bit (LSB). 308 The Receiver SHOULD first decode the Flags field to determine the 309 length of the GMA header, and then decode each optional field 310 accordingly. The GMA (Generic Multi-Access) header MAY consist of 311 the following optional fields: 313 o Client ID (2 Byte): an unsigned integer to identify the client 314 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 315 of the GMA SDU. 316 o Per-Packet Priority (1 Byte): an unsigned integer to identify 317 the relative priority of the GMA SDU in the flow (smaller 318 value means higher priority). 319 o Delivery SN (1 Byte): an auto-incremented integer to indicate 320 the GMA PDU transmission order on a delivery connection. 321 Delivery SN is used to measure packet loss of each delivery 322 connection and therefore generated per delivery connection 323 per flow. This field is present only if the Delivery SN 324 Present bit is set to one. 325 o Flow SN (3 Bytes): an auto-incremented integer to indicate the 326 GMA SDU (IP packet) order of a flow. Flow SN is used for 327 reordering, and therefore generated per flow. This field is 328 present only if the Flow SN Present bit is set to one. 329 o Timestamp (4 Bytes): to contain the current value of the 330 timestamp clock of the transmitter in the unit of 1 331 millisecond. This field is present only if the Timestamp 332 Present bit is set to one. 334 Figure 5 shows the GMA header format with all the fields present, 335 and the order of the GMA control fields SHALL follow the bit order 336 in the Flags field. Note that the bits in the Flags field are 337 ordered with the first bit transmitted being bit 0 (MSB). All 338 fields are transmitted in regular network byte order and appear in 339 order to their corresponding flag bits. If a flag bit is clear, 340 the corresponding optional field is absent. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Flags | reserved | Client ID | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Flow ID | PPP | Delivery SN | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Flow SN | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Timestamp | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 5: GMA Header Format with all Optional Fields Present 356 Some GMA header fields, e.g. Client ID, Flow ID, and PPP are 357 designed to support hierarchical QoS (hQoS) and fine granular 358 packet classification. Notice that GMA header fields (unlike IP 359 header field) won't change regardless how a GMA PDU is delivered 360 on the way, since they are encapsulated as part of UDP payload. 361 Therefore, an intermediate node, e.g. router, Access Point, Base 362 Station, etc., can perform hQoS scheduling and active queue 363 management (AQM) directly based on these GMA header fields without 364 additional packet classification processing. 366 Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp, 367 are designed to support multi-access traffic management. For 368 example, Flow SN allows reordering at the receiver when a flow is 369 split over multiple connections. In the meantime, Delivery SN is 370 needed for packet loss measurement per delivery connection, and 371 Timestamp allows one-way-delay measurement, which can then be used 372 to detect congestion and buffer overflow at intermediate nodes. 374 5. GMA Control Messages 376 A GMA control message is encapsulated as the payload of a GMA PDU 377 (see Figure 4) and the GMA header MUST include the Client ID 378 field, but not any other optional fields. As a result, the Flag in 379 the GMA header is always set to 0x8000 for a GMA control message. 381 GMA control message MAY be encrypted with a symmetric key cipher, 382 e.g. AES256-GCM. If a GMA control message is encrypted, the 383 receiver will use the Client ID field to obtain the corresponding 384 key for decryption. Notice that only the GMA control message is 385 encrypted. The GMA header is authenticated but not encrypted. 387 Figure 6 shows the format of an encrypted GMA control message, 388 where IV (initialization vector) is 12 bytes long and GCM Tag is 389 16 bytes long. The GMA header (Flag (2B) + Client ID (2B)) is used 390 as additional authenticated data (AAD). 392 +---------------------------------------------------------------+ 393 |Flag(0x8000) | Client ID | GMA control message | GCM Tag | IV | 394 +---------------------------------------------------------------+ 395 |<------authenticated---->|<----encrypted ----->| 397 Figure 6: Encrypted GMA Control Message 399 A GMA control message consists of the following fields: 401 o Header (2 Bytes) 402 + Type (1 Byte): the GMA control message type 403 + Connection ID (1 Byte): an unsigned integer to identify 404 the anchor connection for the GMA control message 405 o Payload (variable): the payload of the GMA control message 407 5.1 Probe Message 409 The "Type" field is set to "1" for Probe messages. 411 Client (or multi-access gateway) may send out Probe message for 412 path quality estimation or keepalive. In response, multi-access 413 gateway (or client) may send back the ACK message. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Sequence Number | LS Bitmap | Probing Flag | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Timestamp | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Padding | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 7: Probe Message Format 426 A Probe message consists of the following fields: 428 o Sequence Number (2 Bytes): the sequence number of the message 429 o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0: 430 not connected; 1: connected) of the i-th delivery connection, 431 where connections are ordered according to their Connection ID, 432 bit #7 (LSB) corresponds to the 1st delivery connection and bit 433 #0 (MSB) corresponds to the 8th delivery connection. 434 o Probing Flag (1 Byte): 435 + Bit #0: a bit flag to indicate if the ACK message is 436 expected (0) or not (1) 437 + Bit #1: a bit flag to indicate if multi-access Gateway 438 SHOULD update the UDP tunnel end-point (0) or not (1) based 439 on the received Probe message. 440 + Bit #2~7: reserved 441 o Timestamp (4 Bytes): the current value of the timestamp clock of 442 the sender 443 o Padding (variable) 445 The "Padding" field is used to control the length of a Probe 446 message. 448 Multi-Access Gateway SHOULD update the UDP tunnel end-point of the 449 client based on the received Probe message if the Bit #1 Probing 450 flag is set to 0 (default). 452 5.2 Acknowledgement (ACK) Message 454 The "Type" field is set to "2" for ACK messages. The ACK message 455 consists of the following fields: 457 o Acknowledgment Number (2 Bytes): the sequence number of the 458 corresponding request message 459 o Reserved (1 Byte) 460 o Request Type (1 Byte): the corresponding request message type, 461 e.g. Probe, etc. 462 o Timestamp (4 Bytes): the current value of the timestamp clock 463 of the sender 465 0 1 2 3 466 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Ack Number | Reserved | Request Type | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Timestamp | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Padding | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Figure 8: Ack Message Format 478 5.3 Traffic Splitting Update (TSU) Message 480 The "Type" field is set to "3" for TSU messages. 482 Client (or multi-access gateway) may send out a TSU message to 483 change the traffic splitting/steering/duplicating configuration 484 for downlink flows. Let's use N to denote the number of delivery 485 connections. 487 A TSU message consists of the following fields: 489 o Sequence Number (2 Bytes): the sequence number of the TSU 490 message 491 o Link Status Bitmap (1 Byte): to indicate the status (0: not 492 connected; 1: connected) of the i-th delivery connection, 493 where connections are ordered according to their Connection 494 ID 495 o Number of Flows (1 Byte): the number of flows that are 496 configured by the TSU message 497 o Timestamp (4 Bytes): the current value of the timestamp clock 498 of the sender 500 For each flow, the following Traffic Splitting control parameters 501 are included: 503 o Flow ID (1 Byte): an unsigned integer to identify the flow 504 o L (1 Bytes): the total number of packets per traffic 505 splitting cycle, e.g. L = 32, and each packet is assigned an 506 index from 0 to L-1. 507 o K1[i] (N Bytes): the index of the first packet sent over the 508 i-th delivery connection per traffic splitting cycle, where 509 connections are ordered according to their Connection ID and 510 i = 1, 2, ..., N. 511 o K2[i] (N Bytes): the index of the last packet sent over the 512 i-th delivery connection per traffic splitting cycle, where 513 connections are ordered according to their Connection ID and 514 i = 1, 2, ..., N. 516 For example, with N = 2, i.e. two delivery connections, the 517 configuration of K1[1] = K1[2] = 0, K2[1] = K2[2] = 1, and L = 2 518 indicates sending every packet of the flow over both connections, 519 i.e. duplication. In another example, the configuration of K1[1] = 520 K2[1] = 0, K1[2] = K2[2] = 1 and L = 2 indicates sending one 521 packet of every two packets over the first connection, and the 522 other one over the second connection. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Sequence Number | LS Bitmap |Number of Flows| 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Timestamp | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Flow ID | L | K1[1] | K1[2] | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | K2[1] | K2[2] | Flow ID | L | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | K1[1] | K1[2] | K2[1] | K2[2] | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 9: TSU Message Format (N = 2, Number of Flows = 2) 540 Multi-access gateway SHALL always update the UDP tunnel end-point 541 of the client based on the received TSU message. 543 5.4 Traffic Splitting Acknowledgement (TSA) Message 545 The "Type" field is set to "4" for TSA messages. Multi-access 546 gateway (or client) SHALL send out a TSA message in response to a 547 received TSU message. A TSA message consists of the following 548 fields: 550 o Acknowledgment Number (2 Bytes): the sequence number of the 551 corresponding TSU message 552 o Reserved (1 Byte) 553 o Number of Flows (1 Byte): the number of flows that are 554 configured by the TSU message 555 o Timestamp (4 Bytes): the current value of the timestamp clock 556 of the sender in the unit of 1 millisecond 558 For each flow, the message further consists of the following 559 fields: 561 o Flow ID (1 Byte): an unsigned integer to identify the flow 562 o StartSN (3 Bytes): the Flow SN of the first GMA SDU 563 using the traffic splitting configuration provided by the 564 corresponding TSU message 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Ack Number | Reserved |Number of Flows| 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Timestamp | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Flow ID | StartSN | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Flow ID | StartSN | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 10: TSA Message Format (Number of Flows = 2) 580 Figure 11 shows the traffic splitting update procedure for downlink 581 traffic, where client performs path quality measurement based on 582 received packets and determines traffic splitting parameters. Once 583 update is needed, client will send the TSU message carrying the new 584 traffic splitting parameters to multi-access gateway. Multi-access 585 gateway will send back the TSA message in response, and perform 586 traffic splitting accordingly. The TSA message carries the 587 "StartSN" parameter to indicate the first packet using the new 588 configuration so that client can perform measurements accordingly. 590 client multi-access gateway 591 | | 592 |<------------------ GMA SDU #1 ------------------| 593 |<------------------ GMA SDU #2 ------------------| 594 +--------------------------+ | 595 | path quality measurement | | 596 +--------------------------+ | 597 |------------------ TSU ------------------------->| 598 |<------------------------- TSA(StartSN: 3) ------| 599 |<------------------ GMA SDU #3 ------------------| 600 |<------------------ GMA SDU #4 ------------------| 602 Figure 11: Downlink Traffic Splitting Update Procedure 604 5.5 Timestamp Reset Request (TSR) Message 606 The "Type" field is set to "5" for TSR messages. 608 A TSR message consists of only one field: 610 o Sequence Number (2 Bytes): the sequence number of the TSR 611 message. 613 Client SHOULD send out a TSR message to reset timestamp and 614 prevent it from overflowing for one-way delay measurement due to 615 the limited size (4 Bytes) when its local timestamp timer exceeds 616 a pre-defined value, e.g. 0x7FFF0000. 618 Once receiving a TSR message, multi-access gateway SHOULD reset 619 the timestamp timer to "0" for the client and respond with a ACK 620 message. Client SHOULD reset its timestamp timer to "0" after the 621 TSR message is successfully acknowledged. As a result, the 622 timestamp field in a GMA PDU indicates the duration between the 623 last successful TSR message exchange and the transmission of the 624 GMA PDU. 626 6. GMA Control Flows 628 GMA control sequence consists of the following three phases: 630 o Phase 1 (Initialization): client and gateway exchange MAMS 631 messages [MAMS] to configure the GMA-based multi-access 632 traffic management. 633 o Phase 2 (GMA Operation): client and gateway exchange GMA 634 control messages as defined in this document to manage traffic 635 steering/splitting/duplicating across multiple connections. 636 o Phase 3 (Termination): client and gateway exchange MAMS 637 messages to terminate the GMA operation. 639 6.1. Initialization 641 Client may trigger the initialization procedure once detecting any 642 one of the delivery connections, e.g. Wi-Fi, LTE, etc., becomes 643 available. Figure 12 shows the MAMS message exchange sequence to 644 activate the GMA operation. Please refer to [MAMS] for more 645 details about the MAMS messages. 647 Client multi-access Gateway 648 | | 649 |------- MX Discover Message ----------------------->| 650 | | 651 |<----------------------------- MX System Info ------| 652 | | 653 |------------------------------ MX Capability REQ -->| 654 |<----- MX Capability RSP ---------------------------| 655 |------------------------------ MX Capability ACK -->| 656 | | 657 |<-------------------- MX UP Setup Config -----------| 658 |-------- MX UP Setup Confirmation ----------------->| 659 | | 660 Figure 12: MAMS-based Initialization Procedure 662 To support the virtual (anchor) connection specified in this 663 document, the MX Capability REQ message SHOULD include the 664 following additional information: 666 o Last IP address: the virtual IP address used in the last MAMS 667 session 668 o Last MAMS session ID: the unique session id of the last MAMS 669 session 671 The MX UP Setup Config message SHOULD include the following 672 additional information: 674 o Client IP address: the client IP address of the virtual anchor 675 connection. 676 o Gateway IP address: the gateway IP address the virtual anchor 677 connection 678 o DNS server: the DNS server IP address of the virtual anchor 679 connection 680 o Subnet mask: the subnet mask of the virtual anchor connection 681 o MAMS port: the TCP port number at the multi-access Gateway for 682 exchange MAMS messages over the virtual anchor connection 683 o Key: the symmetric encryption (e.g. AES256-GCM) key for GMA 684 control message. 686 6.2. GMA Operation 688 After completing the initialization phase successfully, client 689 will start the GMA operation phase by sending out probes to decide 690 if a delivery connection is connected and can be used for data 691 transfer. 693 After successful probing, client will activate the virtual anchor 694 connection based on the information in the MX UP Setup Config 695 message and start (GMA-based) multi-access traffic management. 697 First of all, client will send out the TSR message to reset the 698 timestamp clock. Afterwards, client SHOULD only send out the TSR 699 message to reset timestamp when its local timestamp clock exceeds 700 a pre-defined value, e.g. 0x7FFF0000. 702 During the GMA operation, client SHOULD continuously perform path 703 quality measurements (e.g. one-way delay, loss, etc.) based on 704 probing as well as received user-plane packets, and manage user- 705 plane traffic across all available connections accordingly. How 706 and when to trigger probing as well as how to perform path quality 707 measurements are left to implementation, and not considered in 708 this document. Moreover, it is up to client implementation which 709 delivery connection is used to send control messages, e.g. TSU, 710 TSR, etc. However, the ACK message SHALL use the same delivery 711 connection as its corresponding request message. 713 If client decides to update the traffic splitting configuration 714 for downlink flows, it SHOULD send out the TSU message to gateway, 715 notifying the updated configuration, and gateway SHOULD send out 716 the TSA message to confirm the update and also indicate the Flow 717 SN Of the first packet with the updated configuration. 719 For uplink traffic, if splitting is not enabled, client SHOULD 720 control how to steer traffic without any GMA control message 721 exchange with multi-access gateway. Otherwise, if splitting is 722 enabled, multi-access gateway SHOULD perform measurements for the 723 splitting-enabled uplink flow based on received data packets and 724 send the TSU message to client for updating the traffic splitting 725 configuration. 727 Client multi-access Gateway 728 | | 729 +--------------+ | 730 | Link x is up | | 731 +--------------+ | 732 |---------------------------- Probe (over Link x) -->| 733 |<----- ACK (over Link x) ---------------------------| 734 | | 735 +----------------------------------------+ | 736 | activate the virtual anchor connection | | 737 | and start the GMA operation | | 738 +----------------------------------------+ | 739 |---------------------------- TSR ------------------>| 740 | +---------------+ 741 | |reset timestamp| 742 | +--------------+ 743 |<----- ACK -----------------------------------------| 744 +---------------+ | 745 |reset timestamp| | 746 +---------------+ | 747 | | 748 +----------------------------------------+ | 749 | perform path quality measurement based | | 750 | on probes and data packets, and decide | | 751 | to steer traffic over Link x | | 752 +----------------------------------------+ | 753 |------------------------------ TSU (over Link x)--->| 754 |<----- TSA (over Link x)----------------------------| 756 Figure 13: GMA-based Multi-Access Traffic Management Procedure 758 6.3. Termination 760 Client may trigger the termination procedure to stop the GMA 761 operation at any time. Figure 14 shows the MAMS message exchange 762 sequence to terminate the GMA operation. 764 Client multi-access Gateway 765 | | 766 |------- MX Termination Request--------------------->| 767 | | 768 |<------------------------ MX Termination Response---| 770 Figure 14: MAMS-based Termination Procedure 772 7. Security Considerations 774 Security in a network using GMA should be relatively similar to 775 security in a normal IP network. GMA is unaware of IP or higher 776 layer end-to-end security as it carries the IP packets as opaque 777 payload. Deployers are encouraged to not consider that GMA adds 778 any form of security and to continue to use IP or higher layer 779 security as well as link-layer security. 781 8. IANA Considerations 783 This document makes no requests of IANA. 785 9. References 787 9.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, DOI 791 10.17487/RFC2119, March 1997, . 794 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 795 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 796 May 2017, . 798 [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", 799 . 801 9.2. Informative References 803 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 804 Management Services 805 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 807 [IANA] https://www.iana.org/assignments/protocol- 808 numbers/protocol-numbers.xhtml 810 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 811 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 812 Ipsec Tunnel (LWIP) encapsulation; Protocol 813 specification" 815 [RFC791] Internet Protocol, September 1981 817 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 818 and splitting support in the 5G system architecture. 820 [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 822 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, 823 O., and F. Gont, "IP Fragmentation Considered Fragile", 824 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 825 . 827 [ATSSS2] M. Boucadair, et al. 3GPP Access Traffic Steering 828 Switching and Splitting (ATSSS) - Overview for IETF 829 Participants, < 830 https://datatracker.ietf.org/doc/html/draft-bonaventure- 831 quic-atsss-overview-00> 833 [GMAE] J. Zhu, et al. Generic Multi-Access (GMA) Encapsulation, 834 Protocolhttps://www.ietf.org/archive/id/draft-zhu- 835 intarea-gma-10.txt 837 [GCC] S. Holmer, et al. A Google Congestion Control Algorithm for 838 Real-Time Communication, 839 https://www.ietf.org/archive/id/draft-ietf-rmcat-gcc- 840 02.txt 842 [MPIP] L. Sun, et al. Multipath IP Routing on End Devices: 843 Motivation, Design, and Performance, 844 https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/M 845 PIP_Tech.pdf 847 Authors' Addresses 849 Jing Zhu 851 Intel 853 Email: jing.z.zhu@intel.com 855 Menglei Zhang 857 Intel 859 Email: menglei.zhang@intel.com