< draft-brandt-roll-rpl-applicability-home-building-02.txt		draft-brandt-roll-rpl-applicability-home-building-03.txt >
	Roll A. Brandt		Roll A. Brandt
	Internet-Draft Sigma Designs		Internet-Draft Sigma Designs
	Intended status: Informational E. Baccelli		Intended status: Informational E. Baccelli
	Expires: November 30, 2012 INRIA		Expires: August 9, 2013 INRIA
	R. Cragie		R. Cragie
	Gridmerge		Gridmerge
	May 29, 2012		February 5, 2013
	Applicability Statement: The use of RPL in Building and Home		Applicability Statement: The use of RPL-P2P in Home and Building Control
	Environments		draft-brandt-roll-rpl-applicability-home-building-03
	draft-brandt-roll-rpl-applicability-home-building-02
	Abstract		Abstract
	The purpose of this document is to to provide guidance in the use of		The purpose of this document is to provide guidance in the use of
	RPL to provide the features required in building or home		RPL-P2P to implement the features required in building and home
	environments, two application spaces which share a substantial number		environments.
	of requirements. Note that this document refers to a specific
	revision of the RPL draft, and thus, a new revision of the RPL draft
	will likely necessitate a new revision of this document.
	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 November 30, 2012.		This Internet-Draft will expire on August 9, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2.1. Risk of undesired long P2P routes . . . . . . . . . . . . . 3		1.2. Overview of requirements . . . . . . . . . . . . . . . . . 4
	2.1.1. Traffic concentration at the root . . . . . . . . . . . 4		1.3. Out of scope requirements . . . . . . . . . . . . . . . . 4
	2.1.2. Excessive battery consumption in source nodes . . . . . 4		2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Risk of delayed route repair . . . . . . . . . . . . . . . 4		2.1. Network Topologies . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Broken service . . . . . . . . . . . . . . . . . . . . 4		2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 5
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		2.2.1. Human user responsiveness . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		2.2.2. Source-sink (SS) communication paradigm . . . . . . . 6
	5. Informative References . . . . . . . . . . . . . . . . . . . . 5		2.2.3. Peer-to-peer (P2P) communication paradigm . . . . . . 6
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5		2.2.4. Peer-to-multipeer (P2MP) communication paradigm . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Link layer applicability . . . . . . . . . . . . . . . . . 6
			3. Using RPL-P2P to meet requirements . . . . . . . . . . . . . . 7
			4. RPL Profile for RPL-P2P . . . . . . . . . . . . . . . . . . . 7
			4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 7
			4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 7
			4.1.2. Non-Storing Mode . . . . . . . . . . . . . . . . . . . 7
			4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 8
			4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 8
			4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 8
			4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 8
			4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 8
			4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 8
			4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 8
			4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . . 8
			4.2.1. Security functions provided by layer-2 . . . . . . . . 8
			4.2.2. 6LowPAN options assumed . . . . . . . . . . . . . . . 9
			4.2.3. MLE and other things . . . . . . . . . . . . . . . . . 9
			4.3. Recommended Configuration Defaults and Ranges . . . . . . 9
			5. Manageability Considerations . . . . . . . . . . . . . . . . . 9
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
			6.1. Security Considerations during initial deployment . . . . 9
			6.2. Security Considerations during incremental deployment . . 9
			7. Other related protocols . . . . . . . . . . . . . . . . . . . 9
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
			11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
			11.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Appendix A. RPL shortcomings in home and building deployments . . 11
			A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 11
			A.1.1. Traffic concentration at the root . . . . . . . . . . 12
			A.1.2. Excessive battery consumption in source nodes . . . . 12
			A.2. Risk of delayed route repair . . . . . . . . . . . . . . . 12
			A.2.1. Broken service . . . . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The purpose of this document is to to provide guidance in the use of		Home automation and building control application spaces share a
	RPL [RPL-15] to provide the features required both by [HOME-REQ] and		substantial number of properties. The purpose of this document is to
	by [BUILDING-REQ] , as these two application spaces share a		give guidance in the use of RPL-P2P to provide the features required
	substantial number of requirements. Note that this document refers		by the requirements documents "Home Automation Routing Requirements
	to a specific revision of the RPL draft, and thus, a new revision of		in Low-Power and Lossy Networks" [RFC5826] and "Building Automation
	the RPL draft will likely necessitate a new revision of this		Routing Requirements in Low-Power and Lossy Networks" [RFC5867].
	document. RPL provides multipoint-to-point (MP2P) paths from sensors
	to a sink, along a DAG; an advanced tree structure for organising
	network nodes in a loop-free topology with backup routes and
	potential support for policy-based routing. The root of the DAG is
	the sink, and sensors discover and maintain the DAG via the
	dissemination of DIO signaling, initiated by the root. Conversely,
	RPL provides point-to-multippoint (P2MP) paths from the root to nodes
	along the same DAG. RPL also provide point-to-point (P2P) paths from
	node to node, through the first ancestor along the DAG, that is
	common to both source and destination nodes. Such paths are
	discovered and maintained via DAO signaling, initiated by the
	destination node.
	2. Problem Statement		1.1. Requirements Language
	Several features required by [HOME-REQ] and by [BUILDING-REQ]		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	challenge the P2P paths provided by RPL [RPL-15]. This section		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	reviews these challenges. In some cases, a sensor may need to		document are to be interpreted as described in RFC 2119.
	spontaneously initiate the discovery and mainten of a path towards a
	desired destination that is neither the root of a DAG, nor a
	destination originating DAO signaling. This feature is absent from
	the RPL for now. Furthermore, provided P2P paths are not
	satisfactory in some cases because they involve too many intermediate
	sensors before reaching destination, which may be an issue in terms
	of energy or delay constraints. RPL does not provide a mechanism for
	discovering and maintaining more efficient alternative P2P paths when
	they are available. These deficiencies call for the specification,
	within RPL, of complementary mechanisms which will help alleviate the
	challenges described below.
	2.1. Risk of undesired long P2P routes		1.2. Overview of requirements
			Applicable requirements are described in [RFC5826] and [RFC5867].
			1.3. Out of scope requirements
			The considered network diameter is limited to a max diameter of 10
			hops and a typical diameter of 5 hops, which captures the most common
			cases in home automation and building control networks.
			This document does not consider the applicability of RPL-related
			specifications for urban and industrial applications [RFC5548],
			[RFC5673], which may exhibit significantly larger network diameters.
			2. Deployment Scenario
			A typical home automation network is less than 100 nodes. Large
			building deployments may span 10,000 nodes but to ensure
			uninterrupted service of light and air conditioning systems in
			individual zones of the building, nodes are organized in subnetworks.
			Each subnetwork in a building automation deployment is typically less
			than 200 nodes and rarely more than 500 nodes.
			The main purpose of the network is to provide control over light and
			heating/cooling resources. User intervention may be enabled via wall
			controllers combined with movement, light and temperature sensors to
			enable automatic adjustment of window blinds, reduction of room
			temperature, etc.
			Alarm systems are also important applications in home and building
			networks.
			2.1. Network Topologies
			The typical home automation network or building control subnetwork is
			a mesh network with a border router located at a convenient place in
			the home. In a building control network there may be several
			redundant border routers. The network often consists in a number of
			overlapping wireless subnetworks. Two types of routing topologies
			may exist in each subnetwork (i) a tree-shaped collection of routes
			spanning from a central building controller via the border router, on
			to destination nodes in the subnetwork, and/or (ii) a flat, un-
			directed collection of intra-network routes between arbitrary nodes
			in the subnetwork.
			Nodes in Home and Building automation networks are typically
			inexpensive devices with extremely low memory capacities, such as
			individual wall switches. Only a few nodes (such as multi-purpose
			remote controls for instance) are more expensive devices, which can
			afford more memory capacity.
			2.2. Traffic Characteristics
			Traffic may enter the network from a central controller or it may
			originate from an intra-network node, such as a wall switch. The
			majority of traffic is light-weight point-to-point control style;
			e.g. Put-Ack or Get-Response. There are however exceptions. Bulk
			data transfer is used for firmware update and logging. Multicast is
			used for service discovery or to control groups of nodes, such as
			light fixtures. Firmware updates enter the network while logs leave
			the network.
			2.2.1. Human user responsiveness
			While airconditioning and other environmental-control applications
			may accept certain response delays, alarm and light control
			applications may be regarded as soft real-time systems. A slight
			delay is acceptable, but the perceived quality of service degrades
			significantly if response times exceed 250 msec. If the light does
			not turn on at short notice, a user will activate the controls again,
			causing a sequence of commands such as Light{on,off,on,off,..} or
			Volume{up,up,up,up,up,...}.
			The reactive discovery features of RPL-P2P ensures that commands are
			normally delivered within the 250msec time window and when
			connectivity needs to be restored, it is typically completed within
			seconds.
			2.2.2. Source-sink (SS) communication paradigm
			Source-sink (SS) traffic is a common traffic type in home and
			building networks. The traffic is generated by environmental sensors
			which push periodic readings to a central server. The readings may
			be used for pure logging, or more often, to adjust light, heating and
			ventilation. Alarm sensors also generate SS style traffic.
			With regards to message latency, most SS transmissions can tolerate
			worst-case delays measured in tens of seconds. Alarm sensors,
			however, represent one exception.
			2.2.3. Peer-to-peer (P2P) communication paradigm
			Peer-to-peer (P2P) traffic is a common traffic type in home networks.
			Some building networks also rely on P2P traffic while others send all
			control traffic to a local controller box for advanced scene and
			group control; thus generating more SS and P2MP traffic.
			P2P traffic is typically generated by remote controls and wall
			controllers which push control messages directly to light or heat
			sources. P2P traffic has a strong requirement for low latency since
			P2P traffic often carries application messages that are invoked by
			humans. As mentioned in Section 2.2.1 application messages need to
			be delivered within less than a second - even when a route repair is
			needed before the message can be delivered.
			2.2.4. Peer-to-multipeer (P2MP) communication paradigm
			Peer-to-multipeer (P2MP) traffic is common in home and building
			networks. Often, a wall switch in a living room responds to user
			activation by sending commands to a number of light sources
			simultaneously.
			Individual wall switches are typically inexpensive devices with
			extremely low memory capacities. Multi-purpose remote controls for
			use in a home environment typically have more memory but such devices
			are asleep when there is no user activity. RPL-P2P reactive
			discovery allows a node to wake up and find new routes within a few
			seconds while memory constrained nodes only have to keep routes to
			relevant targets.
			2.3. Link layer applicability
			This document applies to [IEEE802.15.4] and [G.9959] which are
			adapted to IPv6 by the adaption layers [RFC4944] and [I-D.lowpanz].
			Due to the limited memory of a majority of devices (such as
			individual light-switches) RPL-P2P MUST be used with source routing
			in non-storing mode. The abovementioned adaptation layers leverage
			on the compression capabilities of [RFC6554] and [RFC6282]. Header
			compression allows small IP packets to fit into a single layer 2
			frame even when source routing is used. A network diameter limited
			to 5 hops helps achieving this.
			Packet drops are often experienced in the targeted environments.
			ICMP, UDP and even TCP flows may benefit from link layer unicast
			acknowledgments and retransmissions. Link layer unicast
			acknowledgments MUST be enabled when [IEEE802.15.4] or [G.9959] is
			used with RPL-P2P.
			3. Using RPL-P2P to meet requirements
			RPL-P2P MUST be used in home and building networks, as P2P traffic is
			substantial and route repair must be completed within seconds. RPL-
			P2P provides a reactive mechanism for quick, efficient and root-
			independent route discovery/repair. The use of RPL-P2P furthermore
			allows data traffic to avoid having to go through a central region
			around the root of the tree, and drastically reduces path length
			[SOFT11] [INTEROP12]. These characteristics are desirable in home
			and building automation networks because they substantially decrease
			unnecessary network congestion around the tree's root.
			4. RPL Profile for RPL-P2P
			RPL-P2P MUST be used in home and building networks. Non-storing mode
			allows for constrained memory in repeaters when source routing is
			used. Reactive discovery allows for low application response times
			even when on-the-fly route repair is needed.
			4.1. RPL Features
			4.1.1. RPL Instances
			TBD.
			4.1.2. Non-Storing Mode
			Non-storing mode MUST be used to cope with the extremely constrained
			memory of a majority of nodes in the network (such as individual
			light switches).
			4.1.3. DAO Policy
			TBD.
			4.1.4. Path Metrics
			TBD.
			4.1.5. Objective Function
			OF0 MUST be supported and is the RECOMMENDED OF to use. Other
			Objective Functions MAY be used as well.
			4.1.6. DODAG Repair
			Since RPL-P2P only creates DODAGs on a temporary basis during route
			repair, there is no need to repair DODAGs.
			4.1.7. Multicast
			TBD.
			4.1.8. Security
			TBD.
			4.1.9. P2P communications
			RPL-P2P [RPL-P2P] MUST be used to accomodate P2P traffic, which is
			typically substantial in home and building automation networks.
			4.2. Layer 2 features
			Security MUST be applied at layer 2 for [IEEE802.15.4] and [G.9959].
			Residential light control can accept a lower security level than
			other contexts (e.g. a nuclear research lab). Safety critical
			devices like electronic door locks SHOULD employ additional higher-
			layer security while light and heating devices may be sufficiently
			protected by a single network key. The border router MAY enforce
			access policies to limit access to the trusted LLN domain from the
			LAN.
			4.2.1. Security functions provided by layer-2
			TBD.
			4.2.2. 6LowPAN options assumed
			TBD.
			4.2.3. MLE and other things
			TBD.
			4.3. Recommended Configuration Defaults and Ranges
			TODO
			5. Manageability Considerations
			TODO
			6. Security Considerations
			TODO
			6.1. Security Considerations during initial deployment
			TODO: (This section explains how nodes get their initial trust
			anchors, initial network keys. It explains if this happens at the
			factory, in a deployment truck, if it is done in the field, perhaps
			like http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/
			papers/CullenJennings.pdf)
			6.2. Security Considerations during incremental deployment
			TODO: (This section explains how that replaces a failed node takes on
			the dead nodes' identity, or not. How are nodes retired. How are
			nodes removed if they are compromised)
			7. Other related protocols
			Application transport protocols may be CoAP over UDP or equivalents.
			Typically, UDP is used for IP transport to keep down the application
			response time and bandwidth overhead.
			Several features required by [RFC5826], [RFC5867] challenge the P2P
			paths provided by RPL. Appendix A reviews these challenges. In some
			cases, a node may need to spontaneously initiate the discovery of a
			path towards a desired destination that is neither the root of a DAG,
			nor a destination originating DAO signaling. Furthermore, P2P paths
			provided by RPL are not satisfactory in all cases because they
			involve too many intermediate nodes before reaching the destination.
			RPL-P2P [RPL-P2P] provides the features requested by [RFC5826] and
			[RFC5867]. RPL-P2P uses a subset of the frame formats and features
			defined for RPL [RFC6550] but may be combined with RPL frame flows in
			advanced deployments.
			8. IANA Considerations
			9. Acknowledgements
			This document reflects discussions and remarks from several
			individuals including (in alphabetical order): Michael Richardson,
			Mukul Goyal, Jerry Martocci, Charles Perkins, and Zach Shelby
			10. References
			11. References
			11.1. Normative References
			[RFC5826] "Home Automation Routing Requirements in Low-Power and
			Lossy Networks".
			[RFC5867] "Building Automation Routing Requirements in Low-Power and
			Lossy Networks".
			[RFC5673] "Industrial Routing Requirements in Low-Power and Lossy
			Networks".
			[RFC5548] "Routing Requirements for Urban Low-Power and Lossy
			Networks".
			[IEEE802.15.4]
			"IEEE 802.15.4 - Standard for Local and metropolitan area
			networks -- Part 15.4: Low-Rate Wireless Personal Area
			Networks", <IEEE Standard 802.15.4>.
			[RFC4944] "Transmission of IPv6 Packets over IEEE 802.15.4
			Networks".
			[G.9959] "ITU-T G.9959 Short range narrow-band digital
			radiocommunication transceivers - PHY and MAC layer
			specifications", <ITU-T G.9959>.
			[I-D.lowpanz]
			Brandt, A., "Transmission of IPv6 Packets over ITU-T
			G.9959 Networks", <draft-brandt-6man-lowpanz>.
			[RFC6282] Hui, J. and Thubert, P., "Compression Format for IPv6
			Datagrams over IEEE 802.15.4-Based Networks", RFC6282 ,
			September 2011.
			[RFC6554] Hui, J., Vasseur, JP., Culler, D., and Manral, V., "An
			IPv6 Routing Header for Source Routes with the Routing
			Protocol for Low-Power and Lossy Networks (RPL)",
			RFC6554 , March 2012.
			[RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy
			Networks".
			[RPL-P2P] Goyal, M., Baccelli, E., Phillip, M., Brandt, A., and J.
			Martocci, "Reactive Discovery of Point-to-Point Routes in
			Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl ,
			May 2012.
			11.2. Informative References
			[SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL
			Routing Protocol for IPv6 Sensor Networks: Testbed
			Experiments", Proceedings of the Conference on Software
			Telecommunications and Computer Networks, Split, Croatia,
			September 2011., September 2011.
			[INTEROP12]
			Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J.
			Buron , "Report on P2P-RPL Interoperability Testing", RR-
			7864 INRIA Research Report RR-7864, Janurary 2012.
			Appendix A. RPL shortcomings in home and building deployments
			This document reflects discussions and remarks from several
			individuals including (in alphabetical order): Charles Perkins, Jerry
			Martocci, Michael Richardson, Mukul Goyal and Zach Shelby.
			A.1. Risk of undesired long P2P routes
	The DAG, being a tree structure is formed from a root. If nodes		The DAG, being a tree structure is formed from a root. If nodes
	residing in different branches have a need for communicating		residing in different branches have a need for communicating
	internally, DAG mechanisms provided in RPL [RPL-15] will propagate		internally, DAG mechanisms provided in RPL [RFC6550] will propagate
	traffic towards the root, potentially all the way to the root, and		traffic towards the root, potentially all the way to the root, and
	down along another branch. In a typical example two nodes could		down along another branch. In a typical example two nodes could
	reach each other via just two router nodes but in unfortunate cases,		reach each other via just two router nodes but in unfortunate cases,
	RPL [RPL-15] may send traffic three hops up and three hops down		RPL may send traffic three hops up and three hops down again. This
	again. This leads to several undesired phenomena described in the		leads to several undesired phenomena described in the following
	following sections		sections
	2.1.1. Traffic concentration at the root		A.1.1. Traffic concentration at the root
	If many P2P data flows have to move up towards the root to get down		If many P2P data flows have to move up towards the root to get down
	again in another branch there is an increased risk of congestion the		again in another branch there is an increased risk of congestion the
	nearer to the root of the DAG the data flows. Due to the broadcast		nearer to the root of the DAG the data flows. Due to the broadcast
	nature of RF systems any child node of the root is not just directing		nature of RF systems any child node of the root is not just directing
	RF power downwards its subtree but just as much upwards towards the		RF power downwards its subtree but just as much upwards towards the
	root; potentially jamming other MP2P traffic leaving the tree or		root; potentially jamming other MP2P traffic leaving the tree or
	preventing the root of the DAG from sending P2MP traffic into the DAG		preventing the root of the DAG from sending P2MP traffic into the DAG
	because the listen-before-talk link-layer protection kicks in.		because the listen-before-talk link-layer protection kicks in.
	2.1.2. Excessive battery consumption in source nodes		A.1.2. Excessive battery consumption in source nodes
	Battery-powered nodes originating P2P traffic depend on the route		Battery-powered nodes originating P2P traffic depend on the route
	length. Long routes cause source nodes to stay awake for longer		length. Long routes cause source nodes to stay awake for longer
	periods before returning to sleep. Thus, a longer route translates		periods before returning to sleep. Thus, a longer route translates
	proportionally (more or less) into higher battery consumption.		proportionally (more or less) into higher battery consumption.
	2.2. Risk of delayed route repair		A.2. Risk of delayed route repair
	The RPL DAG mechanism uses DIO and DAO messages to monitor the health		The RPL DAG mechanism uses DIO and DAO messages to monitor the health
	of the DAG. In rare occasions, changed radio conditions may render		of the DAG. In rare occasions, changed radio conditions may render
	routes unusable just after a destination node has returned a DAO		routes unusable just after a destination node has returned a DAO
	indicating that the destination is reachable. Given enough time, the		indicating that the destination is reachable. Given enough time, the
	next Trickle timer-controlled DIODAO update will eventually repair		next Trickle timer-controlled DIODAO update will eventually repair
	the broken routes. In a worst-case event this is however too late.		the broken routes. In a worst-case event this is however too late.
	In an apparently stable DAG, Trickle-timer dynamics may reduce the		In an apparently stable DAG, Trickle-timer dynamics may reduce the
	update rate to a few times every hour. If a user issues an actuator		update rate to a few times every hour. If a user issues an actuator
	command, e.g. light on in the time interval between the last DAO		command, e.g. light on in the time interval between the last DAO
	message was issued the destination module and the time one of the		message was issued the destination module and the time one of the
	parents sends the next DIO, the destination cannot be reached.		parents sends the next DIO, the destination cannot be reached.
	Nothing in RPL [RPL-15] kicks in to restore connectivity in a		Nothing in RPL kicks in to restore connectivity in a reactive
	reactive fashion. The consequence is a broken service in home and		fashion. The consequence is a broken service in home and building
	building applications.		applications.
	2.2.1. Broken service		A.2.1. Broken service
	Experience from the telecom industry shows that if the voice delay		Experience from the telecom industry shows that if the voice delay
	exceeds 250ms users start getting confused, frustrated andor annoyed.		exceeds 250ms users start getting confused, frustrated andor annoyed.
	In the same way, if the light does not turn on within the same period		In the same way, if the light does not turn on within the same period
	of time, a home control user will activate the controls again,		of time, a home control user will activate the controls again,
	causing a sequence of commands such as Light{on,off,off,on,off,..} or		causing a sequence of commands such as Light{on,off,off,on,off,..} or
	Volume{up,up,up,up,up,...} Whether the outcome is nothing or some		Volume{up,up,up,up,up,...} Whether the outcome is nothing or some
	unintended response this is unacceptable. A controlling system must		unintended response this is unacceptable. A controlling system must
	be able to restore connectivity to recover from the error situation.		be able to restore connectivity to recover from the error situation.
	Waiting for an unknown period of time is not an option. While this		Waiting for an unknown period of time is not an option. While this
	issue was identified during the P2P analysis it applies just as well		issue was identified during the P2P analysis it applies just as well
	to application scenarios where an IP application outside the LLN		to application scenarios where an IP application outside the LLN
	controls actuators, lights, etc.		controls actuators, lights, etc.
	3. IANA Considerations
	This document has no actions for IANA.
	4. Security Considerations
	This document does not have to any security considerations.
	5. Informative References
	[HOME-REQ]
	Brandt, A., Buron, J., and G. Porcu, "Home Automation
	Routing Requirements in Low Power and Lossy Networks",
	RFC5826 .
	[BUILDING-REQ]
	Martocci, J., De Mil, P., Vermeylen, W., and N. Riou,
	"Building Automation Routing Requirements in Low Power and
	Lossy Networks", RFC5867 .
	[RPL-15] Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for
	Low power and Lossy Networks", draft-ietf-roll-rpl-15 ,
	2010.
	Appendix A. Acknowledgements
	This document reflects discussions and remarks from several
	individuals including (in alphabetical order): Mukul Goyal, Jerry
	Martocci, Charles Perkins, and Zach Shelby.
	Authors' Addresses		Authors' Addresses
	Anders Brandt		Anders Brandt
	Sigma Designs		Sigma Designs
	Email: abr@sdesigns.dk		Email: abr@sdesigns.dk
	Emmanuel Baccelli		Emmanuel Baccelli
	INRIA		INRIA
	Email: Emmanuel.Baccelli@inria.fr		Email: Emmanuel.Baccelli@inria.fr
	Robert Cragie		Robert Cragie
	Gridmerge		Gridmerge
	Email: robert.cragie@gridmerge.com		Email: robert.cragie@gridmerge.com
End of changes. 21 change blocks.
	101 lines changed or deleted		426 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/