idnits 2.17.1 draft-zhu-intarea-gma-04.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 (September 30, 2019) is 1669 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: March 30,2020 Nokia 5 September 30, 2019 7 Generic Multi-Access (GMA) Convergence Encapsulation Protocols 8 draft-zhu-intarea-gma-04 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 March 30, 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 ............................ 3 67 3. Use Case ..................................................... 4 68 4. GMA Trailer Format ........................................... 5 69 5. Fragmentation ................................................ 7 70 6. Concatenation ................................................ 8 71 7. GMA Header Format ............................................ 9 72 8. Security Considerations ..................................... 11 73 9. IANA Considerations ......................................... 11 74 10. References ................................................. 12 75 10.1. Normative References .................................12 76 10.2. Informative References ...............................12 78 1. Introduction 80 Figure 1 shows the user-plane Generic Multi-Access (GMA) protocol 81 stack, which has been used in today's multi-access solutions 82 [ATSSS] [MAMS] [LWIPEP] [GRE]. 84 +-----------------------------------------------------+ 85 | IP PDU | 86 |-----------------------------------------------------| 87 | Convergence Sublayer | 88 |-----------------------------------------------------| 89 | Adaptation | Adaptation | Adaptation | 90 | Sublayer | Sublayer | Sublayer | 91 | (optional) | (optional) | (optional) | 92 |-----------------------------------------------------| 93 | Access #1 IP | Access #2 IP | Access #3 IP | 94 +-----------------------------------------------------+ 95 Figure 1: GMA User-Plane Protocol Stack 97 It consists of the following two Sublayers: 99 o Convergence sublayer: This layer performs multi-access 100 specific tasks, e.g., multi-link (path) aggregation, 101 splitting/reordering, lossless switching/retransmission, 102 fragmentation, concatenation, etc. 103 o Adaptation sublayer: This layer performs functions to handle 104 tunnelling, network layer security, and NAT (network address 105 translation). 107 The convergence sublayer operates on top of the adaptation 108 sublayer in the protocol stack. From the Transmitter perspective, 109 a User Payload (e.g. IP packet) is processed by the convergence 110 sublayer first, and then by the adaptation sublayer before being 111 transported over a delivery connection; from the Receiver 112 perspective, an IP packet received over a delivery connection is 113 processed by the adaptation sublayer first, and then by the 114 convergence sublayer. 116 IP-over-IP tunneling has been used in today's multi-access 117 solutions, e.g. [LWIPEP] [GRE], to insert the GRE header, and then 118 encode additional control information in the GRE header fields, 119 e.g. Key, Sequence Number. However, there are two main drawbacks 120 with this approach: 1) IP-over-IP tunneling leads to higher 121 overhead especially for small packet. For example, the overhead of 122 IP-over-IP/GRE tunneling with both Key and Sequence Number is 32 123 Bytes, which is 80% of a 40 Bytes TCP ACK packet; 2) It is 124 difficult to introduce new control fields with the GRE header 125 format. 127 This document presents a light-weight GMA encapsulation protocol 128 for the convergence sublayer. It avoids IP-over-IP tunneling to 129 minimize overhead, and introduces new control fields to support 130 fragmentation and concatenation at the convergence sublayer, which 131 are not available in today's GRE-based solutions [LWIPEP] [GRE]. 133 GMA protocol SHALL only operate between endpoints that have been 134 configured to operate with GMA through additional control messages 135 and procedures, for example [MAMS]. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 140 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 141 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 142 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, 143 and only when, they appear in all capitals, as shown here. 145 3. Use Case 147 Multi-Access Aggregation 149 +---+ +---+ 150 | |A|--- LTE Connection -----|C| | 151 |U|-| |-|S| Internet 152 | |B|--- Wi-Fi Connection ---|D| | 153 +---+ +---+ 154 Client Multi-Access Gateway 156 A: The adaptation sublayer endpoint of the LTE connection 157 resides in the client 159 B: The adaptation sublayer endpoint of the Wi-Fi connection 160 resides in the client 162 C: The adaptation sublayer endpoint of the LTE connection 163 resides in the Multi-Access Gateway, aka N-MADP (Network 164 Multi-Access Data Proxy) in [MAMS] 166 D: The adaptation sublayer endpoint of the Wi-Fi connection 167 resides in the Multi-Access Gateway 169 U: The convergence sublayer endpoint resides in the client 171 S: The convergence sublayer endpoint resides in the Multi- 172 Access Gateway 174 Figure 2: GMA-based Multi-Access Aggregation 176 As shown in Figure 2, a client device (e.g. Smartphone, Laptop, 177 etc.) may connect to Internet via both Wi-Fi and LTE connections, 178 one of which (e.g. LTE) may operate as the anchor connection, and 179 the other (e.g. Wi-Fi) may operate as the delivery connection. The 180 anchor connection provides the IP address and connectivity for 181 end-to-end Internet access, and the delivery connection provides 182 additional path between client and Multi-Access Gateway for multi- 183 access optimizations. 185 For example, per-packet aggregation allows a single IP flow to use 186 the combined bandwidth of the two connections. In another example, 187 packets lost over one connection due to temporarily link loss may 188 be retransmitted over the other connection. Such multi-access 189 optimization requires additional control information, e.g. 190 Sequence Number, in each IP data packet, which can be supported by 191 the GMA encapsulation protocol described in this document. 193 4. GMA Trailer Format 195 +------------------------------------------------------+ 196 | IP hdr | IP payload | GMA Trailer | 197 +------------------------------------------------------+ 198 Figure 3: Trailer-based Encapsulation PDU Format 200 Figure 3 shows the trailer-based encapsulation GMA PDU (protocol 201 data unit) format for the convergence sublayer. A (GMA) PDU may 202 carry one or multiple IP packets, aka (GMA) SDUs (service data 203 unit), in the payload, or a fragment of the SDU. 205 The Protocol Type field in the IP header of the GMA PDU MUST be 206 changed to 114 (Any 0-Hop Protocol) [IANA] to indicate the 207 presence of the GMA trailer. The following three IP header fields 208 SHOULD also be changed: 210 o IP Length: add the length of "GMA Trailer" to the length of 211 the original IP packet 212 o Time To Live (TTL) or Hop-Limit (HL): set the HL field to "0" 213 if the original IP packet is IPv6, and set the TTL field to "1" 214 if the original IP packet is IPv4. 215 o IP checksum: recalculate after changing "Protocol Type", "TTL 216 or HL" and "IP Length" 218 However, if UDP tunneling is used at the adaptation sublayer to 219 carry the GMA PDU, the above three IP header fields MAY remain 220 unchanged, and the receiver will determine the GMA PDU length 221 based on the UDP packet length. 223 The GMA (Generic Multi-Access) trailer MUST consist of the 224 following two mandatory fields. The Next Header field is always 225 the last octet at the end of the PDU, and the Flags field is the 226 second last. The Receiver SHOULD first decode the Flags field to 227 determine the length of the GMA trailer, and then decode each 228 optional field accordingly. 230 o Next Header (1 Byte): the IP protocol type of the (first) SDU 231 in a PDU 232 o Flags (1 Byte): Bit 0 is the least significant bit (LSB), and 233 Bit 7 is the most significant bit (MSB). 235 + Checksum Present (bit 0): If the Checksum Present bit is set 236 to 1, then the Checksum field is present and contains valid 237 information. 238 + Concatenation Present (bit 1): If the Concatenation Present 239 bit is set to 1, then the PDU carries multiple SDUs, and the 240 First SDU Length field is present and contains valid 241 information. 242 + Connection ID Present (bit 2): If the Connection ID Present 243 bit is set to 1, then the Connection ID field is present and 244 contains valid information. 245 + Flow ID Present (bit 3): If the Flow ID Present bit is set 246 to 1, then the Flow ID field is present and contains valid 247 information. 248 + Fragmentation Present (bit 4): If the Fragmentation Present 249 bit is set to 1, then the PDU carry a fragment of the SDU and 250 the Fragmentation Control field is present and contains valid 251 information. 252 + Sequence Number Present (bit 5): If the Sequence Number 253 Present bit is set to 1, then the Sequence Number field is 254 present and contains valid information. 255 + Timestamp Present (bit 6): If the Timestamp Present bit is 256 set to 1, then the Timestamp field is present and contains 257 valid information. 258 + TTL Present (bit 7): If the TTL Present bit is set to 1, 259 then the TTL field is present and contains the valid 260 information. 262 The GMA (Generic Multi-Access) trailer MAY consist of the 263 following optional fields: 265 o Checksum (1 Byte): to contain the (one's complement) checksum 266 sum of all the 8 bit in the trailer. For purposes of computing 267 the checksum, the value of the checksum field is zero. This 268 field is present only if the Checksum Present bit is set to 269 one. 270 o First SDU Length (2 Bytes): the length of the first IP packet 271 in the PDU, only included if a PDU contains multiple IP 272 packets. 273 o Connection ID (1 Byte): an unsigned integer to identify the 274 anchor and delivery connection of the GMA PDU. 275 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 276 identify the anchor connection 277 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 278 identify the delivery connection 279 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 280 that a PDU belongs to, for example Data Radio Bearer (DRB) ID 281 [LWIPEP] for a cellular (e.g. LTE) connection. 283 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 284 information for re-assembly, only needed if a PDU carries 285 fragments. 286 o Sequence Number (4 Bytes): an auto-incremented integer to 287 indicate order of transmission of the SDU (e.g. IP packet), 288 needed for lossless switching or multi-link (path) aggregation 289 or fragmentation. Sequence Number SHALL be generated per flow. 290 o Timestamp (4 Bytes): to contain the current value of the 291 timestamp clock of the transmitter in the unit of 100 292 microseconds. 293 o TTL (1 Byte): to contain the TTL value of the IP header if the 294 GMA SDU is an IPv4 packet, and the Hop-Limit value of the IP 295 header if the GMA SDU is an IPv6 packet. 297 Figure 4 shows the GMA trailer format with all the fields present. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Timestamp | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Sequence Number | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | FC | Flow ID | Connection ID | First SDU 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Length | Checksum | Flags | Next Header | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 4: GMA Trailer Format 313 5. Fragmentation 315 The convergence sublayer MAY support fragmentation if a delivery 316 connection has a smaller maximum transmission unit (MTU) than the 317 original IP packet (SDU). The fragmentation procedure at the 318 convergence sublayer is similar to IP fragmentation [RFC791] in 319 principle, but with the following two differences for less 320 overhead: 322 o The fragment offset field is expressed in number of fragments 323 not 8-bytes blocks 324 o The maximum number of fragments per SDU is 2^7 (=128) 326 The Fragmentation Control (FC) field in the trailer contains the 327 following bits: 329 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 330 is the last one (0) or not (1) 331 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 332 the offset of a particular fragment relative to the beginning 333 of the SDU 335 A PDU carries a whole SDU without fragmentation if the FC field is 336 set to all "0"s or the FC field is not present in the trailer. 337 Otherwise, the PDU contains a fragment of the SDU. 339 The Sequence Number (SN) field in the trailer is used to 340 distinguish the fragments of one SDU from those of another. The 341 Fragment Offset (FO) field tells the receiver the position of a 342 fragment in the original SDU. The More Fragment (MF) flag 343 indicates the last fragment. 345 To fragment a long SDU, the transmitter creates two PDUs and 346 copies the content of the IP header fields from the long PDU into 347 the IP header of both PDUs. The length field in the IP header of 348 PDU SHOULD be changed to the length of the PDU, and the protocol 349 type SHOULD be changed to 114. 351 The data of the long SDU is divided into two portions based on the 352 MTU size of the delivery connection. The first portion of the data 353 is placed in the first PDU. The MF flag is set to "1", and the FO 354 field is set to "0". The second portion of the data is placed in 355 the second PDU. The MF flag is set to "0", and the FO field is set 356 to "1". This procedure can be generalized for an n-way split, 357 rather than the two-way split described the above. 359 To assemble the fragments of a SDU, the receiver combines PDUs 360 that all have the same Sequence Number (in the trailer). The 361 combination is done by placing the data portion of each fragment 362 in the relative order indicated by the Fragment Offset in that 363 fragment's trailer. The first fragment will have the Fragment 364 Offset set to "0", and the last fragment will have the More- 365 Fragments flag reset to "0". 367 6. Concatenation 369 The convergence sublayer MAY support concatenation if a delivery 370 connection has a larger maximum transmission unit (MTU) than the 371 original IP packet (SDU). Only the SDUs with the same client IP 372 address, and the same Flow ID MAY be concatenated. 374 The First SDU Length (FSL) field SHOULD be included in the trailer 375 to indicate the length of the first SDU. 377 +-----------------------------------------------------------+ 378 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 379 +-----------------------------------------------------------+ 380 Figure 5: GMA PDU Format with Concatenation 382 To concatenate two or more SDUs, the transmitter creates one PDU 383 and copies the content of the IP header field from the first SDU 384 into the IP header of the PDU. The data of the first SDU is placed 385 in the first portion of the data of the PDU. The whole second SDU 386 is then placed in the second portion of the data of the PDU 387 (Figure 5). The procedure continues till the PDU size reaches the 388 MTU of the delivery connection. If the FSL field is present in the 389 trailer, the IP length field of the PDU SHOULD be updated to 390 include all concatenated SDUs and the trailer, and the IP checksum 391 field SHOULD be recalculated. However, if UDP tunnelling is used 392 at the adaptation sublayer to carry the GMA PDU, both the IP 393 Length field and the checksum field of the PDU MAY remain 394 unchanged, and the receiver will determine the GMA PDU length 395 based on the UDP packet length. 397 To disaggregate a PDU, the receiver first obtains the length of 398 the first SDU from the FSL field in the trailer, and decodes the 399 first SDU. If the FSL field or the trailer is not present, the 400 receiver obtains the length of the first SDU directly from the IP 401 length field of the PDU. The receiver then obtains the length of 402 the second SDU based on the length field in the second SDU IP 403 header, and decodes the second SDU. The procedure continues till 404 no byte is left in the PDU. 406 If a PDU contains multiple SDUs, the SN field in the trailer is 407 for the last SDU, and the SN of other SDU carried by the same PDU 408 can be obtained according to its order in the PDU. For example, if 409 the SN field is 6 and a PDU contains 3 SDUs (IP packets), the SN 410 is 4, 5, and 6 for the first, second, and last SDU respectively. 412 7. GMA Header Format 414 +-----------------------------------------------------+ 415 |GMA Header | IP hdr | IP payload | 416 +-----------------------------------------------------+ 417 Figure 6: Header-based Non-IP Encapsulation GMA PDU Format 419 Figure 6 shows the header-based encapsulation GMA PDU (protocol 420 data unit) format for the convergence sublayer. A (GMA) PDU may 421 carry one or multiple IP packets, aka (GMA) SDUs (service data 422 unit), in the payload, or a fragment of the SDU. 424 If the adaptation sublayer, e.g. UDP tunnelling, supports non-IP 425 packet format, the GMA PDU format as shown in Figure 6 may be used 426 without any modification. 428 +-----------------------------------------------------+ 429 |IP hdr | GMA Header | IP hdr | IP payload | 430 +-----------------------------------------------------+ 431 Figure 7: Header-based IP Encapsulation GMA PDU Format 433 If the adaptation sublayer supports only IP packet format, the GMA 434 PDU format SHOULD be modified as shown in Figure 7. The IP header 435 of the GMA SDU (e.g. IP packet) is copied to the front of the GMA 436 header so that the GMA PDU becomes an IP packet. Moreover, the 437 Protocol Type field in the IP header of the GMA PDU MUST be 438 changed to 114 (Any 0-Hop Protocol) [IANA] to indicate the 439 presence of the GMA Header. The following three IP header fields 440 SHALL also be changed: 442 o IP Length: add the length of "GMA Header" and "IP Header" to 443 the length of the original IP packet 444 o Time To Live (TTL) or Hop-Limit (HL): set the HL field to "0" 445 if the original IP packet is IPv6, and set the TTL field to "1" 446 if the original IP packet is IPv4. 447 o IP checksum: recalculate after changing "Protocol Type", "TTL 448 or HL" and "IP Length" 450 0 1 2 3 452 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flags | Timestamp 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Sequence Number 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | FC | Flow ID | Connection ID | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Checksum | 470 +-+-+-+-+-+-+-+-+ 471 Figure 8: GMA Header Format 473 Figure 8 shows the GMA header format with all the fields present. 474 In comparison to the GMA trailer format, there are the following 475 key differences: 477 o The "Flags" field is moved to the beginning of the GMA header 478 o The "First SDU Length" field is removed 479 o The "Next Header" field is removed 481 Fragmentation is supported in the same way as using the trailer- 482 based GMA PDU format. 484 Concatenation is also supported. The "Concatenation Present" bit 485 in the Flags field is used to indicate if a GMA PDU carries one or 486 multiple SDUs. However, since the IP header of the first SDU 487 encapsulated in a GMA PDU is not changed during the encapsulation 488 process, the "First SDU Length" field is not included in the GMA 489 header even if the "Concatenation Present" bit is set to 1. 491 The GMA endpoints: client and multi-access gateway (see Figure 2) 492 MAY determine which GMA PDU format (header or trailer) to use 493 through control signalling or pre-configuration. 495 8. Security Considerations 497 Security in a network using GMA should be relatively similar to 498 security in a normal IP network. The GMA protocol at the 499 convergence sublayer is a 0-hop protocol, and relies on the 500 security of the underlying network transport paths. When this 501 cannot be assumed, appropriate security protocols (IPsec, DTLS, 502 etc.) SHOULD be configured at the adaptation sublayer. On the 503 other hand, packet filtering requires either that a firewall looks 504 inside the GMA packet or that the filtering is done on the GMA 505 endpoints. In those environments in which this is considered to be 506 a security issue it may be desirable to terminate the GMA 507 operation at the firewall. 509 The balance of local-only packet leak prevention (HL=0) and 510 security (HL=255) SHOULD be on preventing the leak of the local- 511 only GMA PDUs outside the "local domain" to the Internet or to 512 another domain which could use the same IP protocol type, i.e. 513 114. 515 9. IANA Considerations 517 This draft makes no requests of IANA 519 10. References 521 10.1. Normative References 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, DOI 525 10.17487/RFC2119, March 1997, . 528 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 529 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 530 May 2017, . 532 10.2. Informative References 534 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, 535 "Multiple Access Management Protocol", 536 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 537 protocol-03 539 [IANA] https://www.iana.org/assignments/protocol- 540 numbers/protocol-numbers.xhtml 542 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 543 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 544 Ipsec Tunnel (LWIP) encapsulation; Protocol 545 specification" 547 [RFC791] Internet Protocol, September 1981 549 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 550 and splitting support in the 5G system architecture. 552 [GRE] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 554 Authors' Addresses 556 Jing Zhu 558 Intel 560 Email: jing.z.zhu@intel.com 562 Satish Kanugovi 564 Nokia 566 Email: satish.k@nokia.com