< draft-ietf-lwig-6lowpan-virtual-reassembly-00.txt   draft-ietf-lwig-6lowpan-virtual-reassembly-01.txt >
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational T. Watteyne Intended status: Informational T. Watteyne
Expires: January 3, 2019 Analog Devices Expires: September 12, 2019 Analog Devices
July 02, 2018 March 11, 2019
Virtual reassembly buffers in 6LoWPAN Virtual reassembly buffers in 6LoWPAN
draft-ietf-lwig-6lowpan-virtual-reassembly-00 draft-ietf-lwig-6lowpan-virtual-reassembly-01
Abstract Abstract
When employing adaptation layer fragmentation in 6LoWPAN, it may be When employing adaptation layer fragmentation in 6LoWPAN, it may be
beneficial for a forwarder not to have to reassemble each packet in beneficial for a forwarder not to have to reassemble each packet in
its entirety before forwarding it. its entirety before forwarding it.
This has been always possible with the original fragmentation design 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 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 Section 2.5.2 of the 6LoWPAN book, this has not been extensively
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 19 skipping to change at page 4, line 19
Note that the decision to do local processing of a packet needs to be 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 taken with the first fragment - such packets of course do need to be
fully reassembled (unless transport and application also can cope fully reassembled (unless transport and application also can cope
with fragments, which they rarely can in the presence of security). with fragments, which they rarely can in the presence of security).
4. Header compression 4. Header compression
[RFC6282] defines the header compression format for 6LoWPAN. One [RFC6282] defines the header compression format for 6LoWPAN. One
important impact of header compression is that the header is no important impact of header compression is that the header is no
longer of a fixed length. In particular, changes made by a forwarder longer of a length that stays fixed during forwarding. In
may gain or lose the ability to use a more highly compressed variant, particular, changes made by a forwarder may gain or lose the ability
changing the length of the header in the packet. If the change to use a more highly compressed variant, changing the length of the
increases the size, the maximum frame size may be exceeded, leading header in the packet. If the change increases the size, the maximum
to the need to re-fragment in the forwarder. This is less of a frame size may be exceeded, leading to the need to re-fragment in the
problem with full reassembly, but with virtual reassembly can lead to forwarder. This is less of a problem with full reassembly, but with
the need for sending an additional frame for each packet. 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 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 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 _first_ packet, making this the smallest fragment and not the last
one as would be done in a naive implementation. (This also has other one as would be done in a naive implementation. (This also has other
consequences related to delivery probability, which are not discussed consequences related to delivery probability, which are not discussed
here.) This makes sure an additional fragment only needs to be sent here.) This makes sure an additional fragment only needs to be sent
if the header expansion during forwarding would have created an if the header expansion during forwarding would have created an
additional fragment with full reassembly as well. additional fragment with full reassembly as well.
skipping to change at page 5, line 13 skipping to change at page 5, line 13
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
7.2. Informative References 7.2. Informative References
[BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons, [BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons,
Ltd monograph, DOI 10.1002/9780470686218, November 2009. Ltd monograph, DOI 10.1002/9780470686218, November 2009.
[I-D.watteyne-6lo-minimal-fragment] [I-D.watteyne-6lo-minimal-fragment]
Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal
Fragment Forwarding", draft-watteyne-6lo-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 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
 End of changes. 6 change blocks. 
13 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/