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/