idnits 2.17.1 draft-zhu-intarea-gma-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2020) is 1487 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTAREA/Network Working Group J. Zhu 2 Internet Draft Intel 3 Intended status: Informational S. Kanugovi 4 Expires: September 31,2020 Nokia 5 March 31, 2020 7 Generic Multi-Access (GMA) Convergence Encapsulation Protocols 8 draft-zhu-intarea-gma-06 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on August 31, 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 Today, a device can be simultaneously connected to multiple 52 networks, e.g. Wi-Fi, LTE, 5G, and DSL. It is desirable to combine 53 them seamlessly to improve quality of experience. Such 54 optimization requires additional control information, e.g. 55 Sequence Number, in each (IP) data packet. This document presents 56 a new light-weight and flexible encapsulation protocol for this 57 need. The solution has been developed by the authors based on 58 their experiences in multiple standards bodies including the IETF 59 and 3GPP, is not an Internet Standard and does not represent the 60 consensus opinion of the IETF. This document will enable other 61 developers to build interoperable implementations. 63 Table of Contents 65 1. Introduction ................................................. 2 66 2. Conventions used in this document ............................ 4 67 3. Use Case ..................................................... 4 68 4. GMA Encapsulation Format ..................................... 5 69 5. Fragmentation ................................................ 8 70 6. Concatenation ............................................... 10 71 7. Security Considerations ..................................... 11 72 8. IANA Considerations ......................................... 11 73 9. References .................................................. 11 74 9.1. Normative References ..................................11 75 9.2. Informative References ................................11 77 1. Introduction 79 Figure 1 shows the user-plane Generic Multi-Access (GMA) protocol 80 stack, which has been used in today's multi-access solutions 81 [ATSSS] [MAMS] [LWIPEP] [GRE]. 83 +-----------------------------------------------------+ 84 | IP PDU | 85 |-----------------------------------------------------| 86 | Convergence Sublayer | 87 |-----------------------------------------------------| 88 | Adaptation | Adaptation | Adaptation | 89 | Sublayer | Sublayer | Sublayer | 90 | (optional) | (optional) | (optional) | 91 |-----------------------------------------------------| 92 | Access #1 IP | Access #2 IP | Access #3 IP | 93 +-----------------------------------------------------+ 94 Figure 1: GMA User-Plane Protocol Stack 96 It consists of the following two Sublayers: 98 o Convergence sublayer: This layer performs multi-access 99 specific tasks, e.g., multi-link (path) aggregation, 100 splitting/reordering, lossless switching/retransmission, 101 fragmentation, concatenation, etc. 102 o Adaptation sublayer: This layer performs functions to handle 103 tunnelling, network layer security, and NAT (network address 104 translation). 106 The convergence sublayer operates on top of the adaptation 107 sublayer in the protocol stack. From the Transmitter perspective, 108 a User Payload (e.g. IP packet) is processed by the convergence 109 sublayer first, and then by the adaptation sublayer before being 110 transported over a delivery connection; from the Receiver 111 perspective, an IP packet received over a delivery connection is 112 processed by the adaptation sublayer first, and then by the 113 convergence sublayer. 115 IP-over-IP tunneling has been used in today's multi-access 116 solutions, e.g. [LWIPEP] [GRE], to insert the GRE header, and then 117 encode additional control information in the GRE header fields, 118 e.g. Key, Sequence Number. However, there are two main drawbacks 119 with this approach: 1) IP-over-IP tunneling leads to higher 120 overhead especially for small packet. For example, the overhead of 121 IP-over-IP/GRE tunneling with both Key and Sequence Number is 32 122 Bytes, which is 80% of a 40 Bytes TCP ACK packet; 2) It is 123 difficult to introduce new control fields with the GRE header 124 format. 126 This document presents a light-weight GMA encapsulation protocol 127 for the convergence sublayer. It avoids IP-over-IP tunneling to 128 minimize overhead and introduces new control fields to support 129 fragmentation and concatenation at the convergence sublayer, which 130 are not available in today's GRE-based solutions [LWIPEP] [GRE]. 132 GMA protocol SHALL only operate between endpoints that have been 133 configured to operate with GMA through additional control messages 134 and procedures, for example [MAMS]. Moreover, UDP or IPSec 135 tunneling MAY be used at the adaptation sublayer to protect GMA 136 operation from intermediate nodes. 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 141 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 142 "MAY", and "OPTIONAL" in this document are to be interpreted as 143 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 144 appear in all capitals, as shown here. 146 3. Use Case 148 Multi-Access Aggregation 150 +---+ +---+ 151 | |A|--- LTE Connection -----|C| | 152 |U|-| |-|S| Internet 153 | |B|--- Wi-Fi Connection ---|D| | 154 +---+ +---+ 155 Client Multi-Access Gateway 157 A: The adaptation sublayer endpoint of the LTE connection 158 resides in the client 160 B: The adaptation sublayer endpoint of the Wi-Fi connection 161 resides in the client 163 C: The adaptation sublayer endpoint of the LTE connection 164 resides in the Multi-Access Gateway, aka N-MADP (Network 165 Multi-Access Data Proxy) in [MAMS] 167 D: The adaptation sublayer endpoint of the Wi-Fi connection 168 resides in the Multi-Access Gateway 170 U: The convergence sublayer endpoint resides in the client 172 S: The convergence sublayer endpoint resides in the Multi- 173 Access Gateway 175 Figure 2: GMA-based Multi-Access Aggregation 177 As shown in Figure 2, a client device (e.g. Smartphone, Laptop, 178 etc.) may connect to Internet via both Wi-Fi and LTE connections, 179 one of which (e.g. LTE) may operate as the anchor connection, and 180 the other (e.g. Wi-Fi) may operate as the delivery connection. The 181 anchor connection provides the IP address and connectivity for 182 end-to-end Internet access, and the delivery connection provides 183 additional path between client and Multi-Access Gateway for multi- 184 access optimizations. 186 For example, per-packet aggregation allows a single IP flow to use 187 the combined bandwidth of the two connections. In another example, 188 packets lost due to temporarily link outage may be retransmitted. 189 Moreover, packets may be duplicated over multiple connections to 190 achieve high reliability and low latency, and duplicated packets 191 should be eliminated by the receiving side. Such multi-access 192 optimization requires additional control information, e.g. 193 Sequence Number, in each IP data packet, which can be supported by 194 the GMA encapsulation protocol described in this document. 196 The GMA protocol in this document is designed for multiple 197 connections, but it may also be used when there is only one 198 connection between two end-points. For example, it may be used for 199 loss detection and recovery. In another example, it may be used to 200 concatenate multiple small packets and reduce per packet overhead. 202 4. GMA Encapsulation Format 204 +------------------------------------------------------+ 205 | IP hdr | IP payload | GMA Trailer | 206 +------------------------------------------------------+ 207 Figure 3: Trailer-based Encapsulation Format 209 Figure 3 shows the trailer-based encapsulation GMA PDU (protocol 210 data unit) format for the convergence sublayer. A (GMA) PDU may 211 carry one or multiple IP packets, aka (GMA) SDUs (service data 212 unit), in the payload, or a fragment of the SDU. 214 The Protocol Type field in the IP header of the GMA PDU MUST be 215 changed to 114 (Any 0-Hop Protocol) [IANA] to indicate the 216 presence of the GMA trailer. The following three IP header fields 217 SHOULD also be changed: 219 o IP Length: add the length of "GMA Trailer" to the length of 220 the original IP packet 221 o Time To Live (TTL) or Hop-Limit (HL): set the HL field to "0" 222 if the original IP packet is IPv6, and set the TTL field to "1" 223 if the original IP packet is IPv4. 224 o IP checksum: recalculate after changing "Protocol Type", "TTL 225 or HL" and "IP Length" 227 However, if UDP tunnelling is used at the adaptation sublayer to 228 carry the GMA PDU, the above three IP header fields MAY remain 229 unchanged, and the receiver will determine the GMA PDU length 230 based on the UDP packet length. 232 The GMA (Generic Multi-Access) trailer MUST consist of the 233 following two mandatory fields. The Flags field is at the end of 234 the PDU, and the Next Header field is the second last. The 235 Receiver SHOULD first decode the Flags field to determine the 236 length of the GMA trailer, and then decode each optional field 237 accordingly. 239 o Next Header (1 Byte): the IP protocol type of the (first) SDU 240 in a PDU 241 o Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and 242 Bit 15 is the least significant bit (LSB). 243 + Checksum Present (bit 0): If the Checksum Present bit is set 244 to 1, then the Checksum field is present and contains valid 245 information. 246 + Concatenation Present (bit 1): If the Concatenation Present 247 bit is set to 1, then the PDU carries multiple SDUs, and the 248 First SDU Length field is present and contains valid 249 information. 250 + Connection ID Present (bit 2): If the Connection ID Present 251 bit is set to 1, then the Connection ID field is present and 252 contains valid information. 253 + Flow ID Present (bit 3): If the Flow ID Present bit is set 254 to 1, then the Flow ID field is present and contains valid 255 information. 256 + Fragmentation Present (bit 4): If the Fragmentation Present 257 bit is set to 1, then the PDU carry a fragment of the SDU and 258 the Fragmentation Control field is present and contains valid 259 information. 260 + Delivery SN Present (bit 5): If the Delivery SN (Sequence 261 Number) Present bit is set to 1, then the Delivery SN field is 262 present and contains the valid information. 263 + Flow SN Present (bit 6): If the Flow SN Present bit is set 264 to 1, then the Sequence Number field is present and contains 265 valid information. 266 + Timestamp Present (bit 7): If the Timestamp Present bit is 267 set to 1, then the Timestamp field is present and contains 268 valid information. 269 + TTL Present (bit 8): If the TTL Present bit is set to 1, 270 then the TTL field is present and contains the valid 271 information. 272 + Reserved (bit 9-12) 273 + Version (bit 13~15): GMA version number, this is set to 0. 275 The GMA (Generic Multi-Access) trailer MAY consist of the 276 following optional fields: 278 o Checksum (1 Byte): to contain the (one's complement) checksum 279 sum of all the 8 bits in the trailer. For purposes of 280 computing the checksum, the value of the checksum field is 281 zero. This field is present only if the Checksum Present bit 282 is set to one. 283 o First SDU Length (2 Bytes): the length of the first IP packet 284 in the PDU, only included if a PDU contains multiple IP 285 packets. 286 o Connection ID (1 Byte): an unsigned integer to identify the 287 anchor and delivery connection of the GMA PDU. 288 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 289 identify the anchor connection 290 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 291 identify the delivery connection 292 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 293 that a PDU belongs to, for example Data Radio Bearer (DRB) ID 294 [LWIPEP] for a cellular (e.g. LTE) connection. 295 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 296 information for re-assembly, only needed if a PDU carries 297 fragments. 298 o Delivery SN (1 Byte): an auto-incremented integer to indicate 299 the GMA PDU transmission order on a delivery connection. 300 Delivery SN is needed to measure packet loss of each delivery 301 connection and therefore generated per delivery connection per 302 flow. 303 o Flow SN (3 Bytes): an auto-incremented integer to indicate the 304 GMA SDU (IP packet) order of a flow. Flow SN is needed for 305 retransmission, reordering, and fragmentation. It SHALL be 306 generated per flow. 307 o Timestamp (4 Bytes): to contain the current value of the 308 timestamp clock of the transmitter in the unit of 1 309 millisecond. 310 o TTL (1 Byte): to contain the TTL value of the original IP 311 header if the GMA SDU is IPv4, or the Hop-Limit value of the 312 IP header if the GMA SDU is IPv6. 314 Figure 4 shows the GMA trailer format with all the fields present. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | TTL | Timestamp 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Flow SN | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Delivery SN | FC | Flow ID | Connection ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | First SDU Length (FSL) | Checksum | Next Header | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Flags | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 4: GMA Trailer Format 332 +-----------------------------------------------------+ 333 |GMA Header | IP hdr | IP payload | 334 +-----------------------------------------------------+ 335 Figure 5: Header-based Non-IP Encapsulation Format 337 The trailer-based GMA PDU format SHOULD be used as long as 338 implementation allows. However, if the GMA control fields can't be 339 added at the end due to any reason, e.g. implementation 340 constraints, one may use the header-based encapsulation (Figure 5) 341 with the GMA header format (Figure 6). "Flags" is moved to the 342 front. Moreover, "TTL", "FSL", and "Next Header" are removed from 343 the GMA control fields since the IP header fields of the GMA SDU 344 remain unchanged during encapsulation. 346 +--------------------------------------------------+ 347 | Flags | GMA control fields | 348 +--------------------------------------------------+ 349 Figure 6: GMA Header Format 351 If the adaptation sublayer, e.g. UDP tunnelling, supports non-IP 352 packet format, the GMA PDU format as shown in Figure 5 may be used 353 without any modification. Otherwise, the GMA PDU format SHOULD be 354 modified as shown in Figure 7. The IP header of the GMA SDU is 355 moved to the front so that the GMA PDU becomes an IP packet. The 356 IP header fields SHOULD be changed in the same way as the 357 Trailered-based encapsulation (Figure 3) and the GMA control 358 fields may carry "Next Header", "TTL", and "FSL". 360 +-----------------------------------------------------+ 361 |IP hdr | GMA Header | IP payload | 362 +-----------------------------------------------------+ 363 Figure 7: Header-based IP Encapsulation Format 365 The GMA endpoints MAY choose the GMA PDU format (header or 366 trailer) through control signalling or pre-configuration. 368 5. Fragmentation 370 The convergence sublayer MAY support fragmentation if a delivery 371 connection has a smaller maximum transmission unit (MTU) than the 372 original IP packet (SDU). The fragmentation procedure at the 373 convergence sublayer is similar to IP fragmentation [RFC791] in 374 principle, but with the following two differences for less 375 overhead: 377 o The fragment offset field is expressed in number of fragments 378 o The maximum number of fragments per SDU is 2^7 (=128) 380 The Fragmentation Control (FC) field in the GMA trailer (or 381 header) contains the following bits: 383 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 384 is the last one (0) or not (1) 385 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 386 the offset of a particular fragment relative to the beginning 387 of the SDU 389 A PDU carries a whole SDU without fragmentation if the FC field is 390 set to all "0"s or the FC field is not present in the trailer. 391 Otherwise, the PDU contains a fragment of the SDU. 393 The Flow SN field in the trailer is used to distinguish the 394 fragments of one SDU from those of another. The Fragment Offset 395 (FO) field tells the receiver the position of a fragment in the 396 original SDU. The More Fragment (MF) flag indicates the last 397 fragment. 399 To fragment a long SDU, the transmitter creates two PDUs and 400 copies the content of the IP header fields from the long PDU into 401 the IP header of both PDUs. The length field in the IP header of 402 PDU SHOULD be changed to the length of the PDU, and the protocol 403 type SHOULD be changed to 114. 405 The data of the long SDU is divided into two portions based on the 406 MTU size of the delivery connection. The first portion of the data 407 is placed in the first PDU. The MF flag is set to "1", and the FO 408 field is set to "0". The second portion of the data is placed in 409 the second PDU. The MF flag is set to "0", and the FO field is set 410 to "1". This procedure can be generalized for an n-way split, 411 rather than the two-way split described the above. 413 To assemble the fragments of a SDU, the receiver combines PDUs 414 that all have the same Flow SN. The combination is done by placing 415 the data portion of each fragment in the relative order indicated 416 by the Fragment Offset in that fragment's trailer. The first 417 fragment will have the Fragment Offset set to "0", and the last 418 fragment will have the More-Fragments flag reset to "0". 420 6. Concatenation 422 The convergence sublayer MAY support concatenation if a delivery 423 connection has a larger maximum transmission unit (MTU) than the 424 original IP packet (SDU). Only the SDUs with the same client IP 425 address, and the same Flow ID MAY be concatenated. 427 The First SDU Length (FSL) field SHOULD be included in the trailer 428 to indicate the length of the first SDU. 430 +-----------------------------------------------------------+ 431 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 432 +-----------------------------------------------------------+ 433 Figure 8: GMA PDU Format with Concatenation 435 To concatenate two or more SDUs, the transmitter creates one PDU 436 and copies the content of the IP header field from the first SDU 437 into the IP header of the PDU. The data of the first SDU is placed 438 in the first portion of the data of the PDU. The whole second SDU 439 is then placed in the second portion of the data of the PDU 440 (Figure 8). The procedure continues till the PDU size reaches the 441 MTU of the delivery connection. If the FSL field is present in the 442 trailer, the IP length field of the PDU SHOULD be updated to 443 include all concatenated SDUs and the trailer, and the IP checksum 444 field SHOULD be recalculated. However, if UDP tunnelling is used 445 at the adaptation sublayer to carry the GMA PDU, both the IP 446 Length field and the checksum field of the PDU MAY remain 447 unchanged, and the receiver will determine the GMA PDU length 448 based on the UDP packet length. 450 To disaggregate a PDU, the receiver first obtains the length of 451 the first SDU from the FSL field in the trailer and decodes the 452 first SDU. If the FSL field or the trailer is not present, the 453 receiver obtains the length of the first SDU directly from the IP 454 length field of the PDU. The receiver then obtains the length of 455 the second SDU based on the length field in the second SDU IP 456 header and decodes the second SDU. The procedure continues till no 457 byte is left in the PDU. However, if the header-based Non-IP GMA 458 PDU format (Figure 5) is used, the IP header of the first SDU will 459 not change during the encapsulation process, and therefore the FSL 460 field is not used. 462 If a PDU contains multiple SDUs, the Flow SN field is for the last 463 SDU, and the Flow SN of other SDU carried by the same PDU can be 464 obtained according to its order in the PDU. For example, if the SN 465 field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, 466 and 6 for the first, second, and last SDU respectively. 468 7. Security Considerations 470 Security in a network using GMA should be relatively similar to 471 security in a normal IP network. The GMA protocol at the 472 convergence sublayer is a 0-hop protocol and relies on the 473 security of the underlying network transport paths. When this 474 cannot be assumed, appropriate security protocols (IPsec, DTLS, 475 etc.) SHOULD be configured at the adaptation sublayer. On the 476 other hand, packet filtering requires either that a firewall looks 477 inside the GMA packet or that the filtering is done on the GMA 478 endpoints. In those environments in which this is considered to be 479 a security issue it may be desirable to terminate the GMA 480 operation at the firewall. 482 Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on 483 preventing the leak of the local-only GMA PDUs outside the "local 484 domain" to the Internet or to another domain which could use the 485 same IP protocol type, i.e. 114. 487 8. IANA Considerations 489 This draft makes no requests of IANA 491 9. References 493 9.1. Normative References 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, DOI 497 10.17487/RFC2119, March 1997, . 500 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 501 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 502 May 2017, . 504 9.2. Informative References 506 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 507 Management Services 508 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 510 [IANA] https://www.iana.org/assignments/protocol- 511 numbers/protocol-numbers.xhtml 513 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 514 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 515 Ipsec Tunnel (LWIP) encapsulation; Protocol 516 specification" 518 [RFC791] Internet Protocol, September 1981 520 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 521 and splitting support in the 5G system architecture. 523 [GRE] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 525 Authors' Addresses 527 Jing Zhu 529 Intel 531 Email: jing.z.zhu@intel.com 533 Satish Kanugovi 535 Nokia 537 Email: satish.k@nokia.com