< draft-thubert-6lo-rpl-nhc-00.txt		draft-thubert-6lo-rpl-nhc-01.txt >
	6lo P. Thubert, Ed.		6lo P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Updates: 6282 (if approved) August 28, 2014		Updates: 6282 (if approved) August 28, 2014
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 27, 2015		Expires: February 27, 2015
	A compression mechanism for the RPL option		A compression mechanism for the RPL option
	draft-thubert-6lo-rpl-nhc-00		draft-thubert-6lo-rpl-nhc-01
	Abstract		Abstract
	This document proposes a compression mechanism for the RPL option.		This document proposes a compression mechanism for the RPL option.
	This operation saves up to 48 bits in each frame compared to RFC		This operation saves up to 48 bits in each frame compared to RFC
	6553.		6553.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	The SenderRank is the result of the DAGRank operation on the rank of		The SenderRank is the result of the DAGRank operation on the rank of
	the sender, here the DAGRank operation is defined in section 3.5.1		the sender, here the DAGRank operation is defined in section 3.5.1
	as:		as:
	DAGRank(rank) = floor(rank/MinHopRankIncrease)		DAGRank(rank) = floor(rank/MinHopRankIncrease)
	If MinHopRankIncrease is set to a multiple of 256, it appears that		If MinHopRankIncrease is set to a multiple of 256, it appears that
	the least significant 8 bits of the SenderRank will be all zeroes and		the least significant 8 bits of the SenderRank will be all zeroes and
	can be elided, in which case the SenderRank can be compressed into		can be elided, in which case the SenderRank can be compressed into
	one octet.		one octet. This idea is leveraged in [RFC6552] that uses a
			MinHopRankIncrease of 256 by default.
	[RFC6553] defines an encoding for the RPL information as a RPL option		[RFC6553] defines an encoding for the RPL information as a RPL option
	located in a Hop-by-hop header. The RPL_NHC provides a compressed		located in a Hop-by-hop header. The RPL_NHC provides a compressed
	form for that the RPL information and is constructed as follows:		form for that the RPL information and is constructed as follows:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 1 | 0 | I | K | O | R | F |NH |		| 1 | 0 | I | K | O | R | F |NH |
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	The RPL_NHC is immediately followed by the RPLInstanceID, unless it		The RPL_NHC is immediately followed by the RPLInstanceID, unless it
	is elided, and then the SenderRank, which is either compressed into		is elided, and then the SenderRank, which is either compressed into
	one octet or fully inlined as the whole 2 octets. Bits in the		one octet or fully inlined as the whole 2 octets. Bits in the
	RPL_NHC indicate whether the RPLInstanceID is elided and/or the		RPL_NHC indicate whether the RPLInstanceID is elided and/or the
	SenderRank is compressed:		SenderRank is compressed:
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	RPLInstanceID as specified in [RFC6550] section 5.1.		RPLInstanceID as specified in [RFC6550] section 5.1.
	K: 1-bit. If it is set, the SenderRank is be compressed into one		K: 1-bit. If it is set, the SenderRank is be compressed into one
	octet, and the lowest significant octet is elided. If it is		octet, and the lowest significant octet is elided. If it is
	not set, the SenderRank, is fully inlined as 2 octets.		not set, the SenderRank, is fully inlined as 2 octets.
	In the following case, the RPLInstanceID is the Global RPLInstanceID		In the following case, the RPLInstanceID is the Global RPLInstanceID
	0, and the MinHopRankIncrease is a multiple of 256 so the least		0, and the MinHopRankIncrease is a multiple of 256 so the least
	significant octet is all zeroes and can be elided:		significant octet is all zeroes and can be elided:
	0 1 2		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|0|1|1|O|R|F|N| SenderRank |		|1|0|1|1|O|R|F|N| SenderRank |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	In the following case, the RPLInstanceID is the Global RPLInstanceID		In the following case, the RPLInstanceID is the Global RPLInstanceID
	0, but both octets of the SenderRank are significant so it can not be		0, but both octets of the SenderRank are significant so it can not be
	compressed:		compressed:
	0 1 2		0 1 2
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	In the following case, the RPLInstanceID is not the Global		In the following case, the RPLInstanceID is not the Global
	RPLInstanceID 0, and both octets of the SenderRank are significant:		RPLInstanceID 0, and both octets of the SenderRank are significant:
	0 1 2 3		0 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|0|0|0|O|R|F|N| RPLInstanceID | SenderRank |		|1|0|0|0|O|R|F|N| RPLInstanceID | SenderRank |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Depending on the RPLInstanceID and the MinHopRankIncrease, the		Depending on the RPLInstanceID and the MinHopRankIncrease, the
	proposed format Squeezes the RPL information in 16 to 32 bits, which		proposed format thus squeezes the RPL information in 16 to 32 bits,
	compares to 64 bits when using a Hop-by-hop option with the RPL		which compares to 64 bits when using a Hop-by-hop option with the RPL
	option as specified in [RFC6553].		option as specified in [RFC6553].
	6. Security Considerations		6. Security Considerations
	Using a compressed format as opposed to the full inline RPL option is		Using a compressed format as opposed to the full inline RPL option is
	logically equivalent and does not create an opening for a new threat		logically equivalent and does not create an opening for a new threat
	when compared to [RFC6553].		when compared to [RFC6553].
	7. IANA Considerations		7. IANA Considerations
	This document updates IANA registry for the LOWPAN_NHC defined in		This document updates IANA registry for the LOWPAN_NHC defined in
	[RFC6282] and assigns the previously unassigned:		[RFC6282] and assigns the previously unassigned:
	10IOKRFN: RPL Information [this]		10IOKRFN: RPL Information [this]
	Capital letters in bit positions represent class-specific bit		Capital letters in bit positions represent class-specific bit
	assignments. N indicates whether or not additional LOWPAN_NHC		assignments. IOKRF represents variables specific to RPL Information
	encodings follow, as defined in Section 4.2. IOKRF represents		compression defined in Section 5. N indicates whether or not
	variables specific to RPL Information compression defined in Section		additional LOWPAN_NHC encodings follow, as defined in Section 4.2 of
	5.		[RFC6553].
	8. Acknowledgements		8. Acknowledgements
	The author wishes to thank Laurent Toutain and Carsten Bormann for		The author wishes to thank Laurent Toutain and Carsten Bormann for
	suggesting this work .		suggesting this work .
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[IEEE802154]		[IEEE802154]
	IEEE standard for Information Technology, "IEEE std.		IEEE standard for Information Technology, "IEEE std.
	802.15.4, Part. 15.4: Wireless Medium Access Control		802.15.4, Part. 15.4: Wireless Medium Access Control
	(MAC) and Physical Layer (PHY) Specifications for Low-Rate		(MAC) and Physical Layer (PHY) Specifications for Low-Rate
	Wireless Personal Area Networks", June 2011.		Wireless Personal Area Networks", June 2011.
	[ISA100.11a]		[ISA100.11a]
	ISA, "ISA100, Wireless Systems for Automation", May 2008,		ISA/ANSI, "Wireless Systems for Industrial Automation:
	< http://www.isa.org/Community/		Process Control and Related Applications - ISA100.11a-2011
			- IEC 62734", 2011, <http://www.isa.org/Community/
	SP100WirelessSystemsforAutomation>.		SP100WirelessSystemsforAutomation>.
	[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.
	[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version		[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
	6 (IPv6) Specification", RFC 2460, December 1998.		6 (IPv6) Specification", RFC 2460, December 1998.
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J. 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,
End of changes. 7 change blocks.
	12 lines changed or deleted		14 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/