idnits 2.17.1 draft-thubert-roll-forwarding-frags-02.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 (September 09, 2013) is 3881 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 613, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 649, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft cisco 4 Intended status: Standards Track J.W. Hui 5 Expires: March 11, 2014 Cisco 6 September 09, 2013 8 LLN Fragment Forwarding and Recovery 9 draft-thubert-roll-forwarding-frags-02 11 Abstract 13 In order to be routed, a fragmented packet must be reassembled at 14 every hop of a multihop link where lower layer fragmentation occurs. 15 Considering that the IPv6 minimum MTU is 1280 bytes and that an an 16 802.15.4 frame can have a payload limited to 74 bytes in the worst 17 case, a packet might end up fragmented into as many as 18 fragments 18 at the 6LoWPAN shim layer. If a single one of those fragments is 19 lost in transmission, all fragments must be resent, further 20 contributing to the congestion that might have caused the initial 21 packet loss. This draft introduces a simple protocol to forward and 22 recover individual fragments that might be lost over multiple hops 23 between 6LoWPAN endpoints. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 11, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 6 64 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7 65 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 7 66 7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Upon the first fragment . . . . . . . . . . . . . . . . . 10 69 8.2. Upon the next fragments . . . . . . . . . . . . . . . . . 11 70 8.3. Upon the fragment acknowledgements . . . . . . . . . . . . 11 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 12.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 In most Low Power and Lossy Network (LLN) applications, the bulk of 82 the traffic consists of small chunks of data (in the order few bytes 83 to a few tens of bytes) at a time. Given that an 802.15.4 frame can 84 carry 74 bytes or more in all cases, fragmentation is usually not 85 required. However, and though this happens only occasionally, a 86 number of mission critical applications do require the capability to 87 transfer larger chunks of data, for instance to support a firmware 88 upgrades of the LLN nodes or an extraction of logs from LLN nodes. 89 In the former case, the large chunk of data is transferred to the LLN 90 node, whereas in the latter, the large chunk flows away from the LLN 91 node. In both cases, the size can be on the order of 10K bytes or 92 more and an end-to-end reliable transport is required. 94 Mechanisms such as TCP or application-layer segmentation will be used 95 to support end-to-end reliable transport. One option to support bulk 96 data transfer over a frame-size-constrained LLN is to set the Maximum 97 Segment Size to fit within the link maximum frame size. Doing so, 98 however, can add significant header overhead to each 802.15.4 frame. 99 This causes the end-to-end transport to be intimately aware of the 100 delivery properties of the underlaying LLN, which is a layer 101 violation. 103 An alternative mechanism combines the use of 6LoWPAN fragmentation in 104 addition to transport or application-layer segmentation. Increasing 105 the Maximum Segment Size reduces header overhead by the end-to-end 106 transport protocol. It also encourages the transport protocol to 107 reduce the number of outstanding datagrams, ideally to a single 108 datagram, thus reducing the need to support out-of-order delivery 109 common to LLNs. 111 [RFC4944] defines a datagram fragmentation mechanism for LLNs. 112 However, because [RFC4944] does not define a mechanism for recovering 113 fragments that are lost, datagram forwarding fails if even one 114 fragment is not delivered properly to the next IP hop. End-to-end 115 transport mechanisms will require retransmission of all fragments, 116 wasting resources in an already resource-constrained network. 118 Past experience with fragmentation has shown that missassociated or 119 lost fragments can lead to poor network behavior and, eventually, 120 trouble at application layer. The reader is encouraged to read 121 [RFC4963] and follow the references for more information. That 122 experience led to the definition of the Path MTU discovery [RFC1191] 123 protocol that limits fragmentation over the Internet. 125 For one-hop communications, a number of media propose a local 126 acknowledgement mechanism that is enough to protect the fragments. 127 In a multihop environment, an end-to-end fragment recovery mechanism 128 might be a good complement to a hop-by-hop MAC level recovery. This 129 draft introduces a simple protocol to recover individual fragments 130 between 6LoWPAN endpoints. Specifically in the case of UDP, valuable 131 additional information can be found in UDP Usage Guidelines for 132 Application Designers [RFC5405]. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 Readers are expected to be familiar with all the terms and concepts 141 that are discussed in "IPv6 over Low-Power Wireless Personal Area 142 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 143 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 144 Networks" [RFC4944]. 146 Error Recovery Procedure. 148 The LLN nodes in charge of generating or expanding a 6LoWPAN 149 header from/to a full IPv6 packet. The 6LoWPAN 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 LLN; however, the associated 157 functionality can be critical enough to justify extra care for 158 ensuring effective transport of large packets across the LLN. 160 The list of those usages includes: 162 Towards the LLN node: 164 Packages of Commands: A number of commands or a full configuration 165 can by packaged as a single message to ensure consistency and 166 enable atomic execution or complete roll back. Until such 167 commands are fully received and interpreted, the intended 168 operation will not take effect. 170 Firmware update: For example, a new version of the LLN 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 LLN nodes over a 174 relatively short period of time. 176 From the LLN node: 178 Waveform captures: A number of consecutive samples are measured at 179 a high rate for a short time and then transferred from a sensor 180 to a gateway or an edge server as a single large report. 182 Data logs: LLN nodes may generate large logs of sampled data for 183 later extraction. LLN nodes may also generate system logs to 184 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 LLN 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 [RFC4944] defines an MTU is 1280 bytes and that in 210 most incarnations (but 802.15.4G) a 802.15.4 frame can limit the MAC 211 payload to as few as 74 bytes, a packet might be fragmented into at 212 least 18 fragments at the 6LoWPAN shim layer. Taking into account 213 the worst-case header overhead for 6LoWPAN Fragmentation and Mesh 214 Addressing headers will increase the number of required fragments to 215 around 32. This level of fragmentation is much higher than that 216 traditionally experienced over the Internet with IPv4 fragments. At 217 the same time, the use of radios increases the probability of 218 transmission loss and Mesh-Under techniques compound that risk over 219 multiple hops. 221 4. Requirements 223 This paper proposes a method to recover individual fragments between 224 LLN endpoints. The method is designed to fit the following 225 requirements of a LLN (with or without a Mesh-Under routing 226 protocol): 228 The recovery mechanism must support highly fragmented packets, 229 with a maximum of 32 fragments per packet. 231 Because the radio is half duplex, and because of silent time spent 232 in the various medium access mechanisms, an acknowledgment 233 consumes roughly as many resources as data fragment. 235 The recovery mechanism should be able to acknowledge multiple 236 fragments in a single message and not require an acknowledgement 237 at all if fragments are already protected at a lower layer. 239 The recovery mechanism must succeed or give up within the time 240 boundary imposed by the recovery process of the Upper Layer 241 Protocols. 243 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 244 Layer can introduce out-of-sequence packets. 246 The recovery mechanism must account for packets that appear lost 247 but are actually only delayed over a different path. 249 The aggregation of multiple concurrent flows may lead to the 250 saturation of the radio network and congestion collapse. 252 The recovery mechanism should provide means for controlling the 253 number of fragments in transit over the LLN. 255 5. Overview 257 Considering that a multi-hop LLN can be a very sensitive environment 258 due to the limited queuing capabilities of a large population of its 259 nodes, this draft recommends a simple and conservative approach to 260 congestion control, based on TCP congestion avoidance. 262 Congestion on the forward path is assumed in case of packet loss, and 263 packet loss is assumed upon time out. 265 Congestion on the forward path can also be indicated by an Explicit 266 Congestion Notification (ECN) mechanism. Though whether and how ECN 267 [RFC3168] is carried out over the LoWPAN is out of scope, this draft 268 provides a way for the destination endpoint to echo an ECN indication 269 back to the source endpoint in an acknowledgment message as 270 represented in Figure 5 in Section 6.2. 272 From the standpoint of a source 6LoWPAN 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 LLN 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 6LoWPAN endpoints. The method detailed in [RFC2988] is 287 recommended for that computation. 289 The reader is encouraged to read through "Congestion Control 290 Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide 291 deeper information on why this mechanism is needed and how TCP 292 handles Congestion Control. Basically, the goal here is to manage 293 the amount of fragments present in the network; this is achieved by 294 to reducing the number of outstanding fragments over a congested path 295 by throttling the sources. 297 Section 7 describes how the sender decides how many fragments are 298 (re)sent before an acknowledgment is required, and how the sender 299 adapts that number to the network conditions. 301 6. New Dispatch types and headers 302 This specification extends "Transmission of IPv6 Packets over IEEE 303 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for 304 Recoverable Fragments (RFRAG) headers with or without Acknowledgment 305 Request, and for the Acknowledgment back, with or without ECN Echo. 307 Pattern Header Type 308 +------------+-----------------------------------------------+ 309 | 11 101000 | RFRAG - Recoverable Fragment | 310 | 11 101001 | RFRAG-AR - RFRAG with Ack Request | 311 | 11 101010 | RFRAG-ACK - RFRAG Acknowledgment | 312 | 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo | 313 +------------+-----------------------------------------------+ 315 In the following sections, the semantics of "datagram_tag," 316 "datagram_offset" and "datagram_size" and the reassembly process are 317 changed from [RFC4944] Section 5.3. "Fragmentation Type and 318 Header." The size and offset are expressed on the compressed packet 319 per [RFC6282] as opposed to the uncompressed - native packet - form. 321 6.1. Recoverable Fragment Dispatch type and Header 323 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |Sequence | datagram_size | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 X set == Ack Requested 332 When set, the sender requires an Acknowledgment from the receiver 334 The sequence number of the fragment. Fragments are numbered 335 [0..N] where N is in [0..31]. 337 6.2. Fragment Acknowledgement Dispatch type and Header 339 The specification also defines a 4-octet acknowledgement bitmap that 340 is used to carry selective acknowlegements for the received 341 fragments. A given offset in the bitmap maps one to one with a given 342 sequence number. 344 The offset of the bit in the bitmap indicates which fragment is 345 acknowledged as follows: 347 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Acknowledgment Bitmap | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 ^ ^ 353 | | bitmap indicating whether: 354 | +--- Fragment with sequence 10 was received 355 +----------------------- Fragment with sequence 00 was received 357 So in the example below Figure 4 it appears that all fragments from 358 sequence 0 to 20 were received but for sequence 1, 2 and 16 that were 359 either lost or are still in the network over a slower path. 361 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |1|0|0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|1|1|1|1|0|0|0|0|0|0|0|0|0|0|0| 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 The acknowledgement bitmap is carried in a Fragment Acknowledgement 368 as follows: 370 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |1 1 1 0 1 0 1 Y| datagram_tag | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Acknowledgment Bitmap (32 bits) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Explicit Congestion Notification (ECN) signalling 380 When set, the sender indicates that at least one of the 381 acknowledged fragments was received with an Explicit Congestion 382 Notification, indicating that the path followed by the fragments 383 is subject to congestion. 385 An acknowledgement bitmap, whereby but at offset x indicates that 386 fragment x was received. 388 7. Fragments Recovery 390 The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the 391 original fragment headers from [RFC4944] and replace them in the 392 fragmented packets. The Fragment Acknowledgement RFRAG-ACK is 393 introduced as a standalone header in message that is sent back to the 394 fragment source endpoint as known by its MAC address. This assumes 395 that the source MAC address in the fragment (is any) and datagram_tag 396 are enough information to send the Fragment Acknowledgement back to 397 the source fragmentation endpoint. 399 The 6LoWPAN endpoint that fragments the packets at 6LoWPAN level (the 400 sender) controls the Fragment Acknowledgements. If may do that at 401 any fragment to implement its own policy or perform congestion 402 control which is out of scope for this document. When the sender of 403 the fragment knows that an underlying mechanism protects the 404 Fragments already it MAY refrain from using the Acknowledgement 405 mechanism, and never set the Ack Requested bit. The 6LoWPAN endpoint 406 that recomposes the packets at 6LoWPAN level (the receiver) MUST 407 acknowledge the fragments it has received when asked to, and MAY 408 slightly defer that acknowledgement. 410 The sender transfers a controlled number of fragments and MAY flag 411 the last fragment of a series with an acknowledgment request. The 412 received MUST acknowledge a fragment with the acknowledgment request 413 bit set. If any fragment immediately preceding an acknowledgment 414 request is still missing, the receiver MAY intentionally delay its 415 acknowledgment to allow in-transit fragments to arrive. delaying the 416 acknowledgement might defeat the round trip delay computation so it 417 should be configurable and not enabled by default. 419 The receiver interacts with the sender using an Acknowledgment 420 message with a bitmap that indicates which fragments were actually 421 received. The bitmap is a 32bit SWORD, which accommodates up to 32 422 fragments and is sufficient for the 6LoWPAN MTU. For all n in 423 [0..31], bit n is set to 1 in the bitmap to indicate that fragment 424 with sequence n was received, otherwise the bit is set to 0. All 425 zeroes is a NULL bitmap that indicates that the fragmentation process 426 was cancelled by the receiver for that datagram. 428 The receiver MAY issue unsolicited acknowledgments. An unsolicited 429 acknowledgment enables the sender endpoint to resume sending if it 430 had reached its maximum number of outstanding fragments or indicate 431 that the receiver has cancelled the process of an individual 432 datagram. Note that acknowledgments might consume precious resources 433 so the use of unsolicited acknowledgments should be configurable and 434 not enabled by default. 436 The sender arms a retry timer to cover the fragment that carries the 437 Acknowledgment request. Upon time out, the sender assumes that all 438 the fragments on the way are received or lost. The process must have 439 completed within an acceptable time that is within the boundaries of 440 upper layer retries. The method detailed in [RFC2988] is recommended 441 for the computation of the retry timer. It is expected that the 442 upper layer retries obey the same or friendly rules in which case a 443 single round of fragment recovery should fit within the upper layer 444 recovery timers. 446 Fragments are sent in a round robin fashion: the sender sends all the 447 fragments for a first time before it retries any lost fragment; lost 448 fragments are retried in sequence, oldest first. This mechanism 449 enables the receiver to acknowledge fragments that were delayed in 450 the network before they are actually retried. 452 When the sender decides that a packet should be dropped and the 453 fragmentation process canceled, it sends a pseudo fragment with the 454 datagram_offset, sequence and datagram_size all set to zero, and no 455 data. Upon reception of this message, the receiver should clean up 456 all resources for the packet associated to the datagram_tag. If an 457 acknowledgement is requested, the receiver responds with a NULL 458 bitmap. 460 The receiver might need to cancel the process of a fragmented packet 461 for internal reasons, for instance if it is out of recomposition 462 buffers, or considers that this packet is already fully recomposed 463 and passed to the upper layer. In that case, the receiver SHOULD 464 indicate so to the sender with a NULL bitmap. Upon an 465 acknowledgement with a NULL bitmap, the sender MUST drop the 466 datagram. 468 8. Forwarding Fragments 470 This specification enables intermediate routers to forward fragments 471 with no intermediate reconstruction of the entire packet. Upon the 472 first fragment, the routers lay an label along the path that is 473 followed by that fragment (that is IP routed), and all further 474 fragments are label switched along that path. As a consequence, 475 alternate routes not possible for individual fragments. The datagram 476 tag is used to carry the label, that is swapped at each hop. 478 8.1. Upon the first fragment 480 In route over the L2 source changes at each hop. The label that is 481 formed adnd placed in the datagram tag is associated to the source 482 MAC and only valid (and unique) for that source MAC. Say the first 483 fragment has: 485 Source IPv6 address = IP_A (maybe hops away) 487 Destination IPv6 address = IP_B (maybe hops away) 489 Source MAC = MAC_prv (prv as previous) 491 Datagram_tag= DT_prv 493 The intermediate router that forwards individual fragments does the 494 following: 496 a route lookup to get Next hop IPv6 towards IP_B, which resolves 497 as IP_nxt (nxt as next) 499 a ND resolution to get the MAC address associated to IP_nxt, which 500 resolves as MAC_nxt 502 Since it is a first fragment of a packet from that source MAC address 503 MAC_prv for that tag DT_prv, the router: 505 cleans up any leftover resource associated to the tupple (MAC_prv, 506 DT_prv) 508 allocates a new label for that flow, DT_nxt, from a Least Recently 509 Used pool or some siumilar procedure. 511 allocates a Label swap structure indexed by (MAC_prv, DT_prv) that 512 contains (MAC_nxt, DT_nxt) 514 allocates a Label swap structure indexed by (MAC_nxt, DT_nxt) that 515 contains (MAC_prv, DT_prv) 517 swaps the MAC info to from self to MAC_nxt 519 Swaps the datagram_tag to DT_nxt 521 At this point the router is all set and can forward the packet to 522 nxt. 524 8.2. Upon the next fragments 526 Upon next fragments (that are not first fragment), the router expects 527 to have already Label swap structure indexed by (MAC_prv, DT_prv). 528 The router: 530 lookups up the Label swap entry for (MAC_prv, DT_prv), which 531 resolves as (MAC_nxt, DT_nxt) 533 swaps the MAC info to from self to MAC_nxt; 535 Swaps the datagram_tag to DT_nxt 537 At this point the router is all set and can forward the packet to 538 nxt. 540 if the Label swap entry for (MAC_src, DT_src) is not found, the 541 router builds an RFRAG-ACK to indicate the error. The acknowledgment 542 message has the following information: 544 MAC info set to from self to MAC_prv as found in the fragment 546 Swaps the datagram_tag set to DT_prv 548 Bitmap of all zeroes to indicate the error 550 At this point the router is all set and can send the RFRAG-ACK back 551 ot the previous router. 553 8.3. Upon the fragment acknowledgements 554 Upon fragment acknowledgements next fragments (that are not first 555 fragment), the router expects to have already Label swap structure 556 indexed by (MAC_nxt, DT_nxt). The router: 558 lookups up the Label swap entry for (MAC_nxt, DT_nxt), which 559 resolves as (MAC_prv, DT_prv) 561 swaps the MAC info to from self to MAC_prv; 563 Swaps the datagram_tag to DT_prv 565 At this point the router is all set and can forward the RFRAG-ACK to 566 prv. 568 if the Label swap entry for (MAC_nxt, DT_nxt) is not found, it simply 569 drops the packet. 571 if the RFRAG-ACK indicates either an error or that the fragment was 572 fully receive, the router schedules the Label swap entries for 573 recycling. If the RFRAG-ACK is lost on the way back, the source may 574 retry the last fragments, which will result as an error RFRAG-ACK 575 from the first router on the way that has already cleaned up. 577 9. Security Considerations 579 The process of recovering fragments does not appear to create any 580 opening for new threat compared to "Transmission of IPv6 Packets over 581 IEEE 802.15.4 Networks" [RFC4944]. 583 10. IANA Considerations 585 Need extensions for formats defined in "Transmission of IPv6 Packets 586 over IEEE 802.15.4 Networks" [RFC4944]. 588 11. Acknowledgments 590 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 591 Kolavennu and Harry Courtice for their contribution and review. 593 12. References 595 12.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 601 Timer", RFC 2988, November 2000. 603 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, 604 "Transmission of IPv6 Packets over IEEE 802.15.4 605 Networks", RFC 4944, September 2007. 607 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 608 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 609 September 2011. 611 12.2. Informative References 613 [I-D.mathis-frag-harmful] 614 Mathis, M., "Fragmentation Considered Very Harmful", 615 Internet-Draft draft-mathis-frag-harmful-00, July 2004. 617 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 618 November 1990. 620 [RFC2309] Braden, B., Clark, D.D., Crowcroft, J., Davie, B., 621 Deering, S., Estrin, D., Floyd, S., Jacobson, V., 622 Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, 623 K.K., Shenker, S., Wroclawski, J. and L. Zhang, 624 "Recommendations on Queue Management and Congestion 625 Avoidance in the Internet", RFC 2309, April 1998. 627 [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 628 Control", RFC 2581, April 1999. 630 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 631 2914, September 2000. 633 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 634 Explicit Congestion Notification (ECN) to IP", RFC 3168, 635 September 2001. 637 [RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 638 over Low-Power Wireless Personal Area Networks (6LoWPANs): 639 Overview, Assumptions, Problem Statement, and Goals", RFC 640 4919, August 2007. 642 [RFC4963] Heffner, J., Mathis, M. and B. Chandler, "IPv4 Reassembly 643 Errors at High Data Rates", RFC 4963, July 2007. 645 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 646 for Application Designers", BCP 145, RFC 5405, November 647 2008. 649 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 650 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 651 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 652 Lossy Networks", RFC 6550, March 2012. 654 Authors' Addresses 655 Pascal Thubert, editor 656 Cisco Systems, Inc 657 Building D 658 45 Allee des Ormes - BP1200 659 MOUGINS - Sophia Antipolis, 06254 660 FRANCE 662 Phone: +33 497 23 26 34 663 Email: pthubert@cisco.com 665 Jonathan W. Hui 666 Cisco Systems 667 560 McCarthy Blvd. 668 MILPITAS, California 95035 669 USA 671 Email: johui@cisco.com