idnits 2.17.00 (12 Aug 2021) /tmp/idnits53628/draft-thubert-6lowpan-simple-fragment-recovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 18, 2008) is 5177 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-tsvwg-udp-guidelines has been published as RFC 5405 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track March 18, 2008 5 Expires: September 19, 2008 7 LoWPAN simple fragment Recovery 8 draft-thubert-6lowpan-simple-fragment-recovery-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 Considering that 6LoWPAN packets can be as large as 2K bytes and that 42 an 802.15.4 frame with security will carry in the order of 80 bytes 43 of effective payload, a packet might end up fragmented into as many 44 as 25 fragments at the 6LoWPAN shim layer. If a single one of those 45 fragments is lost in transmission, all fragments must be resent, 46 further contributing to the congestion that might have caused the 47 initial packet loss. This draft introduces a simple protocol to 48 recover individual fragments between 6LoWPAN endpoints. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7 58 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7 59 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 Considering that 6LoWPAN packets can be as large as 2K bytes and that 72 a 802.15.4 frame with security will carry in the order of 80 bytes of 73 effective payload, a packet might be fragmented into about 25 74 fragments at the 6LoWPAN shim layer. This level of fragmentation is 75 much higher than that traditionally experienced over the Internet 76 with IPv4 fragments. At the same time, the use of radios increases 77 the probability of transmission loss and Mesh-Under techniques 78 compound that risk over multiple hops. 80 Past experience with fragmentation has shown that missassociated or 81 lost fragments can lead to poor network behaviour and, eventually, 82 trouble at application layer. The reader might start his research 83 from [I-D.mathis-frag-harmful] and follow the references. That 84 experience led to the definition of the Path MTU discovery [RFC1191] 85 protocol that avoids fragmentation over the Internet. 87 An end-to-end fragment recovery mechanism might be a good complement 88 to a hop-by-hop MAC level recovery with a limited number of retries. 89 This draft introduces a simple protocol to recover individual 90 fragments between 6LoWPAN endpoints. Specifically in the case of 91 UDP, valuable additional information can be found in UDP Usage 92 Guidelines for Application Designers [I-D.ietf-tsvwg-udp-guidelines]. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 Readers are expected to be familiar with all the terms and concepts 101 that are discussed in "IPv6 over Low-Power Wireless Personal Area 102 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 103 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 104 Networks" [RFC4944]. 106 ERP 108 Error Recovery Procedure. 110 LoWPAN endpoints 112 The LoWPAN nodes in charge of generating or expanding a 6LoWPAN 113 header from/to a full IPv6 packet. The LoWPAN endpoints are the 114 points where fragmentation and reassembly take place. 116 3. Rationale 118 There are a number of usages for large packets in Wireless Sensor 119 Networks. Such usages may not be the most typical or represent the 120 largest amount of traffic over the LoWPAN; however, the associated 121 functionality can be critical enough to justify extra care for 122 ensuring effective transport of large packets across the LoWPAN. 124 The list of those usages includes: 126 Towards the LoWPAN node: 128 Packages of Commands: A number of commands or a full 129 configuration can by packaged as a single message to ensure 130 consistency and enable atomic execution or complete roll back. 131 Until such commands are fully received and interpreted, the 132 intended operation will not take effect. 134 Firmware update: For example, a new version of the LoWPAN node 135 software is downloaded from a system manager over unicast or 136 multicast services. Such a reflashing operation typically 137 involves updating a large number of similar 6LoWPAN nodes over 138 a relatively short period of time. 140 From the LoWPAN node: 142 Waveform captures: A number of consecutive samples are measured 143 at a high rate for a short time and then transferred from a 144 sensor to a gateway or an edge server as a single large report. 146 Large data packets: Rich data types might require more than one 147 fragment. 149 Uncontrolled firmware download or waveform upload can easily result 150 in a massive increase of the traffic and saturate the network. 152 When a fragment is lost in transmission, all fragments are resent, 153 further contributing to the congestion that caused the initial loss, 154 and potentially leading to congestion collapse. 156 This saturation may lead to excessive radio interference, or random 157 early discard (leaky bucket) in relaying nodes. Additional queueing 158 and memory congestion may result while waiting for a low power next 159 hop to emerge from its sleeping state. 161 4. Requirements 163 This paper proposes a method to recover individual fragments between 164 LoWPAN endpoints. The method is designed to fit the following 165 requirements of a LoWPAN (with or without a Mesh-Under routing 166 protocol): 168 Number of fragments 170 The recovery mechanism must support highly fragmented packets, 171 with a maximum of 32 fragments per packet. 173 Minimimum acknowledgement overhead 175 Because the radio is half duplex, and because of silent time spent 176 in the various medium access mechanisms, an acknowledgement 177 consumes roughly as many resources as data fragment. 179 The recovery mechanism should be able to acknowledge multiple 180 fragments in a single message. 182 Controlled latency 184 The recovery mechanism must succeed or give up within the time 185 boundary imposed by the recovery process of the Upper Layer 186 Protocols. 188 Support for out-of-order fragment delivery 190 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 191 Layer can introduce out-of-sequence packets. The recovery 192 mechanism must account for packets that appear lost but are 193 actually only delayed over a different path. 195 Optional flow control 197 The aggregation of multiple concurrent flows may lead to the 198 saturation of the radio network and congestion collapse. 200 The recovery mechanism should provide means for controlling the 201 number of fragments in transit over the LoWPAN. 203 Backward compatibility 205 A node that implements this draft should be able to communicate 206 with a node that implements [RFC4944]. This draft assumes that 207 compatibility information about the remote LoWPAN endpoint is 208 obtained by external means. 210 5. Overview 212 The fragmentation/reassembly of a packet must complete within an 213 acceptable overall latency, otherwise the packet expires and must be 214 dropped. This latency must be smaller than Upper Layer Protocol 215 retry values, and smaller than expiration period of the information 216 transported. 218 The sender transfers a controlled number of fragments (possibly all 219 of them) and flags the last fragment of a series with an 220 Acknowledgement request. 222 The sender sets a retry timer for the fragment that carries the 223 Acknowledgement request. That fragment is retransmitted individually 224 upon time out. This is repeated until an Acknowledgement comes back 225 or the packet expires. 227 Upon receipt of an Acknowledgement request, the receiver responds 228 with an Acknowledgement containing a bitmap that indicates which 229 fragments were actually received. The bitmap is a 32bit DWORD, which 230 accommodates up to 32 fragments and is sufficient for the 6LoWPAN 231 MTU. For all n in [0..31], bit n is set to 1 in the bitmap to 232 indicate that fragment n was received, otherwise the bit is set to 0. 234 If any fragment immmediately preceding the acknowledgement request is 235 missing, the receiver MAY intentionally delay its response to allow 236 in-transit fragments to arrive. 238 The sender has either one or no Acknowledgement pending. An 239 Acknowledgement that is not expected or does not acknowledge the 240 pending sequence in the bitmap is a duplicate and is ignored. 242 When a valid Acknowledgement is received, the sender resumes sending 243 fragments and the process is repeated until all fragments are 244 acknowledged or the packet expires. 246 Fragments are sent in a round robin fashion: the sender sends all the 247 fragments for a first time before it retries any lost fragment; lost 248 fragments are retried in sequence, oldest first. This mechanism 249 enables the receiver to acknowledge fragments that were delayed in 250 the network before they are actually retried. 252 It is up to the sender to decide how many fragments are (re)sent 253 before an acknowledgement is received, and the sender can adapt that 254 number to the network conditions. This way, the number of 255 outstanding fragments can be used as a flow control mechanism to 256 protect the network. 258 6. New Dispatch types and headers 260 This specification extends "Transmission of IPv6 Packets over IEEE 261 802.15.4 Networks" [RFC4944] with 3 new dispatch types, for 262 Recoverable Fragments (RFRAG) headers with or without Acknowledgement 263 Request, and for the Acknowledgement back. 265 Pattern Header Type 266 +------------+-----------------------------------------------+ 267 | 11 101000 | RFRAG - Recoverable Fragment | 268 | 11 101001 | RFRAG-AR - RFRAG with Acknowledgement Req | 269 | 11 101010 | RFRAG-ACK - RFRAG Acknowledgement | 270 +------------+-----------------------------------------------+ 272 Figure 1: Additional Dispatch Value Bit Patterns 274 In the following sections, the semantics of "datagram_tag," 275 "datagram_offset" and "datagram_size" and the reassembly process are 276 unchanged from [RFC4944] Section 5.3. "Fragmentation Type and 277 Header." 279 6.1. Recoverable Fragment Dispatch type and Header 281 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |Sequence | datagram_size | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X set == Ack Requested 289 Figure 2: Recoverable Fragment Dispatch type and Header 291 X bit 293 When set, the sender requires an Acknowledgement from the receiver 295 Sequence 297 The sequence number of the fragment. Fragments are numbered 298 [0..N] where N is in [0..31]. 300 6.2. Fragment Acknowledgement Dispatch type and Header 302 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |1 1 1 0 1 0 1 0| datagram_tag | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Acknowledgement Bitmap | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+ 309 ^ ^ 310 | | bitmap indicating whether 311 | +-----Fragment with sequence 10 was received 312 +-------------------------Fragment with sequence 00 was received 314 Figure 3: Fragment Acknowledgement Dispatch type and Header 316 Acknowledgement Bitmap 318 Each bit in the Bitmap refers to a particular fragment: bit n set 319 indicates that fragment with sequence n was received, for n in 320 [0..31]. 322 All zeroes means that the fragment was dropped because it 323 corresponds to an obsolete datagram_tag. This happens if the 324 packet was already reassembled and passed to the network upper 325 layer, or the packet expired and was dropped. 327 7. Security Considerations 329 The process of recovering fragments does not appear to create any 330 opening for new threat. 332 8. IANA Considerations 334 Need extensions for formats defined in "Transmission of IPv6 Packets 335 over IEEE 802.15.4 Networks" [RFC4944]. 337 9. Acknowledgments 339 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 340 Kolavennu and Harry Courtice for their contribution and review. 342 10. References 343 10.1. Normative References 345 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 346 November 1990. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 352 "Transmission of IPv6 Packets over IEEE 802.15.4 353 Networks", RFC 4944, September 2007. 355 10.2. Informative References 357 [I-D.ietf-tsvwg-udp-guidelines] 358 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 359 Application Designers", draft-ietf-tsvwg-udp-guidelines-05 360 (work in progress), February 2008. 362 [I-D.mathis-frag-harmful] 363 Mathis, M., "Fragmentation Considered Very Harmful", 364 draft-mathis-frag-harmful-00 (work in progress), 365 July 2004. 367 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 368 over Low-Power Wireless Personal Area Networks (6LoWPANs): 369 Overview, Assumptions, Problem Statement, and Goals", 370 RFC 4919, August 2007. 372 Author's Address 374 Pascal Thubert 375 Cisco Systems 376 Village d'Entreprises Green Side 377 400, Avenue de Roumanille 378 Batiment T3 379 Biot - Sophia Antipolis 06410 380 FRANCE 382 Phone: +33 4 97 23 26 34 383 Email: pthubert@cisco.com 385 Full Copyright Statement 387 Copyright (C) The IETF Trust (2008). 389 This document is subject to the rights, licenses and restrictions 390 contained in BCP 78, and except as set forth therein, the authors 391 retain all their rights. 393 This document and the information contained herein are provided on an 394 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 395 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 396 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 397 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 398 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 399 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 401 Intellectual Property 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Acknowledgment 427 Funding for the RFC Editor function is provided by the IETF 428 Administrative Support Activity (IASA).