draft-ietf-roll-applicability-ami-01.txt   draft-ietf-roll-applicability-ami-02.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: January 26, 2012 N. Dejean Expires: March 17, 2012 N. Dejean
Elster SAS Elster SAS
R. Salazar R. Salazar
Landis+Gyr Landis+Gyr
J. Hui J. Hui
Cisco Cisco
July 25, 2011 September 14, 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-01 draft-ietf-roll-applicability-ami-02
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 January 26, 2012. This Internet-Draft will expire on March 17, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3 1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3
1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 4 1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 3
1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4 1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5
2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Electric Meter Network . . . . . . . . . . . . . . . . 5
2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6
2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6
2.2.1. Meter Data Management . . . . . . . . . . . . . . . . 6 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7
2.2.2. Distribution Automation . . . . . . . . . . . . . . . 7 2.2.2. Distribution Automation Communication . . . . . . . . 8
2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 7 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8
3. Using RPL to Meet Functional Requirements . . . . . . . . . . 7 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8
4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 8 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 8 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9
4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 9 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10
4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 9 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 10
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 10 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. RPL Options . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 11
4.3. Recommended Configuration Defaults and Ranges . . . . . . 10 4.2. Recommended Configuration Defaults and Ranges . . . . . . 12
5. Manageability Considerations . . . . . . . . . . . . . . . . . 11 4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13
7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 12 5. Manageability Considerations . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Informative References . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Advanced Metering Infrastructure (AMI) systems enable the Advanced Metering Infrastructure (AMI) systems enable the
measurement, configuration, and control of energy, gas and water measurement, configuration, and control of energy, gas and water
consumption and distribution, through two-way scheduled, on consumption and distribution, through two-way scheduled, on
exception, and on-demand communication. exception, and on-demand communication.
AMI networks are composed of millions of endpoints, including meters, AMI networks are composed of millions of endpoints, including meters,
distribution automation elements, and home area network devices. distribution automation elements, and home area network devices.
They are typically inter-connected using some combination of wireless They are typically inter-connected using some combination of wireless
technologies and power-line communications, along with backhaul technologies and power-line communications, along with a backhaul
network providing connectivity to "command-and-control" management network providing connectivity to "command-and-control" management
software applications at the utility company back office. software applications at the utility company back office.
1.1. Electric Metering 1.1. Electric Metering
In many deployments, in addition to measuring energy consumption, the In many deployments, in addition to measuring energy consumption, the
electric meter network plays a central role in the Smart Grid since electric meter network plays a central role in the Smart Grid since
it enables the utility company to control and query the electric it enables the utility company to control and query the electric
meters themselves and also since it can serve as a backhaul for all meters themselves and also since it can serve as a backhaul for all
other devices in the Smart Grid, e.g., water and gas meters, other devices in the Smart Grid, e.g., water and gas meters,
skipping to change at page 3, line 37 skipping to change at page 3, line 37
meters may also be used as sensors to monitor electric grid quality meters may also be used as sensors to monitor electric grid quality
and to support applications such as Electric Vehicle charging. and to support applications such as Electric Vehicle charging.
Electric meter networks are composed of millions of smart meters (or Electric meter networks are composed of millions of smart meters (or
nodes), each of which is resource-constrained in terms of processing nodes), each of which is resource-constrained in terms of processing
power, storage capabilities, and communication bandwidth, due to a power, storage capabilities, and communication bandwidth, due to a
combination of factors including Federal Communications Commission combination of factors including Federal Communications Commission
(FCC) or other continents' regulations on spectrum use, American (FCC) or other continents' regulations on spectrum use, American
National Standards Institute (ANSI) standards or other continents' National Standards Institute (ANSI) standards or other continents'
regulation on meter behavior and performance, on heat emissions regulation on meter behavior and performance, on heat emissions
within the meter, form factor and cost considerations. This results within the meter, form factor and cost considerations. These
in a compromise between range and throughput, with effective link constraints result in a compromise between range and throughput, with
throughput of tens to a few hundred kilobits per second per link, a effective link throughput of tens to a few hundred kilobits per
potentially significant portion of which is taken up by protocol and second per link, a potentially significant portion of which is taken
encryption overhead when strong security measures are in place. up by protocol and encryption overhead when strong security measures
are in place.
Electric meters are often interconnected into multi-hop mesh Electric meters are often interconnected into multi-hop mesh
networks, each of which is connected to a backhaul network leading to networks, each of which is connected to a backhaul network leading to
the utility network through a network aggregation point (NAP). These the utility company network through a network aggregation point,
kinds of networks increase coverage and reduce installation cost, e.g., an LBR (LLN Border Router).
time and complexity, as well as operational costs, as compared to
single-hop wireless networks, relying on a wireline or cellular
backhaul. Each electric meter mesh typically has on the order of
several thousand wireless endpoints, with densities varying based on
the area and the terrain. Apartment buildings in urban centers may
have hundreds of meters in close proximity, whereas rural areas may
have sparse node distributions and include nodes that only have one
or two network neighbors. Paths in the mesh between a network device
and the nearest aggregation point may be composed of several hops or
even tens of hops.
1.2. Gas and Water Metering 1.2. Gas and Water Metering
While electric meters typically consume electricity from the same While electric meters typically consume electricity from the same
electric feed that they are monitoring, gas and water meters electric feed that they are monitoring, gas and water meters
typically run on a modest source of stored energy (i.e. batteries). typically run on a modest source of stored energy (e.g., batteries).
In some scenarios, gas and water meters are integrated into the same In some scenarios, gas and water meters are integrated into the same
AMI network as the electric meters and may operate as network AMI network as the electric meters and may operate as network
endpoints (rather than routers) in order to prolong their own endpoints (rather than routers) in order to prolong their own
lifetime. In other scenarios, such meters may not have the luxury of lifetime. In other scenarios, however, such meters may not have the
relying on a powered routing infrastructure but must communicate luxury of relying on a fully powered AMI routing infrastructure but
through other energy-constrained devices (i.e., through other gas and must communicate through a dedicated infrastructure to reach a LBR.
water meters) to reach a NAP. In some cases, battery-powered meters This infrastructure can be either powered by the electricity grid, by
need to communicate directly with a sparsely deployed network battery-based devices, or ones relying on alternative sources of
infrastructure, requiring them to use high transmit power levels (and energy (e.g., solar power).
thus more energy) in order to achieve the necessary range to reach
the infrastructure. In all of these types of networks, the routing
protocol must operate with energy consumption in mind.
RPL is designed to operate in energy-constrained environments and
includes energy-saving mechanisms (e.g. Trickle timers) and energy-
aware metrics. Its ability to support multiple different metrics and
constraints at the same time enables it to run efficiently in
heterogeneous networks composed of nodes and links with vastly
different characteristics. [I-D.ietf-roll-routing-metrics].
1.3. Routing Protocol for LLNs (RPL) 1.3. Routing Protocol for LLNs (RPL)
RPL provides routing functionality for mesh networks composed of a RPL provides routing functionality for mesh networks that can scale
large number of resource-constrained devices, interconnected by low up to thousands of resource-constrained devices, interconnected by
power and lossy links, and communicating with the external network low power and lossy links, and communicating with the external
infrastructure through a common aggregation point (e.g., a border network infrastructure through a common aggregation point(s) (e.g., a
router). LBR).
RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at
the aggregation point, ensures loop-free routing, and provides the LBR, ensures loop-free routing, and provides support for
support for alternate routes, as well as, for a wide range of routing alternate routes, as well as, for a wide range of routing metrics and
metrics and policies. policies.
RPL was desgined to operate in energy-constrained environments and
includes energy-saving mechanisms (e.g., Trickle timers) and energy-
aware metrics. Its ability to support multiple different metrics and
constraints at the same time enables it to run efficiently in
heterogeneous networks composed of nodes and links with vastly
different characteristics[I-D.ietf-roll-routing-metrics].
This note describes the applicability of RPL (as defined in This note describes the applicability of RPL (as defined in
[I-D.ietf-roll-rpl]) to AMI deployments. RPL was designed to meet [I-D.ietf-roll-rpl]) to AMI deployments. RPL was designed to meet
the following application requirements: the following application requirements:
o Routing Requirements for Urban Low-Power and Lossy Networks o Routing Requirements for Urban Low-Power and Lossy Networks
[RFC5548]. [RFC5548].
o Industrial Routing Requirements in Low-Power and Lossy Networks o Industrial Routing Requirements in Low-Power and Lossy Networks
[RFC5673]. [RFC5673].
skipping to change at page 5, line 38 skipping to change at page 5, line 26
2. Deployment Scenarios 2. Deployment Scenarios
2.1. Network Topology 2.1. Network Topology
AMI networks are composed of millions of endpoints distributed across AMI networks are composed of millions of endpoints distributed across
both urban and rural environments. Such endpoints include electric, both urban and rural environments. Such endpoints include electric,
gas, and water meters, distribution automation elements, and home gas, and water meters, distribution automation elements, and home
area network devices. Devices in the network communicate directly area network devices. Devices in the network communicate directly
with other devices in close proximity using a variety of low-power with other devices in close proximity using a variety of low-power
and/or lossy link technologies that are both wired and wireless (e.g. and/or lossy link technologies that are both wired and wireless
IEEE 802.15.4, IEEE P1901.2, and WiFi). In addition to serving as (e.g., IEEE 802.15.4, IEEE P1901.2, and 802.11). In addition to
sources and destinations of packets, many network elements typically serving as sources and destinations of packets, many network elements
also forward packets to reduce the need for dedicated network typically also forward packets and thus form a mesh topology.
infrastructure and the associated deployment and operational costs.
2.1.1. Electric Meter Network
In a typical AMI deployment, groups of meters within physical In a typical AMI deployment, groups of meters within physical
proximity form routing domains, each in the order of a 1,000 to proximity form routing domains, each in the order of a 1,000 to
10,000 meters. These routing domains are connected to the larger IP 10,000 meters. Thus, each electric meter mesh typically has several
infrastructure through one or more LLN Border Routers (LBRs), which thousand wireless endpoints, with densities varying based on the area
provide Wide Area Network (WAN) connectivity through various and the terrain. For example, apartment buildings in urban centers
traditional network technologies, e.g., Ethernet, Cellular, private may have hundreds of meters in close proximity, whereas rural areas
WAN. may have sparse node distributions and include nodes that only have a
small number of network neighbors.
Each routing domain is connected to the larger IP infrastructure
through one or more LBRs, which provide Wide Area Network (WAN)
connectivity through various traditional network technologies, e.g.,
Ethernet, cellular, private WAN. Paths in the mesh between a network
node and the nearest LBR may be composed of several hops or even
several tens of hops.
Powered from the main line, electric meters have less energy Powered from the main line, electric meters have less energy
constraints than battery powered devices and can afford the constraints than battery powered devices, such as gas and water
additional resources required to route packets. In mixed meters, and can afford the additional resources required to route
environments, electric meters provide the routing topology while gas packets. In mixed environments, electric meters can provide the
and water meters operate as leaf nodes. However, in the absence of a routing topology while gas and water meters can operate as leaf
co-located electric meter network, gas and water meters must either nodes.
connect directly to the larger IP network infrastructure or form
their own routing topology, albeit with energy consumption in mind.
Meter networks may also serve as transit networks for other types of Electric meter networks may also serve as transit networks for other
devices, including distribution automation elements (e.g., sensors types of devices, including distribution automation elements (e.g.,
and actuators), and in-home devices. These other devices may utilize sensors and actuators), and in-home devices. These other devices may
a different link-layer technology than the one used in the meter utilize a different link-layer technology than the one used in the
network. meter network.
The routing protocol operating in networks with the topology
characteristics described above needs to be able to scale with
network size and number of forwarding hops, and have the ability to
handle a wide range of network densities.
2.1.2. Energy-Constrained Network Infrastructure
In the absence of a co-located electric meter network, gas and water
meters must either connect directly to the larger IP network
infrastructure or rely on a dedicated routing infrastructure.
Deploying such infrastructures is a challenging task as the routing
devices can sometimes only be placed in specific locations and thus
do not always have access to a continous energy source. Battery-
operated or energy-harvesting (e.g., equipped with solar panels)
routers are thus often used in these kinds of scenarios.
Due to the expected lifetime (10 to 20 years) of such networks and
their reliance on alternative sources of energy, energy consumption
needs to be taken into account when designing and deploying them.
There are a number of challenging trade-offs and considerations that
exist in that respect. One such consideration is that managing a
higher number of meters per router leads to increased energy
consumption. However, increasing the number of routers in the
network and thus reducing the number of meters managed by each router
increases deployment and maintenance costs. At the same time, the
use of a sparser routing infrastructure necessitates the use of
higher transmit power levels at nodes in the network, which causes
increased energy consumption.
The deployment and operational needs of energy-constrained network
infrastructure require the use of routing mechanisms that take into
account energy consumption, minimize energy use and prolong network
lifetime.
2.2. Traffic Characteristics 2.2. Traffic Characteristics
2.2.1. Smart Metering Data
2.2.1. Meter Data Management In current AMI deployments, metering applications typically require
all smart meters to communicate with a few head-end servers, deployed
in the utility company data center.
Meter Data Management (MDM) applications typically require every Head-end servers generate data traffic to configure smart metering
smart meter to communicate with a few head-end servers deployed in a devices or initiate queries, and use unicast and multicast to
utility data center. As a result, all smart metering traffic efficiently communicate with a single device or groups of devices
typically goes through the LBRs, with the vast majority of traffic respectively (i.e., Point-to-Multipoint (P2MP) communication). The
flowing from smart meter devices to the head-end servers, i.e., in a head-end server may send a single small packet at a time to the
Multipoint-to-Point (MP2P) fashion. meters (e.g., a meter read request, a small configuration change) or
a series of large packets (e.g., a firmware upgrade across one or
even thousands of devices). The frequency of large file transfers,
e.g., firmware upgrade of all metering devices, is typically much
lower than the frequency of sending configuration messages or
queries.
Smart meters may generate traffic according to a schedule (e.g., Each smart meter generates Smart Metering Data (SMD) traffic
periodic meter reads), in response to on-demand queries (e.g., on- according to a schedule (e.g., periodic meter reads), in response to
demand meter reads), or in response to events (e.g., power outages, on-demand queries (e.g., on-demand meter reads), or in response to
leak detections). Such traffic is typically unicast since it is sent some local event (e.g., power outage, leak detection). Such traffic
to a single head-end server. is typically destined to a single head-end server.
Head-end servers generate traffic to configure smart metering devices The SMD traffic is thus highly asymmetric, where the majority of the
or initiate queries, and use unicast and multicast to efficiently traffic generated by the smart meters typically goes through the
communicate with a single device (i.e., Point-to-Point (P2P) LBRs, and is directed from the smart meter devices to the head-end
communication) or groups of devices respectively (i.e., Point-to- servers, in a Multipoint-to-Point (MP2P) fashion.
Multipoint (P2MP) communication). The head-end server may send a
single small packet at a time (e.g., a meter read request, or small
configuration change) or many consecutive large packets (e.g., a
firmware upgrade across one or even thousands of devices).
While smart metering applications typically do not have hard real- Current SMD traffic patterns are fairly uniform and well-understood.
time constraints, they are often subject to stringent latency and The traffic generated by the head-end server and destined to metering
reliability service level agreements. devices is dominated by periodic meter reads, while traffic generated
by the metering devices is typically uniformly spread over some
periodic read time-window.
2.2.2. Distribution Automation Smart metering applications typically do not have hard real-time
constraints, but they are often subject to bounded latency and
stringent reliability service level agreements.
From a routing perspective, SMD applications require efficient P2MP
communication between the devices in the network and one or more
LBRs. In addition, timely loop resolution and broken link repair are
needed to meet latency requirements. Finally, the availability of
redundant paths is important for increasing network reliability.
2.2.2. Distribution Automation Communication
Distribution Automation (DA) applications typically involve a small Distribution Automation (DA) applications typically involve a small
number of devices that communicate with each other in a Point-to- number of devices that communicate with each other in a Point-to-
Point (P2P) fashion. The DA devices may or may not be in close Point (P2P) fashion, and may or may not be in close physical
physical proximity. proximity.
DA applications typically have more stringent latency requirements DA applications typically have more stringent latency requirements
than MDM applications. than SMD applications.
2.2.3. Emerging Applications 2.2.3. Emerging Applications
There are a number of emerging applications such as electric vehicle There are a number of emerging applications such as electric vehicle
charging. These applications may require P2P communication and may charging. These applications may require P2P communication and may
eventually have more stringent latency requirements than MDM eventually have more stringent latency requirements than SMD
applications. applications.
3. Using RPL to Meet Functional Requirements 3. Using RPL to Meet Functional Requirements
The functional requirements for most AMI deployments are similar to The functional requirements for most AMI deployments are similar to
those listed in [RFC5548]: those listed in [RFC5548]:
o The routing protocol MUST be capable of supporting the o The routing protocol MUST be capable of supporting the
organization of a large number of nodes into regions containing on organization of a large number of nodes into regions containing on
the order of 10^2 to 10^4 nodes each. the order of 10^2 to 10^4 nodes each.
skipping to change at page 8, line 28 skipping to change at page 9, line 28
This section outlines a RPL profile for a representative AMI This section outlines a RPL profile for a representative AMI
deployment. deployment.
4.1. RPL Features 4.1. RPL Features
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 MDM 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 electric grid
they are monitoring and are not energy-constrained. Instead, the they are monitoring and are not energy-constrained. Instead, the
capabilities of an electric meter are primarily determined by cost. capabilities of an electric meter are primarily determined by cost.
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 that terms of the memory, computation, and communication trade-offs they
they embody. For this reason, the use of RPL storing or non-storing embody. For this reason, the use of RPL storing or non-storing mode
mode SHOULD be deployment specific. SHOULD be deployment specific.
When meters are memory constrained and cannot adequately store route For example, when meters are memory constrained and cannot adequately
tables to support downward routing, non-storing mode is preferred. store the route tables necessary to support downward routing in a
However, when nodes are capable of adequately storing such routing typical deployment, non-storing mode is preferred. When nodes are
tables, storing mode can lead to reduced overhead and shorter route capable of storing such routing tables, storing mode may lead to
repair latency. reduced overhead and route repair latency.
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 can exhibit Smart metering deployments utilize link technologies that may exhibit
significant packet loss. To characterize a path over such link significant packet loss and thus require routing metrics that take
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 cannot rely on a powered For water- and gas-only networks that do not rely on powered
infrastructure, energy constraints may require simpler metrics that infrastructure, simpler metrics that require less energy to compute
do not require as much energy to compute. In particular, hop count would be more appropriate. In particular, hop count and link quality
and link quality level may be more suitable in such deployments. level may be more suitable. Additional metrics specifically designed
Other possible metrics to use may be vendor-specific or defined at a for such networks may be defined in companion RFCs.
later time 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 basic objective functions for RPL have been defined at network. Two objective functions for RPL have been defined at the
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 a basic AMI deployment. Neither of these supports multiple for AMI deployments.
metrics that might be required in heterogeneous networks (i.e.
networks composed of devices with different energy constraints). A Neither of the currently defined objective functions supports
new objective function can be defined to meet this requirement. multiple metrics that might be required in heterogeneous networks
(e.g., networks composed of devices with different energy
constraints). 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.
The first mechanism for local repair when a node loses connectivity Local repair is triggered by broken link detection and in storing
to its parents is to detach from a DODAG then re-attach to the same mode by loop detection as well.
or to a different DODAG at a later time. While detached, a node
advertises an infinite rank value so that its children can select a
different parent. This process is known as poisoning and described
in Section 8.2.2.5 of [I-D.ietf-roll-rpl]. While RPL provides an
option to form a local DODAG, doing so in AMI deployments is of
little benefit since AMI applications typically communicate through a
LBR. After the detached node has made sufficient effort to send
notification to its children that it is detached, the node can rejoin
the same DODAG with a higher rank value. Note that when joining a
different DODAG, the node need not perform poisoning.
The second local repair mechanism controls how much a node can The first local repair mechanism consists of a node detaching from a
increase its rank within a given DODAG Version. Setting the DODAG and then re-attaching to the same or to a different DODAG at a
DAGMaxRankIncrease to a non-zero value enables this mechanism, and later time. While detached, a node advertises an infinite rank value
setting it to a value of less than infinity limits the cost of count- so that its children can select a different parent. This process is
to-infinity scenarios when they occur. known as poisoning and is described in Section 8.2.2.5 of
[I-D.ietf-roll-rpl]. While RPL provides an option to form a local
DODAG, doing so in AMI deployments is of little benefit since AMI
applications typically communicate through a LBR. After the detached
node has made sufficient effort to send notification to its children
that it is detached, the node can rejoin the same DODAG with a higher
rank value. The configured duration of the poisoning mechanism needs
to take into account the disconnection time applications running over
the network can tolerate. Note that when joining a different DODAG,
the node need not perform poisoning.
The third local repair mechanism enables loop detection, and is The second local repair mechanism controls how much a node can
implemented by including the rank value of the transmitting node in increase its rank within a given DODAG Version (e.g., after detaching
packets forwarded towards the root (in the packet's RPL Packet from the DODAG as a result of broken link or loop detection).
Information option [I-D.ietf-6man-rpl-option]). Note that loop Setting the DAGMaxRankIncrease to a non-zero value enables this
detection is not needed when sending packets using strict source mechanism, and setting it to a value of less than infinity limits the
routing. cost of count-to-infinity scenarios when they occur, thus controlling
the duration of disconnection applications may experience.
4.1.7. Multicast 4.1.7. Multicast
RPL defines multicast support for its storing mode of operation. The RPL defines multicast support for its storing mode of operation,
DODAG structure built for unicast packet dissemination is used for where the DODAG structure built for unicast packet dissemination is
multicast distribution as well. In particular, multicast forwarding used for multicast distribution as well. In particular, multicast
state creation is done through DAO messages with multicast target forwarding state creation is done through DAO messages with multicast
options sent along the DODAG towards the root. Thereafter nodes with target options sent along the DODAG towards the root. Thereafter
forwarding state for a particular group forward multicast packets nodes with forwarding state for a particular group forward multicast
along the DODAG by copying them to all children from which they have packets along the DODAG by copying them to all children from which
received a DAO with a multicast target option for the group. they have received a DAO with a multicast target option for the
group.
Multicast support for RPL in non-storing mode will be defined in Multicast support for RPL in non-storing mode will be defined in
companion RFCs. companion RFCs.
4.1.8. Security 4.1.8. Security
AMI deployments operate in areas that do not provide any physical AMI deployments operate in areas that do not provide any physical
security. For this reason, the link technologies used within AMI security. For this reason, the link layer, transport layer and
deployments typically provide security mechanisms to ensure application layer technologies utilized within AMI networks typically
provide security mechanisms to ensure authentication,
confidentiality, integrity, and freshness. As a result, AMI confidentiality, integrity, and freshness. As a result, AMI
deployments may not need to implement RPL's security mechanisms and deployments may not need to implement RPL's security mechanisms and
could rely on link-layer security features. could rely on link layer and higher layer security features.
4.2. RPL Options 4.1.9. P2P communications
4.3. Recommended Configuration Defaults and Ranges Distribution Automation and other emerging applications may require
efficient P2P communications. Basic P2P capabilities are already
defined in the RPL RFC [I-D.ietf-roll-rpl]. Additional mechanisms
for efficient P2P communication are being developed in companion
RFCs.
o AMI deployments can involve densities of hundreds of devices 4.2. Recommended Configuration Defaults and Ranges
within communication range. As a result, such networks SHOULD set
the DIOIntervalMin to 16 or more, resulting in a Trickle Imin of 1
minute or more. In networks with low-energy consumption
requirements, DIOIntervalMin SHOULD be set to a higher value.
o AMI deployments SHOULD set DIOIntervalDoublings to a value that 4.2.1. Trickle Parameters
gives a Trickle Imax of 2 hours or more. In networks with low-
energy consumption requirements, DIOIntervalDoublings SHOULD be
set to a value that results in a Trickle Imax of several (e.g., 2)
days.
o AMI deployments SHOULD set DIORedundancyConstant to a value of 10 Trickle was designed to be density-aware and perform well in networks
or more. characterized by a wide range of node densities. The combination of
DIO packet suppression and adaptive timers for sending updates allows
Trickle to perform well in both sparse and dense environments.
Node densities in AMI deployments can vary greatly, from nodes having
only one or a handful of neighbors to nodes having several hundred
neighbors. In high density environments, relatively low values for
Imin may cause a short period of congestion when an inconsistency is
detected and DIO updates are sent by a large number of neighboring
nodes nearly simultaneously. While the Trickle timer will
exponentially backoff, some time may elapse before the congestion
subsides. While some link layers employ contention mechanisms that
attempt to avoid congestion, relying solely on the link layer to
avoid congestion caused by a large number of DIO updates can result
in increased communication latency for other control and data traffic
in the network.
To mitigate this kind of short-term congestion, this document
recommends a more conservative set of values for the Trickle
parameters than those specified in [RFC6206]. In particular,
DIOIntervalMin is set to a larger value to avoid periods of
congestion in dense environments, and DIORefundancyConstant is
parameterized accordingly as described below. These values are
appropriate for the timely distribution of DIO updates in both sparse
and dense scenarios while avoiding the short-term congestion that
might arise in dense scenarios.
Because the actual link capacity depends on the particular link
technology used within an AMI deployment, the Trickle parameters are
specified in terms of the link's maximum capacity for transmitting
link-local multicast messages. If the link can transmit m link-local
multicast packets per second on average, the expected time it takes
to transmit a link-local multicast packet is 1/m seconds.
DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that
the Trickle Imin is at least 50 times as long as it takes to
transmit a link-local multicast packet. This value is larger than
that recommended in [RFC6206] to avoid congestion in dense urban
deployments as described above. In energy-constrained deployments
(e.g., in water and gas battery-based routing infrastructure),
DIOIntervalMin MAY be set to a value resulting in a Trickle Imin
of several (e.g. 2) hours.
DIOIntervalDoublings: AMI deployments SHOULD set
DIOIntervalDoublings such that the Trickle Imax is at least 2
hours or more. For very energy constrained deployments (e.g.,
water and gas battery-based routing infrastructure),
DIOIntervalDoublings MAY be set to a value resulting in a Trickle
Imax of several (e.g., 2) days.
DIORedundancyConstant: AMI deployments SHOULD set
DIORedundancyConstant to a value of at least 10. This is due to
the larger chosen value for DIOIntervalMin and the proportional
relationship between Imin and k suggested in [RFC6206]. This
increase is intended to compensate for the increased communication
latency of DIO updates caused by the increase in the
DIOIntervalMin value, though the proportional relationship between
Imin and k suggested in [RFC6206] is not preserved. Instead,
DIORedundancyConstant is set to a lower value in order to reduce
the number of packet transmissions in dense environments.
4.2.2. Other Parameters
o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in
8 bits of resolution (e.g. for the ETX metric). 8 bits of resolution (e.g., for the ETX metric).
o To enable local repair, AMI deployments SHOULD set MaxRankIncrease o To enable local repair, AMI deployments SHOULD set MaxRankIncrease
to a value that allows a device to move a small number of hops to a value that allows a device to move a small number of hops
away from the root. With a MinHopRankIncrease of 256, a away from the root. With a MinHopRankIncrease of 256, a
MaxRankIncrease of 1024 would allow a device to move up to 4 hops MaxRankIncrease of 1024 would allow a device to move up to 4 hops
away. away.
5. Manageability Considerations 5. Manageability Considerations
Network manageability is a critical aspect of smart grid network Network manageability is a critical aspect of smart grid network
deployment and operation. With millions of devices participating in deployment and operation. With millions of devices participating in
the smart grid network, many requiring real-time reachability, the smart grid network, many requiring real-time reachability,
automatic configuration, and lightweight network health monitoring automatic configuration, and lightweight network health monitoring
and management, are crucial for achieving network availability and and management are crucial for achieving network availability and
efficient operation. efficient operation.
RPL enables automatic and consistent configuration of RPL routers RPL enables automatic and consistent configuration of RPL routers
through parameters specified by the DODAG root and dissemintated through parameters specified by the DODAG root and disseminated
through DIO packets. The use of Trickle for scheduling DIO through DIO packets. The use of Trickle for scheduling DIO
transmissions ensures lightweight yet timely propagation of important transmissions ensures lightweight yet timely propagation of important
network and parameter updates. network and parameter updates and allows network operators to choose
the trade-off point they are comfortable with respect to overhead vs.
reliability and timeliness of network updates.
The metrics in use in the network along with the Trickle Timer
parameters used to control the frequency and redundancy of network
updates can be dynamically varied by the root during the lifetime of
the network. To that end, all DIO messages SHOULD contain a Metric
Container option for disseminating the metrics and metric values used
for DODAG setup. In addition, DIO messages SHOULD contain a DODAG
Configuration option for disseminating the Trickle Timer parameters
throughout the network.
The possibility of dynamically updating the metrics in use in the
network as well as the frequency of network updates allows deployment
characteristics (e.g., network density) to be discovered during
network bring-up and to be used to tailor network parameters once the
network is operational rather than having to rely on precise pre-
configuration. This also allows the network parameters and the
overall routing protocol behavior to evolve during the lifetime of
the network.
RPL specifies a number of variables and events that can be tracked RPL specifies a number of variables and events that can be tracked
for purposes of network fault and performance monitoring of RPL for purposes of network fault and performance monitoring of RPL
routers. Depending on the memory and processing capabilities of each routers. Depending on the memory and processing capabilities of each
smart grid device, various subsets of these can be employed in the smart grid device, various subsets of these can be employed in the
field. field.
The CoRE Working Group is developing lightweight resource management
mechanisms for LLNs that are applicable to smart grid RPL networks as
well.
6. Security Considerations 6. Security Considerations
Smart grid networks are subject to stringent security requirements as Smart grid networks are subject to stringent security requirements as
they are considered a critical national infrastructure component. At they are considered a critical infrastructure component. At the same
the same time, since they are composed of large numbers of resource- time, since they are composed of large numbers of resource-
constrained devices inter-connected with limited-throughput links, constrained devices inter-connected with limited-throughput links,
many available security mechanisms are not practical for use in such many available security mechanisms are not practical for use in such
networks. As a result, the choice of security mechanisms is highly networks. As a result, the choice of security mechanisms is highly
dependent on the device and network capabilities characterizing a dependent on the device and network capabilities characterizing a
particular deployment. particular deployment.
In contrast to other types of LLNs, in smart grid networks In contrast to other types of LLNs, in smart grid networks
centralized administrative control and access to a permanent secure centralized administrative control and access to a permanent secure
infrastructure is available. As a result link-layer security infrastructure is available. As a result link-layer, transport-layer
mechanisms are typically in place and using RPL's secure mode is not and/or application-layer security mechanisms are typically in place
necessary. Smart grid networks are often secured at other layers as and using RPL's secure mode is not necessary.
well, including end-to-end at the application layer.
7. Other Related Protocols 7. Other Related Protocols
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. Security Considerations 9. Acknowledgements
This memo includes no security considerations.
10. Acknowledgements
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments from Dominique Barthel. comments of Dominique Barthel, Philip Levis, and Jari Arkko.
11. References 10. References
11.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.
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie,
R., and J. Martocci, "Reactive Discovery of Point-to-Point
Routes in Low Power and Lossy Networks",
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
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011. March 2011.
[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.
skipping to change at page 13, line 36 skipping to change at page 16, line 18
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
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
11.2. Normative References [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011.
10.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Daniel Popa Daniel Popa
Itron Itron
52 rue Camille Desmoulins 52 Rue Camille Desmoulins
Issy-les-Moulineaux, Cedex, 92448 92448 Issy les Moulineaux
France France
Email: daniel.popa@itron.com Email: daniel.popa@itron.com
Jorjeta Jetcheva Jorjeta Jetcheva
Itron Itron
2111 N Molter Rd. 2111 N Molter Rd.
Liberty Lake, WA Liberty Lake, WA 99019
USA USA
Email: jorjeta.jetcheva@itron.com Email: jorjeta.jetcheva@itron.com
Nicolas Dejean Nicolas Dejean
Elster SAS Elster SAS
Espace Concorde, 120 impasse JB Say Espace Concorde, 120 impasse JB Say
Perols, 34470 Perols, 34470
France France
Email: nicolas.dejean@coronis.com Email: nicolas.dejean@coronis.com
Ruben Salazar Ruben Salazar
Landis+Gyr Landis+Gyr
 End of changes. 63 change blocks. 
222 lines changed or deleted 352 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/