idnits 2.17.1 draft-thubert-6lowpan-simple-fragment-recovery-02.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 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 514. 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 29, 2008) is 5808 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 29, 2008 5 Expires: November 30, 2008 7 LoWPAN simple fragment Recovery 8 draft-thubert-6lowpan-simple-fragment-recovery-02 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 30, 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. Though whether and how ECN 224 [RFC3168] is carried out over the LoWPAN is out of scope, this draft 225 provides a way for the destination endpoint to echo an ECN indication 226 back to the source endpoint in an acknowledgement message as 227 represented in Figure 3 in Section 6.2. 229 From the standpoint of a source LoWPAN endpoint, an outstanding 230 fragment is a fragment that was sent but for which no explicit 231 acknowledgement was received yet. This means that the fragment might 232 be on the way, received but not yet acknowledged, or the 233 acknowledgement might be on the way back. It is also possible that 234 either the fragment or the acknowledgement was lost on the way. 236 Because a meshed LoWPAN might deliver frames out of order, it is 237 virtually impossible to differentiate these situations. In other 238 words, from the sender standpoint, all outstanding fragments might 239 still be in the network and contribute to its congestion. There is 240 an assumption, though, that after a certain amount of time, a frame 241 is either received or lost, so it is not causing congestion anymore. 242 This amount of time can be estimated based on the round trip delay 243 between the LoWPAN endpoints. The method detailed in [RFC2988] is 244 recommended for that computation. 246 The reader is encouraged to read through "Congestion Control 247 Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide 248 deeper information on why this mechanism is needed and how TCP 249 handles Congestion Control. Basically, the goal here is to manage 250 the amount of fragments present in the network; this is achieved by 251 to reducing the number of outstanding fragments over a congested path 252 by throttling the sources. 254 Section 7 describes how the sender decides how many fragments are 255 (re)sent before an acknowledgement is required, and how the sender 256 adapts that number to the network conditions. 258 6. New Dispatch types and headers 260 This specification extends "Transmission of IPv6 Packets over IEEE 261 802.15.4 Networks" [RFC4944] with 3 new dispatch types, for 262 Recoverable Fragments (RFRAG) headers with or without Acknowledgement 263 Request, and for the Acknowledgement back. 265 Pattern Header Type 266 +------------+-----------------------------------------------+ 267 | 11 101000 | RFRAG - Recoverable Fragment | 268 | 11 101001 | RFRAG-AR - RFRAG with Acknowledgement Req | 269 | 11 101010 | RFRAG-ACK - RFRAG Acknowledgement | 270 +------------+-----------------------------------------------+ 272 Figure 1: Additional Dispatch Value Bit Patterns 274 In the following sections, the semantics of "datagram_tag," 275 "datagram_offset" and "datagram_size" and the reassembly process are 276 unchanged from [RFC4944] Section 5.3. "Fragmentation Type and 277 Header." 279 6.1. Recoverable Fragment Dispatch type and Header 281 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |Sequence | datagram_size | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 == ECN echo 312 | | 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. 346 Each time that maximum number of fragments is fully acknowledged, 347 that number can be incremented by 1. ECN echo and packet loss cause 348 the number to be divided by 2. 350 The sender transfers a controlled number of fragments and flags the 351 last fragment of a series with an acknowledgement request. 353 The sender arms a timer to cover the fragment that carries the 354 Acknowledgement request. Upon time out, the sender assumes that all 355 the fragments on the way are received or lost. It divides the 356 maximum number of outstanding fragments by 2 and resets the number of 357 outstanding fragments to 0. 359 Upon receipt of an Acknowledgement request, the receiver responds 360 with an Acknowledgement containing a bitmap that indicates which 361 fragments were actually received. The bitmap is a 32bit DWORD, which 362 accommodates up to 32 fragments and is sufficient for the 6LoWPAN 363 MTU. For all n in [0..31], bit n is set to 1 in the bitmap to 364 indicate that fragment with sequence n was received, otherwise the 365 bit is set to 0. 367 The receiver MAY issue unsolicited acknowledgements. An unsolicited 368 acknowledgement enables the sender endpoint to resume sending if it 369 had reached its maximum number of outstanding fragments. Note that 370 acknowledgements might consume precious resources so the use of 371 unsolicited acknowledgements should be configurable and not enabled 372 by default. 374 The received MUST acknowledge a fragment with the acknowledgement 375 request bit set. If any fragment immediately preceding an 376 acknowledgement request is still missing, the receiver MAY 377 intentionally delay its acknowledgement to allow in-transit fragments 378 to arrive. This mechanism might defeat the round trip delay 379 computation so it should be configurable and not enabled by default. 381 Fragments are sent in a round robin fashion: the sender sends all the 382 fragments for a first time before it retries any lost fragment; lost 383 fragments are retried in sequence, oldest first. This mechanism 384 enables the receiver to acknowledge fragments that were delayed in 385 the network before they are actually retried. 387 The process must complete within an acceptable time that is within 388 the boundaries of upper layer retries. Additional work is required 389 to define how this is achieved. When the source endpoint decides 390 that a packet should be dropped and the fragmentation process 391 cancelled, it sends a pseudo fragment with the datagram_offset, 392 sequence and datagram_size all set to zero, and no data. Upon 393 reception of this message, the receiver should clean up all resources 394 for the packet associated to the datagram_tag. 396 8. Security Considerations 398 The process of recovering fragments does not appear to create any 399 opening for new threat. 401 9. IANA Considerations 403 Need extensions for formats defined in "Transmission of IPv6 Packets 404 over IEEE 802.15.4 Networks" [RFC4944]. 406 10. Acknowledgments 408 The author wishes to thank Jay Werb, Christos Polyzois, Soumitri 409 Kolavennu and Harry Courtice for their contribution and review. 411 11. References 413 11.1. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 419 Timer", RFC 2988, November 2000. 421 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 422 "Transmission of IPv6 Packets over IEEE 802.15.4 423 Networks", RFC 4944, September 2007. 425 11.2. Informative References 427 [I-D.ietf-tsvwg-udp-guidelines] 428 Eggert, L. and G. Fairhurst, "Guidelines for Application 429 Designers on Using Unicast UDP", 430 draft-ietf-tsvwg-udp-guidelines-07 (work in progress), 431 May 2008. 433 [I-D.mathis-frag-harmful] 434 Mathis, M., "Fragmentation Considered Very Harmful", 435 draft-mathis-frag-harmful-00 (work in progress), 436 July 2004. 438 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 439 November 1990. 441 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 442 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 443 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 444 S., Wroclawski, J., and L. Zhang, "Recommendations on 445 Queue Management and Congestion Avoidance in the 446 Internet", RFC 2309, April 1998. 448 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 449 Control", RFC 2581, April 1999. 451 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 452 RFC 2914, September 2000. 454 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 455 of Explicit Congestion Notification (ECN) to IP", 456 RFC 3168, September 2001. 458 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 459 over Low-Power Wireless Personal Area Networks (6LoWPANs): 460 Overview, Assumptions, Problem Statement, and Goals", 461 RFC 4919, August 2007. 463 Author's Address 465 Pascal Thubert 466 Cisco Systems 467 Village d'Entreprises Green Side 468 400, Avenue de Roumanille 469 Batiment T3 470 Biot - Sophia Antipolis 06410 471 FRANCE 473 Phone: +33 4 97 23 26 34 474 Email: pthubert@cisco.com 476 Full Copyright Statement 478 Copyright (C) The IETF Trust (2008). 480 This document is subject to the rights, licenses and restrictions 481 contained in BCP 78, and except as set forth therein, the authors 482 retain all their rights. 484 This document and the information contained herein are provided on an 485 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 486 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 487 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 488 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 489 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 492 Intellectual Property 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in 497 this document or the extent to which any license under such rights 498 might or might not be available; nor does it represent that it has 499 made any independent effort to identify any such rights. Information 500 on the procedures with respect to rights in RFC documents can be 501 found in BCP 78 and BCP 79. 503 Copies of IPR disclosures made to the IETF Secretariat and any 504 assurances of licenses to be made available, or the result of an 505 attempt made to obtain a general license or permission for the use of 506 such proprietary rights by implementers or users of this 507 specification can be obtained from the IETF on-line IPR repository at 508 http://www.ietf.org/ipr. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights that may cover technology that may be required to implement 513 this standard. Please address the information to the IETF at 514 ietf-ipr@ietf.org. 516 Acknowledgment 518 Funding for the RFC Editor function is provided by the IETF 519 Administrative Support Activity (IASA).