idnits 2.17.00 (12 Aug 2021) /tmp/idnits55702/draft-thubert-6lowpan-simple-fragment-recovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2009) is 4807 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 437, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: draft-ietf-tsvwg-udp-guidelines has been published as RFC 5405 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track March 23, 2009 5 Expires: September 24, 2009 7 LoWPAN simple fragment Recovery 8 draft-thubert-6lowpan-simple-fragment-recovery-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 24, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Considering that 6LoWPAN packets can be as large as 2K bytes and that 47 an 802.15.4 frame with security will carry in the order of 80 bytes 48 of effective payload, a packet might end up fragmented into as many 49 as 25 fragments at the 6LoWPAN shim layer. If a single one of those 50 fragments is lost in transmission, all fragments must be resent, 51 further contributing to the congestion that might have caused the 52 initial packet loss. This draft introduces a simple protocol to 53 recover individual fragments between 6LoWPAN endpoints. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7 63 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7 64 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 65 7. Outstanding Fragments Control . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Considering that 6LoWPAN packets can be as large as 2K bytes and that 77 a 802.15.4 frame with security will carry in the order of 80 bytes of 78 effective payload, a packet might be fragmented into about 25 79 fragments at the 6LoWPAN shim layer. This level of fragmentation is 80 much higher than that traditionally experienced over the Internet 81 with IPv4 fragments. At the same time, the use of radios increases 82 the probability of transmission loss and Mesh-Under techniques 83 compound that risk over multiple hops. 85 Past experience with fragmentation has shown that missassociated or 86 lost fragments can lead to poor network behaviour and, eventually, 87 trouble at application layer. The reader is encouraged to read 88 [RFC4963] and follow the references for more information. That 89 experience led to the definition of the Path MTU discovery [RFC1191] 90 protocol that limits fragmentation over the Internet. 92 An end-to-end fragment recovery mechanism might be a good complement 93 to a hop-by-hop MAC level recovery with a limited number of retries. 94 This draft introduces a simple protocol to recover individual 95 fragments between 6LoWPAN endpoints. Specifically in the case of 96 UDP, valuable additional information can be found in UDP Usage 97 Guidelines for Application Designers [I-D.ietf-tsvwg-udp-guidelines]. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 Readers are expected to be familiar with all the terms and concepts 106 that are discussed in "IPv6 over Low-Power Wireless Personal Area 107 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 108 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 109 Networks" [RFC4944]. 111 ERP 113 Error Recovery Procedure. 115 LoWPAN endpoints 117 The LoWPAN nodes in charge of generating or expanding a 6LoWPAN 118 header from/to a full IPv6 packet. The LoWPAN endpoints are the 119 points where fragmentation and reassembly take place. 121 3. Rationale 123 There are a number of usages for large packets in Wireless Sensor 124 Networks. Such usages may not be the most typical or represent the 125 largest amount of traffic over the LoWPAN; however, the associated 126 functionality can be critical enough to justify extra care for 127 ensuring effective transport of large packets across the LoWPAN. 129 The list of those usages includes: 131 Towards the LoWPAN node: 133 Packages of Commands: A number of commands or a full 134 configuration can by packaged as a single message to ensure 135 consistency and enable atomic execution or complete roll back. 136 Until such commands are fully received and interpreted, the 137 intended operation will not take effect. 139 Firmware update: For example, a new version of the LoWPAN node 140 software is downloaded from a system manager over unicast or 141 multicast services. Such a reflashing operation typically 142 involves updating a large number of similar 6LoWPAN nodes over 143 a relatively short period of time. 145 From the LoWPAN node: 147 Waveform captures: A number of consecutive samples are measured 148 at a high rate for a short time and then transferred from a 149 sensor to a gateway or an edge server as a single large report. 151 Large data packets: Rich data types might require more than one 152 fragment. 154 Uncontrolled firmware download or waveform upload can easily result 155 in a massive increase of the traffic and saturate the network. 157 When a fragment is lost in transmission, all fragments are resent, 158 further contributing to the congestion that caused the initial loss, 159 and potentially leading to congestion collapse. 161 This saturation may lead to excessive radio interference, or random 162 early discard (leaky bucket) in relaying nodes. Additional queueing 163 and memory congestion may result while waiting for a low power next 164 hop to emerge from its sleeping state. 166 4. Requirements 168 This paper proposes a method to recover individual fragments between 169 LoWPAN endpoints. The method is designed to fit the following 170 requirements of a LoWPAN (with or without a Mesh-Under routing 171 protocol): 173 Number of fragments 175 The recovery mechanism must support highly fragmented packets, 176 with a maximum of 32 fragments per packet. 178 Minimum acknowledgement overhead 180 Because the radio is half duplex, and because of silent time spent 181 in the various medium access mechanisms, an acknowledgement 182 consumes roughly as many resources as data fragment. 184 The recovery mechanism should be able to acknowledge multiple 185 fragments in a single message. 187 Controlled latency 189 The recovery mechanism must succeed or give up within the time 190 boundary imposed by the recovery process of the Upper Layer 191 Protocols. 193 Support for out-of-order fragment delivery 195 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 196 Layer can introduce out-of-sequence packets. The recovery 197 mechanism must account for packets that appear lost but are 198 actually only delayed over a different path. 200 Optional congestion control 202 The aggregation of multiple concurrent flows may lead to the 203 saturation of the radio network and congestion collapse. 205 The recovery mechanism should provide means for controlling the 206 number of fragments in transit over the LoWPAN. 208 Backward compatibility 210 A node that implements this draft should be able to communicate 211 with a node that implements [RFC4944]. This draft assumes that 212 compatibility information about the remote LoWPAN endpoint is 213 obtained by external means. 215 5. Overview 217 Considering that a multi-hop LoWPAN can be a very sensitive 218 environment due to the limited queueing capabilities of a large 219 population of its nodes, this draft recommends a simple and 220 conservative approach to congestion control, based on TCP congestion 221 avoidance. 223 Congestion on the forward path is assumed in case of packet loss, and 224 packet loss is assumed upon time out. 226 Congestion on the forward path can also be indicated by an Explicit 227 Congestion Notification (ECN) mechanism. Though whether and how ECN 228 [RFC3168] is carried out over the LoWPAN is out of scope, this draft 229 provides a way for the destination endpoint to echo an ECN indication 230 back to the source endpoint in an acknowledgement message as 231 represented in Figure 3 in Section 6.2. 233 From the standpoint of a source LoWPAN endpoint, an outstanding 234 fragment is a fragment that was sent but for which no explicit 235 acknowledgement was received yet. This means that the fragment might 236 be on the way, received but not yet acknowledged, or the 237 acknowledgement might be on the way back. It is also possible that 238 either the fragment or the acknowledgement was lost on the way. 240 Because a meshed LoWPAN might deliver frames out of order, it is 241 virtually impossible to differentiate these situations. In other 242 words, from the sender standpoint, all outstanding fragments might 243 still be in the network and contribute to its congestion. There is 244 an assumption, though, that after a certain amount of time, a frame 245 is either received or lost, so it is not causing congestion anymore. 246 This amount of time can be estimated based on the round trip delay 247 between the LoWPAN endpoints. The method detailed in [RFC2988] is 248 recommended for that computation. 250 The reader is encouraged to read through "Congestion Control 251 Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide 252 deeper information on why this mechanism is needed and how TCP 253 handles Congestion Control. Basically, the goal here is to manage 254 the amount of fragments present in the network; this is achieved by 255 to reducing the number of outstanding fragments over a congested path 256 by throttling the sources. 258 Section 7 describes how the sender decides how many fragments are 259 (re)sent before an acknowledgement is required, and how the sender 260 adapts that number to the network conditions. 262 6. New Dispatch types and headers 264 This specification extends "Transmission of IPv6 Packets over IEEE 265 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for 266 Recoverable Fragments (RFRAG) headers with or without Acknowledgement 267 Request, and for the Acknowledgement back, with or without ECN Echo. 269 Pattern Header Type 270 +------------+-----------------------------------------------+ 271 | 11 101000 | RFRAG - Recoverable Fragment | 272 | 11 101001 | RFRAG-AR - RFRAG with Ack Request | 273 | 11 101010 | RFRAG-ACK - RFRAG Acknowledgement | 274 | 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo | 275 +------------+-----------------------------------------------+ 277 Figure 1: Additional Dispatch Value Bit Patterns 279 In the following sections, the semantics of "datagram_tag," 280 "datagram_offset" and "datagram_size" and the reassembly process are 281 unchanged from [RFC4944] Section 5.3. "Fragmentation Type and 282 Header." 284 6.1. Recoverable Fragment Dispatch type and Header 286 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |Sequence | datagram_size | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 X set == Ack Requested 295 Figure 2: Recoverable Fragment Dispatch type and Header 297 X bit 299 When set, the sender requires an Acknowledgement from the receiver 301 Sequence 302 The sequence number of the fragment. Fragments are numbered 303 [0..N] where N is in [0..31]. 305 6.2. Fragment Acknowledgement Dispatch type and Header 307 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |1 1 1 0 1 0 1 Y| datagram_tag | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Acknowledgement Bitmap | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ^ ^ 315 | | Y set == ECN echo 316 | | 317 | | bitmap indicating whether 318 | +-----Fragment with sequence 10 was received 319 +-------------------------Fragment with sequence 00 was received 321 Figure 3: Fragment Acknowledgement Dispatch type and Header 323 Y bit 325 When set, the sender indicates that at least one of the 326 acknowledged fragments was received with an Explicit Congestion 327 Notification, indicating that the path followed by the fragments 328 is subject to congestion. 330 Acknowledgement Bitmap 332 Each bit in the Bitmap refers to a particular fragment: bit n set 333 indicates that fragment with sequence n was received, for n in 334 [0..31]. 336 All zeroes means that the fragment was dropped because it 337 corresponds to an obsolete datagram_tag. This happens if the 338 packet was already reassembled and passed to the network upper 339 layer, or the packet expired and was dropped. 341 7. Outstanding Fragments Control 343 A mechanism based on TCP congestion avoidance dictates the maximum 344 number of outstanding fragments. 346 The maximum number of outstanding fragments for a given packet toward 347 a given LoWPAN endpoint is initially set to a configured value, 348 unless recent history indicates otherwise. 350 Each time that maximum number of fragments is fully acknowledged, 351 that number can be incremented by 1. ECN echo and packet loss cause 352 the number to be divided by 2. 354 The sender transfers a controlled number of fragments and flags the 355 last fragment of a series with an acknowledgement request. 357 The sender arms a timer to cover the fragment that carries the 358 Acknowledgement request. Upon time out, the sender assumes that all 359 the fragments on the way are received or lost. It divides the 360 maximum number of outstanding fragments by 2 and resets the number of 361 outstanding fragments to 0. 363 Upon receipt of an Acknowledgement request, the receiver responds 364 with an Acknowledgement containing a bitmap that indicates which 365 fragments were actually received. The bitmap is a 32bit DWORD, which 366 accommodates up to 32 fragments and is sufficient for the 6LoWPAN 367 MTU. For all n in [0..31], bit n is set to 1 in the bitmap to 368 indicate that fragment with sequence n was received, otherwise the 369 bit is set to 0. 371 The receiver MAY issue unsolicited acknowledgements. An unsolicited 372 acknowledgement enables the sender endpoint to resume sending if it 373 had reached its maximum number of outstanding fragments. Note that 374 acknowledgements might consume precious resources so the use of 375 unsolicited acknowledgements should be configurable and not enabled 376 by default. 378 The received MUST acknowledge a fragment with the acknowledgement 379 request bit set. If any fragment immediately preceding an 380 acknowledgement request is still missing, the receiver MAY 381 intentionally delay its acknowledgement to allow in-transit fragments 382 to arrive. This mechanism might defeat the round trip delay 383 computation so it should be configurable and not enabled by default. 385 Fragments are sent in a round robin fashion: the sender sends all the 386 fragments for a first time before it retries any lost fragment; lost 387 fragments are retried in sequence, oldest first. This mechanism 388 enables the receiver to acknowledge fragments that were delayed in 389 the network before they are actually retried. 391 The process must complete within an acceptable time that is within 392 the boundaries of upper layer retries. Additional work is required 393 to define how this is achieved. When the source endpoint decides 394 that a packet should be dropped and the fragmentation process 395 cancelled, it sends a pseudo fragment with the datagram_offset, 396 sequence and datagram_size all set to zero, and no data. Upon 397 reception of this message, the receiver should clean up all resources 398 for the packet associated to the datagram_tag. 400 8. Security Considerations 402 The process of recovering fragments does not appear to create any 403 opening for new threat. 405 9. IANA Considerations 407 Need extensions for formats defined in "Transmission of IPv6 Packets 408 over IEEE 802.15.4 Networks" [RFC4944]. 410 10. Acknowledgments 412 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 413 Kolavennu and Harry Courtice for their contribution and review. 415 11. References 417 11.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 423 Timer", RFC 2988, November 2000. 425 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 426 "Transmission of IPv6 Packets over IEEE 802.15.4 427 Networks", RFC 4944, September 2007. 429 11.2. Informative References 431 [I-D.ietf-tsvwg-udp-guidelines] 432 Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 433 for Application Designers", 434 draft-ietf-tsvwg-udp-guidelines-11 (work in progress), 435 October 2008. 437 [I-D.mathis-frag-harmful] 438 Mathis, M., "Fragmentation Considered Very Harmful", 439 draft-mathis-frag-harmful-00 (work in progress), 440 July 2004. 442 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 443 November 1990. 445 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 446 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 447 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 448 S., Wroclawski, J., and L. Zhang, "Recommendations on 449 Queue Management and Congestion Avoidance in the 450 Internet", RFC 2309, April 1998. 452 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 453 Control", RFC 2581, April 1999. 455 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 456 RFC 2914, September 2000. 458 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 459 of Explicit Congestion Notification (ECN) to IP", 460 RFC 3168, September 2001. 462 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 463 over Low-Power Wireless Personal Area Networks (6LoWPANs): 464 Overview, Assumptions, Problem Statement, and Goals", 465 RFC 4919, August 2007. 467 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 468 Errors at High Data Rates", RFC 4963, July 2007. 470 Author's Address 472 Pascal Thubert (editor) 473 Cisco Systems 474 Village d'Entreprises Green Side 475 400, Avenue de Roumanille 476 Batiment T3 477 Biot - Sophia Antipolis 06410 478 FRANCE 480 Phone: +33 4 97 23 26 34 481 Email: pthubert@cisco.com