%% You should probably cite rfc9188 instead of this I-D. @techreport{zhu-intarea-gma-02, number = {draft-zhu-intarea-gma-02}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-zhu-intarea-gma/02/}, author = {Jing Zhu and Satish Kanugovi}, title = {{Generic Multi-Access (GMA) Convergence Encapsulation Protocols}}, pagetotal = 9, year = , month = , day = , abstract = {Today, a device can be simultaneously connected to multiple communication networks based on different technology implementations and network architectures like WiFi, LTE, 5G, and DSL. In such scenario, it is desirable to combine multiple access networks to improve quality of experience. For example, an IP flow may be delivered over both LTE and Wi-Fi network for higher end-to-end throughput. In another example, lost packets may be retransmitted when the device switches from Wi-Fi to LTE. However, such multi- access optimization requires inserting additional control information, e.g. Sequence Number, into each IP packet. Unfortunately, there is no existing IP protocol for such purpose. As a result, IP-over-IP tunneling has been used in today's solutions, e.g. {[}LWIPEP{]} {[}GRE{]}, to insert the GRE header, and then encode additional control information in the GRE header fields, e.g. Key, Sequence Number. However, there are two main drawbacks with this approach: 1) IP-over-IP tunneling leads to higher overhead especially for small packet. For example, the overhead of IP-over- IP/GRE tunneling with both Key and Sequence Number is 32 Bytes, which is 80\% of a 40 Bytes TCP ACK packet; 2) It is difficult to introduce new control fields using the existing GRE header format. This document presents a new light-weight and flexible encapsulation protocol to support multi-access solutions {[}ATSSS{]} {[}MAMS{]} {[}LWIPEP{]} without IP-over-IP tunneling.}, }