idnits 2.17.1 draft-thubert-6lowpan-simple-fragment-recovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. 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 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 (May 23, 2008) is 5809 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) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-07 -- 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 (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track May 23, 2008 5 Expires: November 24, 2008 7 LoWPAN simple fragment Recovery 8 draft-thubert-6lowpan-simple-fragment-recovery-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 Considering that 6LoWPAN packets can be as large as 2K bytes and that 42 an 802.15.4 frame with security will carry in the order of 80 bytes 43 of effective payload, a packet might end up fragmented into as many 44 as 25 fragments at the 6LoWPAN shim layer. If a single one of those 45 fragments is lost in transmission, all fragments must be resent, 46 further contributing to the congestion that might have caused the 47 initial packet loss. This draft introduces a simple protocol to 48 recover individual fragments between 6LoWPAN endpoints. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7 58 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7 59 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 60 7. Outstanding Fragments Control . . . . . . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 Intellectual Property and Copyright Statements . . . . . . . . . . 12 70 1. Introduction 72 Considering that 6LoWPAN packets can be as large as 2K bytes and that 73 a 802.15.4 frame with security will carry in the order of 80 bytes of 74 effective payload, a packet might be fragmented into about 25 75 fragments at the 6LoWPAN shim layer. This level of fragmentation is 76 much higher than that traditionally experienced over the Internet 77 with IPv4 fragments. At the same time, the use of radios increases 78 the probability of transmission loss and Mesh-Under techniques 79 compound that risk over multiple hops. 81 Past experience with fragmentation has shown that missassociated or 82 lost fragments can lead to poor network behaviour and, eventually, 83 trouble at application layer. The reader might start his research 84 from [I-D.mathis-frag-harmful] and follow the references. That 85 experience led to the definition of the Path MTU discovery [RFC1191] 86 protocol that avoids fragmentation over the Internet. 88 An end-to-end fragment recovery mechanism might be a good complement 89 to a hop-by-hop MAC level recovery with a limited number of retries. 90 This draft introduces a simple protocol to recover individual 91 fragments between 6LoWPAN endpoints. Specifically in the case of 92 UDP, valuable additional information can be found in UDP Usage 93 Guidelines for Application Designers [I-D.ietf-tsvwg-udp-guidelines]. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 Readers are expected to be familiar with all the terms and concepts 102 that are discussed in "IPv6 over Low-Power Wireless Personal Area 103 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 104 Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 105 Networks" [RFC4944]. 107 ERP 109 Error Recovery Procedure. 111 LoWPAN endpoints 113 The LoWPAN nodes in charge of generating or expanding a 6LoWPAN 114 header from/to a full IPv6 packet. The LoWPAN endpoints are the 115 points where fragmentation and reassembly take place. 117 3. Rationale 119 There are a number of usages for large packets in Wireless Sensor 120 Networks. Such usages may not be the most typical or represent the 121 largest amount of traffic over the LoWPAN; however, the associated 122 functionality can be critical enough to justify extra care for 123 ensuring effective transport of large packets across the LoWPAN. 125 The list of those usages includes: 127 Towards the LoWPAN node: 129 Packages of Commands: A number of commands or a full 130 configuration can by packaged as a single message to ensure 131 consistency and enable atomic execution or complete roll back. 132 Until such commands are fully received and interpreted, the 133 intended operation will not take effect. 135 Firmware update: For example, a new version of the LoWPAN node 136 software is downloaded from a system manager over unicast or 137 multicast services. Such a reflashing operation typically 138 involves updating a large number of similar 6LoWPAN nodes over 139 a relatively short period of time. 141 From the LoWPAN node: 143 Waveform captures: A number of consecutive samples are measured 144 at a high rate for a short time and then transferred from a 145 sensor to a gateway or an edge server as a single large report. 147 Large data packets: Rich data types might require more than one 148 fragment. 150 Uncontrolled firmware download or waveform upload can easily result 151 in a massive increase of the traffic and saturate the network. 153 When a fragment is lost in transmission, all fragments are resent, 154 further contributing to the congestion that caused the initial loss, 155 and potentially leading to congestion collapse. 157 This saturation may lead to excessive radio interference, or random 158 early discard (leaky bucket) in relaying nodes. Additional queueing 159 and memory congestion may result while waiting for a low power next 160 hop to emerge from its sleeping state. 162 4. Requirements 164 This paper proposes a method to recover individual fragments between 165 LoWPAN endpoints. The method is designed to fit the following 166 requirements of a LoWPAN (with or without a Mesh-Under routing 167 protocol): 169 Number of fragments 171 The recovery mechanism must support highly fragmented packets, 172 with a maximum of 32 fragments per packet. 174 Minimimum acknowledgement overhead 176 Because the radio is half duplex, and because of silent time spent 177 in the various medium access mechanisms, an acknowledgement 178 consumes roughly as many resources as data fragment. 180 The recovery mechanism should be able to acknowledge multiple 181 fragments in a single message. 183 Controlled latency 185 The recovery mechanism must succeed or give up within the time 186 boundary imposed by the recovery process of the Upper Layer 187 Protocols. 189 Support for out-of-order fragment delivery 191 A Mesh-Under load balancing mechanism such as the ISA100 Data Link 192 Layer can introduce out-of-sequence packets. The recovery 193 mechanism must account for packets that appear lost but are 194 actually only delayed over a different path. 196 Optional flow control 198 The aggregation of multiple concurrent flows may lead to the 199 saturation of the radio network and congestion collapse. 201 The recovery mechanism should provide means for controlling the 202 number of fragments in transit over the LoWPAN. 204 Backward compatibility 206 A node that implements this draft should be able to communicate 207 with a node that implements [RFC4944]. This draft assumes that 208 compatibility information about the remote LoWPAN endpoint is 209 obtained by external means. 211 5. Overview 213 Considering that a multi-hop LoWPAN can be a very sensitive 214 environment due to the limited queueing capabilities of a large 215 population of its nodes, this draft recommends a simple and 216 conservative approach to flow control, based on TCP congestion 217 avoidance. 219 Congestion on the forward path is assumed in case of packet loss, and 220 packet loss is assumed upon time out. 222 Congestion on the forward path can also be indicated by an Explicit 223 Congestion Notification (ECN) mechanism. This draft provides a way 224 for the destination LoWPAN endpoint to echo en ECN indication back to 225 the source LoWPAN endpoint in an acknowledgement message as 226 represented in Figure 3 in Section 6.2. 228 From the standpoint of a source LoWPAN endpoint, an outstanding 229 fragment is a fragment that was sent but for which no explicit 230 acknowledgement was received yet. This means that the packet might 231 be on the way, received but not yet acknowledged, or the 232 acknowledgement might be on the way back. It is also possible that 233 either the fragment or the acknowledgement was lost on the way. 235 Because a meshed LoWPAN might deliver packets out of order, it is 236 virtually impossible to differentiate these situations. In other 237 words, from the sender standpoint, all outstanding packets might 238 still be in the network and contribute to its congestion. There is 239 an assumption, though, that after a certain amount of time, a packet 240 is either received or lost, so it is not causing congestion anymore. 241 This amount of time can be estimated based on the round trip delay 242 between the LoWPAN endpoints. The method detailed in [RFC2988] is 243 recommended for that computation. 245 The reader is encouraged to read through "Congestion Control 246 Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide 247 deeper information on why this mechanism is needed and how TCP 248 handles Congestion Control. Basically, the goal here is to manage 249 the amount of fragments present in the network; this is achieved by 250 to reducing the number of outstanding fragment over a congested path 251 by throttling the sources. 253 Whether and how ECN [RFC3168] is carried out over the LoWPAN is out 254 of scope for this draft. Section 7 describes how the sender decides 255 how many fragments are (re)sent before an acknowledgement is 256 required, and how the sender adapts that number to the network 257 conditions. 259 6. New Dispatch types and headers 261 This specification extends "Transmission of IPv6 Packets over IEEE 262 802.15.4 Networks" [RFC4944] with 3 new dispatch types, for 263 Recoverable Fragments (RFRAG) headers with or without Acknowledgement 264 Request, and for the Acknowledgement back. 266 Pattern Header Type 267 +------------+-----------------------------------------------+ 268 | 11 101000 | RFRAG - Recoverable Fragment | 269 | 11 101001 | RFRAG-AR - RFRAG with Acknowledgement Req | 270 | 11 101010 | RFRAG-ACK - RFRAG Acknowledgement | 271 +------------+-----------------------------------------------+ 273 Figure 1: Additional Dispatch Value Bit Patterns 275 In the following sections, the semantics of "datagram_tag," 276 "datagram_offset" and "datagram_size" and the reassembly process are 277 unchanged from [RFC4944] Section 5.3. "Fragmentation Type and 278 Header." 280 6.1. Recoverable Fragment Dispatch type and Header 282 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |Sequence | datagram_size | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X set == Ack Requested 290 Figure 2: Recoverable Fragment Dispatch type and Header 292 X bit 294 When set, the sender requires an Acknowledgement from the receiver 296 Sequence 298 The sequence number of the fragment. Fragments are numbered 299 [0..N] where N is in [0..31]. 301 6.2. Fragment Acknowledgement Dispatch type and Header 303 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |1 1 1 0 1 0 1 Y| datagram_tag | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Acknowledgement Bitmap | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+ 310 ^ ^ 311 | | Y set == Backward Explicit Congestion 312 | | Notification 313 | | bitmap indicating whether 314 | +-----Fragment with sequence 10 was received 315 +-------------------------Fragment with sequence 00 was received 317 Figure 3: Fragment Acknowledgement Dispatch type and Header 319 Y bit 321 When set, the sender indicates that at least one of the 322 acknowledged fragments was received with an Explicit Congestion 323 Notification, indicating that the path followed by the fragments 324 is subject to congestion. 326 Acknowledgement Bitmap 328 Each bit in the Bitmap refers to a particular fragment: bit n set 329 indicates that fragment with sequence n was received, for n in 330 [0..31]. 332 All zeroes means that the fragment was dropped because it 333 corresponds to an obsolete datagram_tag. This happens if the 334 packet was already reassembled and passed to the network upper 335 layer, or the packet expired and was dropped. 337 7. Outstanding Fragments Control 339 A mechanism based on TCP congestion avoidance dictates the maximum 340 number of outstanding fragments. 342 The maximum number of outstanding fragments for a given packet toward 343 a given LoWPAN endpoint is initially set to a configured value, 344 unless recent history indicates otherwise. Each time that maximum 345 number of fragments is fully acknowledged, that number can be 346 incremented by 1. ECN echo and packet loss cause the number to be 347 divided by 2. 349 The sender transfers a controlled number of fragments and flags the 350 last fragment of a series with an acknowledgement request. 352 The sender arms a timer to cover the fragment that carries the 353 Acknowledgement request. Upon time out, the sender assumes that all 354 the fragments on the way are received or lost. It divides the 355 maximum number of outstanding fragments by 2 and resets the number of 356 outstanding fragments to 0. 358 Upon receipt of an Acknowledgement request, the receiver responds 359 with an Acknowledgement containing a bitmap that indicates which 360 fragments were actually received. The bitmap is a 32bit DWORD, which 361 accommodates up to 32 fragments and is sufficient for the 6LoWPAN 362 MTU. For all n in [0..31], bit n is set to 1 in the bitmap to 363 indicate that fragment with sequence n was received, otherwise the 364 bit is set to 0. 366 The receiver MAY issue unsolicited acknowledgements. An unsolicited 367 acknowledgement enables the sender endpoint to resume sending if it 368 had reached its maximum number of outstanding fragments. Note that 369 acknowledgements might consume precious resources so the use of 370 unsolicited acknowledgements should be configurable and not enabled 371 by default. 373 The received MUST acknowledge a fragment with the acknowledgement 374 request bit set. If any fragment immediately preceding an 375 acknowledgement request is still missing, the receiver MAY 376 intentionally delay its acknowledgement to allow in-transit fragments 377 to arrive. This mechanism might defeat the round trip delay 378 computation so it should be configurable and not enabled by default. 380 Fragments are sent in a round robin fashion: the sender sends all the 381 fragments for a first time before it retries any lost fragment; lost 382 fragments are retried in sequence, oldest first. This mechanism 383 enables the receiver to acknowledge fragments that were delayed in 384 the network before they are actually retried. 386 The process must complete within an acceptable time that is within 387 the boundaries of upper layer retries. Additional work is required 388 to define how this is achieved. When the source endpoint decides 389 that a packet should be dropped and the fragmentation process 390 cancelled, it sends a pseudo fragment with the datagram_offset, 391 sequence and datagram_size all set to zero, and no data. Upon 392 reception of this message, the receiver should clean up all resources 393 for the packet associated to the datagram_tag. 395 8. Security Considerations 397 The process of recovering fragments does not appear to create any 398 opening for new threat. 400 9. IANA Considerations 402 Need extensions for formats defined in "Transmission of IPv6 Packets 403 over IEEE 802.15.4 Networks" [RFC4944]. 405 10. Acknowledgments 407 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 408 Kolavennu and Harry Courtice for their contribution and review. 410 11. References 412 11.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 418 Timer", RFC 2988, November 2000. 420 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 421 "Transmission of IPv6 Packets over IEEE 802.15.4 422 Networks", RFC 4944, September 2007. 424 11.2. Informative References 426 [I-D.ietf-tsvwg-udp-guidelines] 427 Eggert, L. and G. Fairhurst, "Guidelines for Application 428 Designers on Using Unicast UDP", 429 draft-ietf-tsvwg-udp-guidelines-07 (work in progress), 430 May 2008. 432 [I-D.mathis-frag-harmful] 433 Mathis, M., "Fragmentation Considered Very Harmful", 434 draft-mathis-frag-harmful-00 (work in progress), 435 July 2004. 437 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 438 November 1990. 440 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 441 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 442 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 443 S., Wroclawski, J., and L. Zhang, "Recommendations on 444 Queue Management and Congestion Avoidance in the 445 Internet", RFC 2309, April 1998. 447 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 448 Control", RFC 2581, April 1999. 450 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 451 RFC 2914, September 2000. 453 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 454 of Explicit Congestion Notification (ECN) to IP", 455 RFC 3168, September 2001. 457 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 458 over Low-Power Wireless Personal Area Networks (6LoWPANs): 459 Overview, Assumptions, Problem Statement, and Goals", 460 RFC 4919, August 2007. 462 Author's Address 464 Pascal Thubert 465 Cisco Systems 466 Village d'Entreprises Green Side 467 400, Avenue de Roumanille 468 Batiment T3 469 Biot - Sophia Antipolis 06410 470 FRANCE 472 Phone: +33 4 97 23 26 34 473 Email: pthubert@cisco.com 475 Full Copyright Statement 477 Copyright (C) The IETF Trust (2008). 479 This document is subject to the rights, licenses and restrictions 480 contained in BCP 78, and except as set forth therein, the authors 481 retain all their rights. 483 This document and the information contained herein are provided on an 484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 486 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 487 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 488 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Intellectual Property 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Acknowledgment 517 Funding for the RFC Editor function is provided by the IETF 518 Administrative Support Activity (IASA).