draft-ietf-roll-applicability-ami-03.txt		draft-ietf-roll-applicability-ami-04.txt
	ROLL D. Popa		ROLL D. Popa
	Internet-Draft J. Jetcheva		Internet-Draft J. Jetcheva
	Intended status: Standards Track Itron		Intended status: Standards Track Itron
	Expires: March 30, 2012 N. Dejean		Expires: April 27, 2012 N. Dejean
	Elster SAS		Elster SAS
	R. Salazar		R. Salazar
	Landis+Gyr		Landis+Gyr
	J. Hui		J. Hui
	Cisco		Cisco
	September 27, 2011		October 25, 2011
	Applicability Statement for the Routing Protocol for Low Power and Lossy		Applicability Statement for the Routing Protocol for Low Power and Lossy
	Networks (RPL) in AMI Networks		Networks (RPL) in AMI Networks
	draft-ietf-roll-applicability-ami-03		draft-ietf-roll-applicability-ami-04
	Abstract		Abstract
	This document discusses the applicability of RPL in Advanced Metering		This document discusses the applicability of RPL in Advanced Metering
	Infrastructure (AMI) networks.		Infrastructure (AMI) networks.
	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.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 March 30, 2012.		This Internet-Draft will expire on April 27, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 2, line 32		skipping to change at page 2, line 32
	2.2.2. Distribution Automation Communication . . . . . . . . 8		2.2.2. Distribution Automation Communication . . . . . . . . 8
	2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8		2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8
	3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8		3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8
	4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9		4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9
	4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9		4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9
	4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10		4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10		4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10
	4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10		4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10
	4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 10		4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 11
	4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11		4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 11		4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12		4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12
	4.2. Recommended Configuration Defaults and Ranges . . . . . . 12		4.2. Recommended Configuration Defaults and Ranges . . . . . . 12
	4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12		4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12
	4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13		4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13
	5. Manageability Considerations . . . . . . . . . . . . . . . . . 13		5. Manageability Considerations . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15		7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Informative References . . . . . . . . . . . . . . . . . . 15		10.1. Informative References . . . . . . . . . . . . . . . . . . 15
	10.2. Normative References . . . . . . . . . . . . . . . . . . . 16		10.2. Normative References . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	skipping to change at page 9, line 37		skipping to change at page 9, line 37
	4.1.1. RPL Instances		4.1.1. RPL Instances
	RPL operation is defined for a single RPL instance. However,		RPL operation is defined for a single RPL instance. However,
	multiple RPL instances can be supported in multi-service networks		multiple RPL instances can be supported in multi-service networks
	where different applications may require the use of different routing		where different applications may require the use of different routing
	metrics and constraints, e.g., a network carrying both SDM and DA		metrics and constraints, e.g., a network carrying both SDM and DA
	traffic.		traffic.
	4.1.2. Storing vs. Non-Storing Mode		4.1.2. Storing vs. Non-Storing Mode
	In most scenarios, electric meters are powered by the electric grid		In most scenarios, electric meters are powered by the grid they are
	they are monitoring and are not energy-constrained. Instead, the		monitoring and are not energy-constrained. Instead, electric meters
	capabilities of an electric meter are primarily determined by cost.		have hardware and communication capacity constraints that are
			primarily determined by cost, and secondarily by power consumption.
	As a result, different AMI deployments can vary significantly in		As a result, different AMI deployments can vary significantly in
	terms of the memory, computation, and communication trade-offs they		terms of memory size, computation power and communication
	embody. For this reason, the use of RPL storing or non-storing mode		capabilities. For this reason, the use of RPL storing or non-storing
	SHOULD be deployment specific.		mode SHOULD be deployment specific.
	For example, when meters are memory constrained and cannot adequately		When meters are memory constrained and cannot adequately store the
	store the route tables necessary to support downward routing in a		route tables necessary to support hop-by-hop routing, RPL non-storing
	typical deployment, non-storing mode is preferred. When nodes are		mode SHOULD be preferred. On the other hand, when nodes are capable
	capable of storing such routing tables, storing mode may lead to		of storing such routing tables, the use of storing mode may lead to
	reduced overhead and route repair latency.		reduced overhead and route repair latency. However, in high-density
			environments, storing routes can be challenging because some nodes
			may have to maintain routing information for a large number of
			descendents. When the routing table size becomes challenging, it is
			RECOMMENDED that nodes perform route aggregation, similarly to the
			approach taken by other routing protocols, although the required set
			of mechanism may differ.
	4.1.3. DAO Policy		4.1.3. DAO Policy
	Two-way communication is a requirement in AMI systems. As a result,		Two-way communication is a requirement in AMI systems. As a result,
	nodes SHOULD send DAO messages to establish downward paths from the		nodes SHOULD send DAO messages to establish downward paths from the
	root to themselves.		root to themselves.
	4.1.4. Path Metrics		4.1.4. Path Metrics
	Smart metering deployments utilize link technologies that may exhibit		Smart metering deployments utilize link technologies that may exhibit
	skipping to change at page 10, line 26		skipping to change at page 10, line 31
	technologies, AMI deployments can use the Expected Transmission Count		technologies, AMI deployments can use the Expected Transmission Count
	(ETX) metric as defined in[I-D.ietf-roll-routing-metrics].		(ETX) metric as defined in[I-D.ietf-roll-routing-metrics].
	For water- and gas-only networks that do not rely on powered		For water- and gas-only networks that do not rely on powered
	infrastructure, simpler metrics that require less energy to compute		infrastructure, simpler metrics that require less energy to compute
	would be more appropriate. In particular, a combination of hop count		would be more appropriate. In particular, a combination of hop count
	and link quality can satisfy this requirement. As minimizing energy		and link quality can satisfy this requirement. As minimizing energy
	consumption is critical in these types of networks, available node		consumption is critical in these types of networks, available node
	energy should also be used in conjunction with these two metrics.		energy should also be used in conjunction with these two metrics.
	The usage of additional metrics specifically designed for such		The usage of additional metrics specifically designed for such
	networks may be defined in companion RFCs.		networks may be defined in companion RFCs, e.g.,
			[I-D.ietf-roll-routing-metrics] .
	4.1.5. Objective Function		4.1.5. Objective Function
	RPL relies on an Objective Function for selecting parents and		RPL relies on an Objective Function for selecting parents and
	computing path costs and rank. This objective function is decoupled		computing path costs and rank. This objective function is decoupled
	from the core RPL mechanisms and also from the metrics in use in the		from the core RPL mechanisms and also from the metrics in use in the
	network. Two objective functions for RPL have been defined at the		network. Two objective functions for RPL have been defined at the
	time of this writing, OF0 and MRHOF, both of which define the		time of this writing, OF0 and MRHOF, both of which define the
	selection of a preferred parent and backup parents, and are suitable		selection of a preferred parent and backup parents, and are suitable
	for AMI deployments.		for AMI deployments.
	skipping to change at page 15, line 27		skipping to change at page 15, line 36
	comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Philip		comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Philip
	Levis, and JP Vasseur.		Levis, and JP Vasseur.
	10. References		10. References
	10.1. Informative References		10.1. Informative References
	[I-D.ietf-6man-rpl-option]		[I-D.ietf-6man-rpl-option]
	Hui, J. and J. Vasseur, "RPL Option for Carrying RPL		Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
	Information in Data-Plane Datagrams",		Information in Data-Plane Datagrams",
	draft-ietf-6man-rpl-option-03 (work in progress),		draft-ietf-6man-rpl-option-04 (work in progress),
	March 2011.		October 2011.
	[I-D.ietf-roll-p2p-rpl]		[I-D.ietf-roll-p2p-rpl]
	Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie,		Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie,
	R., and J. Martocci, "Reactive Discovery of Point-to-Point		R., and J. Martocci, "Reactive Discovery of Point-to-Point
	Routes in Low Power and Lossy Networks",		Routes in Low Power and Lossy Networks",
	draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011.		draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011.
	[I-D.ietf-roll-routing-metrics]		[I-D.ietf-roll-routing-metrics]
	Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.		Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
	Barthel, "Routing Metrics used for Path Calculation in Low		Barthel, "Routing Metrics used for Path Calculation in Low
End of changes. 12 change blocks.
	21 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/