idnits 2.17.1 draft-zhu-intarea-gma-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the (trailer or header based) IP encapsulation method is used, the First SDU Length (FSL) field SHOULD be included in the GMA trailer (or header) to indicate the length of the first SDU. Otherwise, the FSL field SHOULD not be included. -- The document date (February 16, 2021) is 1162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: August 16,2021 Nokia 5 February 16, 2021 7 Generic Multi-Access (GMA) Encapsulation Protocol 8 draft-zhu-intarea-gma-08 10 Abstract 12 Today, a device can be simultaneously connected to multiple 13 networks, e.g. Wi-Fi, LTE, 5G, and DSL. It is desirable to combine 14 them seamlessly to improve quality of experience. Such 15 optimization requires additional control information, e.g. 16 Sequence Number, in each (IP) data packet. This document presents 17 a new light-weight and flexible encapsulation protocol for this 18 need. The solution has been developed by the authors based on 19 their experiences in multiple standards bodies including the IETF 20 and 3GPP, is not an Internet Standard and does not represent the 21 consensus opinion of the IETF. This document will enable other 22 developers to build interoperable implementations. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet-Drafts 37 as reference material or to cite them other than as "work in 38 progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on November 16, 2020. 48 Internet-Draft GMA Encapsulation Protocol February 20211 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction ................................................. 2 68 2. Conventions used in this document ............................ 4 69 3. Use Case ..................................................... 4 70 4. GMA Encapsulation Formats .................................... 5 71 5. Fragmentation ................................................ 9 72 6. Concatenation ............................................... 11 73 7. Security Considerations ..................................... 12 74 8. IANA Considerations ......................................... 12 75 9. References .................................................. 12 76 9.1. Normative References ..................................12 77 9.2. Informative References ................................12 79 1. Introduction 81 Figure 1 shows the Multi-Access Management Service (MAMS) user- 82 plane protocol stack [MAMS], which has been used in today's multi- 83 access solutions [ATSSS] [LWIPEP] [GRE]. It consists of two 84 layers: convergence and adaptation. 86 The convergence layer is responsible for multi-access operations, 87 including multi-link (path) aggregation, splitting/reordering, 88 lossless switching/retransmission, fragmentation, concatenation, 89 etc. It operates on top of the adaptation layer in the protocol 90 stack. From the Transmitter perspective, a User Payload (e.g. IP 91 packet) is processed by the convergence layer first, and then by 92 the adaptation layer before being transported over a delivery 93 connection; from the Receiver perspective, an IP packet received 94 over a delivery connection is processed by the adaptation layer 95 first, and then by the convergence layer. 97 Internet-Draft GMA Encapsulation Protocol February 20211 99 +-----------------------------------------------------+ 100 | User Payload, e.g., IP Protocol Data Unit (PDU) | 101 +-----------------------------------------------------+ 102 +-----------------------------------------------------------+ 103 | +-----------------------------------------------------+ | 104 | | Multi-Access (MX) Convergence Layer | | 105 | +-----------------------------------------------------+ | 106 | +-----------------------------------------------------+ | 107 | | MX Adaptation | MX Adaptation | MX Adaptation | | 108 | | Layer | Layer | Layer | | 109 | | (optional) | (optional) | (optional) | | 110 | +-----------------+-----------------+-----------------+ | 111 | | Access #1 IP | Access #2 IP | Access #3 IP | | 112 | +-----------------------------------------------------+ | 113 | MAMS User-Plane Protocol Stack | 114 +-----------------------------------------------------------+ 116 Figure 1: MAMS User-Plane Protocol Stack [MAMS] 118 Today, GRE is used [LWIPEP] [GRE]as the encapsulation protocol at 119 the convergence layer to encode additional control information, 120 e.g. Key, Sequence Number. However, there are two main drawbacks 121 with this approach: 123 o IP-over-IP tunnelling (required for GRE) leads to higher 124 overhead especially for small packet; 125 o It is difficult to introduce new control fields. 127 For example, the overhead of IP-over-IP/GRE tunnelling with both 128 Key and Sequence Number is 32 Bytes (20 Bytes IP header + 12 Bytes 129 GRE header), which is 80% of a 40 Bytes TCP ACK packet; 131 This document presents a light-weight GMA encapsulation protocol 132 for the convergence layer. It supports three encapsulation 133 methods: trailer-based IP encapsulation, header-based IP 134 encapsulation, and non-IP encapsulation. Particularly, the IP 135 encapsulation methods avoid IP-over-IP tunneling overhead (20 136 Bytes), which is 50% of a 40 Bytes TCP ACK packet. Moreover, it 137 introduces new control fields to support fragmentation and 138 concatenation, which are not available in today's GRE-based 139 solutions [LWIPEP] [GRE]. 141 GMA protocol SHALL only operate between endpoints that have been 142 configured to operate with GMA through additional control messages 143 and procedures, for example [MAMS]. Moreover, UDP or IPSec 145 Internet-Draft GMA Encapsulation Protocol February 20211 147 tunneling MAY be used at the adaptation sublayer to protect GMA 148 operation from intermediate nodes. 150 2. Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 153 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 154 "MAY", and "OPTIONAL" in this document are to be interpreted as 155 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 156 appear in all capitals, as shown here. 158 3. Use Case 160 Multi-Access Aggregation 162 +---+ +---+ 163 | |A|--- LTE Connection -----|C| | 164 |U|-| |-|S| Internet 165 | |B|--- Wi-Fi Connection ---|D| | 166 +---+ +---+ 167 Client Multi-Access Gateway 169 A: The adaptation layer endpoint of the LTE connection 170 resides in the client 172 B: The adaptation layer endpoint of the Wi-Fi connection 173 resides in the client 175 C: The adaptation layer endpoint of the LTE connection 176 resides in the Multi-Access Gateway, aka N-MADP (Network 177 Multi-Access Data Proxy) in [MAMS] 179 D: The adaptation layer endpoint of the Wi-Fi connection 180 resides in the Multi-Access Gateway 182 U: The convergence layer endpoint resides in the client 184 S: The convergence layer endpoint resides in the Multi- 185 Access Gateway 187 Figure 2: GMA-based Multi-Access Aggregation 189 As shown in Figure 2, a client device (e.g. Smartphone, Laptop, 190 etc.) may connect to Internet via both Wi-Fi and LTE connections, 191 one of which (e.g. LTE) may operate as the anchor connection, and 192 the other (e.g. Wi-Fi) may operate as the delivery connection. The 193 anchor connection provides the IP address and connectivity for 195 Internet-Draft GMA Encapsulation Protocol February 20211 197 end-to-end Internet access, and the delivery connection provides 198 additional path between client and Multi-Access Gateway for multi- 199 access optimizations. 201 For example, per-packet aggregation allows a single IP flow to use 202 the combined bandwidth of the two connections. In another example, 203 packets lost due to temporarily link outage may be retransmitted. 204 Moreover, packets may be duplicated over multiple connections to 205 achieve high reliability and low latency, and duplicated packets 206 should be eliminated by the receiving side. Such multi-access 207 optimization requires additional control information, e.g. 208 Sequence Number, in each IP data packet, which can be supported by 209 the GMA encapsulation protocol described in this document. 211 The GMA protocol in this document is designed for multiple 212 connections, but it may also be used when there is only one 213 connection between two end-points. For example, it may be used for 214 loss detection and recovery. In another example, it may be used to 215 concatenate multiple small packets and reduce per packet overhead. 217 4. GMA Encapsulation Formats 219 The GMA encapsulation protocol supports the following three 220 formats: 222 o Trailer-based IP Encapsulation 223 o Header-based IP Encapsulation 224 o Header-based non-IP Encapsulation 226 |<---------------------GMA PDU ----------------------->| 227 +------------------------------------------------------+ 228 | IP hdr | IP payload | GMA Trailer | 229 +------------------------------------------------------+ 230 |<------- GMA SDU (user payload)-------->| 232 Figure 3: Trailer-based IP Encapsulation Format 234 Figure 3 shows the trailer-based IP encapsulation GMA PDU 235 (protocol data unit) format. A (GMA) PDU may carry one or multiple 236 IP packets, aka (GMA) SDUs (service data unit), in the payload, or 237 a fragment of the SDU. 239 The Protocol Type field in the IP header of the GMA PDU MUST be 240 changed to 114 (Any 0-Hop Protocol) [IANA] to indicate the 242 Internet-Draft GMA Encapsulation Protocol February 20211 244 presence of the GMA trailer. The following three IP header fields 245 SHOULD also be changed: 247 o IP Length: add the length of "GMA Trailer" to the length of 248 the original IP packet 249 o Time To Live (TTL) or Hop-Limit (HL): set the HL field to "0" 250 if the original IP packet is IPv6, and set the TTL field to "1" 251 if the original IP packet is IPv4. 252 o IP checksum: recalculate after changing "Protocol Type", "TTL 253 or HL" and "IP Length" 255 However, if UDP tunnelling is used at the adaptation layer, the 256 above three IP header fields SHOULD remain unchanged, and the 257 receiver will determine the GMA PDU length based on the UDP packet 258 length. 260 The GMA (Generic Multi-Access) trailer MUST consist of two 261 mandatory fields: Flags and Next Header: 263 o Next Header (1 Byte): the IP protocol type of the (first) SDU 264 in a PDU, and it stores the value before it was overwritten to 265 114. 266 o Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and 267 Bit 15 is the least significant bit (LSB) 268 + Checksum Present (bit 0): If the Checksum Present bit is set 269 to 1, then the Checksum field is present; 270 + Concatenation Present (bit 1): If the Concatenation Present 271 bit is set to 1, then the PDU carries multiple SDUs, and the 272 First SDU Length field is present; 273 + Connection ID Present (bit 2): If the Connection ID Present 274 bit is set to 1, then the Connection ID field is present; 275 + Flow ID Present (bit 3): If the Flow ID Present bit is set 276 to 1, then the Flow ID field is present; 277 + Fragmentation Present (bit 4): If the Fragmentation Present 278 bit is set to 1, then the PDU carry a fragment of the SDU and 279 the Fragmentation Control field is present; 280 + Delivery SN Present (bit 5): If the Delivery SN (Sequence 281 Number) Present bit is set to 1, then the Delivery SN field is 282 present and contains the valid information; 283 + Flow SN Present (bit 6): If the Flow SN Present bit is set 284 to 1, then the Sequence Number field is present; 285 + Timestamp Present (bit 7): If the Timestamp Present bit is 286 set to 1, then the Timestamp field is present; 287 + TTL Present (bit 8): If the TTL Present bit is set to 1, 288 then the TTL field is present; 289 + Reserved (bit 9-12): set to "0" and ignored on receipt; 290 + Version (bit 13~15): GMA version number, set to 0 for the 291 GMA encapsulation protocol specified in this document. 293 Internet-Draft GMA Encapsulation Protocol February 20211 295 The Flags field is at the end of the PDU, and the Next Header 296 field is the second last. The Receiver SHOULD first decode the 297 Flags field to determine the length of the GMA trailer, and then 298 decode each optional field accordingly. The GMA (Generic Multi- 299 Access) trailer MAY consist of the following optional fields: 301 o Checksum (1 Byte): to contain the (one's complement) checksum 302 sum of all the 8 bits in the trailer. For purposes of 303 computing the checksum, the value of the checksum field is 304 zero. This field is present only if the Checksum Present bit 305 is set to one. 306 o First SDU Length (2 Bytes): the length of the first IP packet 307 in the PDU, only included if a PDU contains multiple IP 308 packets. This field is present only if the Concatenation 309 Present bit is set to one. 310 o Connection ID (1 Byte): an unsigned integer to identify the 311 anchor and delivery connection of the GMA PDU. This field is 312 present only if the Connection ID Present bit is set to one. 313 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 314 identify the anchor connection 315 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 316 identify the delivery connection 317 o Flow ID (1 Byte): an unsigned integer to identify the IP flow 318 that a PDU belongs to, for example Data Radio Bearer (DRB) ID 319 [LWIPEP] for a cellular (e.g. LTE) connection. This field is 320 present only if the Flow ID Present bit is set to one. 321 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 322 information for re-assembly, only needed if a PDU carries 323 fragments. This field is present only if the Fragmentation 324 Present bit is set to one. Please refer to section 5 for its 325 detailed format and usage. 326 o Delivery SN (1 Byte): an auto-incremented integer to indicate 327 the GMA PDU transmission order on a delivery connection. 328 Delivery SN is needed to measure packet loss of each delivery 329 connection and therefore generated per delivery connection per 330 flow. This field is present only if the Delivery SN Present 331 bit is set to one. 332 o Flow SN (3 Bytes): an auto-incremented integer to indicate the 333 GMA SDU (IP packet) order of a flow. Flow SN is needed for 334 retransmission, reordering, and fragmentation. It SHALL be 335 generated per flow. This field is present only if the Flow SN 336 Present bit is set to one. 337 o Timestamp (4 Bytes): to contain the current value of the 338 timestamp clock of the transmitter in the unit of 1 339 millisecond. This field is present only if the Timestamp 340 Present bit is set to one. 341 o TTL (1 Byte): to contain the TTL value of the original IP 342 header if the GMA SDU is IPv4, or the Hop-Limit value of the 344 Internet-Draft GMA Encapsulation Protocol February 20211 346 IP header if the GMA SDU is IPv6. This field is present only 347 if the TTL Present bit is set to one. 349 Figure 4 shows the GMA trailer format with all the fields present, 350 and the order of the GMA control fields SHALL follow the bit order 351 in the Flags field. For example, Bit 0 (the MSB) of the Flags 352 field is the Checksum Present bit, and the Checksum field is the 353 last in the trailer except of the two mandatory fields. Bit 1 is 354 the Concatenation present bit, and the FSL field is the second 355 last. 357 The trailer-based IP encapsulation method SHOULD be used as long 358 as implementation allows. However, if the GMA control fields can't 359 be added at the end due to any reason, e.g. implementation 360 constraints, the header-based encapsulation method MAY be used. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | TTL | Timestamp 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Flow SN | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Delivery SN | FC | Flow ID | Connection ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | First SDU Length (FSL) | Checksum | Next Header | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Flags | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 4: GMA Trailer Format 378 +-----------------------------------------------------+ 379 |GMA Header | IP hdr | IP payload | 380 +-----------------------------------------------------+ 381 Figure 5: Header-based Non-IP Encapsulation Format 383 +--------------------------------------------------+ 384 | Flags | GMA control fields | 385 +--------------------------------------------------+ 386 Figure 6: GMA Header Format 388 Figure 5 shows the header-based non-IP encapsulation format, and 389 Figure 6 shows the GMA header format. Herein, "Flags" is moved to 390 the front. Moreover, "TTL", "FSL", and "Next Header" are removed 392 Internet-Draft GMA Encapsulation Protocol February 20211 394 from the GMA control fields since the IP header fields of the GMA 395 SDU remain unchanged during encapsulation. The order of other GMA 396 control fields is the same as shown in Figure 4. 398 If the adaptation layer, e.g. UDP tunnelling, supports non-IP 399 packet format, the GMA PDU format as shown in Figure 5 SHOULD be 400 used without any modification. 402 If the adaptation layer only supports IP packet format, e.g. IPSec 403 tunneling, IP encapsulation SHOULD be used, and Figure 7 shows the 404 header-based IP encapsulation format. Herein, the IP header of the 405 GMA SDU is moved to the front so that the GMA PDU becomes an IP 406 packet, and the IP header fields of the GMA PDU SHOULD be changed 407 in the same way as the trailered-based IP encapsulation method. 409 +-----------------------------------------------------+ 410 |IP hdr | GMA Header | IP payload | 411 +-----------------------------------------------------+ 412 Figure 7: Header-based IP Encapsulation Format 414 If the non-IP encapsulation method is configured, the GMA header 415 SHOULD always be present. In comparison, the (header or trailer 416 based) IP encapsulation method (as shown in Figure 3 and 7) may be 417 used dynamically on per-packet basis, and setting the protocol 418 type of the GMA PDU to "114" indicates the presence of GMA header 419 (or trailer) in an IP packet. 421 The GMA endpoints SHOULD configure the encapsulation method 422 through control signalling or pre-configuration. For example, the 423 "MX UP Setup Configuration Request" message as specified in Multi- 424 Access Management Service[MAMS] includes "MX Convergence Method 425 Parameters", which provides the list of parameters to configure 426 the convergence layer. Here, a new "GMA encapsulation format" 427 parameter SHOULD be included to indicate one of the following 428 three GMA encapsulation formats: 430 o Trailer-based IP Encapsulation (Figure 3) 431 o Header-based non-IP Encapsulation (Figure 5) 432 o Header-based IP Encapsulation (Figure 7) 434 5. Fragmentation 436 The convergence layer MAY support fragmentation if a delivery 437 connection has a smaller maximum transmission unit (MTU) than the 438 original IP packet (SDU). The fragmentation procedure at the 439 convergence sublayer is similar to IP fragmentation [RFC791] in 441 Internet-Draft GMA Encapsulation Protocol February 20211 443 principle, but with the following two differences for less 444 overhead: 446 o The fragment offset field is expressed in number of fragments 447 o The maximum number of fragments per SDU is 2^7 (=128) 449 The Fragmentation Control (FC) field in the GMA trailer (or 450 header) contains the following bits: 452 o Bit #7: a More Fragment (MF) flag to indicate if the fragment 453 is the last one (0) or not (1) 454 o Bit #0~#6: Fragment Offset (in units of fragments) to specify 455 the offset of a particular fragment relative to the beginning 456 of the SDU 458 A PDU carries a whole SDU without fragmentation if the FC field is 459 set to all "0"s or the FC field is not present in the trailer. 460 Otherwise, the PDU contains a fragment of the SDU. 462 The Flow SN field in the trailer is used to distinguish the 463 fragments of one SDU from those of another. The Fragment Offset 464 (FO) field tells the receiver the position of a fragment in the 465 original SDU. The More Fragment (MF) flag indicates the last 466 fragment. 468 To fragment a long SDU, the transmitter creates n PDUs and copies 469 the content of the IP header fields from the long PDU into the IP 470 header of all the PDUs. The length field in the IP header of PDU 471 SHOULD be changed to the length of the PDU, and the protocol type 472 SHOULD be changed to 114. 474 The data of the long SDU is divided into n portions based on the 475 MTU size of the delivery connection. The first portion of the data 476 is placed in the first PDU. The MF flag is set to "1", and the FO 477 field is set to "0". The i-th portion of the data is placed in the 478 i-th PDU. The MF flag is set to "0" if it is the last fragment and 479 set to "1" otherwise. The FO field is set to i-1. 481 To assemble the fragments of a SDU, the receiver combines PDUs 482 that all have the same Flow SN. The combination is done by placing 483 the data portion of each fragment in the relative order indicated 484 by the Fragment Offset in that fragment's GMA trailer (or header). 485 The first fragment will have the Fragment Offset set to "0", and 486 the last fragment will have the More-Fragments flag set to "0". 488 Internet-Draft GMA Encapsulation Protocol February 20211 490 6. Concatenation 492 The convergence sublayer MAY support concatenation if a delivery 493 connection has a larger maximum transmission unit (MTU) than the 494 original IP packet (SDU). Only the SDUs with the same client IP 495 address, and the same Flow ID MAY be concatenated. 497 If the (trailer or header based) IP encapsulation method is used, 498 the First SDU Length (FSL) field SHOULD be included in the GMA 499 trailer (or header) to indicate the length of the first SDU. 500 Otherwise, the FSL field SHOULD not be included. 502 +-----------------------------------------------------------+ 503 |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | 504 +-----------------------------------------------------------+ 505 Figure 8: Example of GMA PDU Format with Concatenation and 506 Trailer-based IP Encapsulation 508 To concatenate two or more SDUs, the transmitter creates one PDU 509 and copies the content of the IP header field from the first SDU 510 into the IP header of the PDU. The data of the first SDU is placed 511 in the first portion of the data of the PDU. The whole second SDU 512 is then placed in the second portion of the data of the PDU 513 (Figure 8). The procedure continues till the PDU size reaches the 514 MTU of the delivery connection. If the FSL field is present, the 515 IP length field of the PDU SHOULD be updated to include all 516 concatenated SDUs and the trailer (or header), and the IP checksum 517 field SHOULD be recalculated. However, if the non-IP encapsulation 518 method is used, both the IP Length field and the checksum field of 519 the PDU SHOULD remain unchanged, and the receiver will determine 520 the GMA PDU length based on the UDP packet length. 522 To disaggregate a PDU, if the (header or trailer based) IP 523 encapsulation method is used, the receiver first obtains the 524 length of the first SDU from the FSL field and decodes the first 525 SDU. The receiver then obtains the length of the second SDU based 526 on the length field in the second SDU IP header and decodes the 527 second SDU. The procedure continues till no byte is left in the 528 PDU. If the non-IP encapsulation method (Figure 5) is used, the IP 529 header of the first SDU will not change during the encapsulation 530 process, and the receiver obtains the length of the first SDU 531 directly from its IP header. 533 If a PDU contains multiple SDUs, the Flow SN field is for the last 534 SDU, and the Flow SN of other SDU carried by the same PDU can be 535 obtained according to its order in the PDU. For example, if the SN 537 Internet-Draft GMA Encapsulation Protocol February 20211 539 field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, 540 and 6 for the first, second, and last SDU respectively. 542 7. Security Considerations 544 Security in a network using GMA should be relatively similar to 545 security in a normal IP network. The GMA protocol at the 546 convergence sublayer is a 0-hop protocol and relies on the 547 security of the underlying network transport paths. When this 548 cannot be assumed, appropriate security protocols (IPsec, DTLS, 549 etc.) SHOULD be configured at the adaptation sublayer. On the 550 other hand, packet filtering requires either that a firewall looks 551 inside the GMA packet or that the filtering is done on the GMA 552 endpoints. In those environments in which this is considered to be 553 a security issue it may be desirable to terminate the GMA 554 operation at the firewall. 556 Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on 557 preventing the leak of the local-only GMA PDUs outside the "local 558 domain" to the Internet or to another domain which could use the 559 same IP protocol type, i.e. 114. 561 8. IANA Considerations 563 This draft makes no requests of IANA 565 9. References 567 9.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, DOI 571 10.17487/RFC2119, March 1997, . 574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 576 May 2017, . 578 9.2. Informative References 580 [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access 581 Management Services 582 (MAMS)https://tools.ietf.org/rfc/rfc8743.txt 584 [IANA] https://www.iana.org/assignments/protocol- 585 numbers/protocol-numbers.xhtml 587 Internet-Draft GMA Encapsulation Protocol February 20211 589 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio 590 Access (E-UTRA); LTE-WLAN Radio Level Integration Using 591 Ipsec Tunnel (LWIP) encapsulation; Protocol 592 specification" 594 [RFC791] Internet Protocol, September 1981 596 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch 597 and splitting support in the 5G system architecture. 599 [GRE] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 601 Authors' Addresses 603 Jing Zhu 605 Intel 607 Email: jing.z.zhu@intel.com 609 Satish Kanugovi 611 Nokia 613 Email: satish.k@nokia.com