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/