idnits 2.17.1 draft-thubert-6lowpan-simple-fragment-recovery-07.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 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 4, 2010) is 5046 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.ietf-roll-rpl' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'I-D.mathis-frag-harmful' is defined on line 657, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-08 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: December 6, 2010 Arch Rock Corporation 6 June 4, 2010 8 LoWPAN fragment Forwarding and Recovery 9 draft-thubert-6lowpan-simple-fragment-recovery-07 11 Abstract 13 Considering that the IPv6 minimum MTU is 1280 bytes and that an an 14 802.15.4 frame can have a payload limited to 74 bytes in the worst 15 case, a packet might end up fragmented into as many as 18 fragments 16 at the 6LoWPAN shim layer. If a single one of those fragments is 17 lost in transmission, all fragments must be resent, further 18 contributing to the congestion that might have caused the initial 19 packet loss. This draft introduces a simple protocol to forward and 20 recover individual fragments that might be lost over multiple hops 21 between 6LoWPAN endpoints. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 6, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7 63 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 8 64 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 65 7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 10 66 8. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Upon the first fragment . . . . . . . . . . . . . . . . . 12 68 8.2. Upon the next fragments . . . . . . . . . . . . . . . . . 13 69 8.3. Upon the fragment acknowledgements . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 In many 6LoWPAN applications, the majority of traffic is spent 81 sending small chunks of data (order few bytes to few tens of bytes) 82 per packet. Given that an 802.15.4 frame can carry 74 bytes or more 83 in all cases, fragmentation is often not needed for most application 84 traffic. However, many applications also require occasional bulk 85 data transfer capabilities to support firmware upgrades of 6LoWPAN 86 devices or extraction of logs from 6LoWPAN devices. In the former 87 case, bulk data is transferred to the 6LoWPAN device, and in the 88 latter, bulk data flows away from the 6LoWPAN device. In both cases, 89 the bulk data size is often on the order of 10K bytes or more and 90 end-to-end reliable transport is required. 92 Mechanisms such as TCP or application-layer segmentation will be used 93 to support end-to-end reliable transport. One option to support bulk 94 data transfer over 6LoWPAN links is to set the Maximum Segment Size 95 to fit within the 802.15.4 MTU. Doing so, however, can add 96 significant header overhead to each 802.15.4 frame. This causes the 97 end-to-end transport to be aware of the delivery properties of 98 6LoWPAN networks, which is a layer violation. 100 An alternative mechanism combines the use of 6LoWPAN fragmentation in 101 addition to transport or application-layer segmentation. Increasing 102 the Maximum Segment Size reduces header overhead by the end-to-end 103 transport protocol. It also encourages the transport protocol to 104 reduce the number of outstanding datagrams, ideally to a single 105 datagram, thus reducing the need to support out-of-order delivery 106 common to 6LoWPAN networks. 108 [RFC4944] defines a datagram fragmentation mechanism for 6LoWPAN 109 networks. However, because [RFC4944] does not define a mechanism for 110 recovering fragments that are lost, datagram forwarding fails if even 111 one fragment is not delivered properly to the next IP hop. End-to- 112 end transport mechanisms will require retransmission of all 113 fragments, wasting resources in an already resource-constrained 114 network. 116 Past experience with fragmentation has shown that missassociated or 117 lost fragments can lead to poor network behavior and, eventually, 118 trouble at application layer. The reader is encouraged to read 119 [RFC4963] and follow the references for more information. That 120 experience led to the definition of the Path MTU discovery [RFC1191] 121 protocol that limits fragmentation over the Internet. 123 For one-hop communications, a number of media propose a local 124 acknowledgement mechanism that is enough to protect the fragments. 125 In a multihop environment, an end-to-end fragment recovery mechanism 126 might be a good complement to a hop-by-hop MAC level recovery. This 127 draft introduces a simple protocol to recover individual fragments 128 between 6LoWPAN endpoints. Specifically in the case of UDP, valuable 129 additional information can be found in UDP Usage Guidelines for 130 Application Designers [RFC5405]. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 Readers are expected to be familiar with all the terms and concepts 139 that are discussed in "IPv6 over Low-Power Wireless Personal Area 140 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 141 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 142 Networks" [RFC4944]. 144 ERP 146 Error Recovery Procedure. 148 LoWPAN endpoints 150 The LoWPAN nodes in charge of generating or expanding a 6LoWPAN 151 header from/to a full IPv6 packet. The LoWPAN endpoints are the 152 points where fragmentation and reassembly take place. 154 3. Rationale 156 There are a number of uses for large packets in Wireless Sensor 157 Networks. Such usages may not be the most typical or represent the 158 largest amount of traffic over the LoWPAN; however, the associated 159 functionality can be critical enough to justify extra care for 160 ensuring effective transport of large packets across the LoWPAN. 162 The list of those usages includes: 164 Towards the LoWPAN node: 166 Packages of Commands: A number of commands or a full 167 configuration can by packaged as a single message to ensure 168 consistency and enable atomic execution or complete roll back. 169 Until such commands are fully received and interpreted, the 170 intended operation will not take effect. 172 Firmware update: For example, a new version of the LoWPAN node 173 software is downloaded from a system manager over unicast or 174 multicast services. Such a reflashing operation typically 175 involves updating a large number of similar 6LoWPAN nodes over 176 a relatively short period of time. 178 From the LoWPAN node: 180 Waveform captures: A number of consecutive samples are measured 181 at a high rate for a short time and then transferred from a 182 sensor to a gateway or an edge server as a single large report. 184 Data logs: 6LoWPAN nodes may generate large logs of sampled data 185 for later extraction. 6LoWPAN nodes may also generate system 186 logs to assist in diagnosing problems on the node or network. 188 Large data packets: Rich data types might require more than one 189 fragment. 191 Uncontrolled firmware download or waveform upload can easily result 192 in a massive increase of the traffic and saturate the network. 194 When a fragment is lost in transmission, all fragments are resent, 195 further contributing to the congestion that caused the initial loss, 196 and potentially leading to congestion collapse. 198 This saturation may lead to excessive radio interference, or random 199 early discard (leaky bucket) in relaying nodes. Additional queuing 200 and memory congestion may result while waiting for a low power next 201 hop to emerge from its sleeping state. 203 To demonstrate the severity of the problem, consider a fairly 204 reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4 205 hop. The expected delivery rate of a 5-fragment datagram would be 206 about 99.5% over a single 802.15.4 hop. However, the expected 207 delivery rate would drop to 95.1% over 10 hops, a reasonable network 208 diameter for 6LoWPAN applications. The expected delivery rate for a 209 1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops. 211 Considering that the IPv6 minimum MTU is 1280 bytes and that a 212 802.15.4 frame can limit the MAC payload to as little as 74 bytes, a 213 packet might be fragmented into at least 18 fragments at the 6LoWPAM 214 shim layer. Taking into account the worst-case header overhead for 215 6LoWPAN Fragmentation and Mesh Addressing headers will increase the 216 number of required fragments to around 32. This level of 217 fragmentation is much higher than that traditionally experienced over 218 the Internet with IPv4 fragments. At the same time, the use of 219 radios increases the probability of transmission loss and Mesh-Under 220 techniques compound that risk over multiple hops. 222 4. Requirements 224 This paper proposes a method to recover individual fragments between 225 LoWPAN endpoints. The method is designed to fit the following 226 requirements of a LoWPAN (with or without a Mesh-Under routing 227 protocol): 229 Number of fragments 231 The recovery mechanism must support highly fragmented packets, 232 with a maximum of 32 fragments per packet. 234 Minimum acknowledgement overhead 236 Because the radio is half duplex, and because of silent time spent 237 in the various medium access mechanisms, an acknowledgment 238 consumes roughly as many resources as data fragment. 240 The recovery mechanism should be able to acknowledge multiple 241 fragments in a single message and not require an acknowledgement 242 at all if fragments are already protected at a lower layer. 244 Controlled latency 246 The recovery mechanism must succeed or give up within the time 247 boundary imposed by the recovery process of the Upper Layer 248 Protocols. 250 Support for out-of-order fragment delivery 252 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 253 Layer can introduce out-of-sequence packets. 255 The recovery mechanism must account for packets that appear lost 256 but are actually only delayed over a different path. 258 Optional congestion control 260 The aggregation of multiple concurrent flows may lead to the 261 saturation of the radio network and congestion collapse. 263 The recovery mechanism should provide means for controlling the 264 number of fragments in transit over the LoWPAN. 266 5. Overview 268 Considering that a multi-hop LoWPAN can be a very sensitive 269 environment due to the limited queuing capabilities of a large 270 population of its nodes, this draft recommends a simple and 271 conservative approach to congestion control, based on TCP congestion 272 avoidance. 274 From the standpoint of a source LoWPAN endpoint, an outstanding 275 fragment is a fragment that was sent but for which no explicit 276 acknowledgment was received yet. This means that the fragment might 277 be on the way, received but not yet acknowledged, or the 278 acknowledgment might be on the way back. It is also possible that 279 either the fragment or the acknowledgment was lost on the way. 281 Because a meshed LoWPAN might deliver frames out of order, it is 282 virtually impossible to differentiate these situations. In other 283 words, from the sender standpoint, all outstanding fragments might 284 still be in the network and contribute to its congestion. There is 285 an assumption, though, that after a certain amount of time, a frame 286 is either received or lost, so it is not causing congestion anymore. 287 This amount of time can be estimated based on the round trip delay 288 between the LoWPAN endpoints. The method detailed in [RFC2988] is 289 recommended for that computation. 291 6. New Dispatch types and headers 293 This specification extends "Transmission of IPv6 Packets over IEEE 294 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for 295 Recoverable Fragments (RFRAG) headers with or without Acknowledgment 296 Request, and for the Acknowledgment back. 298 Pattern Header Type 299 +------------+-----------------------------------------------+ 300 | 11 101000 | RFRAG - Recoverable Fragment | 301 | 11 101001 | RFRAG-AR - RFRAG with Ack Request | 302 | 11 10101x | RFRAG-ACK - RFRAG Acknowledgment | 303 +------------+-----------------------------------------------+ 305 Figure 1: Additional Dispatch Value Bit Patterns 307 In the following sections, the semantics of "datagram_tag," 308 "datagram_offset" and "datagram_size" and the reassembly process are 309 changed from [RFC4944] Section 5.3. "Fragmentation Type and Header." 310 The size and offset are expressed on the compressed packet as opposed 311 to the uncompressed form. 313 6.1. Recoverable Fragment Dispatch type and Header 315 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |Sequence | datagram_size | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 X set == Ack Requested 324 Figure 2: Recoverable Fragment Dispatch type and Header 326 X bit 328 When set, the sender requires an Acknowledgment from the receiver 330 Sequence 332 The sequence number of the fragment. Fragments are numbered 333 [0..N] where N is in [0..31]. 335 6.2. Fragment Acknowledgement Dispatch type and Header 337 The specification also defines an acknowledgement bitmap that is used 338 to carry selective acknowlegements for the received fragments. A 339 given offset in the bitmap maps one to one with a given sequence 340 number. 342 The bitmap is compressed as a variable length field formed by control 343 bits and acknowledgement bits. The leftmost bits of the compressed 344 form are control bits up to the first 0. The rest is ack bits 345 encoded right to left: 347 Pattern Size Ack 348 +--------------------------------------+----------+----------+ 349 | 0XXXXXXX | 1 octet | 1 -> 7 | 350 | 10XXXXXX XXXXXXXX | 2 octets | 1 -> 14 | 351 | 110XXXXX XXXXXXXX XXXXXXXX | 3 octets | 1 -> 21 | 352 | 1110XXXX XXXXXXXX XXXXXXXX XXXXXXXX | 4 octets | 1 -> 28 | 353 +------------+-----------------------------------------------+ 355 Figure 3: Compressed acknowledgement bitmap encoding 357 The highest sequence number to be acknowledged determines the pattern 358 to be used. The format can be extended for more fragments in the 359 future but this specification only requires the support of up to 4 360 octets encoding, which enables to acknowledge up to 28 fragments. 362 A 32 bits uncompressed bitmap is obtained by prepending zeroes to the 363 XXX in the pattern above. For instance: 365 0 1 2 3 4 5 6 7 366 +-+-+-+-+-+-+-+-+ 367 |0|1|1|0|1|1|1|1| is expanded as: 368 +-+-+-+-+-+-+-+-+ 369 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |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| 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 4: Expanding 1 octet encoding 377 and 378 1 2 379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |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: 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |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| 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 5: Expanding 3 octets encoding 391 whereas the 4 octets encoding is expanded by simply setting the first 392 3 bits to 0. The 32 bits uncompressed bitmap is written and read as 393 follows: 395 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Acknowledgment Bitmap | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ^ ^ 401 bitmap indicating whether: | | 402 Fragment with sequence 10 was received --+ | 403 Fragment with sequence 00 was received ----------------------+ 405 Figure 6: Expanded bitmap encoding 407 So in the example in Figure 5 it appears that all fragments from 408 sequence 0 to 20 were received but for sequence 1, 2 and 16 that were 409 either lost or are still in the network over a slower path. 411 The compressed form of the acknowledgement bitmap is carried in a 412 Fragment Acknowledgement as follows: 414 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |1 1 1 0 1 0 1 Y| datagram_tag | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Compressed Acknowledgment Bitmap (8 to 32 bits) 420 +-+-+-+-+-+-+-+-+-+ .... 422 Figure 7: Fragment Acknowledgement Dispatch type and Header 424 Y bit 426 Reserved for Explicit Congestion Notification (ECN) signalling 428 Compressed Acknowledgement Bitmap 430 An encoded form of an acknowledgement bitmap. 432 7. Fragments Recovery 434 The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the 435 original fragment headers from [RFC4944] and replace them in the 436 fragmented packets. The Fragment Acknowledgement RFRAG-ACK is 437 introduced as a standalone header in message that is sent back to the 438 fragment source endpoint as known by its MAC address. This assumes 439 that the source MAC address in the fragment (is any) and datagram_tag 440 are enough information to send the Fragment Acknowledgement back to 441 the source fragmentation endpoint. 443 The node that fragments the packets at 6LoWPAN level (the sender) 444 controls the Fragment Acknowledgements. If may do that at any 445 fragment to implement its own policy or perform congestion control 446 which is out of scope for this document. When the sender of the 447 fragment knows that an underlying mechanism protects the Fragments 448 already it MAY refrain from using the Acknowledgement mechanism, and 449 never set the Ack Requested bit. The node that recomposes the 450 packets at 6LoWPAN level (the receiver) MUST acknowledge the 451 fragments it has received when asked to, and MAY slightly defer that 452 acknowledgement. 454 The sender transfers a controlled number of fragments and MAY flag 455 the last fragment of a series with an acknowledgment request. The 456 received MUST acknowledge a fragment with the acknowledgment request 457 bit set. If any fragment immediately preceding an acknowledgment 458 request is still missing, the receiver MAY intentionally delay its 459 acknowledgment to allow in-transit fragments to arrive. delaying the 460 acknowledgement might defeat the round trip delay computation so it 461 should be configurable and not enabled by default. 463 The receiver interacts with the sender using an Acknowledgment 464 message with a bitmap that indicates which fragments were actually 465 received. The bitmap is a 32bit SWORD, which accommodates up to 32 466 fragments and is sufficient for the 6LoWPAN MTU. For all n in 467 [0..31], bit n is set to 1 in the bitmap to indicate that fragment 468 with sequence n was received, otherwise the bit is set to 0. All 469 zeroes is a NULL bitmap that indicates that the fragmentation process 470 was cancelled by the receiver for that datagram. 472 The receiver MAY issue unsolicited acknowledgments. An unsolicited 473 acknowledgment enables the sender endpoint to resume sending if it 474 had reached its maximum number of outstanding fragments or indicate 475 that the receiver has cancelled the process of an individual 476 datagram. Note that acknowledgments might consume precious resources 477 so the use of unsolicited acknowledgments should be configurable and 478 not enabled by default. 480 The sender arms a retry timer to cover the fragment that carries the 481 Acknowledgment request. Upon time out, the sender assumes that all 482 the fragments on the way are received or lost. The process must have 483 completed within an acceptable time that is within the boundaries of 484 upper layer retries. The method detailed in [RFC2988] is recommended 485 for the computation of the retry timer. It is expected that the 486 upper layer retries obey the same or friendly rules in which case a 487 single round of fragment recovery should fit within the upper layer 488 recovery timers. 490 Fragments are sent in a round robin fashion: the sender sends all the 491 fragments for a first time before it retries any lost fragment; lost 492 fragments are retried in sequence, oldest first. This mechanism 493 enables the receiver to acknowledge fragments that were delayed in 494 the network before they are actually retried. 496 When the sender decides that a packet should be dropped and the 497 fragmentation process canceled, it sends a pseudo fragment with the 498 datagram_offset, sequence and datagram_size all set to zero, and no 499 data. Upon reception of this message, the receiver should clean up 500 all resources for the packet associated to the datagram_tag. If an 501 acknowledgement is requested, the receiver responds with a NULL 502 bitmap. 504 The receiver might need to cancel the process of a fragmented packet 505 for internal reasons, for instance if it is out of recomposition 506 buffers, or considers that this packet is already fully recomposed 507 and passed to the upper layer. In that case, the receiver SHOULD 508 indicate so to the sender with a NULL bitmap. Upon an 509 acknowledgement with a NULL bitmap, the sender MUST drop the 510 datagram. 512 8. Forwarding Fragments 514 This specification enables intermediate routers to forward fragments 515 with no intermediate reconstruction of the entire packet. Upon the 516 first fragment, the routers lay an label along the path that is 517 followed by that fragment (that is IP routed), and all further 518 fragments are label switched along that path. As a consequence, 519 alternate routes not possible for individual fragments. The datagram 520 tag is used to carry the label, that is swapped at each hop. 522 8.1. Upon the first fragment 524 In route over the L2 source changes at each hop. The label that is 525 formed adnd placed in the datagram tag is associated to the source 526 MAC and only valid (and unique) for that source MAC. Say the first 527 fragment has: 529 Source IPv6 address = IP_A (maybe hops away) 531 Destination IPv6 address = IP_B (maybe hops away) 533 Source MAC = MAC_prv (prv as previous) 535 Datagram_tag= DT_prv 537 The intermediate router that forwards individual fragments does the 538 following: 540 a route lookup to get Next hop IPv6 towards IP_B, which resolves 541 as IP_nxt (nxt as next) 543 a ND resolution to get the MAC address associated to IP_nxt, which 544 resolves as MAC_nxt 546 Since it is a first fragment of a packet from that source MAC address 547 MAC_prv for that tag DT_prv, the router: 549 cleans up any leftover resource associated to the tupple (MAC_prv, 550 DT_prv) 551 allocates a new label for that flow, DT_nxt, from a Least Recently 552 Used pool or some siumilar procedure. 554 allocates a Label swap structure indexed by (MAC_prv, DT_prv) that 555 contains (MAC_nxt, DT_nxt) 557 allocates a Label swap structure indexed by (MAC_nxt, DT_nxt) that 558 contains (MAC_prv, DT_prv) 560 swaps the MAC info to from self to MAC_nxt 562 Swaps the datagram_tag to DT_nxt 564 At this point the router is all set and can forward the packet to 565 nxt. 567 8.2. Upon the next fragments 569 Upon next fragments (that are not first fragment), the router expects 570 to have already Label swap structure indexed by (MAC_prv, DT_prv). 571 The router: 573 lookups up the Label swap entry for (MAC_prv, DT_prv), which 574 resolves as (MAC_nxt, DT_nxt) 576 swaps the MAC info to from self to MAC_nxt; 578 Swaps the datagram_tag to DT_nxt 580 At this point the router is all set and can forward the packet to 581 nxt. 583 if the Label swap entry for (MAC_src, DT_src) is not found, the 584 router builds an RFRAG-ACK to indicate the error. The acknowledgment 585 message has the following information: 587 MAC info set to from self to MAC_prv as found in the fragment 589 Swaps the datagram_tag set to DT_prv 591 Bitmap of all zeroes to indicate the error 593 At this point the router is all set and can send the RFRAG-ACK back 594 ot the previous router. 596 8.3. Upon the fragment acknowledgements 598 Upon fragment acknowledgements next fragments (that are not first 599 fragment), the router expects to have already Label swap structure 600 indexed by (MAC_nxt, DT_nxt). The router: 602 lookups up the Label swap entry for (MAC_nxt, DT_nxt), which 603 resolves as (MAC_prv, DT_prv) 605 swaps the MAC info to from self to MAC_prv; 607 Swaps the datagram_tag to DT_prv 609 At this point the router is all set and can forward the RFRAG-ACK to 610 prv. 612 if the Label swap entry for (MAC_nxt, DT_nxt) is not found, it simply 613 drops the packet. 615 if the RFRAG-ACK indicates either an error or that the fragment was 616 fully receive, the router schedules the Label swap entries for 617 recycling. If the RFRAG-ACK is lost on the way back, the source may 618 retry the last fragments, which will result as an error RFRAG-ACK 619 from the first router on the way that has already cleaned up. 621 9. Security Considerations 623 The process of recovering fragments does not appear to create any 624 opening for new threat compared to "Transmission of IPv6 Packets over 625 IEEE 802.15.4 Networks" [RFC4944]. 627 10. IANA Considerations 629 Need extensions for formats defined in "Transmission of IPv6 Packets 630 over IEEE 802.15.4 Networks" [RFC4944]. 632 11. Acknowledgments 634 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 635 Kolavennu and Harry Courtice for their contribution and review. 637 12. References 638 12.1. Normative References 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, March 1997. 643 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 644 Timer", RFC 2988, November 2000. 646 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 647 "Transmission of IPv6 Packets over IEEE 802.15.4 648 Networks", RFC 4944, September 2007. 650 12.2. Informative References 652 [I-D.ietf-roll-rpl] 653 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 654 Protocol for Low power and Lossy Networks", 655 draft-ietf-roll-rpl-08 (work in progress), May 2010. 657 [I-D.mathis-frag-harmful] 658 Mathis, M., "Fragmentation Considered Very Harmful", 659 draft-mathis-frag-harmful-00 (work in progress), 660 July 2004. 662 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 663 November 1990. 665 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 666 over Low-Power Wireless Personal Area Networks (6LoWPANs): 667 Overview, Assumptions, Problem Statement, and Goals", 668 RFC 4919, August 2007. 670 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 671 Errors at High Data Rates", RFC 4963, July 2007. 673 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 674 for Application Designers", BCP 145, RFC 5405, 675 November 2008. 677 Authors' Addresses 679 Pascal Thubert (editor) 680 Cisco Systems 681 Village d'Entreprises Green Side 682 400, Avenue de Roumanille 683 Batiment T3 684 Biot - Sophia Antipolis 06410 685 FRANCE 687 Phone: +33 4 97 23 26 34 688 Email: pthubert@cisco.com 690 Jonathan W. Hui 691 Arch Rock Corporation 692 501 2nd St. Ste. 410 693 San Francisco, California 94107 694 USA 696 Phone: +415 692 0828 697 Email: jhui@archrock.com