< draft-thubert-6lowpan-simple-fragment-recovery-00.txt   draft-thubert-6lowpan-simple-fragment-recovery-01.txt >
6LoWPAN P. Thubert 6LoWPAN P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track March 18, 2008 Intended status: Standards Track May 23, 2008
Expires: September 19, 2008 Expires: November 24, 2008
LoWPAN simple fragment Recovery LoWPAN simple fragment Recovery
draft-thubert-6lowpan-simple-fragment-recovery-00 draft-thubert-6lowpan-simple-fragment-recovery-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 19, 2008. This Internet-Draft will expire on November 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Considering that 6LoWPAN packets can be as large as 2K bytes and that Considering that 6LoWPAN packets can be as large as 2K bytes and that
an 802.15.4 frame with security will carry in the order of 80 bytes an 802.15.4 frame with security will carry in the order of 80 bytes
of effective payload, a packet might end up fragmented into as many of effective payload, a packet might end up fragmented into as many
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7 6. New Dispatch types and headers . . . . . . . . . . . . . . . . 7
6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7 6.1. Recoverable Fragment Dispatch type and Header . . . . . . 7
6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Outstanding Fragments Control . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
Considering that 6LoWPAN packets can be as large as 2K bytes and that Considering that 6LoWPAN packets can be as large as 2K bytes and that
a 802.15.4 frame with security will carry in the order of 80 bytes of a 802.15.4 frame with security will carry in the order of 80 bytes of
effective payload, a packet might be fragmented into about 25 effective payload, a packet might be fragmented into about 25
fragments at the 6LoWPAN shim layer. This level of fragmentation is fragments at the 6LoWPAN shim layer. This level of fragmentation is
much higher than that traditionally experienced over the Internet much higher than that traditionally experienced over the Internet
with IPv4 fragments. At the same time, the use of radios increases with IPv4 fragments. At the same time, the use of radios increases
the probability of transmission loss and Mesh-Under techniques the probability of transmission loss and Mesh-Under techniques
skipping to change at page 6, line 7 skipping to change at page 6, line 7
Backward compatibility Backward compatibility
A node that implements this draft should be able to communicate A node that implements this draft should be able to communicate
with a node that implements [RFC4944]. This draft assumes that with a node that implements [RFC4944]. This draft assumes that
compatibility information about the remote LoWPAN endpoint is compatibility information about the remote LoWPAN endpoint is
obtained by external means. obtained by external means.
5. Overview 5. Overview
The fragmentation/reassembly of a packet must complete within an Considering that a multi-hop LoWPAN can be a very sensitive
acceptable overall latency, otherwise the packet expires and must be environment due to the limited queueing capabilities of a large
dropped. This latency must be smaller than Upper Layer Protocol population of its nodes, this draft recommends a simple and
retry values, and smaller than expiration period of the information conservative approach to flow control, based on TCP congestion
transported. avoidance.
The sender transfers a controlled number of fragments (possibly all
of them) and flags the last fragment of a series with an
Acknowledgement request.
The sender sets a retry timer for the fragment that carries the
Acknowledgement request. That fragment is retransmitted individually
upon time out. This is repeated until an Acknowledgement comes back
or the packet expires.
Upon receipt of an Acknowledgement request, the receiver responds Congestion on the forward path is assumed in case of packet loss, and
with an Acknowledgement containing a bitmap that indicates which packet loss is assumed upon time out.
fragments were actually received. The bitmap is a 32bit DWORD, which
accommodates up to 32 fragments and is sufficient for the 6LoWPAN
MTU. For all n in [0..31], bit n is set to 1 in the bitmap to
indicate that fragment n was received, otherwise the bit is set to 0.
If any fragment immmediately preceding the acknowledgement request is Congestion on the forward path can also be indicated by an Explicit
missing, the receiver MAY intentionally delay its response to allow Congestion Notification (ECN) mechanism. This draft provides a way
in-transit fragments to arrive. for the destination LoWPAN endpoint to echo en ECN indication back to
the source LoWPAN endpoint in an acknowledgement message as
represented in Figure 3 in Section 6.2.
The sender has either one or no Acknowledgement pending. An From the standpoint of a source LoWPAN endpoint, an outstanding
Acknowledgement that is not expected or does not acknowledge the fragment is a fragment that was sent but for which no explicit
pending sequence in the bitmap is a duplicate and is ignored. acknowledgement was received yet. This means that the packet might
be on the way, received but not yet acknowledged, or the
acknowledgement might be on the way back. It is also possible that
either the fragment or the acknowledgement was lost on the way.
When a valid Acknowledgement is received, the sender resumes sending Because a meshed LoWPAN might deliver packets out of order, it is
fragments and the process is repeated until all fragments are virtually impossible to differentiate these situations. In other
acknowledged or the packet expires. words, from the sender standpoint, all outstanding packets might
still be in the network and contribute to its congestion. There is
an assumption, though, that after a certain amount of time, a packet
is either received or lost, so it is not causing congestion anymore.
This amount of time can be estimated based on the round trip delay
between the LoWPAN endpoints. The method detailed in [RFC2988] is
recommended for that computation.
Fragments are sent in a round robin fashion: the sender sends all the The reader is encouraged to read through "Congestion Control
fragments for a first time before it retries any lost fragment; lost Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide
fragments are retried in sequence, oldest first. This mechanism deeper information on why this mechanism is needed and how TCP
enables the receiver to acknowledge fragments that were delayed in handles Congestion Control. Basically, the goal here is to manage
the network before they are actually retried. the amount of fragments present in the network; this is achieved by
to reducing the number of outstanding fragment over a congested path
by throttling the sources.
It is up to the sender to decide how many fragments are (re)sent Whether and how ECN [RFC3168] is carried out over the LoWPAN is out
before an acknowledgement is received, and the sender can adapt that of scope for this draft. Section 7 describes how the sender decides
number to the network conditions. This way, the number of how many fragments are (re)sent before an acknowledgement is
outstanding fragments can be used as a flow control mechanism to required, and how the sender adapts that number to the network
protect the network. conditions.
6. New Dispatch types and headers 6. New Dispatch types and headers
This specification extends "Transmission of IPv6 Packets over IEEE This specification extends "Transmission of IPv6 Packets over IEEE
802.15.4 Networks" [RFC4944] with 3 new dispatch types, for 802.15.4 Networks" [RFC4944] with 3 new dispatch types, for
Recoverable Fragments (RFRAG) headers with or without Acknowledgement Recoverable Fragments (RFRAG) headers with or without Acknowledgement
Request, and for the Acknowledgement back. Request, and for the Acknowledgement back.
Pattern Header Type Pattern Header Type
+------------+-----------------------------------------------+ +------------+-----------------------------------------------+
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Sequence Sequence
The sequence number of the fragment. Fragments are numbered The sequence number of the fragment. Fragments are numbered
[0..N] where N is in [0..31]. [0..N] where N is in [0..31].
6.2. Fragment Acknowledgement Dispatch type and Header 6.2. Fragment Acknowledgement Dispatch type and Header
1 2 3 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1 0| datagram_tag | |1 1 1 0 1 0 1 Y| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Bitmap | | Acknowledgement Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+
^ ^ ^ ^
| | Y set == Backward Explicit Congestion
| | Notification
| | bitmap indicating whether | | bitmap indicating whether
| +-----Fragment with sequence 10 was received | +-----Fragment with sequence 10 was received
+-------------------------Fragment with sequence 00 was received +-------------------------Fragment with sequence 00 was received
Figure 3: Fragment Acknowledgement Dispatch type and Header Figure 3: Fragment Acknowledgement Dispatch type and Header
Y bit
When set, the sender indicates that at least one of the
acknowledged fragments was received with an Explicit Congestion
Notification, indicating that the path followed by the fragments
is subject to congestion.
Acknowledgement Bitmap Acknowledgement Bitmap
Each bit in the Bitmap refers to a particular fragment: bit n set Each bit in the Bitmap refers to a particular fragment: bit n set
indicates that fragment with sequence n was received, for n in indicates that fragment with sequence n was received, for n in
[0..31]. [0..31].
All zeroes means that the fragment was dropped because it All zeroes means that the fragment was dropped because it
corresponds to an obsolete datagram_tag. This happens if the corresponds to an obsolete datagram_tag. This happens if the
packet was already reassembled and passed to the network upper packet was already reassembled and passed to the network upper
layer, or the packet expired and was dropped. layer, or the packet expired and was dropped.
7. Security Considerations 7. Outstanding Fragments Control
A mechanism based on TCP congestion avoidance dictates the maximum
number of outstanding fragments.
The maximum number of outstanding fragments for a given packet toward
a given LoWPAN endpoint is initially set to a configured value,
unless recent history indicates otherwise. Each time that maximum
number of fragments is fully acknowledged, that number can be
incremented by 1. ECN echo and packet loss cause the number to be
divided by 2.
The sender transfers a controlled number of fragments and flags the
last fragment of a series with an acknowledgement request.
The sender arms a timer to cover the fragment that carries the
Acknowledgement request. Upon time out, the sender assumes that all
the fragments on the way are received or lost. It divides the
maximum number of outstanding fragments by 2 and resets the number of
outstanding fragments to 0.
Upon receipt of an Acknowledgement request, the receiver responds
with an Acknowledgement containing a bitmap that indicates which
fragments were actually received. The bitmap is a 32bit DWORD, which
accommodates up to 32 fragments and is sufficient for the 6LoWPAN
MTU. For all n in [0..31], bit n is set to 1 in the bitmap to
indicate that fragment with sequence n was received, otherwise the
bit is set to 0.
The receiver MAY issue unsolicited acknowledgements. An unsolicited
acknowledgement enables the sender endpoint to resume sending if it
had reached its maximum number of outstanding fragments. Note that
acknowledgements might consume precious resources so the use of
unsolicited acknowledgements should be configurable and not enabled
by default.
The received MUST acknowledge a fragment with the acknowledgement
request bit set. If any fragment immediately preceding an
acknowledgement request is still missing, the receiver MAY
intentionally delay its acknowledgement to allow in-transit fragments
to arrive. This mechanism might defeat the round trip delay
computation so it should be configurable and not enabled by default.
Fragments are sent in a round robin fashion: the sender sends all the
fragments for a first time before it retries any lost fragment; lost
fragments are retried in sequence, oldest first. This mechanism
enables the receiver to acknowledge fragments that were delayed in
the network before they are actually retried.
The process must complete within an acceptable time that is within
the boundaries of upper layer retries. Additional work is required
to define how this is achieved. When the source endpoint decides
that a packet should be dropped and the fragmentation process
cancelled, it sends a pseudo fragment with the datagram_offset,
sequence and datagram_size all set to zero, and no data. Upon
reception of this message, the receiver should clean up all resources
for the packet associated to the datagram_tag.
8. Security Considerations
The process of recovering fragments does not appear to create any The process of recovering fragments does not appear to create any
opening for new threat. opening for new threat.
8. IANA Considerations 9. IANA Considerations
Need extensions for formats defined in "Transmission of IPv6 Packets Need extensions for formats defined in "Transmission of IPv6 Packets
over IEEE 802.15.4 Networks" [RFC4944]. over IEEE 802.15.4 Networks" [RFC4944].
9. Acknowledgments 10. Acknowledgments
The author wishes to thank Jay Werb, Christos Polyzois, Soumitri The author wishes to thank Jay Werb, Christos Polyzois, Soumitri
Kolavennu and Harry Courtice for their contribution and review. Kolavennu and Harry Courtice for their contribution and review.
10. References 11. References
10.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 11.1. Normative References
November 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
10.2. Informative References 11.2. Informative References
[I-D.ietf-tsvwg-udp-guidelines] [I-D.ietf-tsvwg-udp-guidelines]
Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Eggert, L. and G. Fairhurst, "Guidelines for Application
Application Designers", draft-ietf-tsvwg-udp-guidelines-05 Designers on Using Unicast UDP",
(work in progress), February 2008. draft-ietf-tsvwg-udp-guidelines-07 (work in progress),
May 2008.
[I-D.mathis-frag-harmful] [I-D.mathis-frag-harmful]
Mathis, M., "Fragmentation Considered Very Harmful", Mathis, M., "Fragmentation Considered Very Harmful",
draft-mathis-frag-harmful-00 (work in progress), draft-mathis-frag-harmful-00 (work in progress),
July 2004. July 2004.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007. RFC 4919, August 2007.
Author's Address Author's Address
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
 End of changes. 23 change blocks. 
63 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/