idnits 2.17.1 draft-zhu-intarea-gma-12.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 21, 2021) is 917 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IANA1999' is mentioned on line 536, 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 21,2022 Nokia 5 October 21, 2021 7 Generic Multi-Access (GMA) Encapsulation Protocol 8 draft-zhu-intarea-gma-12 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 21, 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 .................................... 7 72 4.1. Trailer-based IP Encapsulation .........................8 73 4.2. Header-based IP Encapsulation .........................11 74 4.3. (Header-based) non-IP Encapsulation ...................11 75 4.4. IP Protocol Identifier ................................12 76 5. Fragmentation ............................................... 12 77 6. Concatenation ............................................... 14 78 7. Security Considerations ..................................... 15 79 8. IANA Considerations ......................................... 15 80 9. References .................................................. 16 81 9.1. Normative References ..................................16 82 9.2. Informative References ................................16 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. The experiment should consider the 194 following safety mechanisms: 196 o GMA endpoints SHOULD detect non-GMA IP packets that also use 197 114 and log an error to report the situation (although such 198 error logging MUST be subject to rate limits). 199 o GMA endpoints SHOULD stop using 114 and switch to non-IP 200 (UDP) based encapsulation (Sec 4.3, Figure 7) after detecting 201 any non-GMA usage of 114. 203 The experiment SHOULD use packet tracing tool, e.g., WireShark, 204 TCPDUMP, to monitor both ingress and egress traffic at GMA 205 endpoints and ensure the above safety mechanisms are implemented. 207 Path quality measurements (one-way-delay, loss, etc.) and 208 congestion detection are performed by receiver based on the GMA 209 control fields, e.g., sequence number, timestamp, etc. Receiver 210 will then dynamically control how to split or steer traffic over 211 multiple delivery connections accordingly. GMA control protocol 212 [GMAC] MAY be used for signaling between GMA endpoints. Another 213 objective of the experiment is to evaluate the usage of various 214 receiver-based algorithms [GCC] [MPIP] in multi-path traffic 215 management, and the impact on the e2e performance (throughput, 216 delay, etc.) of higher layer (transport) protocols, e.g., TCP, 217 QUIC, WebRTC, etc. 219 The authors will continually assess the progress of this 220 experiment and encourage other implementers to contact them to 221 report the status of their implementations and their experiences 222 with the protocol. 224 2. Conventions used in this document 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 227 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 228 "MAY", and "OPTIONAL" in this document are to be interpreted as 229 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 230 appear in all capitals, as shown here. 232 3. Use Case 234 As shown in Figure 2, a client device (e.g., Smartphone, Laptop, 235 etc.) may connect to the Internet via both Wi-Fi and LTE 236 connections, one of which (e.g., LTE) may operate as the anchor 237 connection, and the other (e.g., Wi-Fi) may operate as the 238 delivery connection. The anchor connection provides the IP address 239 and connectivity for end-to-end Internet access, and the delivery 240 connection provides an additional path between client and Multi- 241 Access Gateway for multi-access optimizations. 243 Multi-Access Aggregation 245 +---+ +---+ 246 | |A|--- LTE Connection -----|C| | 247 |U|-| |-|S| Internet 248 | |B|--- Wi-Fi Connection ---|D| | 249 +---+ +---+ 250 Client Multi-Access Gateway 252 A: The adaptation layer endpoint of the LTE connection 253 resides in the client 255 B: The adaptation layer endpoint of the Wi-Fi connection 256 resides in the client 258 C: The adaptation layer endpoint of the LTE connection 259 resides in the Multi-Access Gateway, aka N-MADP (Network 260 Multi-Access Data Proxy) in [MAMS] 262 D: The adaptation layer endpoint of the Wi-Fi connection 263 resides in the Multi-Access Gateway 265 U: The convergence layer endpoint resides in the client 267 S: The convergence layer endpoint resides in the Multi- 268 Access Gateway 270 Figure 2: GMA-based Multi-Access Aggregation 272 For example, per-packet aggregation allows a single IP flow to use 273 the combined bandwidth of the two connections. In another example, 274 packets lost due to a temporarily link outage may be 275 retransmitted. Moreover, packets may be duplicated over multiple 276 connections to achieve high reliability and low latency, where 277 duplicated packets are eliminated by the receiving side. Such 278 multi-access optimization requires additional control information, 279 e.g., a sequence number, in each packet, which can be supported by 280 the GMA encapsulation protocol described in this document. 282 The GMA protocol described in this document is designed for 283 multiple connections, but it may also be used when there is only 284 one connection between two endpoints. For example, it may be used 285 for loss detection and recovery. In another example, it may be 286 used to concatenate multiple small packets and reduce per packet 287 overhead. 289 4. GMA Encapsulation Methods 291 The GMA encapsulation protocol supports the following three 292 methods: 294 o Trailer-based IP Encapsulation (4.1) 295 o Header-based IP Encapsulation (4.2) 296 o (Header-based) non-IP Encapsulation (4.3) 298 Trailer-based IP encapsulation MUST be used if it is supported by 299 GMA endpoints. 301 Header-based encapsulation MUST be used if the trailer-based 302 method is not supported by either Client or Multi-Access Gateway. 303 In this case, if the adaptation layer, e.g., UDP tunnelling, 304 supports non-IP packet format, non-IP encapsulation MUST be used; 305 otherwise, header-based IP encapsulation MUST be used. 307 If non-IP encapsulation is configured, a GMA header MUST be 308 present in every packet. In comparison, if IP encapsulation is 309 configured, a GMA header or trailer may be added dynamically on 310 per-packet basis, and it indicates the presence of GMA header (or 311 trailer) to set the protocol type of the GMA PDU to "114" (see 312 Section 4.4). 314 The GMA endpoints MAY configure the GMA encapsulation method 315 through control signalling or pre-configuration. For example, the 316 "MX UP Setup Configuration Request" message as specified in Multi- 317 Access Management Service [MAMS] includes "MX Convergence Method 318 Parameters", which provides the list of parameters to configure 319 the convergence layer, and can be extended to indicate the GMA 320 encapsulation method. 322 GMA endpoint MUST discard a received packet and MAY log an error 323 to report the situation (although such error logging MUST be 324 subject to rate limits) under any of the following conditions: 326 . the GMA version number in the GMA header (or trailer) is not 327 understood or supported by the GMA endpoint 328 . a Flag bit in the GMA header (or trailer) not understood or 329 supported by the GMA endpoint is set to "1" 331 4.1. Trailer-based IP Encapsulation 333 |<---------------------GMA PDU ----------------------->| 334 +------------------------------------------------------+ 335 | IP hdr | IP payload | GMA Trailer | 336 +------------------------------------------------------+ 337 |<------- GMA SDU (user payload)-------->| 339 Figure 3: GMA PDU Format with Trailer-based IP Encapsulation 341 Figure 3 shows the trailer-based IP encapsulation GMA PDU 342 (protocol data unit) format. A (GMA) PDU may carry one or multiple 343 IP packets, aka (GMA) SDUs (service data unit), in the payload, or 344 a fragment of the SDU. 346 The Protocol Type field in the IP header of the GMA PDU MUST be 347 changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to indicate 348 the presence of the GMA trailer. 350 If the original IP packet is IPv4, the following three IP header 351 fields MUST be changed: 353 o IP Length: add the length of "GMA Trailer" to the length of 354 the original IP packet 355 o Time To Live (TTL): set to "1" 356 o IP checksum: recalculate after changing "Protocol Type", "TTL" 357 and "IP Length" 359 If the original IP packet is IPv6, the following two IP header 360 fields MUST be changed: 362 o IP Length: add the length of "GMA Trailer" to the length of 363 the original IP packet 364 o Hop-Limit (HL): set the HL field to "0" 366 The GMA (Generic Multi-Access) trailer MUST consist of two 367 mandatory fields (the last 3 bytes): Next Header and Flags, 368 defined as follows: 370 o Next Header (1 Byte): the IP protocol type of the (first) SDU 371 in a PDU, and it stores the value before it was overwritten to 372 114. 373 o Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and 374 Bit 15 is the least significant bit (LSB) 375 + Checksum Present (bit 0): If the Checksum Present bit is set 376 to 1, then the Checksum field is present 377 + Concatenation Present (bit 1): If the Concatenation Present 378 bit is set to 1, then the PDU carries multiple SDUs, and the 379 First SDU Length field is present 380 + Connection ID Present (bit 2): If the Connection ID Present 381 bit is set to 1, then the Connection ID field is present 382 + Flow ID Present (bit 3): If the Flow ID Present bit is set 383 to 1, then the Flow ID field is present 384 + Fragmentation Present (bit 4): If the Fragmentation Present 385 bit is set to 1, then the PDU carry a fragment of the SDU and 386 the Fragmentation Control field is present 387 + Delivery SN Present (bit 5): If the Delivery SN (Sequence 388 Number) Present bit is set to 1, then the Delivery SN field is 389 present and contains the valid information 390 + Flow SN Present (bit 6): If the Flow SN Present bit is set 391 to 1, then the Sequence Number field is present 392 + Timestamp Present (bit 7): If the Timestamp Present bit is 393 set to 1, then the Timestamp field is present 394 + TTL Present (bit 8): If the TTL Present bit is set to 1, 395 then the TTL field is present 396 + Reserved (bit 9-12): set to "0" and ignored on receipt 397 + Version (bit 13~15): GMA version number, set to 0 for the 398 GMA encapsulation protocol specified in this document. 400 The Flags field is at the end of the PDU, and the Next Header 401 field is the second last. The Receiver SHOULD first decode the 402 Flags field to determine the length of the GMA trailer, and then 403 decode each optional field accordingly. The GMA (Generic Multi- 404 Access) trailer MAY consist of the following optional fields: 406 o Checksum (1 Byte): to contain the (one's complement) checksum 407 sum of all the 8 bits in the trailer. For purposes of 408 computing the checksum, the value of the checksum field is 409 zero. This field is present only if the Checksum Present bit 410 is set to one. 411 o First SDU Length (2 Bytes): the length of the first IP packet 412 in the PDU, only included if a PDU contains multiple IP 413 packets. This field is present only if the Concatenation 414 Present bit is set to one. 415 o Connection ID (1 Byte): an unsigned integer to identify the 416 anchor and delivery connection of the GMA PDU. This field is 417 present only if the Connection ID Present bit is set to one. 418 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 419 identify the anchor connection 420 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 421 identify the delivery connection 422 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 423 that a PDU belongs to, for example Data Radio Bearer (DRB) ID 425 [LWIPEP] for a cellular (e.g., LTE) connection. This field is 426 present only if the Flow ID Present bit is set to one. 427 o Fragmentation Control (FC) (1 Byte): to provide necessary 428 information for re-assembly, only needed if a PDU carries 429 fragments. This field is present only if the Fragmentation 430 Present bit is set to one. Please refer to section 5 for its 431 detailed format and usage. 432 o Delivery SN (1 Byte): an auto-incremented integer to indicate 433 the GMA PDU transmission order on a delivery connection. 434 Delivery SN is needed to measure packet loss of each delivery 435 connection and therefore generated per delivery connection per 436 flow. This field is present only if the Delivery SN Present 437 bit is set to one. 438 o Flow SN (3 Bytes): an auto-incremented integer to indicate the 439 GMA SDU (IP packet) order of a flow. Flow SN is needed for 440 retransmission, reordering, and fragmentation. It SHALL be 441 generated per flow. This field is present only if the Flow SN 442 Present bit is set to one. 443 o Timestamp (4 Bytes): to contain the current value of the 444 timestamp clock of the transmitter in the unit of 1 445 millisecond. This field is present only if the Timestamp 446 Present bit is set to one. 447 o TTL (1 Byte): to contain the TTL value of the original IP 448 header if the GMA SDU is IPv4, or the Hop-Limit value of the 449 IP header if the GMA SDU is IPv6. This field is present only 450 if the TTL Present bit is set to one. 452 Figure 4 shows the GMA trailer format with all the fields present, 453 and the order of the GMA control fields SHALL follow the bit order 454 in the Flags field. Note that the bits in the Flags field are 455 ordered with the first bit transmitted being bit 0 (MSB). All 456 fields are transmitted in regular network byte order and appear in 457 reverse order to their corresponding flag bits. If a flag bit is 458 clear, the corresponding optional field is absent. 460 For example, Bit 0 (the MSB) of the Flags field is the Checksum 461 Present bit, and the Checksum field is the last in the trailer 462 except of the two mandatory fields. Bit 1 is the Concatenation 463 present bit, and the FSL field is the second last. 465 0 1 2 3 466 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | TTL | Timestamp 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Flow SN | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Delivery SN | FC | Flow ID | Connection ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | First SDU Length (FSL) | Checksum | Next Header | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Flags | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 4: GMA Trailer Format with all Optional Fields Present 481 4.2. Header-based IP Encapsulation 483 Figure 5 shows the header-based IP encapsulation format. Here, the 484 GMA header is inserted right after the IP header of the GMA SDU, 485 and the IP header fields of the GMA PDU MUST be changed the same 486 way as in trailered-based IP encapsulation. 488 +-----------------------------------------------+ 489 |IP hdr | GMA Header | IP payload | 490 +-----------------------------------------------+ 491 Figure 5: GMA PDU Format with Header-based IP Encapsulation 493 Figure 6 shows the GMA header format. In comparison to GMA 494 trailer, the only difference is that the Flags field is now in the 495 front so that the Receiver can first decode the Flags field to 496 determine the GMA header length. 498 "TTL" field MUST be included and the "TTL" bit in the GMA header 499 (or Trailer) MUST be set to 1 if (Trailer or Header based) IP 500 Encapsulation is used. 502 +------------------------------------------------------+ 503 | Flags | other fields (TTL, Timestamp, Flow SN, etc.) | 504 +------------------------------------------------------+ 505 Figure 6: GMA Header Format 507 4.3. (Header-based) non-IP Encapsulation 509 Figure 7 shows the header-based non-IP encapsulation format. Here, 510 "UDP Tunnelling" is configured at the MX adaptation layer. The 511 ports for "UDP Tunnelling" at Client are chosen from the Dynamic 512 Port range, and the ports for "UDP Tunnelling" at Multi-Access 513 Gateway are configured and provided to Client through additional 514 control messages, e.g., [MAMS]. 516 "TTL", "FSL", and "Next Header" are no longer needed, and MUST not 517 be included. Moreover, the IP header fields of the GMA SDU remain 518 unchanged. 520 +-------------------------------------------------------------+ 521 | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | 522 +-------------------------------------------------------------+ 523 |<------- GMA SDU------------>| 524 |<------------------- GMA PDU------------>| 526 Figure 7: GMA PDU Format with Non-IP Encapsulation 528 4.4. IP Protocol Identifier 530 As described in Section 4.1, IP encapsulated GMA PDUs are 531 indicated using the IP Protocol Type 114. This is designated and 532 recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No 533 reference is given in the IANA registry for the definition of this 534 Protocol Type, and IANA has no record of why the assignment was 535 made or how it is used, although it was probably assigned before 536 1999 [IANA1999]. 538 There is some risk associated with "re-using" Protocol Type 114 539 because there may be implementations of other protocols also using 540 this Protocol Type. However, because the protocol described in 541 this document is used only between adjacent devices specifically 542 configured for this purpose, the use of Protocol Type 114 should 543 be safe. 545 As described in Section 1.1, one of the purposes of the experiment 546 described in this document is to verify the safety of using this 547 Protocol Type. Deployments should be aware of the risk of a clash 548 with other uses of this Protocol Type. 550 5. Fragmentation 552 If the MTU size of the anchor connection (for GMA SDU) is 553 configured such that the corresponding GMA PDU length adding GMA 554 header (or trailer) and other overhead (UDP tunneling) MAY exceed 555 the MTU of a delivery connection, GMA endpoints MUST be configured 556 to support fragmentation through additional control messages 557 [MAMS]. 559 The fragmentation procedure at the convergence sublayer is similar 560 to IP fragmentation [RFC791] in principle, but with the following 561 two differences for less overhead: 563 o The fragment offset field is expressed in number of fragments 564 o The maximum number of fragments per SDU is 2^7 (=128) 566 The Fragmentation Control (FC) field in the GMA trailer (or 567 header) contains the following bits: 569 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 570 is the last one (0) or not (1) 571 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 572 the offset of a particular fragment relative to the beginning 573 of the SDU 575 A PDU carries a whole SDU without fragmentation if the FC field is 576 set to all "0"s or the FC field is not present in the trailer. 577 Otherwise, the PDU contains a fragment of the SDU. 579 The Flow SN field in the trailer is used to distinguish the 580 fragments of one SDU from those of another. The Fragment Offset 581 (FO) field tells the receiver the position of a fragment in the 582 original SDU. The More Fragment (MF) flag indicates the last 583 fragment. 585 To fragment a long SDU, the transmitter creates n PDUs and copies 586 the content of the IP header fields from the long PDU into the IP 587 header of all the PDUs. The length field in the IP header of PDU 588 SHOULD be changed to the length of the PDU, and the protocol type 589 SHOULD be changed to 114. 591 The data of the long SDU is divided into n portions based on the 592 MTU size of the delivery connection. The first portion of the data 593 is placed in the first PDU. The MF flag is set to "1", and the FO 594 field is set to "0". The i-th portion of the data is placed in the 595 i-th PDU. The MF flag is set to "0" if it is the last fragment and 596 set to "1" otherwise. The FO field is set to i-1. 598 To assemble the fragments of a SDU, the receiver combines PDUs 599 that all have the same Flow SN. The combination is done by placing 600 the data portion of each fragment in the relative order indicated 601 by the Fragment Offset in that fragment's GMA trailer (or header). 602 The first fragment will have the Fragment Offset set to "0", and 603 the last fragment will have the More-Fragments flag set to "0". 605 GMA fragmentation operates above the IP layer of individual access 606 connection (Wi-Fi, LTE) and between the two end points of 607 convergence layer. The convergence layer end points (client, 608 multi-access gateway) SHOULD obtain the MTU of individual 609 connection through either manual configuration or implementing 610 PMTUD as suggested in [RFC8900]. 612 6. Concatenation 614 The convergence sublayer MAY support concatenation if a delivery 615 connection has a larger maximum transmission unit (MTU) than the 616 original IP packet (SDU). Only the SDUs with the same client IP 617 address, and the same Flow ID MAY be concatenated. 619 If the (trailer or header based) IP encapsulation method is used, 620 the First SDU Length (FSL) field SHOULD be included in the GMA 621 trailer (or header) to indicate the length of the first SDU. 622 Otherwise, the FSL field SHOULD not be included. 624 +-----------------------------------------------------------+ 625 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 626 +-----------------------------------------------------------+ 627 Figure 8: Example of GMA PDU Format with Concatenation and 628 Trailer-based IP Encapsulation 630 To concatenate two or more SDUs, the transmitter creates one PDU 631 and copies the content of the IP header field from the first SDU 632 into the IP header of the PDU. The data of the first SDU is placed 633 in the first portion of the data of the PDU. The whole second SDU 634 is then placed in the second portion of the data of the PDU 635 (Figure 8). The procedure continues till the PDU size reaches the 636 MTU of the delivery connection. If the FSL field is present, the 637 IP length field of the PDU SHOULD be updated to include all 638 concatenated SDUs and the trailer (or header), and the IP checksum 639 field SHOULD be recalculated if the packet is IPv4. 641 To disaggregate a PDU, if the (header or trailer based) IP 642 encapsulation method is used, the receiver first obtains the 643 length of the first SDU from the FSL field and decodes the first 644 SDU. The receiver then obtains the length of the second SDU based 645 on the length field in the second SDU IP header and decodes the 646 second SDU. The procedure continues till no byte is left in the 647 PDU. If the non-IP encapsulation method (Figure 7) is used, the IP 648 header of the first SDU will not change during the encapsulation 649 process, and the receiver SHOULD obtain the length of the first 650 SDU directly from its IP header (Figure 9). 652 |<-------1st GMA SDU------------ 653 +---------------------------------------------------------------+ 654 | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | 655 +---------------------------------------------------------------+ 656 | IP hdr | IP payload | 657 +-------------------------------------------+ 658 -------->|<-------2nd GMA SDU---------------> 659 Figure 9: Example of GMA PDU Format with Concatenation and Header- 660 based Non-IP (UDP) Encapsulation 662 If a PDU contains multiple SDUs, the Flow SN field is for the last 663 SDU, and the Flow SN of other SDU carried by the same PDU can be 664 obtained according to its order in the PDU. For example, if the SN 665 field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, 666 and 6 for the first, second, and last SDU respectively. 668 GMA concatenation can be used for packing small packets of a 669 single application, e.g., TCP ACKs, or from multiple applications. 670 Notice that a single GMA flow may carry multiple application flows 671 (TCP, UDP, etc.). 673 GMA endpoint MUST NOT perform concatenation and fragmentation in a 674 single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT 675 carry any other (fragmented or whole) SDU. 677 7. Security Considerations 679 Security in a network using GMA should be relatively similar to 680 security in a normal IP network. GMA is unaware of IP or higher 681 layer end-to-end security as it carries the IP packets as opaque 682 payload. Deployers are encouraged to not consider that GMA adds 683 any form of security and to continue to use IP or higher layer 684 security as well as link-layer security. 686 The GMA protocol at the convergence sublayer is a 0-hop protocol 687 and relies on the security of the underlying network transport 688 paths. When this cannot be assumed, appropriate security protocols 689 (IPsec, DTLS, etc.) SHOULD be configured at the adaptation 690 sublayer. On the other hand, packet filtering requires either that 691 a firewall looks inside the GMA packet or that the filtering is 692 done on the GMA endpoints. In those environments in which this is 693 considered to be a security issue it may be desirable to terminate 694 the GMA operation at the firewall. 696 Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on 697 preventing the leak of the local-only GMA PDUs outside the "local 698 domain" to the Internet or to another domain which could use the 699 same IP protocol type, i.e. 114. 701 8. IANA Considerations 703 This document makes no requests of IANA 705 9. References 707 9.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, DOI 711 10.17487/RFC2119, March 1997, . 714 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 715 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 716 May 2017, . 718 [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", 719 . 721 9.2. Informative References 723 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 724 Management Services 725 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 727 [IANA] https://www.iana.org/assignments/protocol- 728 numbers/protocol-numbers.xhtml 730 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 731 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 732 Ipsec Tunnel (LWIP) encapsulation; Protocol 733 specification" 735 [RFC791] Internet Protocol, September 1981 737 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 738 and splitting support in the 5G system architecture. 740 [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 742 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, 743 O., and F. Gont, "IP Fragmentation Considered Fragile", 744 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 745 . 747 [IANA1999]https://web.archive.org/web/19990203044112/http://www.is 748 i.edu:80/in-notes/iana/assignments/protocol-numbers 750 [GCC] S. Holmer, et al. A Google Congestion Control Algorithm for 751 Real-Time Communication, 752 https://www.ietf.org/archive/id/draft-ietf-rmcat-gcc- 753 02.txt 755 [MPIP] L. Sun, et al. Multipath IP Routing on End Devices: 756 Motivation, Design, and 757 Performance, https://eeweb.engineering.nyu.edu/faculty/ 758 yongliu/docs/MPIP_Tech.pdf 760 [GMAC] J. Zhu M. Zhang, UDP-based GMA Control 761 Protocol, https://www.ietf.org/archive/id/draft-zhu- 762 intarea-gma-control-00.txt 764 Authors' Addresses 766 Jing Zhu 768 Intel 770 Email: jing.z.zhu@intel.com 772 Satish Kanugovi 774 Nokia 776 Email: satish.k@nokia.com