idnits 2.17.1 draft-bormann-lwig-6lowpan-virtual-reassembly-00.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 -- The document date (January 25, 2018) is 2283 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational January 25, 2018 5 Expires: July 29, 2018 7 Virtual reassembly buffers in 6LoWPAN 8 draft-bormann-lwig-6lowpan-virtual-reassembly-00 10 Abstract 12 When employing adaptation layer fragmentation in 6LoWPAN, it may be 13 beneficial for a forwarder not to have to reassemble each packet in 14 its entirety before forwarding it. 16 This has been always possible with the original fragmentation design 17 of RFC 4944. Apart from a brief mention of the way to do this in 18 Section 2.5.2 of the 6LoWPAN book, this has not been extensively 19 described in the literature. The present document attempts to fill 20 that gap. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 29, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Reassembly buffers . . . . . . . . . . . . . . . . . . . . . 2 58 3. Virtual reassembly . . . . . . . . . . . . . . . . . . . . . 3 59 4. Header compression . . . . . . . . . . . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security considerations . . . . . . . . . . . . . . . . . . . 4 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 7.2. Informative References . . . . . . . . . . . . . . . . . 4 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 (TO DO: Insert an extended form of the abstract first here, expanding 71 the references to [RFC4944] and [BOOK] in the process.) 73 2. Reassembly buffers 75 An adaptation layer implementation for 6LoWPAN needs to perform 76 reassembly of every fragmented packet received in order to be able to 77 forward the packet (re-fragmenting it in the process). 79 A reassembly buffer for 6LoWPAN contains: 81 o datagram_size, 83 o datagram_tag and L2 sender and receiver addresses (to which the 84 datagram_tag is local), 86 o actual packet data from the fragments received so far, in a form 87 that makes it possible to detect when the whole packet has been 88 received and can be processed or forwarded, 90 o a timer that allows discarding the partial packet after a timeout. 92 This requires a reassembly buffer for each fragmented packet the 93 reception of which is in progress. Since the forwarder may be 94 receiving fragments for multiple packets concurrently (e.g., from 95 different senders), this means that multiple reassembly buffers are 96 needed, easily dominating the memory requirements in a 6LoWPAN 97 implementation. Worse, as this space may still be limited, any lack 98 of reassembly buffers may lead to an increased loss rate for 99 fragmented packets (which already have to cope with a higher compound 100 loss rate). 102 3. Virtual reassembly 104 To reduce the memory requirement for reassembly buffers, the 105 implementation may opt to not keep the actual packet data in the 106 reassembly buffer. Instead, it may attempt to send out the data for 107 a fragment in the form of a forwarded fragment, as soon as all 108 necessary information for that is available. Obviously, all 109 fragments need to be sent with the same outgoing address (otherwise a 110 full reassembly implementation would discard the fragments) and the 111 same datagram_tag. 113 To this end, the reassembly buffer now also stores, as soon as enough 114 of the packet is available to make a forwarding decision (i.e., as 115 soon as the first fragment has been received): 117 o L2 destination address used for forwarding, 119 o outgoing datagram_tag chosen for this packet. 121 A simple implementation may do away with any attempt to keep packet 122 data in the virtual reassembly buffer. It then has to discard all 123 non-first fragments for which a reassembly buffer is not already 124 available (penalizing reordering, which however may be rare). 126 Note that the decision to do local processing of a packet needs to be 127 taken with the first fragment - such packets of course do need to be 128 fully reassembled (unless transport and application also can cope 129 with fragments, which they rarely can in the presence of security). 131 4. Header compression 133 [RFC6282] defines the header compression format for 6LoWPAN. One 134 important impact of header compression is that the header is no 135 longer of a fixed length. In particular, changes made by a forwarder 136 may gain or lose the ability to use a more highly compressed variant, 137 changing the length of the header in the packet. If the change 138 increases the size, the maximum frame size may be exceeded, leading 139 to the need to re-fragment in the forwarder. This is less of a 140 problem with full reassembly, but with virtual reassembly can lead to 141 the need for sending an additional frame for each packet. 143 The well-known approach to minimize the probability of this need is 144 for the original sender to put all slack in the frame sizes into the 145 _first_ packet, making this the smallest fragment and not the last 146 one as would be done in a naive implementation. (This also has other 147 consequences related to delivery probability, which are not discussed 148 here.) This makes sure an additional fragment only needs to be sent 149 if the header expansion during forwarding would have created an 150 additional fragment with full reassembly as well. 152 5. IANA Considerations 154 This document makes no requests of IANA. 156 6. Security considerations 158 TBD 160 7. References 162 7.1. Normative References 164 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 165 "Transmission of IPv6 Packets over IEEE 802.15.4 166 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 167 . 169 7.2. Informative References 171 [BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons, 172 Ltd monograph, DOI 10.1002/9780470686218, November 2009. 174 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 175 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 176 DOI 10.17487/RFC6282, September 2011, 177 . 179 Acknowledgements 181 Many people have mentioned that it would be good to have a 182 description of virtual reassembly in 6LoWPAN. Finally, Thomas 183 Watteyne assembled a design team that intends to work on 6Lo 184 fragmentation. Writing up the present document has been motivated by 185 that work. 187 Author's Address 188 Carsten Bormann 189 Universitaet Bremen TZI 190 Postfach 330440 191 Bremen D-28359 192 Germany 194 Phone: +49-421-218-63921 195 Email: cabo@tzi.org