Network Working Group J. Zhu Internet Draft Intel Intended status: Experimental S. Kanugovi Expires: April 8,2022 Nokia October 8, 2021 Generic Multi-Access (GMA) Encapsulation Protocol draft-zhu-intarea-gma-11 Abstract A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built in multi-path capabilities. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new light weight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations in order to experiment with the protocol. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Zhu Expires April 8, 2022 [Page 1] Internet-Draft GMA Encapsulation Protocol October 2021 This Internet-Draft will expire on April 8, 2019. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 2 1.1. Scope of Experiment ....................................4 2. Conventions used in this document ............................ 5 3. Use Case ..................................................... 5 4. GMA Encapsulation Methods .................................... 6 4.1. Trailer-based IP Encapsulation .........................7 4.2. Header-based IP Encapsulation .........................10 4.3. (Header-based) non-IP Encapsulation ...................11 4.4. IP Protocol Identifier ................................11 5. Fragmentation ............................................... 12 6. Concatenation ............................................... 13 7. Security Considerations ..................................... 14 8. IANA Considerations ......................................... 15 9. References .................................................. 15 9.1. Normative References ..................................15 9.2. Informative References ................................15 1. Introduction A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built in multi-path capabilities. Figure 1 shows the Multi-Access Management Service (MAMS) user- plane protocol stack [MAMS], which has been used in today's multi- access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. It consists of two layers: convergence and adaptation. Zhu Expires April 8, 2022 [Page 2] Internet-Draft GMA Encapsulation Protocol October 2021 The convergence layer is responsible for multi-access operations, including multi-link (path) aggregation, splitting/reordering, lossless switching/retransmission, fragmentation, concatenation, etc. It operates on top of the adaptation layer in the protocol stack. From the perspective of a transmitter, a User Payload (e.g., IP packet) is processed by the convergence layer first, and then by the adaptation layer before being transported over a delivery connection; from the receiver's perspective, an IP packet received over a delivery connection is processed by the adaptation layer first, and then by the convergence layer. +-----------------------------------------------------+ | User Payload, e.g., IP Protocol Data Unit (PDU) | +-----------------------------------------------------+ +-----------------------------------------------------------+ | +-----------------------------------------------------+ | | | Multi-Access (MX) Convergence Layer | | | +-----------------------------------------------------+ | | +-----------------------------------------------------+ | | | MX Adaptation | MX Adaptation | MX Adaptation | | | | Layer | Layer | Layer | | | +-----------------+-----------------+-----------------+ | | | Access #1 IP | Access #2 IP | Access #3 IP | | | +-----------------------------------------------------+ | | MAMS User-Plane Protocol Stack | +-----------------------------------------------------------+ Figure 1: MAMS User-Plane Protocol Stack [MAMS] GRE (Generic Routing Encapsulation) can be used [LWIPEP] [GRE1] [GRE2] as the encapsulation protocol at the convergence layer to encode additional control information, e.g., Key, Sequence Number. However, there are two main drawbacks with this approach: o It is difficult to introduce new control fields because the GRE header formats are already defined, o IP-over-IP tunnelling (required for GRE) leads to higher overhead especially for small packet. For example, the overhead of IP-over-IP/GRE tunnelling with both Key and Sequence Number is 32 Bytes (20 Bytes IP header + 12 Bytes GRE header), which is 80% of a 40 Bytes TCP ACK packet. This document presents a light-weight GMA (Generic Multi-Access) encapsulation protocol for the convergence layer. It supports three encapsulation methods: trailer-based IP encapsulation, Zhu Expires April 8, 2022 [Page 3] Internet-Draft GMA Encapsulation Protocol October 2021 header-based IP encapsulation, and non-IP encapsulation. Particularly, the IP encapsulation methods avoid IP-over-IP tunneling overhead (20 Bytes), which is 50% of a 40 Bytes TCP ACK packet. Moreover, it introduces new control fields to support fragmentation and concatenation, which are not available in GRE- based solutions [LWIPEP] [GRE1] [GRE2]. The GMA protocol only operates between endpoints that have been configured to use GMA. This configuration can be through any control messages and procedures, including, for example, Multi- Access Management Services [MAMS]. Moreover, UDP or IPSec tunneling can be used at the adaptation sublayer to protect GMA operation from intermediate nodes. The solution described in this document was been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, it is not an Internet Standard and does not represent the consensus opinion of the IETF. This document presents the protocol specification to enable experimentation as described in Section 1.1 and to facilitate other interoperable implementations. 1.1. Scope of Experiment The protocol described in this document is an experiment. The objective of the experiment is to determine whether the protocol meets the requirements, can be safely used, and has support for deployment. Section 4 describes three possible encapsulation methods that are enabled by this protocol. Part of this experiment is to assess whether all three mechanisms are necessary, or whether, for example, all implementations are able to support the main "trailer-based" IP encapsulation method. Similarly, the experiment will investigate the relative merits of the IP and non-IP encapsulation methods. It is expected that this protocol experiment can be conducted on the Internet since the GMA packets are identified by an IP protocol number and the protocol is intended for single hop propagation: devices should not be forwarding packet and if they do they will not need to examine the payload, while destination systems that do not support this protocol should not receive such packets and will handle them as unknown payloads according to normal IP processing. Thus, experimentation is conducted between consenting end systems that have been mutually configured to participate in the experiment as described in Section 7. Zhu Expires April 8, 2022 [Page 4] Internet-Draft GMA Encapsulation Protocol October 2021 Note that this experiment "re-uses" the IP protocol identifier 114 as described in Section 4.4. Part of this experiment is to assess the safety of doing this. The authors will continually assess the progress of this experiment and encourage other implementers to contact them to report the status of their implementations and their experiences with the protocol. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Use Case As shown in Figure 2, a client device (e.g., Smartphone, Laptop, etc.) may connect to the Internet via both Wi-Fi and LTE connections, one of which (e.g., LTE) may operate as the anchor connection, and the other (e.g., Wi-Fi) may operate as the delivery connection. The anchor connection provides the IP address and connectivity for end-to-end Internet access, and the delivery connection provides an additional path between client and Multi- Access Gateway for multi-access optimizations. Multi-Access Aggregation +---+ +---+ | |A|--- LTE Connection -----|C| | |U|-| |-|S| Internet | |B|--- Wi-Fi Connection ---|D| | +---+ +---+ Client Multi-Access Gateway A: The adaptation layer endpoint of the LTE connection resides in the client B: The adaptation layer endpoint of the Wi-Fi connection resides in the client C: The adaptation layer endpoint of the LTE connection resides in the Multi-Access Gateway, aka N-MADP (Network Multi-Access Data Proxy) in [MAMS] Zhu Expires April 8, 2022 [Page 5] Internet-Draft GMA Encapsulation Protocol October 2021 D: The adaptation layer endpoint of the Wi-Fi connection resides in the Multi-Access Gateway U: The convergence layer endpoint resides in the client S: The convergence layer endpoint resides in the Multi- Access Gateway Figure 2: GMA-based Multi-Access Aggregation For example, per-packet aggregation allows a single IP flow to use the combined bandwidth of the two connections. In another example, packets lost due to a temporarily link outage may be retransmitted. Moreover, packets may be duplicated over multiple connections to achieve high reliability and low latency, where duplicated packets are eliminated by the receiving side. Such multi-access optimization requires additional control information, e.g., a sequence number, in each packet, which can be supported by the GMA encapsulation protocol described in this document. The GMA protocol described in this document is designed for multiple connections, but it may also be used when there is only one connection between two endpoints. For example, it may be used for loss detection and recovery. In another example, it may be used to concatenate multiple small packets and reduce per packet overhead. 4. GMA Encapsulation Methods The GMA encapsulation protocol supports the following three methods: o Trailer-based IP Encapsulation (4.1) o Header-based IP Encapsulation (4.2) o (Header-based) non-IP Encapsulation (4.3) Trailer-based IP encapsulation MUST be used if it is supported by GMA endpoints. Header-based encapsulation MUST be used if the trailer-based method is not supported by either Client or Multi-Access Gateway. In this case, if the adaptation layer, e.g., UDP tunnelling, supports non-IP packet format, non-IP encapsulation MUST be used; otherwise, header-based IP encapsulation MUST be used. If non-IP encapsulation is configured, a GMA header MUST be present in every packet. In comparison, if IP encapsulation is configured, a GMA header or trailer may be added dynamically on Zhu Expires April 8, 2022 [Page 6] Internet-Draft GMA Encapsulation Protocol October 2021 per-packet basis, and it indicates the presence of GMA header (or trailer) to set the protocol type of the GMA PDU to "114" (see Section 4.4). The GMA endpoints MAY configure the GMA encapsulation method through control signalling or pre-configuration. For example, the "MX UP Setup Configuration Request" message as specified in Multi- Access Management Service [MAMS] includes "MX Convergence Method Parameters", which provides the list of parameters to configure the convergence layer, and can be extended to indicate the GMA encapsulation method. GMA endpoint MUST discard a received packet and MAY log an error to report the situation (although such error logging MUST be subject to rate limits) under any of the following conditions: . the GMA version number in the GMA header (or trailer) is not understood or supported by the GMA endpoint . a Flag bit in the GMA header (or trailer) not understood or supported by the GMA endpoint is set to "1" 4.1. Trailer-based IP Encapsulation |<---------------------GMA PDU ----------------------->| +------------------------------------------------------+ | IP hdr | IP payload | GMA Trailer | +------------------------------------------------------+ |<------- GMA SDU (user payload)-------->| Figure 3: GMA PDU Format with Trailer-based IP Encapsulation Figure 3 shows the trailer-based IP encapsulation GMA PDU (protocol data unit) format. A (GMA) PDU may carry one or multiple IP packets, aka (GMA) SDUs (service data unit), in the payload, or a fragment of the SDU. The Protocol Type field in the IP header of the GMA PDU MUST be changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to indicate the presence of the GMA trailer. If the original IP packet is IPv4, the following three IP header fields MUST be changed: o IP Length: add the length of "GMA Trailer" to the length of the original IP packet o Time To Live (TTL): set to "1" Zhu Expires April 8, 2022 [Page 7] Internet-Draft GMA Encapsulation Protocol October 2021 o IP checksum: recalculate after changing "Protocol Type", "TTL" and "IP Length" If the original IP packet is IPv6, the following two IP header fields MUST be changed: o IP Length: add the length of "GMA Trailer" to the length of the original IP packet o Hop-Limit (HL): set the HL field to "0" The GMA (Generic Multi-Access) trailer MUST consist of two mandatory fields (the last 3 bytes): Next Header and Flags, defined as follows: o Next Header (1 Byte): the IP protocol type of the (first) SDU in a PDU, and it stores the value before it was overwritten to 114. o Flags (2 Bytes): Bit 0 is the most significant bit (MSB), and Bit 15 is the least significant bit (LSB) + Checksum Present (bit 0): If the Checksum Present bit is set to 1, then the Checksum field is present + Concatenation Present (bit 1): If the Concatenation Present bit is set to 1, then the PDU carries multiple SDUs, and the First SDU Length field is present + Connection ID Present (bit 2): If the Connection ID Present bit is set to 1, then the Connection ID field is present + Flow ID Present (bit 3): If the Flow ID Present bit is set to 1, then the Flow ID field is present + Fragmentation Present (bit 4): If the Fragmentation Present bit is set to 1, then the PDU carry a fragment of the SDU and the Fragmentation Control field is present + Delivery SN Present (bit 5): If the Delivery SN (Sequence Number) Present bit is set to 1, then the Delivery SN field is present and contains the valid information + Flow SN Present (bit 6): If the Flow SN Present bit is set to 1, then the Sequence Number field is present + Timestamp Present (bit 7): If the Timestamp Present bit is set to 1, then the Timestamp field is present + TTL Present (bit 8): If the TTL Present bit is set to 1, then the TTL field is present + Reserved (bit 9-12): set to "0" and ignored on receipt + Version (bit 13~15): GMA version number, set to 0 for the GMA encapsulation protocol specified in this document. The Flags field is at the end of the PDU, and the Next Header field is the second last. The Receiver SHOULD first decode the Flags field to determine the length of the GMA trailer, and then Zhu Expires April 8, 2022 [Page 8] Internet-Draft GMA Encapsulation Protocol October 2021 decode each optional field accordingly. The GMA (Generic Multi- Access) trailer MAY consist of the following optional fields: o Checksum (1 Byte): to contain the (one's complement) checksum sum of all the 8 bits in the trailer. For purposes of computing the checksum, the value of the checksum field is zero. This field is present only if the Checksum Present bit is set to one. o First SDU Length (2 Bytes): the length of the first IP packet in the PDU, only included if a PDU contains multiple IP packets. This field is present only if the Concatenation Present bit is set to one. o Connection ID (1 Byte): an unsigned integer to identify the anchor and delivery connection of the GMA PDU. This field is present only if the Connection ID Present bit is set to one. + Anchor Connection ID (MSB 4 Bits): an unsigned integer to identify the anchor connection + Delivery Connection ID (LSB 4 Bits): an unsigned integer to identify the delivery connection o Flow ID (1 Byte): an unsigned integer to identify the IP flow that a PDU belongs to, for example Data Radio Bearer (DRB) ID [LWIPEP] for a cellular (e.g., LTE) connection. This field is present only if the Flow ID Present bit is set to one. o Fragmentation Control (FC) (1 Byte): to provide necessary information for re-assembly, only needed if a PDU carries fragments. This field is present only if the Fragmentation Present bit is set to one. Please refer to section 5 for its detailed format and usage. o Delivery SN (1 Byte): an auto-incremented integer to indicate the GMA PDU transmission order on a delivery connection. Delivery SN is needed to measure packet loss of each delivery connection and therefore generated per delivery connection per flow. This field is present only if the Delivery SN Present bit is set to one. o Flow SN (3 Bytes): an auto-incremented integer to indicate the GMA SDU (IP packet) order of a flow. Flow SN is needed for retransmission, reordering, and fragmentation. It SHALL be generated per flow. This field is present only if the Flow SN Present bit is set to one. o Timestamp (4 Bytes): to contain the current value of the timestamp clock of the transmitter in the unit of 1 millisecond. This field is present only if the Timestamp Present bit is set to one. o TTL (1 Byte): to contain the TTL value of the original IP header if the GMA SDU is IPv4, or the Hop-Limit value of the IP header if the GMA SDU is IPv6. This field is present only if the TTL Present bit is set to one. Zhu Expires April 8, 2022 [Page 9] Internet-Draft GMA Encapsulation Protocol October 2021 Figure 4 shows the GMA trailer format with all the fields present, and the order of the GMA control fields SHALL follow the bit order in the Flags field. Note that the bits in the Flags field are ordered with the first bit transmitted being bit 0 (MSB). All fields are transmitted in regular network byte order and appear in reverse order to their corresponding flag bits. If a flag bit is clear, the corresponding optional field is absent. For example, Bit 0 (the MSB) of the Flags field is the Checksum Present bit, and the Checksum field is the last in the trailer except of the two mandatory fields. Bit 1 is the Concatenation present bit, and the FSL field is the second last. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Timestamp +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow SN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery SN | FC | Flow ID | Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First SDU Length (FSL) | Checksum | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: GMA Trailer Format with all Optional Fields Present 4.2. Header-based IP Encapsulation Figure 5 shows the header-based IP encapsulation format. Here, the GMA header is inserted right after the IP header of the GMA SDU, and the IP header fields of the GMA PDU MUST be changed the same way as in trailered-based IP encapsulation. +-----------------------------------------------+ |IP hdr | GMA Header | IP payload | +-----------------------------------------------+ Figure 5: GMA PDU Format with Header-based IP Encapsulation Figure 6 shows the GMA header format. In comparison to GMA trailer, the only difference is that the Flags field is now in the front so that the Receiver can first decode the Flags field to determine the GMA header length. Zhu Expires April 8, 2022 [Page 10] Internet-Draft GMA Encapsulation Protocol October 2021 +------------------------------------------------------+ | Flags | other fields (TTL, Timestamp, Flow SN, etc.) | +------------------------------------------------------+ Figure 6: GMA Header Format 4.3. (Header-based) non-IP Encapsulation Figure 7 shows the header-based non-IP encapsulation format. Here, "UDP Tunnelling" is configured at the MX adaptation layer. The ports for "UDP Tunnelling" at Client are chosen from the Dynamic Port range, and the ports for "UDP Tunnelling" at Multi-Access Gateway are configured and provided to Client through additional control messages, e.g., [MAMS]. "TTL", "FSL", and "Next Header" are no longer needed, and MUST not be included. Moreover, the IP header fields of the GMA SDU remain unchanged. +-------------------------------------------------------------+ | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | +-------------------------------------------------------------+ |<------- GMA SDU------------>| |<------------------- GMA PDU------------>| Figure 7: GMA PDU Format with Non-IP Encapsulation 4.4. IP Protocol Identifier As described in Section 4.1, IP encapsulated GMA PDUs are indicated using the IP Protocol Type 114. This is designated and recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No reference is given in the IANA registry for the definition of this Protocol Type, and IANA has no record of why the assignment was made or how it is used, although it was probably assigned before 1999 [IANA1999]. There is some risk associated with "re-using" Protocol Type 114 because there may be implementations of other protocols also using this Protocol Type. However, because the protocol described in this document is used only between adjacent devices specifically configured for this purpose, the use of Protocol Type 114 should be safe. As described in Section 1.1, one of the purposes of the experiment described in this document is to verify the safety of using this Zhu Expires April 8, 2022 [Page 11] Internet-Draft GMA Encapsulation Protocol October 2021 Protocol Type. Deployments should be aware of the risk of a clash with other uses of this Protocol Type. 5. Fragmentation GMA endpoints SHOULD be configured to support fragmentation through additional control messages [MAMS]. However, If fragmentation is not configured or supported, GMA endpoint MUST drop any IP packet (SDU) if its corresponding PDU length adding GMA header (or trailer) and other overhead (e.g., UDP tunneling) exceeds the MTU of a delivery connection. The fragmentation procedure at the convergence sublayer is similar to IP fragmentation [RFC791] in principle, but with the following two differences for less overhead: o The fragment offset field is expressed in number of fragments o The maximum number of fragments per SDU is 2^7 (=128) The Fragmentation Control (FC) field in the GMA trailer (or header) contains the following bits: o Bit #7: a More Fragment (MF) flag to indicate if the fragment is the last one (0) or not (1) o Bit #0~#6: Fragment Offset (in units of fragments) to specify the offset of a particular fragment relative to the beginning of the SDU A PDU carries a whole SDU without fragmentation if the FC field is set to all "0"s or the FC field is not present in the trailer. Otherwise, the PDU contains a fragment of the SDU. The Flow SN field in the trailer is used to distinguish the fragments of one SDU from those of another. The Fragment Offset (FO) field tells the receiver the position of a fragment in the original SDU. The More Fragment (MF) flag indicates the last fragment. To fragment a long SDU, the transmitter creates n PDUs and copies the content of the IP header fields from the long PDU into the IP header of all the PDUs. The length field in the IP header of PDU SHOULD be changed to the length of the PDU, and the protocol type SHOULD be changed to 114. The data of the long SDU is divided into n portions based on the MTU size of the delivery connection. The first portion of the data is placed in the first PDU. The MF flag is set to "1", and the FO field is set to "0". The i-th portion of the data is placed in the Zhu Expires April 8, 2022 [Page 12] Internet-Draft GMA Encapsulation Protocol October 2021 i-th PDU. The MF flag is set to "0" if it is the last fragment and set to "1" otherwise. The FO field is set to i-1. To assemble the fragments of a SDU, the receiver combines PDUs that all have the same Flow SN. The combination is done by placing the data portion of each fragment in the relative order indicated by the Fragment Offset in that fragment's GMA trailer (or header). The first fragment will have the Fragment Offset set to "0", and the last fragment will have the More-Fragments flag set to "0". GMA fragmentation operates above the IP layer of individual access connection (Wi-Fi, LTE) and between the two end points of convergence layer. The convergence layer end points (client, multi-access gateway) SHOULD obtain the MTU of individual connection through either manual configuration or implementing PMTUD as suggested in [RFC8900]. 6. Concatenation The convergence sublayer MAY support concatenation if a delivery connection has a larger maximum transmission unit (MTU) than the original IP packet (SDU). Only the SDUs with the same client IP address, and the same Flow ID MAY be concatenated. 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. +-----------------------------------------------------------+ |IP hdr| IP payload |IP hdr| IP payload | GMA Trailer | +-----------------------------------------------------------+ Figure 8: Example of GMA PDU Format with Concatenation and Trailer-based IP Encapsulation To concatenate two or more SDUs, the transmitter creates one PDU and copies the content of the IP header field from the first SDU into the IP header of the PDU. The data of the first SDU is placed in the first portion of the data of the PDU. The whole second SDU is then placed in the second portion of the data of the PDU (Figure 8). The procedure continues till the PDU size reaches the MTU of the delivery connection. If the FSL field is present, the IP length field of the PDU SHOULD be updated to include all concatenated SDUs and the trailer (or header), and the IP checksum field SHOULD be recalculated if the packet is IPv4. Zhu Expires April 8, 2022 [Page 13] Internet-Draft GMA Encapsulation Protocol October 2021 To disaggregate a PDU, if the (header or trailer based) IP encapsulation method is used, the receiver first obtains the length of the first SDU from the FSL field and decodes the first SDU. The receiver then obtains the length of the second SDU based on the length field in the second SDU IP header and decodes the second SDU. The procedure continues till no byte is left in the PDU. If the non-IP encapsulation method (Figure 7) is used, the IP header of the first SDU will not change during the encapsulation process, and the receiver SHOULD obtain the length of the first SDU directly from its IP header (Figure 9). |<-------1st GMA SDU------------ +---------------------------------------------------------------+ | IP hdr | UDP hdr | GMA Header | IP hdr | IP payload | +---------------------------------------------------------------+ | IP hdr | IP payload | +-------------------------------------------+ -------->|<-------2nd GMA SDU---------------> Figure 9: Example of GMA PDU Format with Concatenation and Header- based Non-IP (UDP) Encapsulation If a PDU contains multiple SDUs, the Flow SN field is for the last SDU, and the Flow SN of other SDU carried by the same PDU can be obtained according to its order in the PDU. For example, if the SN field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, and 6 for the first, second, and last SDU respectively. GMA concatenation can be used for packing small packets of a single application, e.g., TCP ACKs, or from multiple applications. Notice that a single GMA flow may carry multiple application flows (TCP, UDP, etc.). GMA endpoint MUST NOT perform concatenation and fragmentation in a single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT carry any other (fragmented or whole) SDU. 7. Security Considerations Security in a network using GMA should be relatively similar to security in a normal IP network. GMA is unaware of IP or higher layer end-to-end security as it carries the IP packets as opaque payload. Deployers are encouraged to not consider that GMA adds any form of security and to continue to use IP or higher layer security as well as link-layer security. Zhu Expires April 8, 2022 [Page 14] Internet-Draft GMA Encapsulation Protocol October 2021 The GMA protocol at the convergence sublayer is a 0-hop protocol and relies on the security of the underlying network transport paths. When this cannot be assumed, appropriate security protocols (IPsec, DTLS, etc.) SHOULD be configured at the adaptation sublayer. On the other hand, packet filtering requires either that a firewall looks inside the GMA packet or that the filtering is done on the GMA endpoints. In those environments in which this is considered to be a security issue it may be desirable to terminate the GMA operation at the firewall. Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on preventing the leak of the local-only GMA PDUs outside the "local domain" to the Internet or to another domain which could use the same IP protocol type, i.e. 114. 8. IANA Considerations This document makes no requests of IANA 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174 May 2017, . [GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", . 9.2. Informative References [MAMS] S. Kanugovi, F. Baboescu, J. Zhu, and S. Seo "Multi-Access Management Services (MAMS)https://tools.ietf.org/rfc/rfc8743.txt [IANA] https://www.iana.org/assignments/protocol- numbers/protocol-numbers.xhtml [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP) encapsulation; Protocol specification" Zhu Expires April 8, 2022 [Page 15] Internet-Draft GMA Encapsulation Protocol October 2021 [RFC791] Internet Protocol, September 1981 [ATSSS] 3GPP TR 23.793, Study on access traffic steering, switch and splitting support in the 5G system architecture. [GRE2] RFC 8157, Huawei's GRE Tunnel Bonding Protocol, May 2017 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, . [IANA1999]https://web.archive.org/web/19990203044112/http://www.is i.edu:80/in-notes/iana/assignments/protocol-numbers Authors' Addresses Jing Zhu Intel Email: jing.z.zhu@intel.com Satish Kanugovi Nokia Email: satish.k@nokia.com Zhu Expires April 8, 2022 [Page 16]