idnits 2.17.00 (12 Aug 2021) /tmp/idnits54990/draft-thubert-6lowpan-simple-fragment-recovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (June 30, 2009) is 4708 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) == Unused Reference: 'I-D.mathis-frag-harmful' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC2309' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC2581' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC2914' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 564, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: draft-ietf-tsvwg-udp-guidelines has been published as RFC 5405 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Hui 5 Expires: January 1, 2010 Arch Rock Corporation 6 June 30, 2009 8 LoWPAN simple fragment Recovery 9 draft-thubert-6lowpan-simple-fragment-recovery-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 1, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Considering that the IPv6 minimum MTU is 1280 bytes and that an an 48 802.15.4 frame can have a payload limited to 74 bytes in the worst 49 case, a packet might end up fragmented into as many as 18 fragments 50 at the 6LoWPAN shim layer. If a single one of those fragments is 51 lost in transmission, all fragments must be resent, further 52 contributing to the congestion that might have caused the initial 53 packet loss. This draft introduces a simple protocol to recover 54 individual fragments that might be lost over multiple hops between 55 6LoWPAN endpoints. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7 65 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 8 66 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 67 7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 In many 6LoWPAN applications, the majority of traffic is spent 79 sending small chunks of data (order few bytes to few tens of bytes) 80 per packet. Given that an 802.15.4 frame can carry 74 bytes or more 81 in all cases, fragmentation is often not needed for most application 82 traffic. However, many applications also require occasional bulk 83 data transfer capabilities to support firmware upgrades of 6LoWPAN 84 devices or extraction of logs from 6LoWPAN devices. In the former 85 case, bulk data is transferred to the 6LoWPAN device, and in the 86 latter, bulk data flows away from the 6LoWPAN device. In both cases, 87 the bulk data size is often on the order of 10K bytes or more and 88 end-to-end reliable transport is required. 90 Mechanisms such as TCP or application-layer segmentation will be used 91 to support end-to-end reliable transport. One option to support bulk 92 data transfer over 6LoWPAN links is to set the Maximum Segment Size 93 to fit within the 802.15.4 MTU. Doing so, however, can add 94 significant header overhead to each 802.15.4 frame. This causes the 95 end-to-end transport to be aware of the delivery properties of 96 6LoWPAN networks, which is a layer violation. 98 An alternative mechanism combines the use of 6LoWPAN fragmentation in 99 addition to transport or application-layer segmentation. Increasing 100 the Maximum Segment Size reduces header overhead by the end-to-end 101 transport protocol. It also encourages the transport protocol to 102 reduce the number of outstanding datagrams, ideally to a single 103 datagram, thus reducing the need to support out-of-order delivery 104 common to 6LoWPAN networks. 106 [RFC4944] defines a datagram fragmentation mechanism for 6LoWPAN 107 networks. However, because [RFC4944] does not define a mechanism for 108 recovering fragments that are lost, datagram forwarding fails if even 109 one fragment is not delivered properly to the next IP hop. End-to- 110 end transport mechanisms will require retransmission of all 111 fragments, wasting resources in an already resource-constrained 112 network. 114 Past experience with fragmentation has shown that missassociated or 115 lost fragments can lead to poor network behavior and, eventually, 116 trouble at application layer. The reader is encouraged to read 117 [RFC4963] and follow the references for more information. That 118 experience led to the definition of the Path MTU discovery [RFC1191] 119 protocol that limits fragmentation over the Internet. 121 For one-hop communications, a number of media propose a local 122 acknowledgement mechanism that is enough to protect the fragments. 123 In a multihop environment, an end-to-end fragment recovery mechanism 124 might be a good complement to a hop-by-hop MAC level recovery. This 125 draft introduces a simple protocol to recover individual fragments 126 between 6LoWPAN endpoints. Specifically in the case of UDP, valuable 127 additional information can be found in UDP Usage Guidelines for 128 Application Designers [I-D.ietf-tsvwg-udp-guidelines]. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 Readers are expected to be familiar with all the terms and concepts 137 that are discussed in "IPv6 over Low-Power Wireless Personal Area 138 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 139 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 140 Networks" [RFC4944]. 142 ERP 144 Error Recovery Procedure. 146 LoWPAN endpoints 148 The LoWPAN nodes in charge of generating or expanding a 6LoWPAN 149 header from/to a full IPv6 packet. The LoWPAN endpoints are the 150 points where fragmentation and reassembly take place. 152 3. Rationale 154 There are a number of uses for large packets in Wireless Sensor 155 Networks. Such usages may not be the most typical or represent the 156 largest amount of traffic over the LoWPAN; however, the associated 157 functionality can be critical enough to justify extra care for 158 ensuring effective transport of large packets across the LoWPAN. 160 The list of those usages includes: 162 Towards the LoWPAN node: 164 Packages of Commands: A number of commands or a full 165 configuration can by packaged as a single message to ensure 166 consistency and enable atomic execution or complete roll back. 167 Until such commands are fully received and interpreted, the 168 intended operation will not take effect. 170 Firmware update: For example, a new version of the LoWPAN node 171 software is downloaded from a system manager over unicast or 172 multicast services. Such a reflashing operation typically 173 involves updating a large number of similar 6LoWPAN nodes over 174 a relatively short period of time. 176 From the LoWPAN node: 178 Waveform captures: A number of consecutive samples are measured 179 at a high rate for a short time and then transferred from a 180 sensor to a gateway or an edge server as a single large report. 182 Data logs: 6LoWPAN nodes may generate large logs of sampled data 183 for later extraction. 6LoWPAN nodes may also generate system 184 logs to assist in diagnosing problems on the node or network. 186 Large data packets: Rich data types might require more than one 187 fragment. 189 Uncontrolled firmware download or waveform upload can easily result 190 in a massive increase of the traffic and saturate the network. 192 When a fragment is lost in transmission, all fragments are resent, 193 further contributing to the congestion that caused the initial loss, 194 and potentially leading to congestion collapse. 196 This saturation may lead to excessive radio interference, or random 197 early discard (leaky bucket) in relaying nodes. Additional queuing 198 and memory congestion may result while waiting for a low power next 199 hop to emerge from its sleeping state. 201 To demonstrate the severity of the problem, consider a fairly 202 reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4 203 hop. The expected delivery rate of a 5-fragment datagram would be 204 about 99.5% over a single 802.15.4 hop. However, the expected 205 delivery rate would drop to 95.1% over 10 hops, a reasonable network 206 diameter for 6LoWPAN applications. The expected delivery rate for a 207 1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops. 209 Considering that the IPv6 minimum MTU is 1280 bytes and that a 210 802.15.4 frame can limit the MAC payload to as little as 74 bytes, a 211 packet might be fragmented into at least 18 fragments at the 6LoWPAM 212 shim layer. Taking into account the worst-case header overhead for 213 6LoWPAN Fragmentation and Mesh Addressing headers will increase the 214 number of required fragments to around 32. This level of 215 fragmentation is much higher than that traditionally experienced over 216 the Internet with IPv4 fragments. At the same time, the use of 217 radios increases the probability of transmission loss and Mesh-Under 218 techniques compound that risk over multiple hops. 220 4. Requirements 222 This paper proposes a method to recover individual fragments between 223 LoWPAN endpoints. The method is designed to fit the following 224 requirements of a LoWPAN (with or without a Mesh-Under routing 225 protocol): 227 Number of fragments 229 The recovery mechanism must support highly fragmented packets, 230 with a maximum of 32 fragments per packet. 232 Minimum acknowledgement overhead 234 Because the radio is half duplex, and because of silent time spent 235 in the various medium access mechanisms, an acknowledgment 236 consumes roughly as many resources as data fragment. 238 The recovery mechanism should be able to acknowledge multiple 239 fragments in a single message and not require an acknowledgement 240 at all if fragments are already protected at a lower layer. 242 Controlled latency 244 The recovery mechanism must succeed or give up within the time 245 boundary imposed by the recovery process of the Upper Layer 246 Protocols. 248 Support for out-of-order fragment delivery 250 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 251 Layer can introduce out-of-sequence packets. 253 The recovery mechanism must account for packets that appear lost 254 but are actually only delayed over a different path. 256 Optional congestion control 258 The aggregation of multiple concurrent flows may lead to the 259 saturation of the radio network and congestion collapse. 261 The recovery mechanism should provide means for controlling the 262 number of fragments in transit over the LoWPAN. 264 5. Overview 266 Considering that a multi-hop LoWPAN can be a very sensitive 267 environment due to the limited queuing capabilities of a large 268 population of its nodes, this draft recommends a simple and 269 conservative approach to congestion control, based on TCP congestion 270 avoidance. 272 From the standpoint of a source LoWPAN endpoint, an outstanding 273 fragment is a fragment that was sent but for which no explicit 274 acknowledgment was received yet. This means that the fragment might 275 be on the way, received but not yet acknowledged, or the 276 acknowledgment might be on the way back. It is also possible that 277 either the fragment or the acknowledgment was lost on the way. 279 Because a meshed LoWPAN might deliver frames out of order, it is 280 virtually impossible to differentiate these situations. In other 281 words, from the sender standpoint, all outstanding fragments might 282 still be in the network and contribute to its congestion. There is 283 an assumption, though, that after a certain amount of time, a frame 284 is either received or lost, so it is not causing congestion anymore. 285 This amount of time can be estimated based on the round trip delay 286 between the LoWPAN endpoints. The method detailed in [RFC2988] is 287 recommended for that computation. 289 6. New Dispatch types and headers 291 This specification extends "Transmission of IPv6 Packets over IEEE 292 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for 293 Recoverable Fragments (RFRAG) headers with or without Acknowledgment 294 Request, and for the Acknowledgment back. 296 Pattern Header Type 297 +------------+-----------------------------------------------+ 298 | 11 101000 | RFRAG - Recoverable Fragment | 299 | 11 101001 | RFRAG-AR - RFRAG with Ack Request | 300 | 11 10101x | RFRAG-ACK - RFRAG Acknowledgment | 301 +------------+-----------------------------------------------+ 303 Figure 1: Additional Dispatch Value Bit Patterns 305 In the following sections, the semantics of "datagram_tag," 306 "datagram_offset" and "datagram_size" and the reassembly process are 307 unchanged from [RFC4944] Section 5.3. "Fragmentation Type and 308 Header." 310 6.1. Recoverable Fragment Dispatch type and Header 312 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |Sequence | datagram_size | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 X set == Ack Requested 321 Figure 2: Recoverable Fragment Dispatch type and Header 323 X bit 325 When set, the sender requires an Acknowledgment from the receiver 327 Sequence 329 The sequence number of the fragment. Fragments are numbered 330 [0..N] where N is in [0..31]. 332 6.2. Fragment Acknowledgement Dispatch type and Header 334 The specification also defines an acknowledgement bitmap that is used 335 to carry selective acknowlegements for the received fragments. A 336 given offset in the bitmap maps one to one with a given sequence 337 number. 339 The bitmap is compressed as a variable length field formed by control 340 bits and acknowledgement bits. The leftmost bits of the compressed 341 form are control bits up to the first 0. The rest is ack bits 342 encoded right to left: 344 Pattern Size Ack 345 +--------------------------------------+----------+----------+ 346 | 0XXXXXXX | 1 octet | 1 -> 7 | 347 | 10XXXXXX XXXXXXXX | 2 octets | 1 -> 14 | 348 | 110XXXXX XXXXXXXX XXXXXXXX | 3 octets | 1 -> 21 | 349 | 1110XXXX XXXXXXXX XXXXXXXX XXXXXXXX | 4 octets | 1 -> 28 | 350 +------------+-----------------------------------------------+ 352 Figure 3: Compressed acknowledgement bitmap encoding 354 The highest sequence number to be acknowledged determines the pattern 355 to be used. The format can be extended for more fragments in the 356 future but this specification only requires the support of up to 4 357 octets encoding, which enables to acknowledge up to 28 fragments. 359 A 32 bits uncompressed bitmap is obtained by prepending zeroes to the 360 XXX in the pattern above. For instance: 362 0 1 2 3 4 5 6 7 363 +-+-+-+-+-+-+-+-+ 364 |0|1|1|0|1|1|1|1| is expanded as: 365 +-+-+-+-+-+-+-+-+ 366 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|1|0|1|1|1|1| 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 4: Expanding 1 octet encoding 374 and 375 1 2 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |1|1|0|1|1|1|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|0|1| is expanded as: 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |0|0|0|0|0|0|0|0|0|0|0|1|1|1|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|0|1| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 5: Expanding 3 octets encoding 388 whereas the 4 octets encoding is expanded by simply setting the first 389 3 bits to 0. The 32 bits uncompressed bitmap is written and read as 390 follows: 392 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Acknowledgment Bitmap | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 ^ ^ 398 bitmap indicating whether: | | 399 Fragment with sequence 10 was received --+ | 400 Fragment with sequence 00 was received ----------------------+ 402 Figure 6: Expanded bitmap encoding 404 So in the example in Figure 5 it appears that all fragments from 405 sequence 0 to 20 were received but for sequence 1, 2 and 16 that were 406 either lost or are still in the network over a slower path. 408 The compressed form of the acknowledgement bitmap is carried in a 409 Fragment Acknowledgement as follows: 411 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |1 1 1 0 1 0 1 Y| datagram_tag | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Compressed Acknowledgment Bitmap (8 to 32 bits) 417 +-+-+-+-+-+-+-+-+-+ .... 419 Figure 7: Fragment Acknowledgement Dispatch type and Header 421 Compressed Acknowledgement Bitmap 423 An encoded form of an acknowledgement bitmap. 425 7. Fragments Recovery 427 The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the 428 original fragment headers from [RFC4944] and replace them in the 429 fragmented packets. The Fragment Acknowledgement RFRAG-ACK is 430 introduced as a standalone header in message that is sent back to the 431 fragment source endpoint as known by its MAC address. This assumes 432 that the source MAC address in the fragment (is any) and datagram_tag 433 are enough information to send the Fragment Acknowledgement back to 434 the source fragmentation endpoint. 436 The node that fragments the packets at 6LoWPAN level (the sender) 437 controls the Fragment Acknowledgements. If may do that at any 438 fragment to implement its own policy or perform congestion control 439 which is out of scope for this document. When the sender of the 440 fragment knows that an underlying mechanism protects the Fragments 441 already it MAY refrain from using the Acknowledgement mechanism, and 442 never set the Ack Requested bit. The node that recomposes the 443 packets at 6LoWPAN level (the receiver) MUST acknowledge the 444 fragments it has received when asked to, and MAY slightly defer that 445 acknowledgement. 447 The sender transfers a controlled number of fragments and MAY flag 448 the last fragment of a series with an acknowledgment request. The 449 received MUST acknowledge a fragment with the acknowledgment request 450 bit set. If any fragment immediately preceding an acknowledgment 451 request is still missing, the receiver MAY intentionally delay its 452 acknowledgment to allow in-transit fragments to arrive. delaying the 453 acknowledgement might defeat the round trip delay computation so it 454 should be configurable and not enabled by default. 456 The receiver interacts with the sender using an Acknowledgment 457 message with a bitmap that indicates which fragments were actually 458 received. The bitmap is a 32bit SWORD, which accommodates up to 32 459 fragments and is sufficient for the 6LoWPAN MTU. For all n in 460 [0..31], bit n is set to 1 in the bitmap to indicate that fragment 461 with sequence n was received, otherwise the bit is set to 0. All 462 zeroes is a NULL bitmap that indicates that the fragmentation process 463 was cancelled by the receiver for that datagram. 465 The receiver MAY issue unsolicited acknowledgments. An unsolicited 466 acknowledgment enables the sender endpoint to resume sending if it 467 had reached its maximum number of outstanding fragments or indicate 468 that the receiver has cancelled the process of an individual 469 datagram. Note that acknowledgments might consume precious resources 470 so the use of unsolicited acknowledgments should be configurable and 471 not enabled by default. 473 The sender arms a retry timer to cover the fragment that carries the 474 Acknowledgment request. Upon time out, the sender assumes that all 475 the fragments on the way are received or lost. The process must have 476 completed within an acceptable time that is within the boundaries of 477 upper layer retries. The method detailed in [RFC2988] is recommended 478 for the computation of the retry timer. It is expected that the 479 upper layer retries obey the same or friendly rules in which case a 480 single round of fragment recovery should fit within the upper layer 481 recovery timers. 483 Fragments are sent in a round robin fashion: the sender sends all the 484 fragments for a first time before it retries any lost fragment; lost 485 fragments are retried in sequence, oldest first. This mechanism 486 enables the receiver to acknowledge fragments that were delayed in 487 the network before they are actually retried. 489 When the sender decides that a packet should be dropped and the 490 fragmentation process canceled, it sends a pseudo fragment with the 491 datagram_offset, sequence and datagram_size all set to zero, and no 492 data. Upon reception of this message, the receiver should clean up 493 all resources for the packet associated to the datagram_tag. If an 494 acknowledgement is requested, the receiver responds with a NULL 495 bitmap. 497 The receiver might need to cancel the process of a fragmented packet 498 for internal reasons, for instance if it is out of recomposition 499 buffers, or considers that this packet is already fully recomposed 500 and passed to the upper layer. In that case, the receiver SHOULD 501 indicate so to the sender with a NULL bitmap. Upon an 502 acknowledgement with a NULL bitmap, the sender MUST drop the 503 datagram. 505 8. Security Considerations 507 The process of recovering fragments does not appear to create any 508 opening for new threat compared to "Transmission of IPv6 Packets over 509 IEEE 802.15.4 Networks" [RFC4944]. 511 9. IANA Considerations 513 Need extensions for formats defined in "Transmission of IPv6 Packets 514 over IEEE 802.15.4 Networks" [RFC4944]. 516 10. Acknowledgments 518 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 519 Kolavennu and Harry Courtice for their contribution and review. 521 11. References 523 11.1. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 529 Timer", RFC 2988, November 2000. 531 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 532 "Transmission of IPv6 Packets over IEEE 802.15.4 533 Networks", RFC 4944, September 2007. 535 11.2. Informative References 537 [I-D.ietf-tsvwg-udp-guidelines] 538 Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 539 for Application Designers", 540 draft-ietf-tsvwg-udp-guidelines-11 (work in progress), 541 October 2008. 543 [I-D.mathis-frag-harmful] 544 Mathis, M., "Fragmentation Considered Very Harmful", 545 draft-mathis-frag-harmful-00 (work in progress), 546 July 2004. 548 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 549 November 1990. 551 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 552 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 553 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 554 S., Wroclawski, J., and L. Zhang, "Recommendations on 555 Queue Management and Congestion Avoidance in the 556 Internet", RFC 2309, April 1998. 558 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 559 Control", RFC 2581, April 1999. 561 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 562 RFC 2914, September 2000. 564 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 565 of Explicit Congestion Notification (ECN) to IP", 566 RFC 3168, September 2001. 568 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 569 over Low-Power Wireless Personal Area Networks (6LoWPANs): 570 Overview, Assumptions, Problem Statement, and Goals", 571 RFC 4919, August 2007. 573 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 574 Errors at High Data Rates", RFC 4963, July 2007. 576 Authors' Addresses 578 Pascal Thubert (editor) 579 Cisco Systems 580 Village d'Entreprises Green Side 581 400, Avenue de Roumanille 582 Batiment T3 583 Biot - Sophia Antipolis 06410 584 FRANCE 586 Phone: +33 4 97 23 26 34 587 Email: pthubert@cisco.com 588 Jonathan W. Hui 589 Arch Rock Corporation 590 501 2nd St. Ste. 410 591 San Francisco, California 94107 592 USA 594 Phone: +415 692 0828 595 Email: jhui@archrock.com