--- 1/draft-ietf-lwig-6lowpan-virtual-reassembly-00.txt 2019-03-11 14:15:46.055216392 -0700 +++ 2/draft-ietf-lwig-6lowpan-virtual-reassembly-01.txt 2019-03-11 14:15:46.071216784 -0700 @@ -1,19 +1,19 @@ Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Informational T. Watteyne -Expires: January 3, 2019 Analog Devices - July 02, 2018 +Expires: September 12, 2019 Analog Devices + March 11, 2019 Virtual reassembly buffers in 6LoWPAN - draft-ietf-lwig-6lowpan-virtual-reassembly-00 + draft-ietf-lwig-6lowpan-virtual-reassembly-01 Abstract When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it. This has been always possible with the original fragmentation design of RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively @@ -28,25 +28,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on January 3, 2019. + This Internet-Draft will expire on September 12, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 (https://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 @@ -149,27 +149,28 @@ Note that the decision to do local processing of a packet needs to be taken with the first fragment - such packets of course do need to be fully reassembled (unless transport and application also can cope with fragments, which they rarely can in the presence of security). 4. Header compression [RFC6282] defines the header compression format for 6LoWPAN. One important impact of header compression is that the header is no - longer of a fixed length. In particular, changes made by a forwarder - may gain or lose the ability to use a more highly compressed variant, - changing the length of the header in the packet. If the change - increases the size, the maximum frame size may be exceeded, leading - to the need to re-fragment in the forwarder. This is less of a - problem with full reassembly, but with virtual reassembly can lead to - the need for sending an additional frame for each packet. + longer of a length that stays fixed during forwarding. In + particular, changes made by a forwarder may gain or lose the ability + to use a more highly compressed variant, changing the length of the + header in the packet. If the change increases the size, the maximum + frame size may be exceeded, leading to the need to re-fragment in the + forwarder. This is less of a problem with full reassembly, but with + virtual reassembly can lead to the need for sending an additional + frame for each packet. The well-known approach to minimize the probability of this need is for the original sender to put all slack in the frame sizes into the _first_ packet, making this the smallest fragment and not the last one as would be done in a naive implementation. (This also has other consequences related to delivery probability, which are not discussed here.) This makes sure an additional fragment only needs to be sent if the header expansion during forwarding would have created an additional fragment with full reassembly as well. @@ -191,21 +192,21 @@ . 7.2. Informative References [BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons, Ltd monograph, DOI 10.1002/9780470686218, November 2009. [I-D.watteyne-6lo-minimal-fragment] Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal Fragment Forwarding", draft-watteyne-6lo-minimal- - fragment-01 (work in progress), March 2018. + fragment-02 (work in progress), July 2018. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, .