idnits 2.17.1 draft-zhu-intarea-gma-10.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 (June 21, 2021) is 1041 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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: December 21,2021 Nokia 5 June 21, 2021 7 Generic Multi-Access (GMA) Encapsulation Protocol 8 draft-zhu-intarea-gma-10 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 October 21, 2021. 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 in 1995. 507 There is some risk associated with "re-using" Protocol Type 114 508 because there may be implementations of other protocols also using 509 this Protocol Type. However, because the protocol described in 510 this document is used only between adjacent devices specifically 511 configured for this purpose, the use of Protocol Type 114 should 512 be safe. 514 As described in Section 1.1, one of the purposes of the experiment 515 described in this document is to verify the safety of using this 516 Protocol Type. Deployments should be aware of the risk of a clash 517 with other uses of this Protocol Type. 519 5. Fragmentation 521 GMA endpoints SHOULD be configured to support fragmentation 522 through additional control messages [MAMS]. However, If 523 fragmentation is not configured or supported, GMA endpoint MUST 524 drop any IP packet (SDU) if its corresponding PDU length adding 525 GMA header (or trailer) and other overhead (e.g., UDP tunneling) 526 exceeds the MTU of a delivery connection. 528 The fragmentation procedure at the convergence sublayer is similar 529 to IP fragmentation [RFC791] in principle, but with the following 530 two differences for less overhead: 532 o The fragment offset field is expressed in number of fragments 533 o The maximum number of fragments per SDU is 2^7 (=128) 535 The Fragmentation Control (FC) field in the GMA trailer (or 536 header) contains the following bits: 538 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 539 is the last one (0) or not (1) 540 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 541 the offset of a particular fragment relative to the beginning 542 of the SDU 544 A PDU carries a whole SDU without fragmentation if the FC field is 545 set to all "0"s or the FC field is not present in the trailer. 546 Otherwise, the PDU contains a fragment of the SDU. 548 The Flow SN field in the trailer is used to distinguish the 549 fragments of one SDU from those of another. The Fragment Offset 550 (FO) field tells the receiver the position of a fragment in the 551 original SDU. The More Fragment (MF) flag indicates the last 552 fragment. 554 To fragment a long SDU, the transmitter creates n PDUs and copies 555 the content of the IP header fields from the long PDU into the IP 556 header of all the PDUs. The length field in the IP header of PDU 557 SHOULD be changed to the length of the PDU, and the protocol type 558 SHOULD be changed to 114. 560 The data of the long SDU is divided into n portions based on the 561 MTU size of the delivery connection. The first portion of the data 562 is placed in the first PDU. The MF flag is set to "1", and the FO 563 field is set to "0". The i-th portion of the data is placed in the 564 i-th PDU. The MF flag is set to "0" if it is the last fragment and 565 set to "1" otherwise. The FO field is set to i-1. 567 To assemble the fragments of a SDU, the receiver combines PDUs 568 that all have the same Flow SN. The combination is done by placing 569 the data portion of each fragment in the relative order indicated 570 by the Fragment Offset in that fragment's GMA trailer (or header). 571 The first fragment will have the Fragment Offset set to "0", and 572 the last fragment will have the More-Fragments flag set to "0". 574 GMA fragmentation operates above the IP layer of individual access 575 connection (Wi-Fi, LTE) and between the two end points of 576 convergence layer. The convergence layer end points (client, 577 multi-access gateway) SHOULD obtain the MTU of individual 578 connection through either manual configuration or implementing 579 PMTUD as suggested in [RFC8900]. 581 6. Concatenation 583 The convergence sublayer MAY support concatenation if a delivery 584 connection has a larger maximum transmission unit (MTU) than the 585 original IP packet (SDU). Only the SDUs with the same client IP 586 address, and the same Flow ID MAY be concatenated. 588 If the (trailer or header based) IP encapsulation method is used, 589 the First SDU Length (FSL) field SHOULD be included in the GMA 590 trailer (or header) to indicate the length of the first SDU. 591 Otherwise, the FSL field SHOULD not be included. 593 +-----------------------------------------------------------+ 594 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 595 +-----------------------------------------------------------+ 596 Figure 8: Example of GMA PDU Format with Concatenation and 597 Trailer-based IP Encapsulation 599 To concatenate two or more SDUs, the transmitter creates one PDU 600 and copies the content of the IP header field from the first SDU 601 into the IP header of the PDU. The data of the first SDU is placed 602 in the first portion of the data of the PDU. The whole second SDU 603 is then placed in the second portion of the data of the PDU 604 (Figure 8). The procedure continues till the PDU size reaches the 605 MTU of the delivery connection. If the FSL field is present, the 606 IP length field of the PDU SHOULD be updated to include all 607 concatenated SDUs and the trailer (or header), and the IP checksum 608 field SHOULD be recalculated if the packet is IPv4. 610 To disaggregate a PDU, if the (header or trailer based) IP 611 encapsulation method is used, the receiver first obtains the 612 length of the first SDU from the FSL field and decodes the first 613 SDU. The receiver then obtains the length of the second SDU based 614 on the length field in the second SDU IP header and decodes the 615 second SDU. The procedure continues till no byte is left in the 616 PDU. If the non-IP encapsulation method (Figure 7) is used, the IP 617 header of the first SDU will not change during the encapsulation 618 process, and the receiver SHOULD obtain the length of the first 619 SDU directly from its IP header (Figure 9). 621 |<-------1st GMA SDU------------ 622 +---------------------------------------------------------------+ 623 | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | 624 +---------------------------------------------------------------+ 625 | IP hdr | IP payload | 626 +-------------------------------------------+ 627 -------->|<-------2nd GMA SDU---------------> 629 Figure 9: Example of GMA PDU Format with Concatenation and Header- 630 based Non-IP (UDP) Encapsulation 632 If a PDU contains multiple SDUs, the Flow SN field is for the last 633 SDU, and the Flow SN of other SDU carried by the same PDU can be 634 obtained according to its order in the PDU. For example, if the SN 635 field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, 636 and 6 for the first, second, and last SDU respectively. 638 GMA concatenation can be used for packing small packets of a 639 single application, e.g., TCP ACKs, or from multiple applications. 640 Notice that a single GMA flow may carry multiple application flows 641 (TCP, UDP, etc.). 643 GMA endpoint MUST NOT perform concatenation and fragmentation in a 644 single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT 645 carry any other (fragmented or whole) SDU. 647 7. Security Considerations 649 Security in a network using GMA should be relatively similar to 650 security in a normal IP network. GMA is unaware of IP or higher 651 layer end-to-end security as it carries the IP packets as opaque 652 payload. Deployers are encouraged to not consider that GMA adds 653 any form of security and to continue to use IP or higher layer 654 security as well as link-layer security. 656 The GMA protocol at the convergence sublayer is a 0-hop protocol 657 and relies on the security of the underlying network transport 658 paths. When this cannot be assumed, appropriate security protocols 659 (IPsec, DTLS, etc.) SHOULD be configured at the adaptation 660 sublayer. On the other hand, packet filtering requires either that 661 a firewall looks inside the GMA packet or that the filtering is 662 done on the GMA endpoints. In those environments in which this is 663 considered to be a security issue it may be desirable to terminate 664 the GMA operation at the firewall. 666 Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on 667 preventing the leak of the local-only GMA PDUs outside the "local 668 domain" to the Internet or to another domain which could use the 669 same IP protocol type, i.e. 114. 671 8. IANA Considerations 673 This document makes no requests of IANA 675 9. References 677 9.1. Normative References 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, DOI 681 10.17487/RFC2119, March 1997, . 684 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 685 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 686 May 2017, . 688 [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", 689 . 691 9.2. Informative References 693 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 694 Management Services 695 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 697 [IANA] https://www.iana.org/assignments/protocol- 698 numbers/protocol-numbers.xhtml 700 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 701 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 702 Ipsec Tunnel (LWIP) encapsulation; Protocol 703 specification" 705 [RFC791] Internet Protocol, September 1981 707 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 708 and splitting support in the 5G system architecture. 710 [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 712 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, 713 O., and F. Gont, "IP Fragmentation Considered Fragile", 714 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 715 . 717 Authors' Addresses 719 Jing Zhu 721 Intel 723 Email: jing.z.zhu@intel.com 725 Satish Kanugovi 727 Nokia 729 Email: satish.k@nokia.com