idnits 2.17.1 draft-zhu-intarea-gma-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([MAMS], [GRE], [ATSSS], [LWIPEP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2019) is 1908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IANA' is defined on line 362, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTAREA J. Zhu 2 Internet Draft Intel 3 Intended status: Standards Track S. Kanugovi 4 Expires: July 28,2019 Nokia 5 January 28, 2019 7 Generic Multi-Access (GMA) Convergence Encapsulation Protocols 8 draft-zhu-intarea-gma-01 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 documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on July 28, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 Today, a device can be simultaneously connected to multiple 51 communication networks based on different technology implementations 52 and network architectures like WiFi, LTE, 5G, and DSL. In such 53 scenario, it is desirable to combine multiple access networks to 54 improve quality of experience. For example, an IP flow may be 55 delivered over both LTE and Wi-Fi network for higher end-to-end 56 throughput. In another example, lost packets may be retransmitted 57 when the device switches from Wi-Fi to LTE. However, such multi- 58 access optimization requires inserting additional control 59 information, e.g. Sequence Number, into each IP packet. 61 Unfortunately, there is no existing IP protocol for such purpose. As 62 a result, IP-over-IP tunneling has been used in today's solutions, 63 e.g. [LWIPEP] [GRE], to insert the GRE header, and then encode 64 additional control information in the GRE header fields, e.g. Key, 65 Sequence Number. However, there are two main drawbacks with this 66 approach: 1) IP-over-IP tunneling leads to higher overhead 67 especially for small packet. For example, the overhead of IP-over- 68 IP/GRE tunneling with both Key and Sequence Number is 32 Bytes, 69 which is 80% of a 40 Bytes TCP ACK packet; 2) It is difficult to 70 introduce new control fields using the existing GRE header format. 72 This document presents a new light-weight and flexible encapsulation 73 protocol to support multi-access solutions [ATSSS] [MAMS] [LWIPEP] 74 without IP-over-IP tunneling. 76 Table of Contents 78 1. Introduction...................................................2 79 2. Conventions used in this document..............................3 80 3. GMA Trailer Format.............................................4 81 4. Fragmentation..................................................6 82 5. Concatenation..................................................7 83 6. Security Considerations........................................8 84 7. IANA Considerations............................................8 85 8. References.....................................................8 86 8.1. Normative References......................................8 87 8.2. Informative References....................................8 89 1. Introduction 91 Figure 1 shows the user-plane Generic Multi-Access (GMA) protocol 92 stack, which has been used in today's multi-access solutions [ATSSS] 93 [MAMS] [LWIPEP] [GRE]. 95 +-----------------------------------------------------+ 96 | IP PDU | 97 |-----------------------------------------------------| 98 +--|-----------------------------------------------------|--+ 99 | |-----------------------------------------------------| | 100 | | Convergence Sublayer | | 101 | |-----------------------------------------------------| | 102 | |-----------------------------------------------------| | 103 | | Adaptation | Adaptation | Adaptation | | 104 | | Sublayer | Sublayer | Sublayer | | 105 | | (optional) | (optional) | (optional) | | 106 | |-----------------------------------------------------| | 107 | | Access #1 IP | Access #2 IP | Access #3 IP | | 108 | +-----------------------------------------------------+ | 109 +-----------------------------------------------------------+ 110 Figure 1: GMA User-Plane Protocol Stack 112 It consists of the following two Sublayers: 114 o Convergence sublayer: This layer performs multi-access specific 115 tasks, e.g., multi-link (path) aggregation, splitting/reordering, 116 lossless switching/retransmission, fragmentation, concatenation, etc. 117 o Adaptation sublayer: This layer performs functions to handle 118 tunneling, network layer security, and NAT. 120 The convergence sublayer operates on top of the adaptation sublayer in 121 the protocol stack. From the Transmitter perspective, a User Payload 122 (e.g. IP PDU) is processed by the convergence sublayer first, and then 123 by the adaptation sublayer before being transported over a delivery 124 connection; from the Receiver perspective, an IP packet received over a 125 delivery connection is processed by the adaptation sublayer first, and 126 then by the convergence sublayer. 128 This document presents a light-weight encapsulation protocol for the 129 convergence sublayer. It avoids IP-over-IP tunneling to minimize the 130 overhead, and introduces new control fields to support fragmentation 131 and concatenation at the convergence sublayer, which are not available 132 in today's GRE-based solutions [LWIPEP] [GRE]. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. GMA Trailer Format 142 +------------------------------------------------------+ 143 | IP hdr | IP payload | GMA Trailer | 144 +------------------------------------------------------+ 145 Figure 2: Trailer-based Encapsulation PDU Format 147 Figure 2 shows the trailer-based encapsulation GMA PDU (protocol data 148 unit) format for the convergence sublayer. A (GMA) PDU MAY carry one or 149 multiple IP packets, aka (GMA) SDUs (service data unit), in the 150 payload, or a fragment of the SDU. 152 The GMA (Generic Multi-Access) trailer SHOULD consist of the following 153 two mandatory fields: 155 o Next Header (1 Byte): the IP protocol type of the (first) SDU in a 156 PDU 157 o Flags (1 Byte): Bit 0 is the least significant bit (LSB), and Bit 7 158 is the most significant bit (MSB). 159 + Concatenation Present (bit 0): If the Concatenation Present bit 160 is set to 1, then the PDU carries multiple SDUs, and the First 161 SDU Length field is present and contains valid information. 162 + Fragmentation Present (bit 1): If the Fragmentation Present bit 163 is set to 1, then the PDU carry a fragment of the SDU and the 164 Fragmentation Control field is present and contains valid 165 information. 166 + Flow ID Present (bit 2): If the Flow ID Present bit is set to 1, 167 then the Flow ID field is present and contains valid 168 information. 169 + Checksum Present (bit 3): If the Checksum Present bit is set to 170 1, then the Checksum field is present and contains valid 171 information. 172 + Sequence Number Present (bit 4): If the Sequence Number Present 173 bit is set to 1, then the Sequence Number field is present and 174 contains valid information. 175 + Timestamp Present (bit 5): If the Timestamp Present bit is set 176 to 1, then the Timestamp field is present and contains valid 177 information. 178 + Bit 6-7: reserved 180 The GMA (Generic Multi-Access) trailer MAY consist of the following 181 optional fields: 183 o First SDU Length (2 Bytes): the length of the first IP packet in the 184 PDU, only included if a PDU contains multiple IP packets. 185 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 186 information for re-assembly, only needed if a PDU carries fragments. 188 o Flow ID (1 Byte): an unsigned integer to identify the IP flow that a 189 PDU belongs to. It is composted of the following two sub-fields: 190 + Connection ID (MSB 4 Bits): an unsigned integer to identify the 191 connection of the IP flow 192 + Traffic Class ID (LSB 4 Bits): an unsigned integer to identify 193 the traffic class of the IP flow, for example Data Radio Bearer 194 (DRB) ID [LWIPEP] for a cellular (e.g. LTE) connection 195 o Checksum (1 Byte): to contain the (one's complement) checksum sum of 196 all the 8 bit in the trailer. For purposes of computing the checksum, 197 the value of the checksum field is zero. This field is present only 198 if the Checksum Present bit is set to one. 199 o Sequence Number (3 Bytes): an auto-incremented integer to indicate 200 order of transmission of the SDU (e.g. IP packet), needed for 201 lossless switching or multi-link (path) aggregation or fragmentation. 202 Sequence Number SHALL be generated per flow. 203 o Timestamp (4 Bytes): to contain the current value of the timestamp 204 clock of the transmitter in the unit of milliseconds. 206 Figure 3 shows the GMA trailer format with all the fields present. The 207 Next Header field is always the last octet at the end of the PDU, and 208 the Flags field is the second last. The Receiver SHOULD first decode 209 the Flags field to determine the length of the trailer, and then decode 210 each field accordingly. 212 0 1 2 3 214 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Timestamp | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Sequence Number | Checksum | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Flow ID | FC | First SDU Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Flags | Next Header | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 3: GMA Trailer Format 236 Moreover, the Protocol Type field in the IP header of the PDU SHOULD be 237 changed to "xyz" to indicate the presence of GMA trailer. The following 238 two IP header fields MAY also be changed: 240 o IP Length: add the length of "GMA Trailer" to the length of the 241 original IP packet 242 o IP checksum: recalculate after changing "Protocol Type" and "IP 243 Length" 245 4. Fragmentation 247 The convergence sublayer MAY support fragmentation if a delivery 248 connection has a smaller maximum transmission unit (MTU) than the 249 original IP packet (SDU). The fragmentation procedure at the 250 convergence sublayer is similar to IP fragmentation [RFC791] in 251 principle, but with the following two differences for less overhead: 253 o The fragment offset field is expressed in number of fragments not 8- 254 bytes blocks 255 o The maximum number of fragments per SDU is 2^7 (=128) 257 The Fragmentation Control (FC) field in the trailer contains the 258 following bits: 260 o Bit #7: a More Fragment (MF) flag to indicate if the fragment is the 261 last one (0) or not (1) 262 o Bit #0~#6: Fragment Offset (in units of fragments) to specify the 263 offset of a particular fragment relative to the beginning of the SDU 265 A PDU carries a whole SDU without fragmentation if the FC field is set 266 to all "0"s or the FC field is not present in the trailer. Otherwise, 267 the PDU contains a fragment of the SDU. 269 The Sequence Number (SN) field in the trailer is used to distinguish 270 the fragments of one SDU from those of another. The Fragment Offset 271 (FO) field tells the receiver the position of a fragment in the 272 original SDU. The More Fragment (MF) flag indicates the last fragment. 274 To fragment a long SDU, the transmitter creates two PDUs and copies the 275 content of the IP header fields from the long PDU into the IP header of 276 both PDUs. The length field in the IP header of PDU SHOULD be changed 277 to the length of the PDU, and the protocol type SHOULD be changed to 278 "xyz". 280 The data of the long SDU is divided into two portions based on the MTU 281 size of the delivery connection. The first portion of the data is 282 placed in the first PDU. The MF flag is set to "1", and the FO field is 283 set to "0". The second portion of the data is placed in the second PDU. 285 The MF flag is set to "0", and the FO field is set to "1". This 286 procedure can be generalized for an n-way split, rather than the two- 287 way split described the above. 289 To assemble the fragments of a SDU, the receiver combines PDUs that all 290 have the same Sequence Number (in the trailer). The combination is done 291 by placing the data portion of each fragment in the relative order 292 indicated by the Fragment Offset in that fragment's trailer. The first 293 fragment will have the Fragment Offset set to "0", and the last fragment 294 will have the More-Fragments flag reset to "0". 296 5. Concatenation 298 The convergence sublayer MAY support concatenation if a delivery 299 connection has a larger maximum transmission unit (MTU) than the 300 original IP packet (SDU). Only the SDUs with the same client IP 301 address, and the same Flow ID MAY be concatenated. 303 The First SDU Length (FSL) field SHOULD be included in the trailer to 304 indicate the length of the first SDU. 306 To concatenate two or more SDUs, the transmitter creates one PDU and 307 copies the content of the IP header field from the first SDU into the 308 IP header of the PDU. The data of the first SDU is placed in the first 309 portion of the data of the PDU. The whole second SDU is then placed in 310 the second portion of the data of the PDU (Figure 4). The procedure 311 continues till the PDU size reaches the MTU of the delivery connection. 312 If the FSL field is present in the trailer, the IP length field of the 313 PDU SHOULD be updated to include all concatenated SDUs and the trailer, 314 and the IP checksum field SHOULD be recalculated. 316 To disaggregate a PDU, the receiver first obtains the length of the 317 first SDU from the FSL field in the trailer, and decodes the first SDU. 318 If the FSL field or the trailer is not present, the receiver obtains 319 the length of the first SDU directly from the IP length field of the 320 PDU. The receiver then obtains the length of the second SDU based on 321 the length field in the second SDU IP header, and decodes the second 322 SDU. The procedure continues till no byte is left in the PDU. 324 If a PDU contains multiple SDUs, the SN field in the trailer is for the 325 last SDU, and the SN of other SDU carried by the same PDU can be 326 obtained according to its order in the PDU. For example, if the SN 327 field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, and 328 6 for the first, second, and last SDU respectively. 330 +------------------------------------------------------------+ 331 | IP hdr | IP payload | IP hdr | IP payload | GMA Trailer | 332 +------------------------------------------------------------+ 333 Figure 4: GMA PDU Format with Concatenation 335 6. Security Considerations 337 The convergence sublayer relies on the security of the underlying 338 network transport paths. When this cannot be assumed, appropriate 339 security protocols (IPsec, DTLS, etc.) SHOULD be configured at the 340 adaptation sublayer. 342 7. IANA Considerations 344 The trailer based encapsulation protocol in this document requires the 345 allocation of a new value in the "IP Protocol Type" field within the IP 346 header (e.g. xyz GMA Generic-Multi-Access-convergence-encapsulation). 348 8. References 350 8.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 8.2. Informative References 357 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 358 Access Management Protocol", 359 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 360 protocol-03 362 [IANA] https://www.iana.org/assignments/protocol- 363 numbers/protocol-numbers.xhtml 365 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 366 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 367 Tunnel (LWIP) encapsulation; Protocol specification" 369 [RFC791] Internet Protocol, September 1981 371 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch and 372 splitting support in the 5G system architecture. 374 [GRE] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 376 Authors' Addresses 378 Jing Zhu 380 Intel 382 Email: jing.z.zhu@intel.com 384 Satish Kanugovi 386 Nokia 388 Email: satish.k@nokia.com