< draft-bormann-6lo-rpl-mesh-01.txt		draft-bormann-6lo-rpl-mesh-02.txt >
	6lo working group C. Bormann		6lo working group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Standards Track August 14, 2014		Intended status: Standards Track October 12, 2014
	Expires: February 15, 2015		Expires: April 15, 2015
	6lo RPL Information Header		NHC compression for RPL Packet Information
	draft-bormann-6lo-rpl-mesh-01		draft-bormann-6lo-rpl-mesh-02
	Abstract		Abstract
	This short draft provides a straw man for the RPL Information Header,		This short draft provides a straw man for the RPL Packet Information
	a method to compress RPL Option [RFC6553] information within 6lowpan-		(RPI) NHC compression, a method to compress RPL Option [RFC6553]
	style ("6lo") adaptation layers.		information within 6lowpan-style ("6lo") adaptation layers.
	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
	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). 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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 February 15, 2015.		This Internet-Draft will expire on April 15, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. The NHC escape mechanism . . . . . . . . . . . . . . . . . . 2
	3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. RPI_NHC Encoding . . . . . . . . . . . . . . . . . . . . . . 3
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6		6. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security considerations . . . . . . . . . . . . . . . . . . . 6		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		8. Security considerations . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 6		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		10.2. Informative References . . . . . . . . . . . . . . . . . 9
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[I-D.thubert-6man-flow-label-for-rpl] defines a way to compress		[I-D.thubert-6man-flow-label-for-rpl] defines a way to compress
	information from the [RFC6553] RPL Option, for inclusion in an IPv6		information from the [RFC6553] RPL Option, for inclusion in an IPv6
	flow label. The present draft shows how to carry the same		flow label. The present draft shows how to carry the same
	information in a RPL Information Header, in a potentially slightly		information in a RPL Packet Information (RPI) NHC compression header,
	more efficient way.		without consuming a lot of the code space for NHC headers.
	The RPL Information Header is added to the 6lo adaptation layer		The RPL Packet Information is added to the 6lo adaptation layer
	framework ([RFC4944], [RFC6282]) as a small number of additional		framework ([RFC4944], [RFC6282]) as a small number of additional NHC
	dispatch codes.		compression codes.
	(More background information in Section 5.)		(More background information in Section 6.)
	1.1. Terminology		1.1. 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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Encoding		2. The NHC escape mechanism
	(Insert definitions from [I-D.thubert-6man-flow-label-for-rpl] here.)		The NHC space of [RFC6282] is limited to 256 code points. For the
			case some infrequent bit combinations do not fit into the 256 code
			points, this specification assigns four code points:
	Where [I-D.thubert-6man-flow-label-for-rpl] would carry the [RFC6553]		0 1 2 3 4 5 6 7
	information in a flow label:		+---+---+---+---+---+---+---+---+
			| 0 | 1 | 0 | 0 | 0 | 1 | X | Y |
			+---+---+---+---+---+---+---+---+
	0 1 2		Figure 1: NHC Escape Codes
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |O|R|F| SenderRank | RPLInstanceID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	the RPL Information header carries it in a RFC 4944 header.		Each NHC escape code is followed by a further NHC code point. The
	Depending on whether Rank and Inst both fit into 4 bits (S=0) or not		latter MUST be a code point for which special semantics for a
	(S=1), this header is structured as shown in Figure 1.		preceding escape code are defined, i.e., an escape code MUST NOT be
			used in front of an NHC code point that does not define special
			semantics for this escape code.
	1 2 3		An escape code followed by another escape code supplies additional
	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		semantics; again, a sequence of such escape codes MUST NOT be used
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		unless the final NHC code following this sequence defines the
	|0 1 0 0 0 1|0|U| Rank | Inst | (continuation)...		semantics for the specific sequence.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	1 2 3		3. RPI_NHC Encoding
	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 0 0 0 1|1|U| Rank | Inst | (continuation)...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: RPL Mesh Header: Short and Long Version		[RFC6550] section 11.2 specifies the RPL Packet Information (RPI) as
			a set of fields that are to be added to the IP packets for the
			purpose of Instance Identification, as well as Loop Avoidance and
			Detection.
	The U bit controls whether an [RFC6282] IPHC dispatch follows (U=0,		[RFC6553] defines an encoding for the RPI as a RPL option located in
	Figure 2) or an [RFC4944] FRAG1 fragment header (U=1, Figure 3). In		the IPv6 Hop-by-hop Header.
	both cases, the first three bits of the dispatch are replaced by the
	O, R, and F bits from [I-D.thubert-6man-flow-label-for-rpl].
	0 1		The present NHC compression mechanism compresses IPv6 Hop-by-hop
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		Headers that contain only that RPL option.
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| O | R | F | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	Figure 2: continuation for U=0		The fields in the RPI include an 'O', an 'R', and an 'F' bit, a 8-bit
			RPLInstanceID (with some internal structure), and a 16-bit
			SenderRank.
	1 2 3		The SenderRank is the result of the DAGRank operation on the rank of
	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		the sender, here the DAGRank operation is defined in section 3.5.1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		as:
	|O R F 0 0| datagram_size | datagram_tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: continuation for U=1		DAGRank(rank) = floor(rank/MinHopRankIncrease)
	Note that, for U=1, continuation bytes of the form XXXnnXXX, where nn		If MinHopRankIncrease is set to a multiple of 256, it appears that
	is not 00, are available for future updates of this header (they do		the least significant 8 bits of the SenderRank will be all zeroes and
	not necessarily imply a Frag1 header).		can be elided, in which case the SenderRank can be compressed into
			one byte. This idea is used in [RFC6550] by defining
			DEFAULT_MIN_HOP_RANK_INCREASE as 256. The RPI_NHC provides a
			compressed form for the RPI and is constructed as follows:
	3. Operation		0 1 2 3 4 5 6 7
			+---+---+---+---+---+---+---+---+
			| 1 | 0 | 0 | 0 | O | I | K |NH |
			+---+---+---+---+---+---+---+---+
			Figure 2: RPI NHC
			The RPL_NHC is immediately followed by the RPLInstanceID, unless it
			is elided, and then the SenderRank, which is either compressed into
			one byte or fully inlined as the whole 2 bytes. Bits in the RPL_NHC
			indicate whether the RPLInstanceID is elided and/or the SenderRank is
			compressed:
			O: The O bit is defined in [RFC6550] section 11.2.
			NH: 1-bit field. The Next Header (NH) bit is defined in [RFC6282]
			section 4.2, and it is set to indicate that the next header is
			encoded using LOWPAN_NHC.
			I: 1-bit field. If it is set, the Instance ID is elided and the
			RPLInstanceID is the Global RPLInstanceID 0. If it is not set,
			the byte immediately following the RPL_NHC contains the
			RPLInstanceID as specified in [RFC6550] section 5.1.
			K: 1-bit field. If it is set, the SenderRank is be compressed into
			one byte, and the lowest significant byte is elided. If it is not
			set, the SenderRank, is fully inlined as 2 bytes.
			R, and F bits: The R and F bits are defined in [RFC6550] section
			11.2. If R=0 and F=0, the NHC code is used as defined above. If
			either is non-zero, a single escape code with X=R and Y=F is
			prepended in front of the NHC code. (An escape code with X=0 and
			Y=0 MUST NOT be used with RPI_NHC. A sequence of two or more
			escape codes MUST NOT be used with RPI_NHC.)
			In the following case, the RPLInstanceID is the Global RPLInstanceID
			0, and the MinHopRankIncrease is a multiple of 256 so the least
			significant byte is all zeroes and can be elided:
			0 1
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|1|0|0|0|O|1|1|N| SenderRank |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			In the following case, the RPLInstanceID is the Global RPLInstanceID
			0, but both bytes of the SenderRank are significant so it can not be
			compressed:
			0 1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|1|0|0|0|O|1|0|N| SenderRank |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			In the following case, the RPLInstanceID is not the Global
			RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256:
			0 1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|1|0|0|0|O|0|1|N| RPLInstanceID | SenderRank |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			In the following case, the RPLInstanceID is not the Global
			RPLInstanceID 0, and both bytes of the SenderRank are significant:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|1|0|0|0|O|0|0|N| RPLInstanceID | SenderRank |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Depending on the RPLInstanceID and the MinHopRankIncrease, the
			proposed format thus squeezes the RPI into 16 to 40 bits, which
			compares to 64 bits when using a Hop-by-hop option with the RPL
			option as specified in [RFC6553].
			4. Operation
	A 6lo compressor that is about to create either an RFC 6282 IPHC		A 6lo compressor that is about to create either an RFC 6282 IPHC
	header [RFC6282] or a Frag1 header [RFC4944] and finds a Hop-by-Hop		header [RFC6282] or a Frag1 header [RFC4944] and finds a Hop-by-Hop
	Options header [RFC2460] with a single RPL Option [RFC6553] in it,		Options header [RFC2460] with an RPL Option [RFC6553] in it, performs
	performs the following checks:		the following checks:
	1. Does the compression scheme in		1. Does the compression scheme apply? I.e.:
	[I-D.thubert-6man-flow-label-for-rpl] apply? I.e.:
	A. is no sub-tlv present in the RPL Option?		A. is no sub-tlv present in the RPL Option?
	B. is SenderRank < 256?		B. is the RPL Option the only option in the Hop-by-Hop Options
			header?
	2. Does the additional compression for S=0 apply? I.e.:		2. Does the additional compression for I=1 apply? I.e.: is
			RPLInstanceID == 0?
	A. is SenderRank < 16?		3. Does the additional compression for K=1 apply? I.e.: is
			SenderRank < 256?
	B. is RPLInstanceID < 16?		4. Is both R=0 and F=0, or do we need an escape code?
	If check 1 succeeds, the compressor removes the Hop-by-Hop Options		If check 1 succeeds, the compressor removes the Hop-by-Hop Options
	header (replacing the zero-valued next header field in the IPv6		header (replacing the zero-valued next header field in the IPv6
	header with the value of the next header field of the Hop-by-Hop		header with the value of the next header field of the Hop-by-Hop
	Options header), and, depending on the outcome of check 2, generates		Options header), and, depending on the outcome of check 2 and 3,
	an RPL Information Header with S=0 or S=1 from the payload		generates an RPI_NHC Header with I and K set from the payload
	information in the RPL Option. It then continues generating the RFC		information in the RPL Option. If one or both of R and F are non-
	6282 IPHC or RFC 4944 Frag1 header, filling in the continuation of		zero (check 4), it precedes the first byte in the RPI_NHC header with
	the RPL Information header as defined in Section 2.		an escape code with X=R and Y=F. It then continues generating the
			RFC 6282 IPHC or RFC 4944 Frag1 header, filling in the continuation
			of the RPL Information header as defined in Section 3.
	A 6lo decompressor that encounters a RPL Information header reverses		A 6lo decompressor that encounters a RPL Information header reverses
	this process, creating a Hop-by-Hop Options header with a single RPL		this process, creating a Hop-by-Hop Options header with a single RPL
	Option carrying the information in the RPL Information header.		Option carrying the information in the RPL Information header.
	4. Discussion		5. Discussion
	(This section to be removed by the RFC editor.)		(This section to be removed by the RFC editor.)
	Compared to [I-D.thubert-6man-flow-label-for-rpl], the 6lo-based		Compared to [I-D.thubert-6man-flow-label-for-rpl], the 6lo-based
	approach used here has the following advantages:		approach used here has the following advantages:
	o more efficient (in size) encoding possible		o more efficient (in size) encoding possible
	o avoids any entanglement with flow label from RFC 6437		o avoids any entanglement with flow label from RFC 6437
	skipping to change at page 5, line 9 ¶		skipping to change at page 6, line 45 ¶
	* because the IPv6 header is not covered by a checksum		* because the IPv6 header is not covered by a checksum
	* because nodes that happen to become on-path use the flow label		* because nodes that happen to become on-path use the flow label
	for something else		for something else
	o nodes outside 6lo that do not need the compression do not have to		o nodes outside 6lo that do not need the compression do not have to
	deal with an alternate representations of the RFC 6553 information		deal with an alternate representations of the RFC 6553 information
	Compared to [I-D.toutain-6lo-local-extensions], RPL Information		Compared to [I-D.toutain-6lo-local-extensions], RPL Information
	Header proposal is entirely focused on RFC 6553 (with some extension		Header proposal is entirely focused on RFC 6553 So it may be possible
	bits left to possibly eventually cover RFC 6554). So it may be		to complete this focused draft much faster than a general approach.
	possible to complete this focused draft much faster than a general		Also, the result is likely to be more efficient.
	approach. Also, the result is likely to be more efficient. Finally,
	this draft can be ignored by implementations not implementing RPL.
	5. Background		Compared to [I-D.thubert-6lo-rpl-nhc], much more of the NHC space is
			left usable, e.g., leaving bits available to possibly eventually
			cover [RFC6554].
	Some more historical background about compression and RPL: (This		Finally, this draft can be ignored by implementations not
	section to be removed by the RFC editor.)		implementing RPL.
			6. Background
			Some more historical background about compression and RPL:\
			(This section to be removed by the RFC editor.)
	The ROLL WG has a routing protocol, RPL [RFC6550], that requires some		The ROLL WG has a routing protocol, RPL [RFC6550], that requires some
	data to be shipped around together with IP packets. [RFC6553] and		data to be shipped around together with IP packets. [RFC6553] and
	[RFC6554] define ways to do this that are consistent with the IP		[RFC6554] define ways to do this that are consistent with the IP
	architecture: The RPL Option defined in [RFC6553] is a hop-by-hop		architecture: The RPL Option defined in [RFC6553] is a hop-by-hop
	option that provides RPL rank and instance-id, as well as a few		option that provides RPL rank and instance-id, as well as a few
	flags; the Routing Header defined in [RFC6554] provides the source		flags; the Routing Header defined in [RFC6554] provides the source
	routing needed for downward-routed packets in RPL's dominant non-		routing needed for downward-routed packets in RPL's dominant non-
	storing mode.		storing mode.
	skipping to change at page 6, line 7 ¶		skipping to change at page 7, line 50 ¶
	a flow label really only costs 3 bytes (instead of the 8 bytes a RPL		a flow label really only costs 3 bytes (instead of the 8 bytes a RPL
	Option [RFC6553] costs). The most useful information from [RFC6553]		Option [RFC6553] costs). The most useful information from [RFC6553]
	can be stuffed into 19 bits, as demonstrated by		can be stuffed into 19 bits, as demonstrated by
	[I-D.thubert-6man-flow-label-for-rpl].		[I-D.thubert-6man-flow-label-for-rpl].
	[RFC6282] has extension points (GHC uses one of them), but not really		[RFC6282] has extension points (GHC uses one of them), but not really
	useful ones for the ROLL data plane. So it appears it never occurred		useful ones for the ROLL data plane. So it appears it never occurred
	to us that the best way to handle these 19 bits is to actually		to us that the best way to handle these 19 bits is to actually
	sidestep [RFC6282], and use the existing extension points of		sidestep [RFC6282], and use the existing extension points of
	[RFC4944]. Until Laurent Toutain showed one way of doing this		[RFC4944]. Until Laurent Toutain showed one way of doing this
	[I-D.toutain-6lo-local-extensions]. The present draft just went from		[I-D.toutain-6lo-local-extensions]. The previous version of the
	there and used Laurent's idea for compressing the [RFC6553] option,		present draft just went from there and used Laurent's idea for
	in a way that is as efficient as (or, in most cases, actually more		compressing the [RFC6553] option, in a way that is as efficient as
	efficient than) using the flow label opportunity.		(or, in most cases, actually more efficient than) using the flow
			label opportunity.
	This means the present draft intends to replace the flow label bit		The present draft is a variation of the idea to use NHC header
	allocation of [I-D.thubert-6man-flow-label-for-rpl]. It does not		compression for representing the [RFC6553] RPL option
	cover the "license-to-drop" the flow label that		[I-D.thubert-6lo-rpl-nhc]. It may be slightly less efficient than
			the previous version of this draft, but it is much more conservative
			in consuming NHC code point space than [I-D.thubert-6lo-rpl-nhc].
			In summary, this means the present draft intends to replace the flow
			label bit allocation of [I-D.thubert-6man-flow-label-for-rpl]. It
			does not cover the "license-to-drop" the flow label that
	[I-D.thubert-6man-flow-label-for-rpl] implies (and that is denied by		[I-D.thubert-6man-flow-label-for-rpl] implies (and that is denied by
	[RFC6437]). It also does not cover the compression of [RFC6554]		[RFC6437]). It also does not cover the compression of [RFC6554]
	source routing information, but does provide an extension point for		source routing information, but does provide an extension point for
	adding that later.		adding that later.
	6. IANA considerations		7. IANA considerations
	This draft requests IANA to assign the following four dispatch types		This draft requests IANA to assign the following LOWPAN_NHC types in
	in the "IPv6 Low Power Personal Area Network Parameters" registry:		the "IPv6 Low Power Personal Area Network Parameters" registry:
	01 0001SU		010001XY: Escape X=0/Y=0 to X=1/Y=1 [RFCthis]
	7. Security considerations		1000IOKN: RPL Information [RFCthis]
			8. Security considerations
	The security considerations of [RFC4944], [RFC6282], and [RFC6553]		The security considerations of [RFC4944], [RFC6282], and [RFC6553]
	apply.		apply.
	8. Acknowledgments		9. Acknowledgments
	This document is based on the ideas in the specification		This document is based on the ideas in the specifications
	[I-D.thubert-6man-flow-label-for-rpl]. Its use of the RFC 4944		[I-D.thubert-6man-flow-label-for-rpl] and [I-D.thubert-6lo-rpl-nhc]
	framework was inspired by [I-D.toutain-6lo-local-extensions]. Ralph		and has borrowed a lot of text from the latter. Its use of the RFC
	Droms supplied a number of helpful comments on the -00 draft. The		4944 framework was inspired by [I-D.toutain-6lo-local-extensions].
	discussion in the 6man and roll working groups also was helpful.		Ralph Droms supplied a number of helpful comments on the -00 draft.
			The discussion in the 6man and roll working groups also was helpful.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[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. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, September 2007.
	[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,
	September 2011.		September 2011.
	[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-		[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
	Power and Lossy Networks (RPL) Option for Carrying RPL		Power and Lossy Networks (RPL) Option for Carrying RPL
	Information in Data-Plane Datagrams", RFC 6553, March		Information in Data-Plane Datagrams", RFC 6553, March
	2012.		2012.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-6lo-ghc]		[I-D.ietf-6lo-ghc]
	Bormann, C., "6LoWPAN Generic Compression of Headers and		Bormann, C., "6LoWPAN Generic Compression of Headers and
	Header-like Payloads", draft-ietf-6lo-ghc-03 (work in		Header-like Payloads (GHC)", draft-ietf-6lo-ghc-05 (work
	progress), July 2014.		in progress), September 2014.
			[I-D.thubert-6lo-rpl-nhc]
			Thubert, P., "A compression mechanism for the RPL option",
			draft-thubert-6lo-rpl-nhc-01 (work in progress), August
			2014.
	[I-D.thubert-6man-flow-label-for-rpl]		[I-D.thubert-6man-flow-label-for-rpl]
	Thubert, P., "The IPv6 Flow Label within a RPL domain",		Thubert, P., "The IPv6 Flow Label within a LLN domain",
	draft-thubert-6man-flow-label-for-rpl-04 (work in		draft-thubert-6man-flow-label-for-rpl-05 (work in
	progress), August 2014.		progress), August 2014.
	[I-D.toutain-6lo-local-extensions]		[I-D.toutain-6lo-local-extensions]
	Toutain, L., "6LoWPAN Local Extensions", draft-toutain-		Toutain, L., "6LoWPAN Local Extensions", draft-toutain-
	6lo-local-extensions-00 (work in progress), June 2014.		6lo-local-extensions-00 (work in progress), June 2014.
	[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification", RFC 6437, November 2011.		"IPv6 Flow Label Specification", RFC 6437, November 2011.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
End of changes. 47 change blocks.
	115 lines changed or deleted		217 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/