draft-ietf-roll-applicability-ami-02.txt   draft-ietf-roll-applicability-ami-03.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 17, 2012 N. Dejean Expires: March 30, 2012 N. Dejean
Elster SAS Elster SAS
R. Salazar R. Salazar
Landis+Gyr Landis+Gyr
J. Hui J. Hui
Cisco Cisco
September 14, 2011 September 27, 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-02 draft-ietf-roll-applicability-ami-03
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 17, 2012. This Internet-Draft will expire on March 30, 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 29 skipping to change at page 2, line 29
2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6 2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6
2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6
2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 10
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 14 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
Advanced Metering Infrastructure (AMI) systems enable the Advanced Metering Infrastructure (AMI) systems enable the
skipping to change at page 7, line 28 skipping to change at page 7, line 28
e.g., firmware upgrade of all metering devices, is typically much e.g., firmware upgrade of all metering devices, is typically much
lower than the frequency of sending configuration messages or lower than the frequency of sending configuration messages or
queries. 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 SMD traffic is thus highly asymmetric, where the majority of the The bulk of the SMD traffic tends to be directed towards the LBR,
traffic generated by the smart meters typically goes through the both in terms of bytes (since reports are typically much larger than
LBRs, and is directed from the smart meter devices to the head-end queries) and in terms of number of packets, e.g., some reports have
servers, in a Multipoint-to-Point (MP2P) fashion. to be split into multiple packets due to packet size limitations,
periodic reports can be sent without requiring a query to be sent for
each one first, unsolicited events like alarms and outage
notifications are only generated by the meters and sent towards the
LBR. The SMD traffic is thus highly asymmetric, where the majority
of the traffic volume generated by the smart meters typically goes
through the LBRs, and is directed from the smart meter devices to the
head-end servers, in a Multipoint-to-Point (MP2P) fashion.
Current SMD traffic patterns are fairly uniform and well-understood. Current SMD traffic patterns are fairly uniform and well-understood.
The traffic generated by the head-end server and destined to metering The traffic generated by the head-end server and destined to metering
devices is dominated by periodic meter reads, while traffic generated devices is dominated by periodic meter reads, while traffic generated
by the metering devices is typically uniformly spread over some by the metering devices is typically uniformly spread over some
periodic read time-window. periodic read time-window.
Smart metering applications typically do not have hard real-time Smart metering applications typically do not have hard real-time
constraints, but they are often subject to bounded latency and constraints, but they are often subject to bounded latency and
stringent reliability service level agreements. stringent reliability service level agreements.
skipping to change at page 10, line 16 skipping to change at page 10, line 21
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
significant packet loss and thus require routing metrics that take significant packet loss and thus require routing metrics that take
packet loss into account. To characterize a path over such link packet loss into account. To characterize a path over such link
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, hop count and link quality would be more appropriate. In particular, a combination of hop count
level may be more suitable. Additional metrics specifically designed and link quality can satisfy this requirement. As minimizing energy
for such networks may be defined in companion RFCs. consumption is critical in these types of networks, available node
energy should also be used in conjunction with these two metrics.
The usage of additional metrics specifically designed for such
networks may be defined in companion RFCs.
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.
Neither of the currently defined objective functions supports Neither of the currently defined objective functions supports
multiple metrics that might be required in heterogeneous networks multiple metrics that might be required in heterogeneous networks
(e.g., networks composed of devices with different energy (e.g., networks composed of devices with different energy
constraints). Additional objective functions specifically designed constraints) or combination of metrics that might be required for
for such networks may be defined in companion RFCs. water- and gas-only networks. Additional objective functions
specifically designed for such networks may be defined in companion
RFCs.
4.1.6. DODAG Repair 4.1.6. DODAG Repair
To effectively handle time-varying link characteristics and To effectively handle time-varying link characteristics and
availability, AMI deployments SHOULD utilize the local repair availability, AMI deployments SHOULD utilize the local repair
mechanisms in RPL. mechanisms in RPL.
Local repair is triggered by broken link detection and in storing Local repair is triggered by broken link detection and in storing
mode by loop detection as well. mode by loop detection as well.
skipping to change at page 15, line 12 skipping to change at page 15, line 17
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 Dominique Barthel, Philip Levis, and Jari Arkko. comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, 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-03 (work in progress), draft-ietf-6man-rpl-option-03 (work in progress),
March 2011. March 2011.
skipping to change at page 15, line 46 skipping to change at page 16, line 8
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-06 (work in
progress), March 2011. progress), September 2011.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
 End of changes. 12 change blocks. 
19 lines changed or deleted 32 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/