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/ |