idnits 2.17.1 draft-zhu-intarea-gma-control-00.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 586 has weird spacing: '... SN of the ...' == Line 610 has weird spacing: '...traffic split...' == Line 645 has weird spacing: '...message is s...' -- The document date (October 13, 2021) is 897 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 559 -- Looks like a reference, but probably isn't: '2' on line 559 == Unused Reference: 'IANA' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'RFC8900' is defined on line 846, 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: April 13,2022 5 October 13, 2021 7 UDP-based Generic Multi-Access (GMA) Control Protocol 9 draft-zhu-intarea-gma-control-00 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 April 13, 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 ........................................10 74 5.2 Acknowledgement (ACK) Message ........................11 75 5.3 Traffic Splitting Update (TSU) Message ...............11 76 5.4 Traffic Splitting Acknowledgement (TSA) Message ......13 77 5.5 Timestamp Reset Request (TSR) Message ................14 78 6. GMA Control Flows ........................................... 15 79 6.1. Initialization ........................................15 80 6.2. GMA Operation .........................................16 81 6.3. Termination ...........................................17 82 7. Security Considerations ..................................... 18 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 Payload Type (bit 0): to indicate the GMA PDU payload type 293 + 0: control message 294 + 1: user-plane message 295 o Client ID Present (bit 1): If the Client ID Present bit is set 296 to 1, then the Client ID field is present 297 o Slice ID Present (bit 2): if the Slice ID Present bit is set, to 298 1, then the Slice ID field is present 299 o Connection ID Present (bit 3): If the Connection ID Present bit 300 is set to 1, then the Connection ID field is present 301 o Flow ID Present (bit 4): If the Flow ID Present bit is set to 1, 302 then the Flow ID field is present 303 o Per-Packet Priority (PPP) Present (bit 5): If the PPP Present 304 bit is set to 1, then the PPP field is present 305 o Delivery SN Present (bit 6): If the Delivery SN (Sequence 306 Number) Present bit is set to 1, then the Delivery SN field is 307 present and contains the valid information 308 o Flow SN Present (bit 7): If the Flow SN Present bit is set to 1, 309 then the Sequence Number field is present 310 o Timestamp Present (bit 8): If the Timestamp Present bit is set 311 to 1, then the Timestamp field is present 312 o Concatenation Present (bit 9): If the Concatenation Present bit 313 is set to 1, then the PDU carries multiple SDUs 314 o Reserved (bit 10-15): set to "0" and ignored on receipt 316 Bit 0 is the most significant bit (MSB), and Bit 15 is the least 317 significant bit (LSB). 319 The Receiver SHOULD first decode the Flags field to determine the 320 length of the GMA header, and then decode each optional field 321 accordingly. The GMA (Generic Multi-Access) header MAY consist of 322 the following optional fields: 324 o Client ID (2 Byte): an unsigned integer to identify the client 325 o Slice ID (1 Byte): an unsigned integer to identify the network 326 slice of the GMA SDU 328 o Connection ID (1 Byte): an unsigned integer to identify the 329 anchor connection of the GMA SDU. 330 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 331 of the GMA SDU. 332 o Per-Packet Priority (1 Byte): an unsigned integer to identify 333 the relative priority of the GMA SDU in the flow (smaller 334 value means higher priority). 335 o Delivery SN (1 Byte): an auto-incremented integer to indicate 336 the GMA PDU transmission order on a delivery connection. 337 Delivery SN is used to measure packet loss of each delivery 338 connection and therefore generated per delivery connection 339 per flow. This field is present only if the Delivery SN 340 Present bit is set to one. 341 o Flow SN (3 Bytes): an auto-incremented integer to indicate the 342 GMA SDU (IP packet) order of a flow. Flow SN is used for 343 reordering, and therefore generated per flow. This field is 344 present only if the Flow SN Present bit is set to one. 345 o Timestamp (4 Bytes): to contain the current value of the 346 timestamp clock of the transmitter in the unit of 1 347 millisecond. This field is present only if the Timestamp 348 Present bit is set to one. 350 Figure 5 shows the GMA header format with all the fields present, 351 and the order of the GMA control fields SHALL follow the bit order 352 in the Flags field. Note that the bits in the Flags field are 353 ordered with the first bit transmitted being bit 0 (MSB). All 354 fields are transmitted in regular network byte order and appear in 355 order to their corresponding flag bits. If a flag bit is clear, 356 the corresponding optional field is absent. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Flags | reserved | Client ID | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Slice ID | Conn ID | Flow ID | PPP | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Delivery SN | Flow SN | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Timestamp | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 5: GMA Header Format with all Optional Fields Present 372 Some GMA header fields, e.g. Slice ID, Conn ID, Flow ID, and PPP 373 are designed to support hierarchical QoS (hQoS) and fine granular 374 packet classification. Notice that GMA header fields (unlike IP 375 header field) won't change regardless how a GMA PDU is delivered 376 on the way, since they are encapsulated as part of UDP payload. 377 Therefore, an intermediate node, e.g. router, Access Point, Base 378 Station, etc., can perform hQoS scheduling and active queue 379 management (AQM) directly based on these GMA header fields without 380 additional packet classification processing. 382 Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp, 383 are designed to support multi-access traffic management. For 384 example, Flow SN allows reordering at the receiver when a flow is 385 split over multiple connections. In the meantime, Delivery SN is 386 needed for packet loss measurement per delivery connection, and 387 Timestamp allows one-way-delay measurement, which can then be used 388 to detect congestion and buffer overflow at intermediate nodes. 390 If concatenation is supported, a GMA PDU MAY carry multiple GMA 391 SDUs with the same Slice ID, Connection ID, Flow ID, and PPP. 392 However, concatenation is only applicable to IP-based virtual 393 (anchor) connection. Please refer to [GMAE] for more details on 394 concatenation. 396 5. GMA Control Messages 398 A GMA control message is encapsulated as the payload of a GMA PDU 399 (see Figure 4) and indicated by setting Bit 0 in the Flags field 400 of the GMA header to 0. Moreover, the GMA header MUST include the 401 Client ID field, but not any other optional fields. As a result, 402 the Flag in the GMA header is always set to 0x4000 for a GMA 403 control message. 405 GMA control message MAY be encrypted with a symmetric key cipher, 406 e.g. AES256-GCM. If a GMA control message is encrypted, the 407 receiver will use the Client ID field to obtain the corresponding 408 key for decryption. Notice that only the GMA control message is 409 encrypted. The GMA header is authenticated but not encrypted. 411 Figure 6 shows the format of an encrypted GMA control message, 412 where IV (initialization vector) is 12 bytes long and GCM Tag is 413 16 bytes long. The GMA header (Flag (2B) + Client ID (2B)) is used 414 as additional authenticated data (AAD). 416 +---------------------------------------------------------------+ 417 |Flag(0x4000) | Client ID | GMA control message | GCM Tag | IV | 418 +---------------------------------------------------------------+ 419 |<------authenticated---->|<----encrypted ----->| 420 Figure 6: Encrypted GMA Control Message 422 A GMA control message consists of the following fields: 424 o Header (2 Bytes) 425 + Type (1 Byte): the GMA control message type 426 + Connection ID (1 Byte): an unsigned integer to identify 427 the anchor connection for the GMA control message 428 o Payload (variable): the payload of the GMA control message 430 5.1 Probe Message 432 The "Type" field is set to "1" for Probe messages. 434 Client (or multi-access gateway) may send out Probe message for 435 path quality estimation or keepalive. In response, multi-access 436 gateway (or client) may send back the ACK message. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Sequence Number | LS Bitmap | Probing Flag | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Timestamp | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Padding | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Figure 7: Probe Message Format 450 A Probe message consists of the following fields: 452 o Sequence Number (2 Bytes): the sequence number of the message 453 o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0: 454 not connected; 1: connected) of the i-th delivery connection, 455 where connections are ordered according to their Connection ID, 456 bit #7 (LSB) corresponds to the 1st delivery connection and bit 457 #0 (MSB) corresponds to the 8th delivery connection. 458 o Probing Flag (1 Byte): 459 + Bit #0: a bit flag to indicate if the ACK message is 460 expected (0) or not (1) 461 + Bit #1: a bit flag to indicate if multi-access Gateway 462 SHOULD update the UDP tunnel end-point (0) or not (1) based 463 on the received Probe message. 464 + Bit #2~7: reserved 466 o Timestamp (4 Bytes): the current value of the timestamp clock of 467 the sender 468 o Padding (variable) 470 The "Padding" field is used to control the length of a Probe 471 message. 473 Multi-Access Gateway SHOULD update the UDP tunnel end-point of the 474 client based on the received Probe message if the Bit #1 Probing 475 flag is set to 0 (default). 477 5.2 Acknowledgement (ACK) Message 479 The "Type" field is set to "2" for ACK messages. The ACK message 480 consists of the following fields: 482 o Acknowledgment Number (2 Bytes): the sequence number of the 483 corresponding request message 484 o Reserved (1 Byte) 485 o Request Type (1 Byte): the corresponding request message type, 486 e.g. Probe, etc. 487 o Timestamp (4 Bytes): the current value of the timestamp clock 488 of the sender 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Ack Number | Reserved | Request Type | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Timestamp | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Padding | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Figure 8: Ack Message Format 502 5.3 Traffic Splitting Update (TSU) Message 504 The "Type" field is set to "3" for TSU messages. 506 Client (or multi-access gateway) may send out a TSU message to 507 change the traffic splitting/steering/duplicating configuration 508 for downlink flows. Let's use N to denote the number of delivery 509 connections. 511 A TSU message consists of the following fields: 513 o Sequence Number (2 Bytes): the sequence number of the TSU 514 message 515 o Link Status Bitmap (1 Byte): to indicate the status (0: not 516 connected; 1: connected) of the i-th delivery connection, 517 where connections are ordered according to their Connection 518 ID 519 o Number of Flows (1 Byte): the number of flows that are 520 configured by the TSU message 521 o Timestamp (4 Bytes): the current value of the timestamp clock 522 of the sender 524 For each flow, the following Traffic Splitting control parameters 525 are included: 527 o Flow ID (1 Byte): an unsigned integer to identify the flow 528 o L (1 Bytes): the total number of packets per traffic 529 splitting cycle, e.g. L = 32, and each packet is assigned an 530 index from 0 to L-1. 531 o K1[i] (N Bytes): the index of the first packet sent over the 532 i-th delivery connection per traffic splitting cycle, where 533 connections are ordered according to their Connection ID and 534 i = 1, 2, ..., N. 535 o K2[i] (N Bytes): the index of the last packet sent over the 536 i-th delivery connection per traffic splitting cycle, where 537 connections are ordered according to their Connection ID and 538 i = 1, 2, ..., N. 540 For example, with N = 2, i.e. two delivery connections, the 541 configuration of K1[1] = K1[2] = 0, K2[1] = K2[2] = 1, and L = 2 542 indicates sending every packet of the flow over both connections, 543 i.e. duplication. In another example, the configuration of K1[1] = 544 K2[1] = 0, K1[2] = K2[2] = 1 and L = 2 indicates sending one 545 packet of every two packets over the first connection, and the 546 other one over the second connection. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sequence Number | LS Bitmap |Number of Flows| 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Timestamp | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Flow ID | L | K1[1] | K1[2] | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | K2[1] | K2[2] | Flow ID | L | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | K1[1] | K1[2] | K2[1] | K2[2] | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 9: TSU Message Format (N = 2, Number of Flows = 2) 564 Multi-access gateway SHALL always update the UDP tunnel end-point 565 of the client based on the received TSU message. 567 5.4 Traffic Splitting Acknowledgement (TSA) Message 569 The "Type" field is set to "4" for TSA messages. Multi-access 570 gateway (or client) SHALL send out a TSA message in response to a 571 received TSU message. A TSA message consists of the following 572 fields: 574 o Acknowledgment Number (2 Bytes): the sequence number of the 575 corresponding TSU message 576 o Reserved (1 Byte) 577 o Number of Flows (1 Byte): the number of flows that are 578 configured by the TSU message 579 o Timestamp (4 Bytes): the current value of the timestamp clock 580 of the sender in the unit of 1 millisecond 582 For each flow, the message further consists of the following 583 fields: 585 o Flow ID (1 Byte): an unsigned integer to identify the flow 586 o StartSN (3 Bytes): the Flow SN of the first GMA SDU 587 using the traffic splitting configuration provided by the 588 corresponding TSU message 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Ack Number | Reserved |Number of Flows| 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Timestamp | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Flow ID | StartSN | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Flow ID | StartSN | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Figure 10: TSA Message Format (Number of Flows = 2) 604 Figure 11 shows the traffic splitting update procedure for downlink 605 traffic, where client performs path quality measurement based on 606 received packets and determines traffic splitting parameters. Once 607 update is needed, client will send the TSU message carrying the new 608 traffic splitting parameters to multi-access gateway. Multi-access 609 gateway will send back the TSA message in response, and perform 610 traffic splitting accordingly. The TSA message carries the 611 "StartSN" parameter to indicate the first packet using the new 612 configuration so that client can perform measurements accordingly. 614 client multi-access gateway 615 | | 616 |<------------------ GMA SDU #1 ------------------| 617 |<------------------ GMA SDU #2 ------------------| 618 +--------------------------+ | 619 | path quality measurement | | 620 +--------------------------+ | 621 |------------------ TSU ------------------------->| 622 |<------------------------- TSA(StartSN: 3) ------| 623 |<------------------ GMA SDU #3 ------------------| 624 |<------------------ GMA SDU #4 ------------------| 626 Figure 11: Downlink Traffic Splitting Update Procedure 628 5.5 Timestamp Reset Request (TSR) Message 630 The "Type" field is set to "5" for TSR messages. 632 A TSR message consists of only one field: 634 o Sequence Number (2 Bytes): the sequence number of the TSR 635 message. 637 Client SHOULD send out a TSR message to reset timestamp and 638 prevent it from overflowing for one-way delay measurement due to 639 the limited size (4 Bytes) when its local timestamp timer exceeds 640 a pre-defined value, e.g. 0x7FFF0000. 642 Once receiving a TSR message, multi-access gateway SHOULD reset 643 the timestamp timer to "0" for the client and respond with a ACK 644 message. Client SHOULD reset its timestamp timer to "0" after the 645 TSR message is successfully acknowledged. As a result, the 646 timestamp field in a GMA PDU indicates the duration between the 647 last successful TSR message exchange and the transmission of the 648 GMA PDU. 650 6. GMA Control Flows 652 GMA control sequence consists of the following three phases: 654 o Phase 1 (Initialization): client and gateway exchange MAMS 655 messages [MAMS] to configure the GMA-based multi-access 656 traffic management. 657 o Phase 2 (GMA Operation): client and gateway exchange GMA 658 control messages as defined in this document to manage traffic 659 steering/splitting/duplicating across multiple connections. 660 o Phase 3 (Termination): client and gateway exchange MAMS 661 messages to terminate the GMA operation. 663 6.1. Initialization 665 Client may trigger the initialization procedure once detecting any 666 one of the delivery connections, e.g. Wi-Fi, LTE, etc., becomes 667 available. Figure 12 shows the MAMS message exchange sequence to 668 activate the GMA operation. Please refer to [MAMS] for more 669 details about the MAMS messages. 671 Client multi-access Gateway 672 | | 673 |------- MX Discover Message ----------------------->| 674 | | 675 |<----------------------------- MX System Info ------| 676 | | 677 |------------------------------ MX Capability REQ -->| 678 |<----- MX Capability RSP ---------------------------| 679 |------------------------------ MX Capability ACK -->| 680 | | 681 |<-------------------- MX UP Setup Config -----------| 682 |-------- MX UP Setup Confirmation ----------------->| 683 | | 684 Figure 12: MAMS-based Initialization Procedure 686 To support the virtual (anchor) connection specified in this 687 document, the MX Capability REQ message SHOULD include the 688 following additional information: 690 o Last IP address: the virtual IP address used in the last MAMS 691 session 692 o Last MAMS session ID: the unique session id of the last MAMS 693 session 695 The MX UP Setup Config message SHOULD include the following 696 additional information: 698 o Client IP address: the client IP address of the virtual anchor 699 connection. 700 o Gateway IP address: the gateway IP address the virtual anchor 701 connection 702 o DNS server: the DNS server IP address of the virtual anchor 703 connection 704 o Subnet mask: the subnet mask of the virtual anchor connection 705 o MAMS port: the TCP port number at the multi-access Gateway for 706 exchange MAMS messages over the virtual anchor connection 707 o Key: the symmetric encryption (e.g. AES256-GCM) key for GMA 708 control message. 710 6.2. GMA Operation 712 After completing the initialization phase successfully, client 713 will start the GMA operation phase by sending out probes to decide 714 if a delivery connection is connected and can be used for data 715 transfer. 717 After successful probing, client will activate the virtual anchor 718 connection based on the information in the MX UP Setup Config 719 message and start (GMA-based) multi-access traffic management. 721 First of all, client will send out the TSR message to reset the 722 timestamp clock. Afterwards, client SHOULD only send out the TSR 723 message to reset timestamp when its local timestamp clock exceeds 724 a pre-defined value, e.g. 0x7FFF0000. 726 During the GMA operation, client SHOULD continuously perform path 727 quality measurements (e.g. one-way delay, loss, etc.) based on 728 probing as well as received user-plane packets, and manage user- 729 plane traffic across all available connections accordingly. How 730 and when to trigger probing as well as how to perform path quality 731 measurements are left to implementation, and not considered in 732 this document. Moreover, it is up to client implementation which 733 delivery connection is used to send control messages, e.g. TSU, 734 TSR, etc. However, the ACK message SHALL use the same delivery 735 connection as its corresponding request message. 737 If client decides to update the traffic splitting configuration 738 for downlink flows, it SHOULD send out the TSU message to gateway, 739 notifying the updated configuration, and gateway SHOULD send out 740 the TSA message to confirm the update and also indicate the Flow 741 SN Of the first packet with the updated configuration. 743 For uplink traffic, if splitting is not enabled, client SHOULD 744 control how to steer traffic without any GMA control message 745 exchange with multi-access gateway. Otherwise, if splitting is 746 enabled, multi-access gateway SHOULD perform measurements for the 747 splitting-enabled uplink flow based on received data packets and 748 send the TSU message to client for updating the traffic splitting 749 configuration. 751 Client multi-access Gateway 752 | | 753 +--------------+ | 754 | Link x is up | | 755 +--------------+ | 756 |---------------------------- Probe (over Link x) -->| 757 |<----- ACK (over Link x) ---------------------------| 758 | | 759 +----------------------------------------+ | 760 | activate the virtual anchor connection | | 761 | and start the GMA operation | | 762 +----------------------------------------+ | 763 |---------------------------- TSR ------------------>| 764 | +---------------+ 765 | |reset timestamp| 766 | +--------------+ 767 |<----- ACK -----------------------------------------| 768 +---------------+ | 769 |reset timestamp| | 770 +---------------+ | 771 | | 772 +----------------------------------------+ | 773 | perform path quality measurement based | | 774 | on probes and data packets, and decide | | 775 | to steer traffic over Link x | | 776 +----------------------------------------+ | 777 |------------------------------ TSU (over Link x)--->| 778 |<----- TSA (over Link x)----------------------------| 780 Figure 13: GMA-based Multi-Access Traffic Management Procedure 782 6.3. Termination 784 Client may trigger the termination procedure to stop the GMA 785 operation at any time. Figure 14 shows the MAMS message exchange 786 sequence to terminate the GMA operation. 788 Client multi-access Gateway 789 | | 790 |------- MX Termination Request--------------------->| 791 | | 792 |<------------------------ MX Termination Response---| 794 Figure 14: MAMS-based Termination Procedure 796 7. Security Considerations 798 Security in a network using GMA should be relatively similar to 799 security in a normal IP network. GMA is unaware of IP or higher 800 layer end-to-end security as it carries the IP packets as opaque 801 payload. Deployers are encouraged to not consider that GMA adds 802 any form of security and to continue to use IP or higher layer 803 security as well as link-layer security. 805 8. IANA Considerations 807 This document makes no requests of IANA. 809 9. References 811 9.1. Normative References 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, DOI 815 10.17487/RFC2119, March 1997, . 818 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 819 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 820 May 2017, . 822 [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", 823 . 825 9.2. Informative References 827 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 828 Management Services 829 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 831 [IANA] https://www.iana.org/assignments/protocol- 832 numbers/protocol-numbers.xhtml 834 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 835 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 836 Ipsec Tunnel (LWIP) encapsulation; Protocol 837 specification" 839 [RFC791] Internet Protocol, September 1981 841 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 842 and splitting support in the 5G system architecture. 844 [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 846 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, 847 O., and F. Gont, "IP Fragmentation Considered Fragile", 848 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 849 . 851 [ATSSS2] M. Boucadair, et al. 3GPP Access Traffic Steering 852 Switching and Splitting (ATSSS) - Overview for IETF 853 Participants, < 854 https://datatracker.ietf.org/doc/html/draft-bonaventure- 855 quic-atsss-overview-00> 857 [GMAE] J. Zhu, et al. Generic Multi-Access (GMA) Encapsulation, 858 Protocolhttps://www.ietf.org/archive/id/draft-zhu- 859 intarea-gma-10.txt 861 [GCC] S. Holmer, et al. A Google Congestion Control Algorithm for 862 Real-Time Communication, 863 https://www.ietf.org/archive/id/draft-ietf-rmcat-gcc- 864 02.txt 866 [MPIP] L. Sun, et al. Multipath IP Routing on End Devices: 867 Motivation, Design, and Performance, 868 https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/M 869 PIP_Tech.pdf 871 Authors' Addresses 873 Jing Zhu 875 Intel 877 Email: jing.z.zhu@intel.com 879 Menglei Zhang 881 Intel 882 Email: menglei.zhang@intel.com