< draft-clausen-lln-rpl-experiences-10.txt		draft-clausen-lln-rpl-experiences-11.txt >
	Network Working Group T. Clausen		Network Working Group T. Clausen
	Internet-Draft A. Colin de Verdiere		Internet-Draft A. Colin de Verdiere
	Intended status: Informational		Intended status: Informational
	Expires: July 27, 2018 J. Yi		Expires: September 28, 2018 J. Yi
	Ecole Polytechnique		Ecole Polytechnique
	U. Herberg		U. Herberg
	Y. Igarashi		Y. Igarashi
	Hitachi, Ltd., Yokohama Research		Hitachi, Ltd., Yokohama Research
	Laboratory		Laboratory
	January 23, 2018		March 27, 2018
	Observations on RPL: IPv6 Routing Protocol for Low power and Lossy		Observations on RPL: IPv6 Routing Protocol for Low power and Lossy
	Networks		Networks
	draft-clausen-lln-rpl-experiences-10		draft-clausen-lln-rpl-experiences-11
	Abstract		Abstract
	With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" -		With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" -
	published as a Proposed Standard after a ~2-year development cycle,		published as a Proposed Standard after a ~2-year development cycle,
	this document presents an observation of the resulting protocol, of		this document presents an observation of the resulting protocol, of
	its applicability, and of its limits. The documents presents a		its applicability, and of its limits. The documents presents a
	selection of observations on the protocol characteristics, exposes		selection of observations on the protocol characteristics, exposes
	experiences acquired when producing various prototype implementations		experiences acquired when producing various prototype implementations
	of RPL, and presents results obtained from testing this protocol - by		of RPL, and presents results obtained from testing this protocol - by
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 July 27, 2018.		This Internet-Draft will expire on September 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	1. Introduction		1. Introduction
	RPL - the "Routing Protocol for Low Power and Lossy Networks"		RPL - the "Routing Protocol for Low Power and Lossy Networks"
	[RFC6550] - is a proposal for an IPv6 routing protocol for Low-power		[RFC6550] - is a proposal for an IPv6 routing protocol for Low-power
	Lossy Networks (LLNs), by the ROLL Working Group in the Internet		Lossy Networks (LLNs), by the ROLL Working Group in the Internet
	Engineering Task Force (IETF). This routing protocol is intended to		Engineering Task Force (IETF). This routing protocol is intended to
	be the IPv6 routing protocol for LLNs and sensor networks, applicable		be the IPv6 routing protocol for LLNs and sensor networks, applicable
	in all kinds of deployments and applications of LLNs.		in all kinds of deployments and applications of LLNs.
	The objective of RPL and ROLL is to provide routing in networks which		The objective of RPL and ROLL at the time of development and
	"comprise up to thousands of nodes" [roll-charter], where the		publication of [RFC6550] in 2012 is to provide routing in networks
			which "comprise up to thousands of nodes" [roll-charter], where the
	majority of the nodes have very constrained resources [RFC7102], and		majority of the nodes have very constrained resources [RFC7102], and
	where handling mobility is not an explicit design criteria [RFC5867],		where handling mobility is not an explicit design criteria [RFC5867],
	[RFC5826], [RFC5673], [RFC5548].		[RFC5826], [RFC5673], [RFC5548].
	[roll-charter] states that "Typical traffic patterns are not simply		[roll-charter] in 2012 states that "Typical traffic patterns are not
	unicast flows (e.g. in some cases most if not all traffic can be		simply unicast flows (e.g. in some cases most if not all traffic can
	point to multipoint)". [RFC7102] further categorizes the supported		be point to multipoint)". [RFC7102] further categorizes the
	traffic types into "upward" traffic from sensors to an actuator or		supported traffic types into "upward" traffic from sensors to an
	LBR (LLN Border Router) (denoted multipoint-to-point), "downward"		actuator or LBR (LLN Border Router) (denoted multipoint-to-point),
	traffic from the actuator or LBR to the sensors (denoted point-to-		"downward" traffic from the actuator or LBR to the sensors (denoted
	multipoint) and traffic from "sensor to sensor" (denoted point-to-		point-to-multipoint) and traffic from "sensor to sensor" (denoted
	point traffic), and establishes this terminology for these traffic		point-to-point traffic), and establishes this terminology for these
	types. Thus, while the target for RPL and ROLL is to support all of		traffic types. Thus, while the target for RPL and ROLL is to support
	these traffic types, the emphasis among these, according to		all of these traffic types, the emphasis among these, according to
	[roll-charter], appears to be to optimize for multipoint-to-point		[roll-charter], appears to be to optimize for multipoint-to-point
	traffic, while also supporting point-to-multipoint and point-to-point		traffic, while also supporting point-to-multipoint and point-to-point
	traffic.		traffic.
	With experiences obtained since the publication of RPL as [RFC6550],		With experiences obtained since the publication of RPL as [RFC6550],
	it is opportune to document observations of the protocol, in order to		it is opportune to document observations of the protocol, in order to
	understand which aspects of it work well and which necessitate		understand which aspects of it work well and which necessitate
	further investigations. Understanding possible limitations is		further investigations. Understanding possible limitations is
	important to identify issues which may restrict the deployment scope		important to identify issues which may restrict the deployment scope
	of the protocol and which may need further protocol work or		of the protocol and which may need further protocol work or
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	required energy, memory and computational resources so as to serve as		required energy, memory and computational resources so as to serve as
	DODAG Roots, and be administratively configured as such - with the		DODAG Roots, and be administratively configured as such - with the
	remainder of the routers in the network being of typically lesser		remainder of the routers in the network being of typically lesser
	capacity. In storing mode, the DODAG root needs to keep a routing		capacity. In storing mode, the DODAG root needs to keep a routing
	entry for each router in the RPL instance. In non-storing mode, the		entry for each router in the RPL instance. In non-storing mode, the
	resource requirements on the DODAG Root are likely much higher than		resource requirements on the DODAG Root are likely much higher than
	in storing mode, as the DODAG Root needs to store a network graph		in storing mode, as the DODAG Root needs to store a network graph
	containing complete routes to all destinations in the RPL instance,		containing complete routes to all destinations in the RPL instance,
	in order to calculate the routing table (whereas in storing mode,		in order to calculate the routing table (whereas in storing mode,
	only the next hop for each destination in the RPL instance needs to		only the next hop for each destination in the RPL instance needs to
	be stored. Aaggregation may be used to further reduce the resource		be stored. Aggregation may be used to further reduce the resource
	requirements).		requirements).
	A router that acts as a DODAG Root represents a single point of		A router that acts as a DODAG Root represents a single point of
	failure for the DODAG it serves. It is possible for a given RPL		failure for the DODAG it serves. It is possible for a given RPL
	deployment to contain several DODAGs, each rooted in a border router.		deployment to contain several DODAGs, each rooted in a border router.
	RPL also supports that several border routers participate in the same		RPL also supports that several border routers participate in the same
	DODAG - with the caveat that in this case, a "virtual" DODAG root,		DODAG - with the caveat that in this case, a "virtual" DODAG root,
	external to the LLN, exists and which coordinates DODAGVersionNumbers		external to the LLN, exists and which coordinates DODAGVersionNumbers
	and other DODAG parameters. The precise coordination mechanism is		and other DODAG parameters. The precise coordination mechanism is
	not specified in [RFC6550], which instead states that:		not specified in [RFC6550], which instead states that:
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 41 ¶
	bidirectional traffic by way of data-packets and their		bidirectional traffic by way of data-packets and their
	corresponding acknowledgements. In fact, current Internet		corresponding acknowledgements. In fact, current Internet
	protocols generally require some form of acknowledgment.		protocols generally require some form of acknowledgment.
	Foregoing an acknowledgment probably means a trade-off in the area		Foregoing an acknowledgment probably means a trade-off in the area
	of reliable transmission or repeated retransmissions or both.		of reliable transmission or repeated retransmissions or both.
	o Telemetry scenarios where the DODAG root and the sink are not co-		o Telemetry scenarios where the DODAG root and the sink are not co-
	located. This can happen if different kinds of information are		located. This can happen if different kinds of information are
	sent to different central authorities for processing: for example,		sent to different central authorities for processing: for example,
	temperature goes to Server A and humidity goes to Server B. A		temperature goes to Server A and humidity goes to Server B. A
	possible solution for RPL is to run several DADAGs with different		possible solution for RPL is to run several DODAGs with different
	roots, which incurs extra overhead.		roots, which incurs extra overhead.
	For scenarios in which point-to-point traffic is a more common		For scenarios in which point-to-point traffic is a more common
	occurrence, all point-to-point routes include the DODAG Root,		occurrence, all point-to-point routes include the DODAG Root,
	possibly causing congestion events on the communication medium near		possibly causing congestion events on the communication medium near
	the DODAG Root, and draining energy from the intermediate routers on		the DODAG Root, and draining energy from the intermediate routers on
	an unnecessarily long route. If sensor-to-sensor traffic is common,		an unnecessarily long route. If sensor-to-sensor traffic is common,
	routers near the DODAG Root will be particularly solicited as relays,		routers near the DODAG Root will be particularly solicited as relays,
	especially in non-storing mode.		especially in non-storing mode.
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 33 ¶
	o Energy drain from the routers near the DODAG root, because they		o Energy drain from the routers near the DODAG root, because they
	need to forward more traffic for other parts of the network.		need to forward more traffic for other parts of the network.
	6. Fragmentation Of RPL Control Messages And Data Packet		6. Fragmentation Of RPL Control Messages And Data Packet
	The link layers for LLNs generally have limited MTUs compared to		The link layers for LLNs generally have limited MTUs compared to
	ethernet or wireless LANs. For example, for [ieee802154], the MTU is		ethernet or wireless LANs. For example, for [ieee802154], the MTU is
	limited to 127 bytes; for [g3-plc], it is up to 252 octets, or 511		limited to 127 bytes; for [g3-plc], it is up to 252 octets, or 511
	octets, depending on the bandplan. Those link layers are unable to		octets, depending on the bandplan. Those link layers are unable to
	provide an MTU of at least 1280 octets - as otherwise required for		provide an MTU of at least 1280 octets - as otherwise required for
	IPv6 [RFC2460]. In such LLNs, link fragmentation and reassembly of		IPv6 [RFC8200]. In such LLNs, link fragmentation and reassembly of
	IP packets at a layer below IPv6 is used to transport larger IP		IP packets at a layer below IPv6 is used to transport larger IP
	packets, providing the required minimum 1280 octet MTU [RFC4919].		packets, providing the required minimum 1280 octet MTU [RFC4919].
	When such link fragmentation is used, the IP packet has to be		When such link fragmentation is used, the IP packet has to be
	reassembled at every hop. Every fragment must be received		reassembled at every hop. Every fragment must be received
	successfully by the receiving device, or the entire IP packet is		successfully by the receiving device, or the entire IP packet is
	lost. Moreover, the additional link-layer frame overhead (and IPv6		lost. Moreover, the additional link-layer frame overhead (and IPv6
	Fragment header overhead in case of IP fragmentation) for each of the		Fragment header overhead in case of IP fragmentation) for each of the
	fragments increases the capacity required from the medium. It may		fragments increases the capacity required from the medium. It may
	consume more energy for transmitting a higher number of frames on the		consume more energy for transmitting a higher number of frames on the
	network interface.		network interface.
	RPL is an IPv6 routing protocol, designed to operate on constrained		RPL is an IPv6 routing protocol, designed to operate on constrained
	link layers, such as [ieee802154], with a maximum frame size of 127		link layers, such as [ieee802154], with a maximum frame size of 127
	bytes - a much smaller value than the specified minimum MTU of 1280		bytes - a much smaller value than the specified minimum MTU of 1280
	bytes for IPv6 [RFC2460]. Reducing the need of fragmentation of IP		bytes for IPv6 [RFC8200]. Reducing the need of fragmentation of IP
	datagrams on such a link layer, 6LoWPAN provides an adaptation layer		datagrams on such a link layer, 6LoWPAN provides an adaptation layer
	[RFC4944], [RFC6282], providing link fragmentation in order to		[RFC4944], [RFC6282], providing link fragmentation in order to
	accommodate IPv6 packet transmissions over the maximum IEEE 802.15.4		accommodate IPv6 packet transmissions over the maximum IEEE 802.15.4
	frame size of 127 octets, as well as compressing the IPv6 header,		frame size of 127 octets, as well as compressing the IPv6 header,
	reducing the overhead of the IPv6 header from at least 40 octets to a		reducing the overhead of the IPv6 header from at least 40 octets to a
	minimum of 2 octets. Given that the IEEE 802.15.4 frame size of 127		minimum of 2 octets. Given that the IEEE 802.15.4 frame size of 127
	octets, a maximum frame overhead of 25 octets and 21 octets for link		octets, a maximum frame overhead of 25 octets and 21 octets for link
	layer security [RFC4944], 81 octets remain for L2 payload. Further		layer security [RFC4944], 81 octets remain for L2 payload. Further
	subtracting 2 octets for the compressed IPv6 header leaves 79 octets		subtracting 2 octets for the compressed IPv6 header leaves 79 octets
	for L3 data payload if link fragmentation is to be avoided.		for L3 data payload if link fragmentation is to be avoided.
	skipping to change at page 28, line 18 ¶		skipping to change at page 28, line 18 ¶
	contributions to conducting many of the experiments, revealing or		contributions to conducting many of the experiments, revealing or
	confirming the issues described in this document.		confirming the issues described in this document.
	Moreover, the authors would like to express their gratitude to Ralph		Moreover, the authors would like to express their gratitude to Ralph
	Droms (Cisco) for his careful review of various versions of this		Droms (Cisco) for his careful review of various versions of this
	document, for many long discussions, and for his considerable		document, for many long discussions, and for his considerable
	contributions to both the content and the quality of this document.		contributions to both the content and the quality of this document.
	18. Informative References		18. Informative References
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, Decemer 1998.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals",		Overview, Assumptions, Problem Statement, and Goals",
	RFC 4919, August 2007.		RFC 4919, August 2007.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	skipping to change at page 29, line 50 ¶		skipping to change at page 29, line 47 ¶
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554,		for Low-Power and Lossy Networks (RPL)", RFC 6554,
	March 2012.		March 2012.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Lossy Networks", RFC 7102, January 2014.		Lossy Networks", RFC 7102, January 2014.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252, June 2014.		Application Protocol (CoAP)", RFC 7252, June 2014.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/
			RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
	[SEP2.0] Computer Society, IEEE., "P2030.5 IEEE Draft Standard for		[SEP2.0] Computer Society, IEEE., "P2030.5 IEEE Draft Standard for
	Smart Energy Profile 2.0 Application Protocol", 2014.		Smart Energy Profile 2.0 Application Protocol", 2014.
	[ZigBeeIP]		[ZigBeeIP]
	Alliance, ZigBee., "ZigBee IP Specification",		Alliance, ZigBee., "ZigBee IP Specification",
	ZigBee Public Document 13-002r00, February 2013.		ZigBee Public Document 13-002r00, February 2013.
	[bidir] Clausen, T. and U. Herberg, "A Comparative Performance		[bidir] Clausen, T. and U. Herberg, "A Comparative Performance
	Study of the Routing Protocols LOAD and RPL with Bi-		Study of the Routing Protocols LOAD and RPL with Bi-
	Directional Traffic in Low-power and Lossy Networks		Directional Traffic in Low-power and Lossy Networks
	skipping to change at page 30, line 44 ¶		skipping to change at page 30, line 47 ¶
	Layer (PHY) Specifications for LowData-Rate, Wireless,		Layer (PHY) Specifications for LowData-Rate, Wireless,
	Smart Metering Utility Networks", April 2012.		Smart Metering Utility Networks", April 2012.
	[powertrace]		[powertrace]
	Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes,		Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes,
	"Powertrace: Network-level Power Profiling for Low-power		"Powertrace: Network-level Power Profiling for Low-power
	Wireless Networks", Technical Report SICS T2011:05.		Wireless Networks", Technical Report SICS T2011:05.
	[roll-charter]		[roll-charter]
	"ROLL Charter",		"ROLL Charter",
	web http://datatracker.ietf.org/wg/roll/charter/,		web https://datatracker.ietf.org/doc/charter-ietf-
	February 2012.		roll/03/, February 2012.
	[rpl-contiki]		[rpl-contiki]
	Tsiftes, N., Eriksson, J., and A. Dunkels, "Low-Power		Tsiftes, N., Eriksson, J., and A. Dunkels, "Low-Power
	Wireless IPv6 Routing with ContikiRPL",		Wireless IPv6 Routing with ContikiRPL",
	Proceedings Proceedings of the 9th ACM/IEEE International		Proceedings Proceedings of the 9th ACM/IEEE International
	Conference on Information Processing in Sensor Networks		Conference on Information Processing in Sensor Networks
	(ISPN), 2011.		(ISPN), 2011.
	[rpl-eval]		[rpl-eval]
	Clausen, T., Herberg, U., and M. Philipp, "A Critical		Clausen, T., Herberg, U., and M. Philipp, "A Critical
End of changes. 13 change blocks.
	25 lines changed or deleted		28 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/