< draft-brandt-roll-rpl-applicability-home-building-00.txt		draft-brandt-roll-rpl-applicability-home-building-01.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: October 8, 2010 INRIA		Expires: May 16, 2011 INRIA
	R. Cragie		R. Cragie
	Gridmerge		Gridmerge
	April 6, 2010		November 16, 2010
	Applicability Statement: The use of RPL in Building and Home		Applicability Statement: The use of RPL in Building and Home
	Environments		Environments
	draft-brandt-roll-rpl-applicability-home-building-00		draft-brandt-roll-rpl-applicability-home-building-01
	Abstract		Abstract
	The purpose of this document is to to provide guidance in the use of		The purpose of this document is to to provide guidance in the use of
	RPL to provide the features required in building or home		RPL to provide the features required in building or home
	environments, two application spaces which share a substantial number		environments, two application spaces which share a substantial number
	of requirements. Note that this document refers to a specific		of requirements. Note that this document refers to a specific
	revision of the RPL draft, and thus, a new revision of the RPL draft		revision of the RPL draft, and thus, a new revision of the RPL draft
	will likely necessitate a new revision of this document.		will likely necessitate a new revision of this document.
	skipping to change at page 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	2.2.1. Broken service . . . . . . . . . . . . . . . . . . . . 4		2.2.1. Broken service . . . . . . . . . . . . . . . . . . . . 4
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	5. Informative References . . . . . . . . . . . . . . . . . . . . 5		5. Informative References . . . . . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	The purpose of this document is to to provide guidance in the use of		The purpose of this document is to to provide guidance in the use of
	RPL [RPL-07] to provide the features required both by [HOME-REQ] and		RPL [RPL-15] to provide the features required both by [HOME-REQ] and
	by [BUILDING-REQ] , as these two application spaces share a		by [BUILDING-REQ] , as these two application spaces share a
	substantial number of requirements. Note that this document refers		substantial number of requirements. Note that this document refers
	to a specific revision of the RPL draft, and thus, a new revision of		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		the RPL draft will likely necessitate a new revision of this
	document. RPL provides multipoint-to-point (MP2P) paths from sensors		document. RPL provides multipoint-to-point (MP2P) paths from sensors
	to a sink, along a DAG; an advanced tree structure for organising		to a sink, along a DAG; an advanced tree structure for organising
	network nodes in a loop-free topology with backup routes and		network nodes in a loop-free topology with backup routes and
	potential support for policy-based routing. The root of the DAG is		potential support for policy-based routing. The root of the DAG is
	the sink, and sensors discover and maintain the DAG via the		the sink, and sensors discover and maintain the DAG via the
	dissemination of DIO signaling, initiated by the root. Conversely,		dissemination of DIO signaling, initiated by the root. Conversely,
	RPL provides point-to-multippoint (P2MP) paths from the root to nodes		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		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		node to node, through the first ancestor along the DAG, that is
	common to both source and destination nodes. Such paths are		common to both source and destination nodes. Such paths are
	discovered and maintained via DAO signaling, initiated by the		discovered and maintained via DAO signaling, initiated by the
	destination node.		destination node.
	2. Problem Statement		2. Problem Statement
	Several features required by [HOME-REQ] and by [BUILDING-REQ]		Several features required by [HOME-REQ] and by [BUILDING-REQ]
	challenge the P2P paths provided by RPL [RPL-07]. This section		challenge the P2P paths provided by RPL [RPL-15]. This section
	reviews these challenges. In some cases, a sensor may need to		reviews these challenges. In some cases, a sensor may need to
	spontaneously initiate the discovery and mainten of a path towards a		spontaneously initiate the discovery and mainten of a path towards a
	desired destination that is neither the root of a DAG, nor a		desired destination that is neither the root of a DAG, nor a
	destination originating DAO signaling. This feature is absent from		destination originating DAO signaling. This feature is absent from
	the RPL for now. Furthermore, provided P2P paths are not		the RPL for now. Furthermore, provided P2P paths are not
	satisfactory in some cases because they involve too many intermediate		satisfactory in some cases because they involve too many intermediate
	sensors before reaching destination, which may be an issue in terms		sensors before reaching destination, which may be an issue in terms
	of energy or delay constraints. RPL does not provide a mechanism for		of energy or delay constraints. RPL does not provide a mechanism for
	discovering and maintaining more efficient alternative P2P paths when		discovering and maintaining more efficient alternative P2P paths when
	they are available. These deficiencies call for the specification,		they are available. These deficiencies call for the specification,
	within RPL, of complementary mechanisms which will help alleviate the		within RPL, of complementary mechanisms which will help alleviate the
	challenges described below.		challenges described below.
	2.1. Risk of undesired long P2P routes		2.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-07] will propagate		internally, DAG mechanisms provided in RPL [RPL-15] 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-07] may send traffic three hops up and three hops down		RPL [RPL-15] may send traffic three hops up and three hops down
	again. This leads to several undesired phenomena described in the		again. This leads to several undesired phenomena described in the
	following sections		following sections
	2.1.1. Traffic concentration at the root		2.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
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	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-07] kicks in to restore connectivity in a		Nothing in RPL [RPL-15] kicks in to restore connectivity in a
	reactive fashion. The consequence is a broken service in home and		reactive fashion. The consequence is a broken service in home and
	building applications.		building applications.
	2.2.1. Broken service		2.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
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	4. Security Considerations		4. Security Considerations
	This document does not have to any security considerations.		This document does not have to any security considerations.
	5. Informative References		5. Informative References
	[HOME-REQ]		[HOME-REQ]
	Brandt, A., Buron, J., and G. Porcu, "Home Automation		Brandt, A., Buron, J., and G. Porcu, "Home Automation
	Routing Requirements in Low Power and Lossy Networks",		Routing Requirements in Low Power and Lossy Networks",
	draft-ietf-roll-home-routing-reqs-11 , 2010.		RFC5826.
	[BUILDING-REQ]		[BUILDING-REQ]
	Martocci, J., De Mil, P., Vermeylen, W., and N. Riou,		Martocci, J., De Mil, P., Vermeylen, W., and N. Riou,
	"Building Automation Routing Requirements in Low Power and		"Building Automation Routing Requirements in Low Power and
	Lossy Networks",		Lossy Networks", RFC5867.
	draft-ietf-roll-building-routing-reqs-09 , 2010.
	[RPL-07] Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for		[RPL-15] Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for
	Low power and Lossy Networks", draft-ietf-roll-rpl-07 ,		Low power and Lossy Networks", draft-ietf-roll-rpl-15 ,
	2010.		2010.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This document reflects discussions and remarks from several		This document reflects discussions and remarks from several
	individuals including (in alphabetical order): Mukul Goyal, Jerry		individuals including (in alphabetical order): Mukul Goyal, Jerry
	Martocci, Charles Perkins, and Zach Shelby.		Martocci, Charles Perkins, and Zach Shelby.
	Authors' Addresses		Authors' Addresses
End of changes. 11 change blocks.
	13 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/