< draft-thubert-6man-flow-label-for-rpl-02.txt		draft-thubert-6man-flow-label-for-rpl-03.txt >
	6MAN P. Thubert, Ed.		6MAN P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track May 13, 2014		Intended status: Standards Track May 20, 2014
	Expires: November 14, 2014		Expires: November 21, 2014
	The IPv6 Flow Label within a RPL domain		The IPv6 Flow Label within a RPL domain
	draft-thubert-6man-flow-label-for-rpl-02		draft-thubert-6man-flow-label-for-rpl-03
	Abstract		Abstract
	This document present how the Flow Label can be used inside a RPL		This document present how the Flow Label can be used inside a RPL
	domain as a replacement to the RPL option and provides rules for the		domain as a replacement to the RPL option and provides rules for the
	root to set and reset the Flow Label when forwarding between the		root to set and reset the Flow Label when forwarding between the
	inside of RPL domain and the larger Internet, in both direction.		inside of RPL domain and the larger Internet, in both direction.
	This new operation saves 44 bits in each frame, and an eventual IP-		This new operation saves 44 bits in each frame, and an eventual IP-
	in-IP encapsulation within the RPL domain that is required for all		in-IP encapsulation within the RPL domain that is required for all
	packets that reach outside of the RPL domain.		packets that reach outside of the RPL domain.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 November 14, 2014.		This Internet-Draft will expire on November 21, 2014.
	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
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 44 ¶
	For the compelling reason of saving energy, this specification allows		For the compelling reason of saving energy, this specification allows
	that regardless of its original setting, a root of a RPL domain MAY		that regardless of its original setting, a root of a RPL domain MAY
	reset the Flow Label of IPv6 packets entering the RPL domain to zero		reset the Flow Label of IPv6 packets entering the RPL domain to zero
	for an optimal Header Compression by 6LoWPAN [RFC6282]. The		for an optimal Header Compression by 6LoWPAN [RFC6282]. The
	specification also allows that the root and LLN routers MAY reuse the		specification also allows that the root and LLN routers MAY reuse the
	Flow Label inside the LLN for LLN purposes, such as to carry the RPL		Flow Label inside the LLN for LLN purposes, such as to carry the RPL
	Information as detailed hereafter.		Information as detailed hereafter.
	This specification also allows that regardless of its original		This specification also allows that regardless of its original
	setting, a a root of a RPL domain MAY set low Label of IPv6 packets		setting, a root of a RPL domain MAY set the Flow Label of IPv6
	that exits the RPL domain MAY be set by the RPL, in a manner that		packets that exit the RPL domain in a manner that SHOULD conform to
	SHOULD conform the prescriptions in [RFC6437], and that a source in		the prescriptions in [RFC6437]. Therefore a source in the RPL domain
	the RPL domain MAY NOT expect that its setting of the Flow Label be		MUST NOT assume that its setting of the Flow Label be preserved end-
	preserved end-to-end. From there, the capability by RPL routers		to-end. From there, the capability by RPL routers inside the LLN to
	inside the LLN to alter a non-zero Flow Label between the source and		alter a non-zero Flow Label between the source and the root is
	the root is another minor deviation to [RFC6437] that is also		another minor deviation to [RFC6437] that is also acceptable since it
	acceptable since it is transparent to the core of the Internet.		is transparent to the core of the Internet.
	4. Flow Label Format Within the RPL Domain		4. Flow Label Format Within the RPL Domain
	[RFC6550] section 11.2 specifies the fields that are to be placed		[RFC6550] section 11.2 specifies the fields that are to be placed
	into the packets for the purpose of Instance Identification, as well		into the packets for the purpose of Instance Identification, as well
	as Loop Avoidance and Detection. Those fields include an 'O', and		as Loop Avoidance and Detection. Those fields include an 'O', and
	'R' and an 'F' bits, the 8-bit RPLInstanceID, and the 16-bit		'R' and an 'F' bits, the 8-bit RPLInstanceID, and the 16-bit
	SenderRank. SenderRank is the result of the DAGRank operation on the		SenderRank. SenderRank is the result of the DAGRank operation on the
	rank of the sender, where the DAGRank operation is defined in section		rank of the sender, where the DAGRank operation is defined in section
	3.5.1 as:		3.5.1 as:
End of changes. 4 change blocks.
	12 lines changed or deleted		12 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/