idnits 2.17.1 draft-zhu-intarea-gma-03.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 -- The document date (June 4, 2019) is 1781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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: December 4,2019 Nokia 5 June 4, 2019 7 Generic Multi-Access (GMA) Convergence Encapsulation Protocols 8 draft-zhu-intarea-gma-03 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 December 4, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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, but is not an Internet Standard and does not represent 60 the 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 Trailer Format ........................................... 5 69 5. Fragmentation ................................................ 7 70 6. Concatenation ................................................ 9 71 7. Security Considerations ..................................... 10 72 8. IANA Considerations ......................................... 10 73 9. References .................................................. 10 74 9.1. Normative References ..................................10 75 9.2. Informative References ................................10 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 +-----------------------------------------------------+ 85 | IP PDU | 87 |-----------------------------------------------------| 89 +--|-----------------------------------------------------|--+ 91 | |-----------------------------------------------------| | 93 | | Convergence Sublayer | | 95 | |-----------------------------------------------------| | 96 | |-----------------------------------------------------| | 98 | | Adaptation | Adaptation | Adaptation | | 100 | | Sublayer | Sublayer | Sublayer | | 102 | | (optional) | (optional) | (optional) | | 104 | |-----------------------------------------------------| | 106 | | Access #1 IP | Access #2 IP | Access #3 IP | | 108 | +-----------------------------------------------------+ | 110 +-----------------------------------------------------------+ 112 Figure 1: GMA User-Plane Protocol Stack 114 It consists of the following two Sublayers: 116 o Convergence sublayer: This layer performs multi-access 117 specific tasks, e.g., multi-link (path) aggregation, 118 splitting/reordering, lossless switching/retransmission, 119 fragmentation, concatenation, etc. 120 o Adaptation sublayer: This layer performs functions to handle 121 tunnelling, network layer security, and NAT (network address 122 translation). 124 The convergence sublayer operates on top of the adaptation 125 sublayer in the protocol stack. From the Transmitter perspective, 126 a User Payload (e.g. IP packet) is processed by the convergence 127 sublayer first, and then by the adaptation sublayer before being 128 transported over a delivery connection; from the Receiver 129 perspective, an IP packet received over a delivery connection is 130 processed by the adaptation sublayer first, and then by the 131 convergence sublayer. 133 IP-over-IP tunneling has been used in today's multi-access 134 solutions, e.g. [LWIPEP] [GRE], to insert the GRE header, and then 135 encode additional control information in the GRE header fields, 136 e.g. Key, Sequence Number. However, there are two main drawbacks 137 with this approach: 1) IP-over-IP tunneling leads to higher 138 overhead especially for small packet. For example, the overhead of 139 IP-over-IP/GRE tunneling with both Key and Sequence Number is 32 140 Bytes, which is 80% of a 40 Bytes TCP ACK packet; 2) It is 141 difficult to introduce new control fields with the GRE header 142 format. 144 This document presents a light-weight GMA encapsulation protocol 145 for the convergence sublayer. It avoids IP-over-IP tunneling to 146 minimize overhead, and introduces new control fields to support 147 fragmentation and concatenation at the convergence sublayer, which 148 are not available in today's GRE-based solutions [LWIPEP] [GRE]. 150 GMA protocol SHALL only operate between endpoints that have been 151 configured to operate with GMA through additional control messages 152 and procedures, for example [MAMS]. 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 157 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 158 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 159 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, 160 and only when, they appear in all capitals, as shown here. 162 3. Use Case 164 Multi-Access Aggregation 166 +-+*+-+ +-+*+-+ 168 | |*|A+-- LTE Connection -----+C|*| | 170 |U|*+-+ +-+*|S| Internet 172 | |*+-+ +-+*| | 174 | |*|B+-- Wi-Fi Connection ---+D|*| | 176 |+|*+-+ +-+*|+| 178 Client Multi-Access Gateway 180 A: The adaptation sublayer endpoint of the LTE connection 181 resides in the client 183 B: The adaptation sublayer endpoint of the Wi-Fi connection 184 resides in the client 186 C: The adaptation sublayer endpoint of the LTE connection 187 resides in the Multi-Access Gateway, aka N-MADP (Network 188 Multi-Access Data Proxy) in [MAMS] 190 D: The adaptation sublayer endpoint of the Wi-Fi connection 191 resides in the Multi-Access Gateway 192 U: The convergence sublayer endpoint resides in the client 194 S: The convergence sublayer endpoint resides in the Multi- 195 Access Gateway 197 Figure 2: GMA-based Multi-Access Aggregation 199 As shown in Figure 2, a client device (e.g. Smartphone, Laptop, 200 etc.) may connect to Internet via both Wi-Fi and LTE connections, 201 one of which (e.g. LTE) may operate as the anchor connection, and 202 the other (e.g. Wi-Fi) may operate as the delivery connection. The 203 anchor connection provides the IP address and connectivity for 204 end-to-end Internet access, and the delivery connection provides 205 additional path between client and Multi-Access Gateway for multi- 206 access optimizations. 208 For example, per-packet aggregation allows a single IP flow to use 209 the combined bandwidth of the two connections. In another example, 210 packets lost over one connection due to temporarily link loss may 211 be retransmitted over the other connection. Such multi-access 212 optimization requires additional control information, e.g. 213 Sequence Number, in each IP data packet, which can be supported by 214 the GMA encapsulation protocol described in this document. 216 4. GMA Trailer Format 218 +------------------------------------------------------+ 219 | IP hdr | IP payload | GMA Trailer | 220 +------------------------------------------------------+ 221 Figure 3: Trailer-based Encapsulation PDU Format 223 Figure 3 shows the trailer-based encapsulation GMA PDU (protocol 224 data unit) format for the convergence sublayer. A (GMA) PDU may 225 carry one or multiple IP packets, aka (GMA) SDUs (service data 226 unit), in the payload, or a fragment of the SDU. 228 The Protocol Type field in the IP header of the GMA PDU MUST be 229 changed to 114 (Any 0-Hop Protocol) [IANA] to indicate the 230 presence of the GMA trailer. The following two IP header fields 231 SHOULD also be changed: 233 o IP Length: add the length of "GMA Trailer" to the length of 234 the original IP packet 235 o IP checksum: recalculate after changing "Protocol Type" and 236 "IP Length" 238 However, if UDP tunneling is used at the adaptation sublayer to 239 carry the GMA PDU, both the IP Length field and the checksum field 240 MAY remain unchanged, and the receiver will determine the GMA PDU 241 length based on the UDP packet length. 243 The GMA (Generic Multi-Access) trailer MUST consist of the 244 following two mandatory fields. The Next Header field is always 245 the last octet at the end of the PDU, and the Flags field is the 246 second last. The Receiver SHOULD first decode the Flags field to 247 determine the length of the GMA trailer, and then decode each 248 optional field accordingly. 250 o Next Header (1 Byte): the IP protocol type of the (first) SDU 251 in a PDU 252 o Flags (1 Byte): Bit 0 is the least significant bit (LSB), and 253 Bit 7 is the most significant bit (MSB). 254 + Checksum Present (bit 0): If the Checksum Present bit is set 255 to 1, then the Checksum field is present and contains valid 256 information. 257 + Concatenation Present (bit 1): If the Concatenation Present 258 bit is set to 1, then the PDU carries multiple SDUs, and the 259 First SDU Length field is present and contains valid 260 information. 261 + Connection ID Present (bit 2): If the Connection ID Present 262 bit is set to 1, then the Connection ID field is present and 263 contains valid information. 264 + Flow ID Present (bit 3): If the Flow ID Present bit is set 265 to 1, then the Flow ID field is present and contains valid 266 information. 267 + Fragmentation Present (bit 4): If the Fragmentation Present 268 bit is set to 1, then the PDU carry a fragment of the SDU and 269 the Fragmentation Control field is present and contains valid 270 information. 271 + Sequence Number Present (bit 5): If the Sequence Number 272 Present bit is set to 1, then the Sequence Number field is 273 present and contains valid information. 274 + Timestamp Present (bit 6): If the Timestamp Present bit is 275 set to 1, then the Timestamp field is present and contains 276 valid information. 277 + Bit 7: reserved 279 The GMA (Generic Multi-Access) trailer MAY consist of the 280 following optional fields: 282 o Checksum (1 Byte): to contain the (one's complement) checksum 283 sum of all the 8 bit in the trailer. For purposes of computing 284 the checksum, the value of the checksum field is zero. This 285 field is present only if the Checksum Present bit is set to 286 one. 287 o First SDU Length (2 Bytes): the length of the first IP packet 288 in the PDU, only included if a PDU contains multiple IP 289 packets. 290 o Connection ID (1 Byte): an unsigned integer to identify the 291 anchor and delivery connection of the GMA PDU. 292 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 293 identify the anchor connection 294 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 295 identify the delivery connection 296 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 297 that a PDU belongs to, for example Data Radio Bearer (DRB) ID 298 [LWIPEP] for a cellular (e.g. LTE) connection. 299 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 300 information for re-assembly, only needed if a PDU carries 301 fragments. 302 o Sequence Number (3 Bytes): an auto-incremented integer to 303 indicate order of transmission of the SDU (e.g. IP packet), 304 needed for lossless switching or multi-link (path) aggregation 305 or fragmentation. Sequence Number SHALL be generated per flow. 306 o Timestamp (4 Bytes): to contain the current value of the 307 timestamp clock of the transmitter in the unit of 308 milliseconds. 310 Figure 4 shows the GMA trailer format with all the fields present. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Timestamp | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sequence Number | FC | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Flow ID | Connection ID | First SDU Length | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Checksum | Flags | Next Header | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 4: GMA Trailer Format 325 5. Fragmentation 327 The convergence sublayer MAY support fragmentation if a delivery 328 connection has a smaller maximum transmission unit (MTU) than the 329 original IP packet (SDU). The fragmentation procedure at the 330 convergence sublayer is similar to IP fragmentation [RFC791] in 331 principle, but with the following two differences for less 332 overhead: 334 o The fragment offset field is expressed in number of fragments 335 not 8-bytes blocks 336 o The maximum number of fragments per SDU is 2^7 (=128) 338 The Fragmentation Control (FC) field in the trailer contains the 339 following bits: 341 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 342 is the last one (0) or not (1) 343 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 344 the offset of a particular fragment relative to the beginning 345 of the SDU 347 A PDU carries a whole SDU without fragmentation if the FC field is 348 set to all "0"s or the FC field is not present in the trailer. 349 Otherwise, the PDU contains a fragment of the SDU. 351 The Sequence Number (SN) field in the trailer is used to 352 distinguish the fragments of one SDU from those of another. The 353 Fragment Offset (FO) field tells the receiver the position of a 354 fragment in the original SDU. The More Fragment (MF) flag 355 indicates the last fragment. 357 To fragment a long SDU, the transmitter creates two PDUs and 358 copies the content of the IP header fields from the long PDU into 359 the IP header of both PDUs. The length field in the IP header of 360 PDU SHOULD be changed to the length of the PDU, and the protocol 361 type SHOULD be changed to 114. 363 The data of the long SDU is divided into two portions based on the 364 MTU size of the delivery connection. The first portion of the data 365 is placed in the first PDU. The MF flag is set to "1", and the FO 366 field is set to "0". The second portion of the data is placed in 367 the second PDU. The MF flag is set to "0", and the FO field is set 368 to "1". This procedure can be generalized for an n-way split, 369 rather than the two-way split described the above. 371 To assemble the fragments of a SDU, the receiver combines PDUs that 372 all have the same Sequence Number (in the trailer). The combination 373 is done by placing the data portion of each fragment in the relative 374 order indicated by the Fragment Offset in that fragment's trailer. 375 The first fragment will have the Fragment Offset set to "0", and the 376 last fragment will have the More-Fragments flag reset to "0". 378 6. Concatenation 380 The convergence sublayer MAY support concatenation if a delivery 381 connection has a larger maximum transmission unit (MTU) than the 382 original IP packet (SDU). Only the SDUs with the same client IP 383 address, and the same Flow ID MAY be concatenated. 385 The First SDU Length (FSL) field SHOULD be included in the trailer 386 to indicate the length of the first SDU. 388 +-----------------------------------------------------------+ 389 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 390 +-----------------------------------------------------------+ 391 Figure 5: GMA PDU Format with Concatenation 393 To concatenate two or more SDUs, the transmitter creates one PDU 394 and copies the content of the IP header field from the first SDU 395 into the IP header of the PDU. The data of the first SDU is placed 396 in the first portion of the data of the PDU. The whole second SDU 397 is then placed in the second portion of the data of the PDU 398 (Figure 5). The procedure continues till the PDU size reaches the 399 MTU of the delivery connection. If the FSL field is present in the 400 trailer, the IP length field of the PDU SHOULD be updated to 401 include all concatenated SDUs and the trailer, and the IP checksum 402 field SHOULD be recalculated. However, if UDP tunneling is used at 403 the adaptation sublayer to carry the GMA PDU, both the IP Length 404 field and the checksum field of the PDU MAY remain unchanged, and 405 the receiver will determine the GMA PDU length based on the UDP 406 packet length. 408 To disaggregate a PDU, the receiver first obtains the length of 409 the first SDU from the FSL field in the trailer, and decodes the 410 first SDU. If the FSL field or the trailer is not present, the 411 receiver obtains the length of the first SDU directly from the IP 412 length field of the PDU. The receiver then obtains the length of 413 the second SDU based on the length field in the second SDU IP 414 header, and decodes the second SDU. The procedure continues till 415 no byte is left in the PDU. 417 If a PDU contains multiple SDUs, the SN field in the trailer is 418 for the last SDU, and the SN of other SDU carried by the same PDU 419 can be obtained according to its order in the PDU. For example, if 420 the SN field is 6 and a PDU contains 3 SDUs (IP packets), the SN 421 is 4, 5, and 6 for the first, second, and last SDU respectively. 423 7. Security Considerations 425 Security in a network using GMA should be relatively similar to 426 security in a normal IP network. The GMA protocol at the 427 convergence sublayer is a 0-hop protocol, and relies on the 428 security of the underlying network transport paths. When this 429 cannot be assumed, appropriate security protocols (IPsec, DTLS, 430 etc.) SHOULD be configured at the adaptation sublayer. On the 431 other hand, packet filtering requires either that a firewall looks 432 inside the GMA packet or that the filtering is done on the GMA 433 endpoints. In those environments in which this is considered to be 434 a security issue it may be desirable to terminate the GMA 435 operation at the firewall. 437 8. IANA Considerations 439 This draft makes no requests of IANA 441 9. References 443 9.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, DOI 447 10.17487/RFC2119, March 1997, . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 452 May 2017, . 454 9.2. Informative References 456 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, 457 "Multiple Access Management Protocol", 458 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 459 protocol-03 461 [IANA] https://www.iana.org/assignments/protocol- 462 numbers/protocol-numbers.xhtml 464 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 465 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 466 Ipsec Tunnel (LWIP) encapsulation; Protocol 467 specification" 469 [RFC791] Internet Protocol, September 1981 471 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 472 and splitting support in the 5G system architecture. 474 [GRE] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 476 Authors' Addresses 478 Jing Zhu 480 Intel 482 Email: jing.z.zhu@intel.com 484 Satish Kanugovi 486 Nokia 488 Email: satish.k@nokia.com