draft-ietf-roll-applicability-ami-04.txt		draft-ietf-roll-applicability-ami-05.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: April 27, 2012 N. Dejean		Expires: May 3, 2012 N. Dejean
	Elster SAS		Elster SAS
	R. Salazar		R. Salazar
	Landis+Gyr		Landis+Gyr
	J. Hui		J. Hui
	Cisco		Cisco
	October 25, 2011		K. Monden
			Hitachi, Ltd., Yokohama Research
			Laboratory
			October 31, 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-04		draft-ietf-roll-applicability-ami-05
	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 41
	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 April 27, 2012.		This Internet-Draft will expire on May 3, 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 7, line 15		skipping to change at page 7, line 15
	In current AMI deployments, metering applications typically require		In current AMI deployments, metering applications typically require
	all smart meters to communicate with a few head-end servers, deployed		all smart meters to communicate with a few head-end servers, deployed
	in the utility company data center.		in the utility company data center.
	Head-end servers generate data traffic to configure smart metering		Head-end servers generate data traffic to configure smart metering
	devices or initiate queries, and use unicast and multicast to		devices or initiate queries, and use unicast and multicast to
	efficiently communicate with a single device or groups of devices		efficiently communicate with a single device or groups of devices
	respectively (i.e., Point-to-Multipoint (P2MP) communication). The		respectively (i.e., Point-to-Multipoint (P2MP) communication). The
	head-end server may send a single small packet at a time to the		head-end server may send a single small packet at a time to the
	meters (e.g., a meter read request, a small configuration change) or		meters (e.g., a meter read request, a small configuration change,
	a series of large packets (e.g., a firmware upgrade across one or		service switch command) or a series of large packets (e.g., a
	even thousands of devices). The frequency of large file transfers,		firmware upgrade across one or even thousands of devices). The
	e.g., firmware upgrade of all metering devices, is typically much		frequency of large file transfers, e.g., firmware upgrade of all
	lower than the frequency of sending configuration messages or		metering devices, is typically much lower than the frequency of
	queries.		sending configuration messages or queries.
	Each smart meter generates Smart Metering Data (SMD) traffic		Each smart meter generates Smart Metering Data (SMD) traffic
	according to a schedule (e.g., periodic meter reads), in response to		according to a schedule (e.g., periodic meter reads), in response to
	on-demand queries (e.g., on-demand meter reads), or in response to		on-demand queries (e.g., on-demand meter reads), or in response to
	some local event (e.g., power outage, leak detection). Such traffic		some local event (e.g., power outage, leak detection). Such traffic
	is typically destined to a single head-end server.		is typically destined to a single head-end server.
	The bulk of the SMD traffic tends to be directed towards the LBR,		The bulk of the SMD traffic tends to be directed towards the LBR,
	both in terms of bytes (since reports are typically much larger than		both in terms of bytes (since reports are typically much larger than
	queries) and in terms of number of packets, e.g., some reports have		queries) and in terms of number of packets, e.g., some reports have
	skipping to change at page 15, line 26		skipping to change at page 15, line 26
	This document contains no other related protocols.		This document contains no other related protocols.
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to acknowledge the review, feedback, and		The authors would like to acknowledge the review, feedback, and
	comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Philip		comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi
	Levis, and JP Vasseur.		Igarashi, Philip 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-04 (work in progress),		draft-ietf-6man-rpl-option-04 (work in progress),
	October 2011.		October 2011.
	skipping to change at line 787		skipping to change at page 17, line 46
	Email: ruben.salazar@landisgyr.com		Email: ruben.salazar@landisgyr.com
	Jonathan W. Hui		Jonathan W. Hui
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, California 95134		San Jose, California 95134
	USA		USA
	Phone: +408 424 1547		Phone: +408 424 1547
	Email: jonhui@cisco.com		Email: jonhui@cisco.com
			Kazuya Monden
			Hitachi, Ltd., Yokohama Research Laboratory
			292, Yoshida-cho, Totsuka-ku, Yokohama-shi
			Kanagawa-ken, 244-0817
			Japan
			Phone: +81-45-860-3083
			Email: kazuya.monden.vw@hitachi.com
End of changes. 7 change blocks.
	12 lines changed or deleted		15 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/