draft-ietf-lwig-6lowpan-virtual-reassembly-00.txt		draft-ietf-lwig-6lowpan-virtual-reassembly-01.txt
	Network Working Group C. Bormann		Network Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Informational T. Watteyne		Intended status: Informational T. Watteyne
	Expires: January 3, 2019 Analog Devices		Expires: September 12, 2019 Analog Devices
	July 02, 2018		March 11, 2019
	Virtual reassembly buffers in 6LoWPAN		Virtual reassembly buffers in 6LoWPAN
	draft-ietf-lwig-6lowpan-virtual-reassembly-00		draft-ietf-lwig-6lowpan-virtual-reassembly-01
	Abstract		Abstract
	When employing adaptation layer fragmentation in 6LoWPAN, it may be		When employing adaptation layer fragmentation in 6LoWPAN, it may be
	beneficial for a forwarder not to have to reassemble each packet in		beneficial for a forwarder not to have to reassemble each packet in
	its entirety before forwarding it.		its entirety before forwarding it.
	This has been always possible with the original fragmentation design		This has been always possible with the original fragmentation design
	of RFC 4944. Apart from a brief mention of the way to do this in		of RFC 4944. Apart from a brief mention of the way to do this in
	Section 2.5.2 of the 6LoWPAN book, this has not been extensively		Section 2.5.2 of the 6LoWPAN book, this has not been extensively
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 3, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	Note that the decision to do local processing of a packet needs to be		Note that the decision to do local processing of a packet needs to be
	taken with the first fragment - such packets of course do need to be		taken with the first fragment - such packets of course do need to be
	fully reassembled (unless transport and application also can cope		fully reassembled (unless transport and application also can cope
	with fragments, which they rarely can in the presence of security).		with fragments, which they rarely can in the presence of security).
	4. Header compression		4. Header compression
	[RFC6282] defines the header compression format for 6LoWPAN. One		[RFC6282] defines the header compression format for 6LoWPAN. One
	important impact of header compression is that the header is no		important impact of header compression is that the header is no
	longer of a fixed length. In particular, changes made by a forwarder		longer of a length that stays fixed during forwarding. In
	may gain or lose the ability to use a more highly compressed variant,		particular, changes made by a forwarder may gain or lose the ability
	changing the length of the header in the packet. If the change		to use a more highly compressed variant, changing the length of the
	increases the size, the maximum frame size may be exceeded, leading		header in the packet. If the change increases the size, the maximum
	to the need to re-fragment in the forwarder. This is less of a		frame size may be exceeded, leading to the need to re-fragment in the
	problem with full reassembly, but with virtual reassembly can lead to		forwarder. This is less of a problem with full reassembly, but with
	the need for sending an additional frame for each packet.		virtual reassembly can lead to the need for sending an additional
			frame for each packet.
	The well-known approach to minimize the probability of this need is		The well-known approach to minimize the probability of this need is
	for the original sender to put all slack in the frame sizes into the		for the original sender to put all slack in the frame sizes into the
	_first_ packet, making this the smallest fragment and not the last		_first_ packet, making this the smallest fragment and not the last
	one as would be done in a naive implementation. (This also has other		one as would be done in a naive implementation. (This also has other
	consequences related to delivery probability, which are not discussed		consequences related to delivery probability, which are not discussed
	here.) This makes sure an additional fragment only needs to be sent		here.) This makes sure an additional fragment only needs to be sent
	if the header expansion during forwarding would have created an		if the header expansion during forwarding would have created an
	additional fragment with full reassembly as well.		additional fragment with full reassembly as well.
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	<https://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
	7.2. Informative References		7.2. Informative References
	[BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons,		[BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons,
	Ltd monograph, DOI 10.1002/9780470686218, November 2009.		Ltd monograph, DOI 10.1002/9780470686218, November 2009.
	[I-D.watteyne-6lo-minimal-fragment]		[I-D.watteyne-6lo-minimal-fragment]
	Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal		Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal
	Fragment Forwarding", draft-watteyne-6lo-minimal-		Fragment Forwarding", draft-watteyne-6lo-minimal-
	fragment-01 (work in progress), March 2018.		fragment-02 (work in progress), July 2018.
	[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	DOI 10.17487/RFC6282, September 2011,		DOI 10.17487/RFC6282, September 2011,
	<https://www.rfc-editor.org/info/rfc6282>.		<https://www.rfc-editor.org/info/rfc6282>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	<https://www.rfc-editor.org/info/rfc7228>.		<https://www.rfc-editor.org/info/rfc7228>.
End of changes. 6 change blocks.
	13 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/