idnits 2.17.1 draft-thubert-6lo-forwarding-fragments-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2017) is 2663 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-10 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Hui 5 Expires: July 14, 2017 Nest Labs 6 January 10, 2017 8 LLN Fragment Forwarding and Recovery 9 draft-thubert-6lo-forwarding-fragments-04 11 Abstract 13 In order to be routed, a fragmented 6LoWPAN packet must be 14 reassembled at every hop of a multihop link where lower layer 15 fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 16 bytes and that an an 802.15.4 frame can have a payload limited to 74 17 bytes in the worst case, a packet might end up fragmented into as 18 many as 18 fragments at the 6LoWPAN shim layer. If a single one of 19 those fragments is lost in transmission, all fragments must be 20 resent, further contributing to the congestion that might have caused 21 the initial packet loss. This draft introduces a simple protocol to 22 forward and recover individual fragments that might be lost over 23 multiple hops 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 July 14, 2017. 42 Copyright Notice 44 Copyright (c) 2017 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 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. New Dispatch types and headers . . . . . . . . . . . . . . . 8 65 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 8 66 6.2. Fragment acknowledgment Dispatch type and Header . . . . 8 67 7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . 10 68 8. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Upon the first fragment . . . . . . . . . . . . . . . . . 12 70 8.2. Upon the next fragments . . . . . . . . . . . . . . . . . 13 71 8.3. Upon the fragment acknowledgments . . . . . . . . . . . . 13 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 12.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 In most Low Power and Lossy Network (LLN) applications, the bulk of 83 the traffic consists of small chunks of data (in the order few bytes 84 to a few tens of bytes) at a time. Given that an 802.15.4 frame can 85 carry 74 bytes or more in all cases, fragmentation is usually not 86 required. However, and though this happens only occasionally, a 87 number of mission critical applications do require the capability to 88 transfer larger chunks of data, for instance to support a firmware 89 upgrades of the LLN nodes or an extraction of logs from LLN nodes. 90 In the former case, the large chunk of data is transferred to the LLN 91 node, whereas in the latter, the large chunk flows away from the LLN 92 node. In both cases, the size can be on the order of 10K bytes or 93 more and an end-to-end reliable transport is required. 95 Mechanisms such as TCP or application-layer segmentation will be used 96 to support end-to-end reliable transport. One option to support bulk 97 data transfer over a frame-size-constrained LLN is to set the Maximum 98 Segment Size to fit within the link maximum frame size. Doing so, 99 however, can add significant header overhead to each 802.15.4 frame. 100 This causes the end-to-end transport to be intimately aware of the 101 delivery properties of the underlaying LLN, which is a layer 102 violation. 104 An alternative mechanism combines the use of 6LoWPAN fragmentation in 105 addition to transport or application-layer segmentation. Increasing 106 the Maximum Segment Size reduces header overhead by the end-to-end 107 transport protocol. It also encourages the transport protocol to 108 reduce the number of outstanding datagrams, ideally to a single 109 datagram, thus reducing the need to support out-of-order delivery 110 common to LLNs. 112 [RFC4944] defines a datagram fragmentation mechanism for LLNs. 113 However, because [RFC4944] does not define a mechanism for recovering 114 fragments that are lost, datagram forwarding fails if even one 115 fragment is not delivered properly to the next IP hop. End-to-end 116 transport mechanisms will require retransmission of all fragments, 117 wasting resources in an already resource-constrained network. 119 Past experience with fragmentation has shown that missassociated or 120 lost fragments can lead to poor network behavior and, eventually, 121 trouble at application layer. The reader is encouraged to read 122 [RFC4963] and follow the references for more information. That 123 experience led to the definition of the Path MTU discovery [RFC1191] 124 protocol that limits fragmentation over the Internet. 126 For one-hop communications, a number of media propose a local 127 acknowledgment mechanism that is enough to protect the fragments. In 128 a multihop environment, an end-to-end fragment recovery mechanism 129 might be a good complement to a hop-by-hop MAC level recovery. This 130 draft introduces a simple protocol to recover individual fragments 131 between 6LoWPAN endpoints. Specifically in the case of UDP, valuable 132 additional information can be found in UDP Usage Guidelines for 133 Application Designers [RFC5405]. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 Readers are expected to be familiar with all the terms and concepts 142 that are discussed in "IPv6 over Low-Power Wireless Personal Area 143 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 144 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 145 Networks" [RFC4944]. 147 ERP 149 Error Recovery Procedure. 151 6LoWPAN endpoints 153 The LLN nodes in charge of generating or expanding a 6LoWPAN 154 header from/to a full IPv6 packet. The 6LoWPAN endpoints are the 155 points where fragmentation and reassembly take place. 157 3. Rationale 159 There are a number of uses for large packets in Wireless Sensor 160 Networks. Such usages may not be the most typical or represent the 161 largest amount of traffic over the LLN; however, the associated 162 functionality can be critical enough to justify extra care for 163 ensuring effective transport of large packets across the LLN. 165 The list of those usages includes: 167 Towards the LLN node: 169 Packages of Commands: A number of commands or a full 170 configuration can by packaged as a single message to ensure 171 consistency and enable atomic execution or complete roll back. 172 Until such commands are fully received and interpreted, the 173 intended operation will not take effect. 175 Firmware update: For example, a new version of the LLN node 176 software is downloaded from a system manager over unicast or 177 multicast services. Such a reflashing operation typically 178 involves updating a large number of similar LLN nodes over a 179 relatively short period of time. 181 From the LLN node: 183 Waveform captures: A number of consecutive samples are measured 184 at a high rate for a short time and then transferred from a 185 sensor to a gateway or an edge server as a single large report. 187 Data logs: LLN nodes may generate large logs of sampled data for 188 later extraction. LLN nodes may also generate system logs to 189 assist in diagnosing problems on the node or network. 191 Large data packets: Rich data types might require more than one 192 fragment. 194 Uncontrolled firmware download or waveform upload can easily result 195 in a massive increase of the traffic and saturate the network. 197 When a fragment is lost in transmission, all fragments are resent, 198 further contributing to the congestion that caused the initial loss, 199 and potentially leading to congestion collapse. 201 This saturation may lead to excessive radio interference, or random 202 early discard (leaky bucket) in relaying nodes. Additional queuing 203 and memory congestion may result while waiting for a low power next 204 hop to emerge from its sleeping state. 206 To demonstrate the severity of the problem, consider a fairly 207 reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4 208 hop. The expected delivery rate of a 5-fragment datagram would be 209 about 99.5% over a single 802.15.4 hop. However, the expected 210 delivery rate would drop to 95.1% over 10 hops, a reasonable network 211 diameter for LLN applications. The expected delivery rate for a 212 1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops. 214 Considering that [RFC4944] defines an MTU is 1280 bytes and that in 215 most incarnations (but 802.15.4G) a 802.15.4 frame can limit the MAC 216 payload to as few as 74 bytes, a packet might be fragmented into at 217 least 18 fragments at the 6LoWPAN shim layer. Taking into account 218 the worst-case header overhead for 6LoWPAN Fragmentation and Mesh 219 Addressing headers will increase the number of required fragments to 220 around 32. This level of fragmentation is much higher than that 221 traditionally experienced over the Internet with IPv4 fragments. At 222 the same time, the use of radios increases the probability of 223 transmission loss and Mesh-Under techniques compound that risk over 224 multiple hops. 226 4. Requirements 228 This paper proposes a method to recover individual fragments between 229 LLN endpoints. The method is designed to fit the following 230 requirements of a LLN (with or without a Mesh-Under routing 231 protocol): 233 Number of fragments 235 The recovery mechanism must support highly fragmented packets, 236 with a maximum of 32 fragments per packet. 238 Minimum acknowledgment overhead 239 Because the radio is half duplex, and because of silent time spent 240 in the various medium access mechanisms, an acknowledgment 241 consumes roughly as many resources as data fragment. 243 The recovery mechanism should be able to acknowledge multiple 244 fragments in a single message and not require an acknowledgment at 245 all if fragments are already protected at a lower layer. 247 Controlled latency 249 The recovery mechanism must succeed or give up within the time 250 boundary imposed by the recovery process of the Upper Layer 251 Protocols. 253 Support for out-of-order fragment delivery 255 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 256 Layer can introduce out-of-sequence packets. 258 The recovery mechanism must account for packets that appear lost 259 but are actually only delayed over a different path. 261 Optional congestion control 263 The aggregation of multiple concurrent flows may lead to the 264 saturation of the radio network and congestion collapse. 266 The recovery mechanism should provide means for controlling the 267 number of fragments in transit over the LLN. 269 5. Overview 271 Considering that a multi-hop LLN can be a very sensitive environment 272 due to the limited queuing capabilities of a large population of its 273 nodes, this draft recommends a simple and conservative approach to 274 congestion control, based on TCP congestion avoidance. 276 Congestion on the forward path is assumed in case of packet loss, and 277 packet loss is assumed upon time out. The draft allows to control 278 the number of outstanding fragments, that have been transmitted but 279 for which an acknowledgment was not received yet. It must be noted 280 that the number of outstanding fragments should not exceed the number 281 of hops in the network, but the way to figure the number of hops is 282 out of scope for this document. 284 Congestion on the forward path can also be indicated by an Explicit 285 Congestion Notification (ECN) mechanism. Though whether and how ECN 286 [RFC3168] is carried out over the LoWPAN is out of scope, this draft 287 provides a way for the destination endpoint to echo an ECN indication 288 back to the source endpoint in an acknowledgment message as 289 represented in Figure 5 in Section 6.2. 291 It must be noted that congestion and collision are different topics. 292 In particular, when a mesh operates on a same channel over multiple 293 hops, then the forwarding of a fragment over a certain hop may 294 collide with the forwarding of a next fragment that is following over 295 a previous hop but in a same interference domain. This draft enables 296 an end-to-end flow control, but leaves it to the sender stack to pace 297 individual fragments within a transmit window, so that a given 298 fragment is sent only when the previous fragment has had a chance to 299 progress beyond the interference domain of this hop. In the case of 300 6TiSCH [I-D.ietf-6tisch-architecture], which operates over the 301 TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) mode of 302 operation of IEEE802.14.5, a fragment is forwarded over a different 303 channel at a different time and it make full sense to fire a next 304 fragment as soon as the previous fragment has had its chance to be 305 forwarded at the next hop, retry (ARQ) operations included. 307 From the standpoint of a source 6LoWPAN endpoint, an outstanding 308 fragment is a fragment that was sent but for which no explicit 309 acknowledgment was received yet. This means that the fragment might 310 be on the way, received but not yet acknowledged, or the 311 acknowledgment might be on the way back. It is also possible that 312 either the fragment or the acknowledgment was lost on the way. 314 Because a meshed LLN might deliver frames out of order, it is 315 virtually impossible to differentiate these situations. In other 316 words, from the sender standpoint, all outstanding fragments might 317 still be in the network and contribute to its congestion. There is 318 an assumption, though, that after a certain amount of time, a frame 319 is either received or lost, so it is not causing congestion anymore. 320 This amount of time can be estimated based on the round trip delay 321 between the 6LoWPAN endpoints. The method detailed in [RFC6298] is 322 recommended for that computation. 324 The reader is encouraged to read through "Congestion Control 325 Principles" [RFC2914]. Additionally [RFC2309] and [RFC5681] provide 326 deeper information on why this mechanism is needed and how TCP 327 handles Congestion Control. Basically, the goal here is to manage 328 the amount of fragments present in the network; this is achieved by 329 to reducing the number of outstanding fragments over a congested path 330 by throttling the sources. 332 Section 7 describes how the sender decides how many fragments are 333 (re)sent before an acknowledgment is required, and how the sender 334 adapts that number to the network conditions. 336 6. New Dispatch types and headers 338 This specification extends "Transmission of IPv6 Packets over IEEE 339 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for 340 Recoverable Fragments (RFRAG) headers with or without Acknowledgment 341 Request, and for the Acknowledgment back, with or without ECN Echo. 343 Pattern Header Type 344 +------------+-----------------------------------------------+ 345 | 11 101000 | RFRAG - Recoverable Fragment | 346 | 11 101001 | RFRAG-AR - RFRAG with Ack Request | 347 | 11 101010 | RFRAG-ACK - RFRAG Acknowledgment | 348 | 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo | 349 +------------+-----------------------------------------------+ 351 Figure 1: Additional Dispatch Value Bit Patterns 353 In the following sections, the semantics of "datagram_tag", 354 "datagram_offset" and "datagram_size" and the reassembly process are 355 changed from [RFC4944] Section 5.3. "Fragmentation Type and Header." 356 The size and offset are expressed on the compressed packet per 357 [RFC6282] as opposed to the uncompressed - native packet - form. 359 6.1. Recoverable Fragment Dispatch type and Header 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 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |Sequence | datagram_size | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 X set == Ack Requested 370 Figure 2: Recoverable Fragment Dispatch type and Header 372 X: 1 bit; When set, the sender requires an Acknowledgment from the 373 receiver 375 Sequence: 5 bits; The sequence number of the fragment. Fragments 376 are numbered [0..N] where N is in [0..31]. 378 6.2. Fragment acknowledgment Dispatch type and Header 380 The specification also defines a 4-octet acknowledgment bitmap that 381 is used to carry selective acknowledgments for the received 382 fragments. A given offset in the bitmap maps one to one with a given 383 sequence number. 385 The offset of the bit in the bitmap indicates which fragment is 386 acknowledged as follows: 388 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Acknowledgment Bitmap | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 ^ ^ 394 | | bitmap indicating whether: 395 | +--- Fragment with sequence 10 was received 396 +----------------------- Fragment with sequence 00 was received 398 Figure 3: Acknowledgment bitmap encoding 400 So in the example below Figure 4 it appears that all fragments from 401 sequence 0 to 20 were received but for sequence 1, 2 and 16 that were 402 either lost or are still in the network over a slower path. 404 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |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| 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 4: Expanding 3 octets encoding 412 The acknowledgment bitmap is carried in a Fragment Acknowledgment as 413 follows: 415 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 |1 1 1 0 1 0 1 Y| datagram_tag | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Acknowledgment Bitmap (32 bits) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 5: Fragment Acknowledgment Dispatch type and Header 425 Y: 1 bit; Explicit Congestion Notification (ECN) signalling 427 When set, the sender indicates that at least one of the 428 acknowledged fragments was received with an Explicit Congestion 429 Notification, indicating that the path followed by the fragments 430 is subject to congestion. 432 acknowledgment Bitmap 433 An acknowledgment bitmap, whereby but at offset x indicates that 434 fragment x was received. 436 7. Fragments Recovery 438 The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the 439 original fragment headers from [RFC4944] and replace them in the 440 fragmented packets. The Fragment Acknowledgment RFRAG-ACK is 441 introduced as a standalone header in message that is sent back to the 442 fragment source endpoint as known by its MAC address. This assumes 443 that the source MAC address in the fragment (is any) and datagram_tag 444 are enough information to send the Fragment Acknowledgment back to 445 the source fragmentation endpoint. 447 The 6LoWPAN endpoint that fragments the packets at 6LoWPAN level (the 448 sender) controls the Fragment Acknowledgments. If may do that at any 449 fragment to implement its own policy or perform congestion control 450 which is out of scope for this document. When the sender of the 451 fragment knows that an underlying mechanism protects the Fragments 452 already it MAY refrain from using the Acknowledgment mechanism, and 453 never set the Ack Requested bit. The 6LoWPAN endpoint that 454 recomposes the packets at 6LoWPAN level (the receiver) MUST 455 acknowledge the fragments it has received when asked to, and MAY 456 slightly defer that acknowledgment. 458 The sender transfers a controlled number of fragments and MAY flag 459 the last fragment of a series with an acknowledgment request. The 460 received MUST acknowledge a fragment with the acknowledgment request 461 bit set. If any fragment immediately preceding an acknowledgment 462 request is still missing, the receiver MAY intentionally delay its 463 acknowledgment to allow in-transit fragments to arrive. delaying the 464 acknowledgment might defeat the round trip delay computation so it 465 should be configurable and not enabled by default. 467 The receiver interacts with the sender using an Acknowledgment 468 message with a bitmap that indicates which fragments were actually 469 received. The bitmap is a 32bit SWORD, which accommodates up to 32 470 fragments and is sufficient for the 6LoWPAN MTU. For all n in 471 [0..31], bit n is set to 1 in the bitmap to indicate that fragment 472 with sequence n was received, otherwise the bit is set to 0. All 473 zeros is a NULL bitmap that indicates that the fragmentation process 474 was canceled by the receiver for that datagram. 476 The receiver MAY issue unsolicited acknowledgments. An unsolicited 477 acknowledgment enables the sender endpoint to resume sending if it 478 had reached its maximum number of outstanding fragments or indicate 479 that the receiver has cancelled the process of an individual 480 datagram. Note that acknowledgments might consume precious resources 481 so the use of unsolicited acknowledgments should be configurable and 482 not enabled by default. 484 The sender arms a retry timer to cover the fragment that carries the 485 Acknowledgment request. Upon time out, the sender assumes that all 486 the fragments on the way are received or lost. The process must have 487 completed within an acceptable time that is within the boundaries of 488 upper layer retries. The method detailed in [RFC6298] is recommended 489 for the computation of the retry timer. It is expected that the 490 upper layer retries obey the same or friendly rules in which case a 491 single round of fragment recovery should fit within the upper layer 492 recovery timers. 494 Fragments are sent in a round robin fashion: the sender sends all the 495 fragments for a first time before it retries any lost fragment; lost 496 fragments are retried in sequence, oldest first. This mechanism 497 enables the receiver to acknowledge fragments that were delayed in 498 the network before they are actually retried. 500 When the sender decides that a packet should be dropped and the 501 fragmentation process canceled, it sends a pseudo fragment with the 502 datagram_offset, sequence and datagram_size all set to zero, and no 503 data. Upon reception of this message, the receiver should clean up 504 all resources for the packet associated to the datagram_tag. If an 505 acknowledgment is requested, the receiver responds with a NULL 506 bitmap. 508 The receiver might need to cancel the process of a fragmented packet 509 for internal reasons, for instance if it is out of recomposition 510 buffers, or considers that this packet is already fully recomposed 511 and passed to the upper layer. In that case, the receiver SHOULD 512 indicate so to the sender with a NULL bitmap. Upon an acknowledgment 513 with a NULL bitmap, the sender MUST drop the datagram. 515 8. Forwarding Fragments 517 This specification enables intermediate routers to forward fragments 518 with no intermediate reconstruction of the entire packet. Upon the 519 first fragment, the routers lay an label along the path that is 520 followed by that fragment (that is IP routed), and all further 521 fragments are label switched along that path. As a consequence, 522 alternate routes not possible for individual fragments. The 523 datagram_tag is used to carry the label, that is swapped at each hop. 525 8.1. Upon the first fragment 527 In route over the L2 source changes at each hop. The label that is 528 formed and placed in the datagram_tag is associated to the source MAC 529 and only valid (and unique) for that source MAC. Say the first 530 fragment has: 532 Source IPv6 address = IP_A (maybe hops away) 534 Destination IPv6 address = IP_B (maybe hops away) 536 Source MAC = MAC_prv (prv as previous) 538 Datagram_tag= DT_prv 540 The intermediate router that forwards individual fragments does the 541 following: 543 a route lookup to get Next hop IPv6 towards IP_B, which resolves 544 as IP_nxt (nxt as next) 546 a MAC address resolution to get the MAC address associated to 547 IP_nxt, which resolves as MAC_nxt 549 Since it is a first fragment of a packet from that source MAC address 550 MAC_prv for that tag DT_prv, the router: 552 cleans up any leftover resource associated to the tupple (MAC_prv, 553 DT_prv) 555 allocates a new label for that flow, DT_nxt, from a Least Recently 556 Used pool or some siumilar procedure. 558 allocates a Label swap structure indexed by (MAC_prv, DT_prv) that 559 contains (MAC_nxt, DT_nxt) 561 allocates a Label swap structure indexed by (MAC_nxt, DT_nxt) that 562 contains (MAC_prv, DT_prv) 564 swaps the MAC info to from self to MAC_nxt 566 Swaps the datagram_tag to DT_nxt 568 At this point the router is all set and can forward the packet to 569 nxt. 571 8.2. Upon the next fragments 573 Upon next fragments (that are not first fragment), the router expects 574 to have already Label swap structure indexed by (MAC_prv, DT_prv). 575 The router: 577 lookups up the Label swap entry for (MAC_prv, DT_prv), which 578 resolves as (MAC_nxt, DT_nxt) 580 swaps the MAC info to from self to MAC_nxt; 582 Swaps the datagram_tag to DT_nxt 584 At this point the router is all set and can forward the packet to 585 nxt. 587 if the Label swap entry for (MAC_src, DT_src) is not found, the 588 router builds an RFRAG-ACK to indicate the error. The acknowledgment 589 message has the following information: 591 MAC info set to from self to MAC_prv as found in the fragment 593 Swaps the datagram_tag set to DT_prv 595 Bitmap of all zeroes to indicate the error 597 At this point the router is all set and can send the RFRAG-ACK back 598 ot the previous router. 600 8.3. Upon the fragment acknowledgments 602 Upon fragment acknowledgments next fragments (that are not first 603 fragment), the router expects to have already Label swap structure 604 indexed by (MAC_nxt, DT_nxt). The router: 606 lookups up the Label swap entry for (MAC_nxt, DT_nxt), which 607 resolves as (MAC_prv, DT_prv) 609 swaps the MAC info to from self to MAC_prv; 611 Swaps the datagram_tag to DT_prv 613 At this point the router is all set and can forward the RFRAG-ACK to 614 prv. 616 if the Label swap entry for (MAC_nxt, DT_nxt) is not found, it simply 617 drops the packet. 619 if the RFRAG-ACK indicates either an error or that the fragment was 620 fully receive, the router schedules the Label swap entries for 621 recycling. If the RFRAG-ACK is lost on the way back, the source may 622 retry the last fragments, which will result as an error RFRAG-ACK 623 from the first router on the way that has already cleaned up. 625 9. Security Considerations 627 The process of recovering fragments does not appear to create any 628 opening for new threat compared to "Transmission of IPv6 Packets over 629 IEEE 802.15.4 Networks" [RFC4944]. 631 10. IANA Considerations 633 Need extensions for formats defined in "Transmission of IPv6 Packets 634 over IEEE 802.15.4 Networks" [RFC4944]. 636 11. Acknowledgments 638 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 639 Kolavennu, Pat Kinney, Margaret Wasserman, Richard Kelsey, Carsten 640 Bormann and Harry Courtice for their contributions and review. 642 12. References 644 12.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, 648 DOI 10.17487/RFC2119, March 1997, 649 . 651 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 652 "Transmission of IPv6 Packets over IEEE 802.15.4 653 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 654 . 656 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 657 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 658 DOI 10.17487/RFC6282, September 2011, 659 . 661 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 662 "Computing TCP's Retransmission Timer", RFC 6298, 663 DOI 10.17487/RFC6298, June 2011, 664 . 666 12.2. Informative References 668 [I-D.ietf-6tisch-architecture] 669 Thubert, P., "An Architecture for IPv6 over the TSCH mode 670 of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work 671 in progress), June 2016. 673 [I-D.ietf-6tisch-tsch] 674 Watteyne, T., Palattella, M., and L. Grieco, "Using 675 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 676 Statement and Goals", draft-ietf-6tisch-tsch-06 (work in 677 progress), March 2015. 679 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 680 DOI 10.17487/RFC1191, November 1990, 681 . 683 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 684 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 685 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 686 S., Wroclawski, J., and L. Zhang, "Recommendations on 687 Queue Management and Congestion Avoidance in the 688 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 689 . 691 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 692 RFC 2914, DOI 10.17487/RFC2914, September 2000, 693 . 695 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 696 of Explicit Congestion Notification (ECN) to IP", 697 RFC 3168, DOI 10.17487/RFC3168, September 2001, 698 . 700 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 701 over Low-Power Wireless Personal Area Networks (6LoWPANs): 702 Overview, Assumptions, Problem Statement, and Goals", 703 RFC 4919, DOI 10.17487/RFC4919, August 2007, 704 . 706 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 707 Errors at High Data Rates", RFC 4963, 708 DOI 10.17487/RFC4963, July 2007, 709 . 711 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 712 for Application Designers", BCP 145, RFC 5405, 713 DOI 10.17487/RFC5405, November 2008, 714 . 716 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 717 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 718 . 720 Authors' Addresses 722 Pascal Thubert (editor) 723 Cisco Systems, Inc 724 Building D 725 45 Allee des Ormes - BP1200 726 MOUGINS - Sophia Antipolis 06254 727 FRANCE 729 Phone: +33 497 23 26 34 730 Email: pthubert@cisco.com 732 Jonathan W. Hui 733 Nest Labs 734 3400 Hillview Ave 735 Palo Alto, California 94304 736 USA 738 Email: jonhui@nestlabs.com