< draft-thubert-6lowpan-simple-fragment-recovery-01.txt		draft-thubert-6lowpan-simple-fragment-recovery-02.txt >
	6LoWPAN P. Thubert		6LoWPAN P. Thubert
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track May 23, 2008		Intended status: Standards Track May 29, 2008
	Expires: November 24, 2008		Expires: November 30, 2008
	LoWPAN simple fragment Recovery		LoWPAN simple fragment Recovery
	draft-thubert-6lowpan-simple-fragment-recovery-01		draft-thubert-6lowpan-simple-fragment-recovery-02
	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 November 24, 2008.		This Internet-Draft will expire on November 30, 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 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	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 queueing 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 flow control, based on TCP congestion		conservative approach to flow control, based on TCP congestion
	avoidance.		avoidance.
	Congestion on the forward path is assumed in case of packet loss, and		Congestion on the forward path is assumed in case of packet loss, and
	packet loss is assumed upon time out.		packet loss is assumed upon time out.
	Congestion on the forward path can also be indicated by an Explicit		Congestion on the forward path can also be indicated by an Explicit
	Congestion Notification (ECN) mechanism. This draft provides a way		Congestion Notification (ECN) mechanism. Though whether and how ECN
	for the destination LoWPAN endpoint to echo en ECN indication back to		[RFC3168] is carried out over the LoWPAN is out of scope, this draft
	the source LoWPAN endpoint in an acknowledgement message as		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.		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 packet might		acknowledgement 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		acknowledgement 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 acknowledgement was lost on the way.
	Because a meshed LoWPAN might deliver packets 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 packets 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 packet		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		The reader is encouraged to read through "Congestion Control
	Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide		Principles" [RFC2914]. Additionally [RFC2309] and [RFC2581] provide
	deeper information on why this mechanism is needed and how TCP		deeper information on why this mechanism is needed and how TCP
	handles Congestion Control. Basically, the goal here is to manage		handles Congestion Control. Basically, the goal here is to manage
	the amount of fragments present in the network; this is achieved by		the amount of fragments present in the network; this is achieved by
	to reducing the number of outstanding fragment over a congested path		to reducing the number of outstanding fragments over a congested path
	by throttling the sources.		by throttling the sources.
	Whether and how ECN [RFC3168] is carried out over the LoWPAN is out		Section 7 describes how the sender decides how many fragments are
	of scope for this draft. Section 7 describes how the sender decides		(re)sent before an acknowledgement is required, and how the sender
	how many fragments are (re)sent before an acknowledgement is		adapts that number to the network conditions.
	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 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 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	Header."		Header."
	6.1. Recoverable Fragment Dispatch type and Header		6.1. Recoverable Fragment 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 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 Acknowledgement from the receiver
	Sequence		Sequence
	The sequence number of the fragment. Fragments are numbered		The sequence number of the fragment. Fragments are numbered
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	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 |		| Acknowledgement Bitmap |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+
	^ ^		^ ^
	| | Y set == Backward Explicit Congestion		| | Y set == ECN echo
	| | 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		Y bit
	When set, the sender indicates that at least one of the		When set, the sender indicates that at least one of the
	acknowledged fragments was received with an Explicit Congestion		acknowledged fragments was received with an Explicit Congestion
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	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. Outstanding Fragments Control		7. Outstanding Fragments Control
	A mechanism based on TCP congestion avoidance dictates the maximum		A mechanism based on TCP congestion avoidance dictates the maximum
	number of outstanding fragments.		number of outstanding fragments.
	The maximum number of outstanding fragments for a given packet toward		The maximum number of outstanding fragments for a given packet toward
	a given LoWPAN endpoint is initially set to a configured value,		a given LoWPAN endpoint is initially set to a configured value,
	unless recent history indicates otherwise. Each time that maximum		unless recent history indicates otherwise.
	number of fragments is fully acknowledged, that number can be
	incremented by 1. ECN echo and packet loss cause the number to be		Each time that maximum number of fragments is fully acknowledged,
	divided by 2.		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 sender transfers a controlled number of fragments and flags the
	last fragment of a series with an acknowledgement request.		last fragment of a series with an acknowledgement request.
	The sender arms a timer to cover the fragment that carries the		The sender arms a timer to cover the fragment that carries the
	Acknowledgement request. Upon time out, the sender assumes that all		Acknowledgement request. Upon time out, the sender assumes that all
	the fragments on the way are received or lost. It divides the		the fragments on the way are received or lost. It divides the
	maximum number of outstanding fragments by 2 and resets the number of		maximum number of outstanding fragments by 2 and resets the number of
	outstanding fragments to 0.		outstanding fragments to 0.
End of changes. 13 change blocks.
	24 lines changed or deleted		25 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/