< draft-thubert-6lowpan-simple-fragment-recovery-03.txt   draft-thubert-6lowpan-simple-fragment-recovery-04.txt >
6LoWPAN P. Thubert, Ed. 6LoWPAN P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track March 23, 2009 Intended status: Standards Track J. Hui
Expires: September 24, 2009 Expires: September 29, 2009 Arch Rock Corporation
March 28, 2009
LoWPAN simple fragment Recovery LoWPAN simple fragment Recovery
draft-thubert-6lowpan-simple-fragment-recovery-03 draft-thubert-6lowpan-simple-fragment-recovery-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 33
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 24, 2009. This Internet-Draft will expire on September 29, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 8 skipping to change at page 2, line 9
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
as 25 fragments at the 6LoWPAN shim layer. If a single one of those as 25 fragments at the 6LoWPAN shim layer. If a single one of those
fragments is lost in transmission, all fragments must be resent, fragments is lost in transmission, all fragments must be resent,
further contributing to the congestion that might have caused the further contributing to the congestion that might have caused the
initial packet loss. This draft introduces a simple protocol to initial packet loss. This draft introduces a simple protocol to
recover individual fragments between 6LoWPAN endpoints. recover individual fragments that might be lost over multiple hops
between 6LoWPAN endpoints.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . 8
6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8 6.2. Fragment Acknowledgement Dispatch type and Header . . . . 8
7. Outstanding Fragments Control . . . . . . . . . . . . . . . . 8 7. Fragments Recovery . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Considering that 6LoWPAN packets can be as large as 2K bytes and that In many 6LoWPAN applications, the majority of traffic is spent
a 802.15.4 frame with security will carry in the order of 80 bytes of sending small chunks of data (order few bytes to few tens of bytes)
effective payload, a packet might be fragmented into about 25 per packet. Given that an 802.15.4 frame can carry on the order of
fragments at the 6LoWPAN shim layer. This level of fragmentation is 80 bytes in the worst case, fragmentation is often not needed for
much higher than that traditionally experienced over the Internet most application traffic. However, many applications also require
with IPv4 fragments. At the same time, the use of radios increases occasional bulk data transfer capabilities to support firmware
the probability of transmission loss and Mesh-Under techniques upgrades of 6LoWPAN devices or extraction of logs from 6LoWPAN
compound that risk over multiple hops. devices. In the former case, bulk data is transferred to the 6LoWPAN
device, and in the latter, bulk data flows away from the 6LoWPAN
device. In both cases, the bulk data size is often on the order of
10K bytes or more and end-to-end reliable transport is required.
Mechanisms such as TCP or application-layer segmentation will be used
to support end-to-end reliable transport. One option to support bulk
data transfer over 6LoWPAN links is to set the Maximum Segment Size
to fit within the 802.15.4 MTU. Doing so, however, can add
significant header overhead to each 802.15.4 frame. This causes the
end-to-end transport to be aware of the delivery properties of
6LoWPAN networks, which is a layer violation.
An alternative mechanism combines the use of 6LoWPAN fragmentation in
addition to transport or application-layer segmentation. Increasing
the Maximum Segment Size reduces header overhead by the end-to-end
transport protocol. It also encourages the transport protocol to
reduce the number of outstanding datagrams, ideally to a single
datagram, thus reducing the need to support out-of-order delivery
common to 6LoWPAN networks.
[RFC4944] defines a datagram fragmentation mechanism for 6LoWPAN
networks. However, because [RFC4944] does not define a mechanism for
recovering fragments that are lost, datagram forwarding fails if even
one fragment is not delivered properly to the next IP hop. End-to-
end transport mechanisms will require retransmission of all
fragments, wasting resources in an already resource-constrained
network.
Past experience with fragmentation has shown that missassociated or Past experience with fragmentation has shown that missassociated or
lost fragments can lead to poor network behaviour and, eventually, lost fragments can lead to poor network behavior and, eventually,
trouble at application layer. The reader is encouraged to read trouble at application layer. The reader is encouraged to read
[RFC4963] and follow the references for more information. That [RFC4963] and follow the references for more information. That
experience led to the definition of the Path MTU discovery [RFC1191] experience led to the definition of the Path MTU discovery [RFC1191]
protocol that limits fragmentation over the Internet. protocol that limits fragmentation over the Internet.
An end-to-end fragment recovery mechanism might be a good complement For one-hop communications, a number of media propose a local
to a hop-by-hop MAC level recovery with a limited number of retries. acknowledgement mechanism that is enough to protect the fragments.
This draft introduces a simple protocol to recover individual In a multihop environment, an end-to-end fragment recovery mechanism
fragments between 6LoWPAN endpoints. Specifically in the case of might be a good complement to a hop-by-hop MAC level recovery. This
UDP, valuable additional information can be found in UDP Usage draft introduces a simple protocol to recover individual fragments
Guidelines for Application Designers [I-D.ietf-tsvwg-udp-guidelines]. between 6LoWPAN endpoints. Specifically in the case of UDP, valuable
additional information can be found in UDP Usage Guidelines for
Application Designers [I-D.ietf-tsvwg-udp-guidelines].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in "IPv6 over Low-Power Wireless Personal Area that are discussed in "IPv6 over Low-Power Wireless Personal Area
Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
skipping to change at page 4, line 35 skipping to change at page 5, line 17
multicast services. Such a reflashing operation typically multicast services. Such a reflashing operation typically
involves updating a large number of similar 6LoWPAN nodes over involves updating a large number of similar 6LoWPAN nodes over
a relatively short period of time. a relatively short period of time.
From the LoWPAN node: From the LoWPAN node:
Waveform captures: A number of consecutive samples are measured Waveform captures: A number of consecutive samples are measured
at a high rate for a short time and then transferred from a at a high rate for a short time and then transferred from a
sensor to a gateway or an edge server as a single large report. sensor to a gateway or an edge server as a single large report.
Data logs: 6LoWPAN nodes may generate large logs of sampled data
for later extraction. 6LoWPAN nodes may also generate system
logs to assist in diagnosing problems on the node or network.
Large data packets: Rich data types might require more than one Large data packets: Rich data types might require more than one
fragment. fragment.
Uncontrolled firmware download or waveform upload can easily result Uncontrolled firmware download or waveform upload can easily result
in a massive increase of the traffic and saturate the network. in a massive increase of the traffic and saturate the network.
When a fragment is lost in transmission, all fragments are resent, When a fragment is lost in transmission, all fragments are resent,
further contributing to the congestion that caused the initial loss, further contributing to the congestion that caused the initial loss,
and potentially leading to congestion collapse. and potentially leading to congestion collapse.
This saturation may lead to excessive radio interference, or random This saturation may lead to excessive radio interference, or random
early discard (leaky bucket) in relaying nodes. Additional queueing early discard (leaky bucket) in relaying nodes. Additional queuing
and memory congestion may result while waiting for a low power next and memory congestion may result while waiting for a low power next
hop to emerge from its sleeping state. hop to emerge from its sleeping state.
To demonstrate the severity of the problem, consider a fairly
reliable 802.15.4 frame delivery rate of 99.9% over a single 802.15.4
hop. The expected delivery rate of a 5-fragment datagram would be
about 99.5% over a single 802.15.4 hop. However, the expected
delivery rate would drop to 95.1% over 10 hops, a reasonable network
diameter for 6LoWPAN applications. The expected delivery rate for a
1280-byte datagram is 98.4% over a single hop and 85.2% over 10 hops.
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
effective payload, a packet might be fragmented into about 25
fragments at the 6LoWPAN shim layer. This level of fragmentation is
much higher than that traditionally experienced over the Internet
with IPv4 fragments. At the same time, the use of radios increases
the probability of transmission loss and Mesh-Under techniques
compound that risk over multiple hops.
4. Requirements 4. Requirements
This paper proposes a method to recover individual fragments between This paper proposes a method to recover individual fragments between
LoWPAN endpoints. The method is designed to fit the following LoWPAN endpoints. The method is designed to fit the following
requirements of a LoWPAN (with or without a Mesh-Under routing requirements of a LoWPAN (with or without a Mesh-Under routing
protocol): protocol):
Number of fragments Number of fragments
The recovery mechanism must support highly fragmented packets, The recovery mechanism must support highly fragmented packets,
with a maximum of 32 fragments per packet. with a maximum of 32 fragments per packet.
Minimum acknowledgement overhead Minimum acknowledgement overhead
Because the radio is half duplex, and because of silent time spent Because the radio is half duplex, and because of silent time spent
in the various medium access mechanisms, an acknowledgement in the various medium access mechanisms, an acknowledgment
consumes roughly as many resources as data fragment. consumes roughly as many resources as data fragment.
The recovery mechanism should be able to acknowledge multiple The recovery mechanism should be able to acknowledge multiple
fragments in a single message. fragments in a single message and not require an acknowledgement
at all if fragments are already protected at a lower layer.
Controlled latency Controlled latency
The recovery mechanism must succeed or give up within the time The recovery mechanism must succeed or give up within the time
boundary imposed by the recovery process of the Upper Layer boundary imposed by the recovery process of the Upper Layer
Protocols. Protocols.
Support for out-of-order fragment delivery Support for out-of-order fragment delivery
A Mesh-Under load balancing mechanism such as the ISA100 Data Link A Mesh-Under load balancing mechanism such as the ISA100 Data Link
Layer can introduce out-of-sequence packets. The recovery Layer can introduce out-of-sequence packets.
mechanism must account for packets that appear lost but are
actually only delayed over a different path. The recovery mechanism must account for packets that appear lost
but are actually only delayed over a different path.
Optional congestion control Optional congestion control
The aggregation of multiple concurrent flows may lead to the The aggregation of multiple concurrent flows may lead to the
saturation of the radio network and congestion collapse. saturation of the radio network and congestion collapse.
The recovery mechanism should provide means for controlling the The recovery mechanism should provide means for controlling the
number of fragments in transit over the LoWPAN. number of fragments in transit over the LoWPAN.
Backward compatibility
A node that implements this draft should be able to communicate
with a node that implements [RFC4944]. This draft assumes that
compatibility information about the remote LoWPAN endpoint is
obtained by external means.
5. Overview 5. Overview
Considering that a multi-hop LoWPAN can be a very sensitive Considering that a multi-hop LoWPAN can be a very sensitive
environment due to the limited queueing capabilities of a large environment due to the limited queuing capabilities of a large
population of its nodes, this draft recommends a simple and population of its nodes, this draft recommends a simple and
conservative approach to congestion control, based on TCP congestion conservative approach to congestion control, based on TCP congestion
avoidance. avoidance.
Congestion on the forward path is assumed in case of packet loss, and
packet loss is assumed upon time out.
Congestion on the forward path can also be indicated by an Explicit
Congestion Notification (ECN) mechanism. Though whether and how ECN
[RFC3168] is carried out over the LoWPAN is out of scope, this draft
provides a way for the destination endpoint to echo an ECN indication
back to the source endpoint in an acknowledgement message as
represented in Figure 3 in Section 6.2.
From the standpoint of a source LoWPAN endpoint, an outstanding From the standpoint of a source LoWPAN endpoint, an outstanding
fragment is a fragment that was sent but for which no explicit fragment is a fragment that was sent but for which no explicit
acknowledgement was received yet. This means that the fragment might acknowledgment was received yet. This means that the fragment might
be on the way, received but not yet acknowledged, or the be on the way, received but not yet acknowledged, or the
acknowledgement might be on the way back. It is also possible that acknowledgment might be on the way back. It is also possible that
either the fragment or the acknowledgement was lost on the way. either the fragment or the acknowledgment was lost on the way.
Because a meshed LoWPAN might deliver frames out of order, it is Because a meshed LoWPAN might deliver frames out of order, it is
virtually impossible to differentiate these situations. In other virtually impossible to differentiate these situations. In other
words, from the sender standpoint, all outstanding fragments might words, from the sender standpoint, all outstanding fragments might
still be in the network and contribute to its congestion. There is still be in the network and contribute to its congestion. There is
an assumption, though, that after a certain amount of time, a frame an assumption, though, that after a certain amount of time, a frame
is either received or lost, so it is not causing congestion anymore. 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 This amount of time can be estimated based on the round trip delay
between the LoWPAN endpoints. The method detailed in [RFC2988] is between the LoWPAN endpoints. The method detailed in [RFC2988] is
recommended for that computation. recommended for that computation.
The reader is encouraged to read through "Congestion Control
Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide
deeper information on why this mechanism is needed and how TCP
handles Congestion Control. Basically, the goal here is to manage
the amount of fragments present in the network; this is achieved by
to reducing the number of outstanding fragments over a congested path
by throttling the sources.
Section 7 describes how the sender decides how many fragments are
(re)sent before an acknowledgement is required, and how the sender
adapts that number to 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 4 new dispatch types, for 802.15.4 Networks" [RFC4944] with 4 new dispatch types, for
Recoverable Fragments (RFRAG) headers with or without Acknowledgement Recoverable Fragments (RFRAG) headers with or without Acknowledgment
Request, and for the Acknowledgement back, with or without ECN Echo. Request, and for the Acknowledgment back.
Pattern Header Type Pattern Header Type
+------------+-----------------------------------------------+ +------------+-----------------------------------------------+
| 11 101000 | RFRAG - Recoverable Fragment | | 11 101000 | RFRAG - Recoverable Fragment |
| 11 101001 | RFRAG-AR - RFRAG with Ack Request | | 11 101001 | RFRAG-AR - RFRAG with Ack Request |
| 11 101010 | RFRAG-ACK - RFRAG Acknowledgement | | 11 10101x | RFRAG-ACK - RFRAG Acknowledgment |
| 11 101011 | RFRAG-AEC - RFRAG Ack with ECN Echo |
+------------+-----------------------------------------------+ +------------+-----------------------------------------------+
Figure 1: Additional Dispatch Value Bit Patterns Figure 1: Additional Dispatch Value Bit Patterns
In the following sections, the semantics of "datagram_tag," In the following sections, the semantics of "datagram_tag,"
"datagram_offset" and "datagram_size" and the reassembly process are "datagram_offset" and "datagram_size" and the reassembly process are
unchanged from [RFC4944] Section 5.3. "Fragmentation Type and unchanged from [RFC4944] Section 5.3. "Fragmentation Type and
Header." Header."
6.1. Recoverable Fragment Dispatch type and Header 6.1. Recoverable Fragment Dispatch type and Header
skipping to change at page 7, line 42 skipping to change at page 8, line 20
|1 1 1 0 1 0 0 X|datagram_offset| datagram_tag | |1 1 1 0 1 0 0 X|datagram_offset| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sequence | datagram_size | |Sequence | datagram_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X set == Ack Requested X set == Ack Requested
Figure 2: Recoverable Fragment Dispatch type and Header Figure 2: Recoverable Fragment Dispatch type and Header
X bit X bit
When set, the sender requires an Acknowledgement from the receiver When set, the sender requires an Acknowledgment from the receiver
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 Y| datagram_tag | |1 1 1 0 1 0 1 Y| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Bitmap | | Acknowledgment Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^
| | Y set == ECN echo | | Y is reserved
| | | |
| | 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 Y bit
When set, the sender indicates that at least one of the Reserved.
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 A NULL bitmap (All zeroes) means that the fragment was dropped .
corresponds to an obsolete datagram_tag. This happens if the
packet was already reassembled and passed to the network upper
layer, or the packet expired and was dropped.
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, 7. Fragments Recovery
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 The node that fragments the packets at 6LoWPAN level (the sender)
last fragment of a series with an acknowledgement request. controls the Fragment Acknowledgements. If may do that at any
fragment to implement its own policy or perform congestion control
which is out of scope for this document. When the sender of the
fragment knows that an underlying mechanism protects the Fragments
already it MAY refrain from using the Acknowledgement mechanism, and
never set the Ack Requested bit. The node that recomposes the
packets at 6LoWPAN level (the receiver) MUST acknowledge the
fragments it has received when asked to, and MAY slightly defer that
acknowledgement.
The sender arms a timer to cover the fragment that carries the The sender transfers a controlled number of fragments and MAY flag
Acknowledgement request. Upon time out, the sender assumes that all the last fragment of a series with an acknowledgment request. The
the fragments on the way are received or lost. It divides the received MUST acknowledge a fragment with the acknowledgment request
maximum number of outstanding fragments by 2 and resets the number of bit set. If any fragment immediately preceding an acknowledgment
outstanding fragments to 0. request is still missing, the receiver MAY intentionally delay its
acknowledgment to allow in-transit fragments to arrive. delaying the
acknowledgement might defeat the round trip delay computation so it
should be configurable and not enabled by default.
Upon receipt of an Acknowledgement request, the receiver responds The receiver interacts with the sender using an Acknowledgment
with an Acknowledgement containing a bitmap that indicates which message with a bitmap that indicates which fragments were actually
fragments were actually received. The bitmap is a 32bit DWORD, which received. The bitmap is a 32bit SWORD, which accommodates up to 32
accommodates up to 32 fragments and is sufficient for the 6LoWPAN fragments and is sufficient for the 6LoWPAN MTU. For all n in
MTU. For all n in [0..31], bit n is set to 1 in the bitmap to [0..31], bit n is set to 1 in the bitmap to indicate that fragment
indicate that fragment with sequence n was received, otherwise the with sequence n was received, otherwise the bit is set to 0. All
bit is set to 0. zeroes is a NULL bitmap that indicates that the fragmentation process
was cancelled by the receiver for that datagram.
The receiver MAY issue unsolicited acknowledgements. An unsolicited The receiver MAY issue unsolicited acknowledgments. An unsolicited
acknowledgement enables the sender endpoint to resume sending if it acknowledgment enables the sender endpoint to resume sending if it
had reached its maximum number of outstanding fragments. Note that had reached its maximum number of outstanding fragments or indicate
acknowledgements might consume precious resources so the use of that the receiver has cancelled the process of an individual
unsolicited acknowledgements should be configurable and not enabled datagram. Note that acknowledgments might consume precious resources
by default. so the use of unsolicited acknowledgments should be configurable and
not enabled by default.
The received MUST acknowledge a fragment with the acknowledgement The sender arms a retry timer to cover the fragment that carries the
request bit set. If any fragment immediately preceding an Acknowledgment request. Upon time out, the sender assumes that all
acknowledgement request is still missing, the receiver MAY the fragments on the way are received or lost. The process must
intentionally delay its acknowledgement to allow in-transit fragments completed within an acceptable time that is within the boundaries of
to arrive. This mechanism might defeat the round trip delay upper layer retries. The method detailed in [RFC2988] is recommended
computation so it should be configurable and not enabled by default. for the computation of the retry timer. It is expected that the
upper layer retries obey the same or friendly rules in which case a
single round of fragment recovery should fit within the upper layer
recovery timers.
Fragments are sent in a round robin fashion: the sender sends all the 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 for a first time before it retries any lost fragment; lost
fragments are retried in sequence, oldest first. This mechanism fragments are retried in sequence, oldest first. This mechanism
enables the receiver to acknowledge fragments that were delayed in enables the receiver to acknowledge fragments that were delayed in
the network before they are actually retried. the network before they are actually retried.
The process must complete within an acceptable time that is within When the sender decides that a packet should be dropped and the
the boundaries of upper layer retries. Additional work is required fragmentation process canceled, it sends a pseudo fragment with the
to define how this is achieved. When the source endpoint decides datagram_offset, sequence and datagram_size all set to zero, and no
that a packet should be dropped and the fragmentation process data. Upon reception of this message, the receiver should clean up
cancelled, it sends a pseudo fragment with the datagram_offset, all resources for the packet associated to the datagram_tag. If an
sequence and datagram_size all set to zero, and no data. Upon acknowledment is requested, the receiver responds with a NULL bitmap.
reception of this message, the receiver should clean up all resources
for the packet associated to the datagram_tag. The receiver might need to cancel the process of a fragmented packet
for internal reasons, for instance if it is out of recomposition
buffers, or considers that this packet is already fully recomposed
and passed to the upper layer. In that case, the receiver SHOULD
indicate so to the sender with a NULL bitmap. Upon an
acknowledgement with a NULL bitmap, the sender MUST drop the
datagram.
8. Security Considerations 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 compared to "Transmission of IPv6 Packets over
IEEE 802.15.4 Networks" [RFC4944].
9. 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].
10. 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.
skipping to change at page 11, line 34 skipping to change at page 12, line 14
RFC 3168, September 2001. 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.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007. Errors at High Data Rates", RFC 4963, July 2007.
Author's Address Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
Phone: +33 4 97 23 26 34 Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, California 94107
USA
Phone: +415 692 0828
Email: jhui@archrock.com
 End of changes. 42 change blocks. 
131 lines changed or deleted 162 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/