< draft-thubert-6man-flow-label-for-rpl-01.txt		draft-thubert-6man-flow-label-for-rpl-02.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 13, 2014
	Expires: November 14, 2014		Expires: November 14, 2014
	The IPv6 Flow Label within a RPL domain		The IPv6 Flow Label within a RPL domain
	draft-thubert-6man-flow-label-for-rpl-01		draft-thubert-6man-flow-label-for-rpl-02
	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 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	practical, for instance rotating devices.		practical, for instance rotating devices.
	In particular, IEEE802.14.5 [IEEE802154] that is chartered to specify		In particular, IEEE802.14.5 [IEEE802154] that is chartered to specify
	PHY and MAC layers for radio Lowpower Lossy Networks (LLNs), defined		PHY and MAC layers for radio Lowpower Lossy Networks (LLNs), defined
	the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) mode of		the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) mode of
	operation as part of the IEEE802.15.4e MAC specification in order to		operation as part of the IEEE802.15.4e MAC specification in order to
	address Time Sensitive applications.		address Time Sensitive applications.
	The 6TISCH architecture [I-D.ietf-6tisch-architecture] specifies the		The 6TISCH architecture [I-D.ietf-6tisch-architecture] specifies the
	operation IPv6 over TSCH wireless networks attached and synchronized		operation IPv6 over TSCH wireless networks attached and synchronized
	by backbone routers. In that model, route Computation may be		by backbone routers.
	achieved in a centralized fashion by a Path Computation Element
	(PCE), in a distributed fashion using the Routing Protocol for Low		With 6TiSCH, the route Computation may be achieved in a centralized
	Power and Lossy Networks [RFC6550] (RPL), or in a mixed mode. The		fashion by a Path Computation Element (PCE), in a distributed fashion
	Backbone Routers may typically serve as roots for the RPL domain.		using the Routing Protocol for Low Power and Lossy Networks [RFC6550]
			(RPL), or in a mixed mode.
	6TiSCH was created to simplify the adoption of IETF technology by		6TiSCH was created to simplify the adoption of IETF technology by
	other Standard Defining Organizations (SDOs), in particular in the		other Standard Defining Organizations (SDOs), in particular in the
	Industrial Automation space, which already relies on variations of		Industrial Automation space, which already relies on variations of
	IEEE802.15.4e TSCH for Wireless Sensor Networking. ISA100.11a		IEEE802.15.4e TSCH for Wireless Sensor Networking.
	[ISA100.11a] is an example of such industrial WSN standard, using
	IEEE802.15.4e over the classical IEEE802.14.5 PHY. In that case,		ISA100.11a [ISA100.11a] is an example of such industrial WSN
	after security is applied, roughly 80 octets are available per frame		standard, using IEEE802.15.4e over the classical IEEE802.14.5 PHY.
	for IP and Payload. In order to 1) avoid fragmentation and 2)		In that case, after security is applied, roughly 80 octets are
	conserve energy, the SDO will scrutinize any bit in the frame and		available per frame for IP and Payload. In order to 1) avoid
	reject any waste.		fragmentation and 2) conserve energy, the SDO will scrutinize any bit
			in the frame and reject any waste.
	The challenge to obtain the adoption of IPv6 in the original standard		The challenge to obtain the adoption of IPv6 in the original standard
	was really to save any possible bit in the frames, including the UDP		was really to save any possible bit in the frames, including the UDP
	checksum which was an interesting discussion on its own. This work		checksum which was an interesting discussion on its own. This work
	was actually one of the roots for the 6LoWPAN Header Compression		was actually one of the roots for the 6LoWPAN Header Compression
	[RFC6282] work, which goes down to the individual bits to save space		[RFC6282] work, which goes down to the individual bits to save space
	in the frames for actual data, and allowed ISA100.11a to adopt IPv6.		in the frames for actual data, and allowed ISA100.11a to adopt IPv6.
	1.1. On Wasted Energy		1.1. On Wasted Energy
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 5 ¶
	A classical RPL implementation will use the RPL Option for Carrying		A classical RPL implementation will use the RPL Option for Carrying
	RPL Information in Data-Plane Datagrams [RFC6553] to tag a packet		RPL Information in Data-Plane Datagrams [RFC6553] to tag a packet
	with the Instance ID and other information that RPL requires for its		with the Instance ID and other information that RPL requires for its
	operation within the RPL domain. In particular, the Rank, which is		operation within the RPL domain. In particular, the Rank, which is
	the scalar metric computed by an specialized Objective Function such		the scalar metric computed by an specialized Objective Function such
	as [RFC6552], is modified at each hop and allows to validate that the		as [RFC6552], is modified at each hop and allows to validate that the
	packet progresses in the expected direction each upwards or downwards		packet progresses in the expected direction each upwards or downwards
	in along the DODAG.		in along the DODAG.
	With [RFC6553] the RPL option is encoded as 6 Octets; it must be		With [RFC6553], the RPL option is encoded as 6 Octets; it must be
	placed in a Hop-by-Hop header that represents 2 additional octets for		placed in a Hop-by-Hop header that represents 2 additional octets for
	a total of 8. In order to limit its range to the inside the RPL		a total of 8. In order to limit its range to the inside the RPL
	domain, the Hop-by-Hop header must be added to (or removed from)		domain, the Hop-by-Hop header must be added to (or removed from)
	packets that cross the border of the RPL domain. For reasons such as		packets that cross the border of the RPL domain. For reasons such as
	the capability to send ICMP errors back to the source, this operation		the capability to send ICMP errors back to the source, this operation
	involves an extra IP-in-IP encapsulation inside the RPL domain for		involves an extra IP-in-IP encapsulation inside the RPL domain for
	all the packets which path is not contained within the RPL domain.		all the packets which path is not contained within the RPL domain.
	The 8-octets overhead is detrimental to the LLN operation, in		The 8-octets overhead is detrimental to the LLN operation, in
	particular with regards to bandwidth and battery constraints. The		particular with regards to bandwidth and battery constraints. The
End of changes. 4 change blocks.
	14 lines changed or deleted		16 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/