idnits 2.17.1 draft-zhu-intarea-gma-11.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: "TTL", "FSL", and "Next Header" are no longer needed, and MUST not be included. Moreover, the IP header fields of the GMA SDU remain unchanged. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the (trailer or header based) IP encapsulation method is used, the First SDU Length (FSL) field SHOULD be included in the GMA trailer (or header) to indicate the length of the first SDU. Otherwise, the FSL field SHOULD not be included. -- The document date (October 8, 2021) is 931 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IANA1999' is mentioned on line 506, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Zhu 2 Internet Draft Intel 3 Intended status: Experimental S. Kanugovi 4 Expires: April 8,2022 Nokia 5 October 8, 2021 7 Generic Multi-Access (GMA) Encapsulation Protocol 8 draft-zhu-intarea-gma-11 10 Abstract 12 A device can be simultaneously connected to multiple networks, 13 e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly 14 combine the connectivity over these networks below the transport 15 layer (L4) to improve quality of experience for applications that 16 do not have built in multi-path capabilities. Such optimization 17 requires additional control information, e.g., a sequence number, 18 in each packet. This document presents a new light weight and 19 flexible encapsulation protocol for this need. The solution has 20 been developed by the authors based on their experiences in 21 multiple standards bodies including the IETF and 3GPP, is not an 22 Internet Standard and does not represent the consensus opinion of 23 the IETF. This document will enable other developers to build 24 interoperable implementations in order to experiment with the 25 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 8, 2019. 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. GMA Encapsulation Methods .................................... 6 72 4.1. Trailer-based IP Encapsulation .........................7 73 4.2. Header-based IP Encapsulation .........................10 74 4.3. (Header-based) non-IP Encapsulation ...................11 75 4.4. IP Protocol Identifier ................................11 76 5. Fragmentation ............................................... 12 77 6. Concatenation ............................................... 13 78 7. Security Considerations ..................................... 14 79 8. IANA Considerations ......................................... 15 80 9. References .................................................. 15 81 9.1. Normative References ..................................15 82 9.2. Informative References ................................15 84 1. Introduction 86 A device can be simultaneously connected to multiple networks, 87 e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly 88 combine the connectivity over these networks below the transport 89 layer (L4) to improve quality of experience for applications that 90 do not have built in multi-path capabilities. 92 Figure 1 shows the Multi-Access Management Service (MAMS) user- 93 plane protocol stack [MAMS], which has been used in today's multi- 94 access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. It consists of 95 two layers: convergence and adaptation. 97 The convergence layer is responsible for multi-access operations, 98 including multi-link (path) aggregation, splitting/reordering, 99 lossless switching/retransmission, fragmentation, concatenation, 100 etc. It operates on top of the adaptation layer in the protocol 101 stack. From the perspective of a transmitter, a User Payload 102 (e.g., IP packet) is processed by the convergence layer first, and 103 then by the adaptation layer before being transported over a 104 delivery connection; from the receiver's perspective, an IP packet 105 received over a delivery connection is processed by the adaptation 106 layer first, and then by the convergence layer. 108 +-----------------------------------------------------+ 109 | User Payload, e.g., IP Protocol Data Unit (PDU) | 110 +-----------------------------------------------------+ 111 +-----------------------------------------------------------+ 112 | +-----------------------------------------------------+ | 113 | | Multi-Access (MX) Convergence Layer | | 114 | +-----------------------------------------------------+ | 115 | +-----------------------------------------------------+ | 116 | | MX Adaptation | MX Adaptation | MX Adaptation | | 117 | | Layer | Layer | Layer | | 118 | +-----------------+-----------------+-----------------+ | 119 | | Access #1 IP | Access #2 IP | Access #3 IP | | 120 | +-----------------------------------------------------+ | 121 | MAMS User-Plane Protocol Stack | 122 +-----------------------------------------------------------+ 124 Figure 1: MAMS User-Plane Protocol Stack [MAMS] 126 GRE (Generic Routing Encapsulation) can be used [LWIPEP] [GRE1] 127 [GRE2] as the encapsulation protocol at the convergence layer to 128 encode additional control information, e.g., Key, Sequence Number. 129 However, there are two main drawbacks with this approach: 131 o It is difficult to introduce new control fields because the 132 GRE header formats are already defined, 133 o IP-over-IP tunnelling (required for GRE) leads to higher 134 overhead especially for small packet. 136 For example, the overhead of IP-over-IP/GRE tunnelling with both 137 Key and Sequence Number is 32 Bytes (20 Bytes IP header + 12 Bytes 138 GRE header), which is 80% of a 40 Bytes TCP ACK packet. 140 This document presents a light-weight GMA (Generic Multi-Access) 141 encapsulation protocol for the convergence layer. It supports 142 three encapsulation methods: trailer-based IP encapsulation, 143 header-based IP encapsulation, and non-IP encapsulation. 144 Particularly, the IP encapsulation methods avoid IP-over-IP 145 tunneling overhead (20 Bytes), which is 50% of a 40 Bytes TCP ACK 146 packet. Moreover, it introduces new control fields to support 147 fragmentation and concatenation, which are not available in GRE- 148 based solutions [LWIPEP] [GRE1] [GRE2]. 150 The GMA protocol only operates between endpoints that have been 151 configured to use GMA. This configuration can be through any 152 control messages and procedures, including, for example, Multi- 153 Access Management Services [MAMS]. Moreover, UDP or IPSec 154 tunneling can be used at the adaptation sublayer to protect GMA 155 operation from intermediate nodes. 157 The solution described in this document was been developed by the 158 authors based on their experiences in multiple standards bodies 159 including the IETF and 3GPP. However, it is not an Internet 160 Standard and does not represent the consensus opinion of the IETF. 161 This document presents the protocol specification to enable 162 experimentation as described in Section 1.1 and to facilitate 163 other interoperable implementations. 165 1.1. Scope of Experiment 167 The protocol described in this document is an experiment. The 168 objective of the experiment is to determine whether the protocol 169 meets the requirements, can be safely used, and has support for 170 deployment. 172 Section 4 describes three possible encapsulation methods that are 173 enabled by this protocol. Part of this experiment is to assess 174 whether all three mechanisms are necessary, or whether, for 175 example, all implementations are able to support the main 176 "trailer-based" IP encapsulation method. Similarly, the experiment 177 will investigate the relative merits of the IP and non-IP 178 encapsulation methods. 180 It is expected that this protocol experiment can be conducted on 181 the Internet since the GMA packets are identified by an IP 182 protocol number and the protocol is intended for single hop 183 propagation: devices should not be forwarding packet and if they 184 do they will not need to examine the payload, while destination 185 systems that do not support this protocol should not receive such 186 packets and will handle them as unknown payloads according to 187 normal IP processing. Thus, experimentation is conducted between 188 consenting end systems that have been mutually configured to 189 participate in the experiment as described in Section 7. 191 Note that this experiment "re-uses" the IP protocol identifier 114 192 as described in Section 4.4. Part of this experiment is to assess 193 the safety of doing this. 195 The authors will continually assess the progress of this 196 experiment and encourage other implementers to contact them to 197 report the status of their implementations and their experiences 198 with the protocol. 200 2. Conventions used in this document 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 203 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 204 "MAY", and "OPTIONAL" in this document are to be interpreted as 205 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 206 appear in all capitals, as shown here. 208 3. Use Case 210 As shown in Figure 2, a client device (e.g., Smartphone, Laptop, 211 etc.) may connect to the Internet via both Wi-Fi and LTE 212 connections, one of which (e.g., LTE) may operate as the anchor 213 connection, and the other (e.g., Wi-Fi) may operate as the 214 delivery connection. The anchor connection provides the IP address 215 and connectivity for end-to-end Internet access, and the delivery 216 connection provides an additional path between client and Multi- 217 Access Gateway for multi-access optimizations. 219 Multi-Access Aggregation 221 +---+ +---+ 222 | |A|--- LTE Connection -----|C| | 223 |U|-| |-|S| Internet 224 | |B|--- Wi-Fi Connection ---|D| | 225 +---+ +---+ 226 Client Multi-Access Gateway 228 A: The adaptation layer endpoint of the LTE connection 229 resides in the client 231 B: The adaptation layer endpoint of the Wi-Fi connection 232 resides in the client 234 C: The adaptation layer endpoint of the LTE connection 235 resides in the Multi-Access Gateway, aka N-MADP (Network 236 Multi-Access Data Proxy) in [MAMS] 237 D: The adaptation layer endpoint of the Wi-Fi connection 238 resides in the Multi-Access Gateway 240 U: The convergence layer endpoint resides in the client 242 S: The convergence layer endpoint resides in the Multi- 243 Access Gateway 245 Figure 2: GMA-based Multi-Access Aggregation 247 For example, per-packet aggregation allows a single IP flow to use 248 the combined bandwidth of the two connections. In another example, 249 packets lost due to a temporarily link outage may be 250 retransmitted. Moreover, packets may be duplicated over multiple 251 connections to achieve high reliability and low latency, where 252 duplicated packets are eliminated by the receiving side. Such 253 multi-access optimization requires additional control information, 254 e.g., a sequence number, in each packet, which can be supported by 255 the GMA encapsulation protocol described in this document. 257 The GMA protocol described in this document is designed for 258 multiple connections, but it may also be used when there is only 259 one connection between two endpoints. For example, it may be used 260 for loss detection and recovery. In another example, it may be 261 used to concatenate multiple small packets and reduce per packet 262 overhead. 264 4. GMA Encapsulation Methods 266 The GMA encapsulation protocol supports the following three 267 methods: 269 o Trailer-based IP Encapsulation (4.1) 270 o Header-based IP Encapsulation (4.2) 271 o (Header-based) non-IP Encapsulation (4.3) 273 Trailer-based IP encapsulation MUST be used if it is supported by 274 GMA endpoints. 276 Header-based encapsulation MUST be used if the trailer-based 277 method is not supported by either Client or Multi-Access Gateway. 278 In this case, if the adaptation layer, e.g., UDP tunnelling, 279 supports non-IP packet format, non-IP encapsulation MUST be used; 280 otherwise, header-based IP encapsulation MUST be used. 282 If non-IP encapsulation is configured, a GMA header MUST be 283 present in every packet. In comparison, if IP encapsulation is 284 configured, a GMA header or trailer may be added dynamically on 285 per-packet basis, and it indicates the presence of GMA header (or 286 trailer) to set the protocol type of the GMA PDU to "114" (see 287 Section 4.4). 289 The GMA endpoints MAY configure the GMA encapsulation method 290 through control signalling or pre-configuration. For example, the 291 "MX UP Setup Configuration Request" message as specified in Multi- 292 Access Management Service [MAMS] includes "MX Convergence Method 293 Parameters", which provides the list of parameters to configure 294 the convergence layer, and can be extended to indicate the GMA 295 encapsulation method. 297 GMA endpoint MUST discard a received packet and MAY log an error 298 to report the situation (although such error logging MUST be 299 subject to rate limits) under any of the following conditions: 301 . the GMA version number in the GMA header (or trailer) is not 302 understood or supported by the GMA endpoint 303 . a Flag bit in the GMA header (or trailer) not understood or 304 supported by the GMA endpoint is set to "1" 306 4.1. Trailer-based IP Encapsulation 308 |<---------------------GMA PDU ----------------------->| 309 +------------------------------------------------------+ 310 | IP hdr | IP payload | GMA Trailer | 311 +------------------------------------------------------+ 312 |<------- GMA SDU (user payload)-------->| 314 Figure 3: GMA PDU Format with Trailer-based IP Encapsulation 316 Figure 3 shows the trailer-based IP encapsulation GMA PDU 317 (protocol data unit) format. A (GMA) PDU may carry one or multiple 318 IP packets, aka (GMA) SDUs (service data unit), in the payload, or 319 a fragment of the SDU. 321 The Protocol Type field in the IP header of the GMA PDU MUST be 322 changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to indicate 323 the presence of the GMA trailer. 325 If the original IP packet is IPv4, the following three IP header 326 fields MUST be changed: 328 o IP Length: add the length of "GMA Trailer" to the length of 329 the original IP packet 330 o Time To Live (TTL): set to "1" 331 o IP checksum: recalculate after changing "Protocol Type", "TTL" 332 and "IP Length" 334 If the original IP packet is IPv6, the following two IP header 335 fields MUST be changed: 337 o IP Length: add the length of "GMA Trailer" to the length of 338 the original IP packet 339 o Hop-Limit (HL): set the HL field to "0" 341 The GMA (Generic Multi-Access) trailer MUST consist of two 342 mandatory fields (the last 3 bytes): Next Header and Flags, 343 defined as follows: 345 o Next Header (1 Byte): the IP protocol type of the (first) SDU 346 in a PDU, and it stores the value before it was overwritten to 347 114. 348 o Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and 349 Bit 15 is the least significant bit (LSB) 350 + Checksum Present (bit 0): If the Checksum Present bit is set 351 to 1, then the Checksum field is present 352 + Concatenation Present (bit 1): If the Concatenation Present 353 bit is set to 1, then the PDU carries multiple SDUs, and the 354 First SDU Length field is present 355 + Connection ID Present (bit 2): If the Connection ID Present 356 bit is set to 1, then the Connection ID field is present 357 + Flow ID Present (bit 3): If the Flow ID Present bit is set 358 to 1, then the Flow ID field is present 359 + Fragmentation Present (bit 4): If the Fragmentation Present 360 bit is set to 1, then the PDU carry a fragment of the SDU and 361 the Fragmentation Control field is present 362 + Delivery SN Present (bit 5): If the Delivery SN (Sequence 363 Number) Present bit is set to 1, then the Delivery SN field is 364 present and contains the valid information 365 + Flow SN Present (bit 6): If the Flow SN Present bit is set 366 to 1, then the Sequence Number field is present 367 + Timestamp Present (bit 7): If the Timestamp Present bit is 368 set to 1, then the Timestamp field is present 369 + TTL Present (bit 8): If the TTL Present bit is set to 1, 370 then the TTL field is present 371 + Reserved (bit 9-12): set to "0" and ignored on receipt 372 + Version (bit 13~15): GMA version number, set to 0 for the 373 GMA encapsulation protocol specified in this document. 375 The Flags field is at the end of the PDU, and the Next Header 376 field is the second last. The Receiver SHOULD first decode the 377 Flags field to determine the length of the GMA trailer, and then 378 decode each optional field accordingly. The GMA (Generic Multi- 379 Access) trailer MAY consist of the following optional fields: 381 o Checksum (1 Byte): to contain the (one's complement) checksum 382 sum of all the 8 bits in the trailer. For purposes of 383 computing the checksum, the value of the checksum field is 384 zero. This field is present only if the Checksum Present bit 385 is set to one. 386 o First SDU Length (2 Bytes): the length of the first IP packet 387 in the PDU, only included if a PDU contains multiple IP 388 packets. This field is present only if the Concatenation 389 Present bit is set to one. 390 o Connection ID (1 Byte): an unsigned integer to identify the 391 anchor and delivery connection of the GMA PDU. This field is 392 present only if the Connection ID Present bit is set to one. 393 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 394 identify the anchor connection 395 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 396 identify the delivery connection 397 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 398 that a PDU belongs to, for example Data Radio Bearer (DRB) ID 399 [LWIPEP] for a cellular (e.g., LTE) connection. This field is 400 present only if the Flow ID Present bit is set to one. 401 o Fragmentation Control (FC) (1 Byte): to provide necessary 402 information for re-assembly, only needed if a PDU carries 403 fragments. This field is present only if the Fragmentation 404 Present bit is set to one. Please refer to section 5 for its 405 detailed format and usage. 406 o Delivery SN (1 Byte): an auto-incremented integer to indicate 407 the GMA PDU transmission order on a delivery connection. 408 Delivery SN is needed to measure packet loss of each delivery 409 connection and therefore generated per delivery connection per 410 flow. This field is present only if the Delivery SN Present 411 bit is set to one. 412 o Flow SN (3 Bytes): an auto-incremented integer to indicate the 413 GMA SDU (IP packet) order of a flow. Flow SN is needed for 414 retransmission, reordering, and fragmentation. It SHALL be 415 generated per flow. This field is present only if the Flow SN 416 Present bit is set to one. 417 o Timestamp (4 Bytes): to contain the current value of the 418 timestamp clock of the transmitter in the unit of 1 419 millisecond. This field is present only if the Timestamp 420 Present bit is set to one. 421 o TTL (1 Byte): to contain the TTL value of the original IP 422 header if the GMA SDU is IPv4, or the Hop-Limit value of the 423 IP header if the GMA SDU is IPv6. This field is present only 424 if the TTL Present bit is set to one. 426 Figure 4 shows the GMA trailer format with all the fields present, 427 and the order of the GMA control fields SHALL follow the bit order 428 in the Flags field. Note that the bits in the Flags field are 429 ordered with the first bit transmitted being bit 0 (MSB). All 430 fields are transmitted in regular network byte order and appear in 431 reverse order to their corresponding flag bits. If a flag bit is 432 clear, the corresponding optional field is absent. 434 For example, Bit 0 (the MSB) of the Flags field is the Checksum 435 Present bit, and the Checksum field is the last in the trailer 436 except of the two mandatory fields. Bit 1 is the Concatenation 437 present bit, and the FSL field is the second last. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | TTL | Timestamp 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Flow SN | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Delivery SN | FC | Flow ID | Connection ID | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | First SDU Length (FSL) | Checksum | Next Header | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Flags | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 4: GMA Trailer Format with all Optional Fields Present 455 4.2. Header-based IP Encapsulation 457 Figure 5 shows the header-based IP encapsulation format. Here, the 458 GMA header is inserted right after the IP header of the GMA SDU, 459 and the IP header fields of the GMA PDU MUST be changed the same 460 way as in trailered-based IP encapsulation. 462 +-----------------------------------------------+ 463 |IP hdr | GMA Header | IP payload | 464 +-----------------------------------------------+ 465 Figure 5: GMA PDU Format with Header-based IP Encapsulation 467 Figure 6 shows the GMA header format. In comparison to GMA 468 trailer, the only difference is that the Flags field is now in the 469 front so that the Receiver can first decode the Flags field to 470 determine the GMA header length. 472 +------------------------------------------------------+ 473 | Flags | other fields (TTL, Timestamp, Flow SN, etc.) | 474 +------------------------------------------------------+ 475 Figure 6: GMA Header Format 477 4.3. (Header-based) non-IP Encapsulation 479 Figure 7 shows the header-based non-IP encapsulation format. Here, 480 "UDP Tunnelling" is configured at the MX adaptation layer. The 481 ports for "UDP Tunnelling" at Client are chosen from the Dynamic 482 Port range, and the ports for "UDP Tunnelling" at Multi-Access 483 Gateway are configured and provided to Client through additional 484 control messages, e.g., [MAMS]. 486 "TTL", "FSL", and "Next Header" are no longer needed, and MUST not 487 be included. Moreover, the IP header fields of the GMA SDU remain 488 unchanged. 490 +-------------------------------------------------------------+ 491 | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | 492 +-------------------------------------------------------------+ 493 |<------- GMA SDU------------>| 494 |<------------------- GMA PDU------------>| 496 Figure 7: GMA PDU Format with Non-IP Encapsulation 498 4.4. IP Protocol Identifier 500 As described in Section 4.1, IP encapsulated GMA PDUs are 501 indicated using the IP Protocol Type 114. This is designated and 502 recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No 503 reference is given in the IANA registry for the definition of this 504 Protocol Type, and IANA has no record of why the assignment was 505 made or how it is used, although it was probably assigned before 506 1999 [IANA1999]. 508 There is some risk associated with "re-using" Protocol Type 114 509 because there may be implementations of other protocols also using 510 this Protocol Type. However, because the protocol described in 511 this document is used only between adjacent devices specifically 512 configured for this purpose, the use of Protocol Type 114 should 513 be safe. 515 As described in Section 1.1, one of the purposes of the experiment 516 described in this document is to verify the safety of using this 517 Protocol Type. Deployments should be aware of the risk of a clash 518 with other uses of this Protocol Type. 520 5. Fragmentation 522 GMA endpoints SHOULD be configured to support fragmentation 523 through additional control messages [MAMS]. However, If 524 fragmentation is not configured or supported, GMA endpoint MUST 525 drop any IP packet (SDU) if its corresponding PDU length adding 526 GMA header (or trailer) and other overhead (e.g., UDP tunneling) 527 exceeds the MTU of a delivery connection. 529 The fragmentation procedure at the convergence sublayer is similar 530 to IP fragmentation [RFC791] in principle, but with the following 531 two differences for less overhead: 533 o The fragment offset field is expressed in number of fragments 534 o The maximum number of fragments per SDU is 2^7 (=128) 536 The Fragmentation Control (FC) field in the GMA trailer (or 537 header) contains the following bits: 539 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 540 is the last one (0) or not (1) 541 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 542 the offset of a particular fragment relative to the beginning 543 of the SDU 545 A PDU carries a whole SDU without fragmentation if the FC field is 546 set to all "0"s or the FC field is not present in the trailer. 547 Otherwise, the PDU contains a fragment of the SDU. 549 The Flow SN field in the trailer is used to distinguish the 550 fragments of one SDU from those of another. The Fragment Offset 551 (FO) field tells the receiver the position of a fragment in the 552 original SDU. The More Fragment (MF) flag indicates the last 553 fragment. 555 To fragment a long SDU, the transmitter creates n PDUs and copies 556 the content of the IP header fields from the long PDU into the IP 557 header of all the PDUs. The length field in the IP header of PDU 558 SHOULD be changed to the length of the PDU, and the protocol type 559 SHOULD be changed to 114. 561 The data of the long SDU is divided into n portions based on the 562 MTU size of the delivery connection. The first portion of the data 563 is placed in the first PDU. The MF flag is set to "1", and the FO 564 field is set to "0". The i-th portion of the data is placed in the 565 i-th PDU. The MF flag is set to "0" if it is the last fragment and 566 set to "1" otherwise. The FO field is set to i-1. 568 To assemble the fragments of a SDU, the receiver combines PDUs 569 that all have the same Flow SN. The combination is done by placing 570 the data portion of each fragment in the relative order indicated 571 by the Fragment Offset in that fragment's GMA trailer (or header). 572 The first fragment will have the Fragment Offset set to "0", and 573 the last fragment will have the More-Fragments flag set to "0". 575 GMA fragmentation operates above the IP layer of individual access 576 connection (Wi-Fi, LTE) and between the two end points of 577 convergence layer. The convergence layer end points (client, 578 multi-access gateway) SHOULD obtain the MTU of individual 579 connection through either manual configuration or implementing 580 PMTUD as suggested in [RFC8900]. 582 6. Concatenation 584 The convergence sublayer MAY support concatenation if a delivery 585 connection has a larger maximum transmission unit (MTU) than the 586 original IP packet (SDU). Only the SDUs with the same client IP 587 address, and the same Flow ID MAY be concatenated. 589 If the (trailer or header based) IP encapsulation method is used, 590 the First SDU Length (FSL) field SHOULD be included in the GMA 591 trailer (or header) to indicate the length of the first SDU. 592 Otherwise, the FSL field SHOULD not be included. 594 +-----------------------------------------------------------+ 595 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 596 +-----------------------------------------------------------+ 597 Figure 8: Example of GMA PDU Format with Concatenation and 598 Trailer-based IP Encapsulation 600 To concatenate two or more SDUs, the transmitter creates one PDU 601 and copies the content of the IP header field from the first SDU 602 into the IP header of the PDU. The data of the first SDU is placed 603 in the first portion of the data of the PDU. The whole second SDU 604 is then placed in the second portion of the data of the PDU 605 (Figure 8). The procedure continues till the PDU size reaches the 606 MTU of the delivery connection. If the FSL field is present, the 607 IP length field of the PDU SHOULD be updated to include all 608 concatenated SDUs and the trailer (or header), and the IP checksum 609 field SHOULD be recalculated if the packet is IPv4. 611 To disaggregate a PDU, if the (header or trailer based) IP 612 encapsulation method is used, the receiver first obtains the 613 length of the first SDU from the FSL field and decodes the first 614 SDU. The receiver then obtains the length of the second SDU based 615 on the length field in the second SDU IP header and decodes the 616 second SDU. The procedure continues till no byte is left in the 617 PDU. If the non-IP encapsulation method (Figure 7) is used, the IP 618 header of the first SDU will not change during the encapsulation 619 process, and the receiver SHOULD obtain the length of the first 620 SDU directly from its IP header (Figure 9). 622 |<-------1st GMA SDU------------ 623 +---------------------------------------------------------------+ 624 | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | 625 +---------------------------------------------------------------+ 626 | IP hdr | IP payload | 627 +-------------------------------------------+ 628 -------->|<-------2nd GMA SDU---------------> 630 Figure 9: Example of GMA PDU Format with Concatenation and Header- 631 based Non-IP (UDP) Encapsulation 633 If a PDU contains multiple SDUs, the Flow SN field is for the last 634 SDU, and the Flow SN of other SDU carried by the same PDU can be 635 obtained according to its order in the PDU. For example, if the SN 636 field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, 637 and 6 for the first, second, and last SDU respectively. 639 GMA concatenation can be used for packing small packets of a 640 single application, e.g., TCP ACKs, or from multiple applications. 641 Notice that a single GMA flow may carry multiple application flows 642 (TCP, UDP, etc.). 644 GMA endpoint MUST NOT perform concatenation and fragmentation in a 645 single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT 646 carry any other (fragmented or whole) SDU. 648 7. Security Considerations 650 Security in a network using GMA should be relatively similar to 651 security in a normal IP network. GMA is unaware of IP or higher 652 layer end-to-end security as it carries the IP packets as opaque 653 payload. Deployers are encouraged to not consider that GMA adds 654 any form of security and to continue to use IP or higher layer 655 security as well as link-layer security. 657 The GMA protocol at the convergence sublayer is a 0-hop protocol 658 and relies on the security of the underlying network transport 659 paths. When this cannot be assumed, appropriate security protocols 660 (IPsec, DTLS, etc.) SHOULD be configured at the adaptation 661 sublayer. On the other hand, packet filtering requires either that 662 a firewall looks inside the GMA packet or that the filtering is 663 done on the GMA endpoints. In those environments in which this is 664 considered to be a security issue it may be desirable to terminate 665 the GMA operation at the firewall. 667 Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on 668 preventing the leak of the local-only GMA PDUs outside the "local 669 domain" to the Internet or to another domain which could use the 670 same IP protocol type, i.e. 114. 672 8. IANA Considerations 674 This document makes no requests of IANA 676 9. References 678 9.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, DOI 682 10.17487/RFC2119, March 1997, . 685 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 686 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 687 May 2017, . 689 [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", 690 . 692 9.2. Informative References 694 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 695 Management Services 696 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 698 [IANA] https://www.iana.org/assignments/protocol- 699 numbers/protocol-numbers.xhtml 701 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 702 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 703 Ipsec Tunnel (LWIP) encapsulation; Protocol 704 specification" 706 [RFC791] Internet Protocol, September 1981 708 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 709 and splitting support in the 5G system architecture. 711 [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 713 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, 714 O., and F. Gont, "IP Fragmentation Considered Fragile", 715 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 716 . 718 [IANA1999]https://web.archive.org/web/19990203044112/http://www.is 719 i.edu:80/in-notes/iana/assignments/protocol-numbers 721 Authors' Addresses 723 Jing Zhu 725 Intel 727 Email: jing.z.zhu@intel.com 729 Satish Kanugovi 731 Nokia 733 Email: satish.k@nokia.com