< draft-thubert-6lowpan-simple-fragment-recovery-04.txt		draft-thubert-6lowpan-simple-fragment-recovery-05.txt >
	6LoWPAN P. Thubert, Ed.		6LoWPAN P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Hui		Intended status: Standards Track J. Hui
	Expires: September 29, 2009 Arch Rock Corporation		Expires: September 29, 2009 Arch Rock Corporation
	March 28, 2009		March 28, 2009
	LoWPAN simple fragment Recovery		LoWPAN simple fragment Recovery
	draft-thubert-6lowpan-simple-fragment-recovery-04		draft-thubert-6lowpan-simple-fragment-recovery-05
	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 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	^ ^		^ ^
	| | Y is reserved		| | 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
	Reserved.
	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]. A NULL bitmap (All zeroes) means that the fragment was
			dropped .
	A NULL bitmap (All zeroes) means that the fragment was dropped .
	7. Fragments Recovery		7. Fragments Recovery
			The Recoverable Fragments header RFRAG and RFRAG-AR deprecate the
			original fragment headers from [RFC4944] and replace them in the
			fragmented packets. The Fragment Acknowledgement RFRAG-ACK is
			introduced as a standalone header in message that is sent back to the
			fragment source endpoint as known by its MAC address. This assumes
			that the source MAC address in the fragment (is any) and datagram_tag
			are enough information to send the Fragment Acknowledgement back to
			the source fragmentation endpoint.
	The node that fragments the packets at 6LoWPAN level (the sender)		The node that fragments the packets at 6LoWPAN level (the sender)
	controls the Fragment Acknowledgements. If may do that at any		controls the Fragment Acknowledgements. If may do that at any
	fragment to implement its own policy or perform congestion control		fragment to implement its own policy or perform congestion control
	which is out of scope for this document. When the sender of the		which is out of scope for this document. When the sender of the
	fragment knows that an underlying mechanism protects the Fragments		fragment knows that an underlying mechanism protects the Fragments
	already it MAY refrain from using the Acknowledgement mechanism, and		already it MAY refrain from using the Acknowledgement mechanism, and
	never set the Ack Requested bit. The node that recomposes the		never set the Ack Requested bit. The node that recomposes the
	packets at 6LoWPAN level (the receiver) MUST acknowledge the		packets at 6LoWPAN level (the receiver) MUST acknowledge the
	fragments it has received when asked to, and MAY slightly defer that		fragments it has received when asked to, and MAY slightly defer that
	acknowledgement.		acknowledgement.
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	The receiver MAY issue unsolicited acknowledgments. An unsolicited		The receiver MAY issue unsolicited acknowledgments. An unsolicited
	acknowledgment 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 or indicate		had reached its maximum number of outstanding fragments or indicate
	that the receiver has cancelled the process of an individual		that the receiver has cancelled the process of an individual
	datagram. Note that acknowledgments might consume precious resources		datagram. Note that acknowledgments might consume precious resources
	so the use of unsolicited acknowledgments should be configurable and		so the use of unsolicited acknowledgments should be configurable and
	not enabled by default.		not enabled by default.
	The sender arms a retry timer to cover the fragment that carries the		The sender arms a retry timer to cover the fragment that carries the
	Acknowledgment request. Upon time out, the sender assumes that all		Acknowledgment request. Upon time out, the sender assumes that all
	the fragments on the way are received or lost. The process must		the fragments on the way are received or lost. The process must have
	completed within an acceptable time that is within the boundaries of		completed within an acceptable time that is within the boundaries of
	upper layer retries. The method detailed in [RFC2988] is recommended		upper layer retries. The method detailed in [RFC2988] is recommended
	for the computation of the retry timer. It is expected that the		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		upper layer retries obey the same or friendly rules in which case a
	single round of fragment recovery should fit within the upper layer		single round of fragment recovery should fit within the upper layer
	recovery timers.		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
End of changes. 5 change blocks.
	9 lines changed or deleted		13 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/