draft-ietf-roll-applicability-ami-00.txt   draft-ietf-roll-applicability-ami-01.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: January 26, 2012 N. Dejean
Elster Elster SAS
R. Salazar R. Salazar
Landis+Gyr Landis+Gyr
J. Hui J. Hui
Cisco Cisco
July 25, 2011 July 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-00 draft-ietf-roll-applicability-ami-01
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 2, line 25 skipping to change at page 2, line 25
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.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6
2.2.1. Meter Data Management . . . . . . . . . . . . . . . . 6 2.2.1. Meter Data Management . . . . . . . . . . . . . . . . 6
2.2.2. Distribution Automation . . . . . . . . . . . . . . . 7 2.2.2. Distribution Automation . . . . . . . . . . . . . . . 7
2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 7 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 7
3. Using RPL to Meet Functional Requirements . . . . . . . . . . 7 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 7
4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 8 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 8
4.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 8
4.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 8
4.1.4. Objective Function . . . . . . . . . . . . . . . . . . 9 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 9
4.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 9 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 9
4.1.6. Security . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 9
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 10
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. RPL Options . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. RPL Options . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Recommended Configuration Defaults and Ranges . . . . . . 10 4.3. Recommended Configuration Defaults and Ranges . . . . . . 10
5. Other Related Protocols . . . . . . . . . . . . . . . . . . . 10 5. Manageability Considerations . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Informative References . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Normative References . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Informative References . . . . . . . . . . . . . . . . . . 12
11.2. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Advanced Metering Infrastructure (AMI) systems measure, collect, and Advanced Metering Infrastructure (AMI) systems enable the
analyze energy consumption information. An AMI system enables two- measurement, configuration, and control of energy, gas and water
way communication with electricity, water, gas, and/or heat meters. consumption and distribution, through two-way scheduled, on
The communication may be scheduled, on exception, or on-demand. 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.
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 a wired or technologies and power-line communications, along with backhaul
wireless backhaul network providing connectivity to "command-and- network providing connectivity to "command-and-control" management
control" management software applications at the utility company back software applications at the utility company back office.
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, including water and gas meters, other devices in the Smart Grid, e.g., water and gas meters,
distribution automation and home area network devices. Electric distribution automation and home area network devices. Electric
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 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. This results
in a compromise between range and throughput, with effective link in a compromise between range and throughput, with effective link
throughput of tens to a few hundred kilobits per second per link, a throughput of tens to a few hundred kilobits per second per link, a
potentially significant portion of which is taken up by protocol and potentially significant portion of which is taken up by protocol and
encryption overhead when strong security measures are in place. 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) node. the utility network through a network aggregation point (NAP). These
These kinds of networks increase coverage and reduce installation kinds of networks increase coverage and reduce installation cost,
cost, time and complexity, as well as operational costs, as compared time and complexity, as well as operational costs, as compared to
to single-hop wireless networks relying on a wired or cellular single-hop wireless networks, relying on a wireline or cellular
backhaul. Each electric meter mesh typically has in the order of backhaul. Each electric meter mesh typically has on the order of
several thousand wireless endpoints, with densities varying based on several thousand wireless endpoints, with densities varying based on
the area and the terrain, with apartment buildings in urban centers the area and the terrain. Apartment buildings in urban centers may
having possibly hundreds of meters in close proximity, and rural have hundreds of meters in close proximity, whereas rural areas may
areas having sparse node distributions, including nodes that only have sparse node distributions and include nodes that only have one
have one or two network neighbors. Mesh deployments can exhibit tens or two network neighbors. Paths in the mesh between a network device
of hops between a network device and the nearest aggregation point. 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 can 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 (i.e. batteries).
In certain scenarios, gas and water meters are integrated with
electric meters in the same AMI network. In this scenario, gas and
water meters typically do not route messages or operate as hosts to
prolong their lifetime.
In other scenarios, however, gas and water meters do not have the In some scenarios, gas and water meters are integrated into the same
luxury of communicating with a powered routing infrastructure. AMI network as the electric meters and may operate as network
Instead, they must communicate through other battery powered devices endpoints (rather than routers) in order to prolong their own
(i.e. through other gas and water meters) to reach a NAP. lifetime. In other scenarios, such meters may not have the luxury of
Alternative scenarios also include water and/or gas meters relying on a powered routing infrastructure but must communicate
communicating directly to a sparsely deployed network infrastructure, through other energy-constrained devices (i.e., through other gas and
requiring increased transmit power levels for increased range that water meters) to reach a NAP. In some cases, battery-powered meters
significantly impacts energy consumption and battery lifetime. For need to communicate directly with a sparsely deployed network
such networks, the routing protocol must configure routes with energy infrastructure, requiring them to use high transmit power levels (and
consumption in mind. The NAPs, however, are typically mains powered thus more energy) in order to achieve the necessary range to reach
as in AMI networks with electric meters. 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 RPL is designed to operate in energy-constrained environments and
includes energy-saving mechanisms (e.g. Trickle timers) and energy- includes energy-saving mechanisms (e.g. Trickle timers) and energy-
aware metrics. By supporting a number of different metrics and aware metrics. Its ability to support multiple different metrics and
constraints, RPL is also designed to support networks composed of constraints at the same time enables it to run efficiently in
nodes that have vastly different characteristics heterogeneous networks composed of nodes and links with vastly
[I-D.ietf-roll-routing-metrics]. 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 composed of a
large number of resource-constrained devices interconnected by low large number of resource-constrained devices, interconnected by low
power and lossy links. Constrained devices within the same network power and lossy links, and communicating with the external network
typically communicate through a common aggregation point (e.g., a infrastructure through a common aggregation point (e.g., a border
border router). RPL builds a Directed Acyclic Graph (DAG) routing router).
structure rooted at the aggregation point. It ensures loop-free
routing, support for alternate routes, and a wide range of routing RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at
the aggregation point, ensures loop-free routing, and provides
support for alternate routes, as well as, for a wide range of routing
metrics and policies. metrics and policies.
This note describes the applicability of RPL 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 the [I-D.ietf-roll-rpl]) to AMI deployments. RPL was designed to meet
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].
o Home Automation Routing Requirements in Low-Power and Lossy o Home Automation Routing Requirements in Low-Power and Lossy
Networks [RFC5826]. Networks [RFC5826].
o Building Automation Routing Requirements in Low-Power and Lossy o Building Automation Routing Requirements in Low-Power and Lossy
Networks [RFC5867]. Networks [RFC5867].
The Routing Requirements for Urban Low-Power and Lossy Networks is The Routing Requirements for Urban Low-Power and Lossy Networks are
most applicable to AMI networks. applicable to AMI networks as well.
The terminology used in this document is defined in The terminology used in this document is defined in
[I-D.ietf-roll-terminology]. [I-D.ietf-roll-terminology].
1.4. Requirements Language 1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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 in-home gas, and water meters, distribution automation elements, and home
devices. Devices in the network communicate directly with other area network devices. Devices in the network communicate directly
devices in close proximity using a variety of low-power and/or lossy with other devices in close proximity using a variety of low-power
link technologies that are both wired and wireless (e.g. IEEE and/or lossy link technologies that are both wired and wireless (e.g.
802.15.4, IEEE P1901.2, and WiFi). Network elements may not only IEEE 802.15.4, IEEE P1901.2, and WiFi). In addition to serving as
source and sink packets, but must also forward packets to reduce the sources and destinations of packets, many network elements typically
need for dedicated routers and associated deployment costs. also forward packets to reduce the need for dedicated network
infrastructure and the associated deployment and operational costs.
In a typical AMI deployment, groups of meters within physical In a typical AMI deployment, groups of meters within physical
proximity form routing domains. The size of each group in a typical proximity form routing domains, each in the order of a 1,000 to
AMI deployment can be from 1000 to 10000 or 15000 meters 10,000 meters. These routing domains are connected to the larger IP
infrastructure through one or more LLN Border Routers (LBRs), which
provide Wide Area Network (WAN) connectivity through various
traditional network technologies, e.g., Ethernet, Cellular, private
WAN.
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 and can afford the
additional resources required for routing packets. In mixed additional resources required to route packets. In mixed
environments, electric meters provide the routing topology while gas environments, electric meters provide the routing topology while gas
and water meters operate as leaves. However, in networks that cannot and water meters operate as leaf nodes. However, in the absence of a
afford a powered infrastructure, gas and water meters must either co-located electric meter network, gas and water meters must either
talk directly to a network infrastructure or form their own routing connect directly to the larger IP network infrastructure or form
topology, albeit with energy consumption in mind. their own routing topology, albeit with energy consumption in mind.
Each meter routing domain is connected to a larger IP infrastructure
through one or more LLN Border Routers (LBRs). The LBRs provide Wide
Area Network (WAN) connectivity through more traditional links (e.g.
Ethernet, Cellular, Private WAN) or other wireless technologies.
The meter networks may also serve as transit networks for other Meter networks may also serve as transit networks for other types of
devices, including battery powered gas and water meters, distribution devices, including distribution automation elements (e.g., sensors
automation elements (i.e. distribution sensors and actuators), and and actuators), and in-home devices. These other devices may utilize
in-home devices. These other devices may utilize a different link- a different link-layer technology than the one used in the meter
layer technology than the one used in the metering network. network.
2.2. Traffic Characteristics 2.2. Traffic Characteristics
2.2.1. Meter Data Management 2.2.1. Meter Data Management
Meter Data Management (MDM) applications typically require every Meter Data Management (MDM) applications typically require every
smart meter to communicate with a few head-end servers deployed in a smart meter to communicate with a few head-end servers deployed in a
utility data center. As a result, all smart metering traffic utility data center. As a result, all smart metering traffic
typically flows through the LBRs. In general, the vast majority of typically goes through the LBRs, with the vast majority of traffic
traffic flows from smart meter devices to the head-end servers with flowing from smart meter devices to the head-end servers, i.e., in a
limited traffic flowing from head-end servers to smart meter devices. Multipoint-to-Point (MP2P) fashion.
In RPL terminology, this traffic flow is also referred to as
Multipoint-to-point Traffic (MP2P).
Smart meters may generate traffic according to a schedule (e.g. meter Smart meters may generate traffic according to a schedule (e.g.,
read reporting), in response to on-demand queries (e.g. on-demand periodic meter reads), in response to on-demand queries (e.g., on-
meter read), or in response to events (e.g. power outages or leak demand meter reads), or in response to events (e.g., power outages,
detections). Such traffic is typically unicast since it is sent to a leak detections). Such traffic is typically unicast since it is sent
single head-end server. to a single head-end server.
Head-end servers may generate traffic to configure smart metering Head-end servers generate traffic to configure smart metering devices
devices or initiate queries. Head-end servers generate both unicast or initiate queries, and use unicast and multicast to efficiently
and multicast traffic to efficiently communicate with a single device communicate with a single device (i.e., Point-to-Point (P2P)
or groups of devices. In RPL terminology, this traffic flow is also communication) or groups of devices respectively (i.e., Point-to-
referred to as Point-to-Multipoint Traffic (P2MP). The head-end Multipoint (P2MP) communication). The head-end server may send a
server may send a single small packet at a time (e.g. a meter read single small packet at a time (e.g., a meter read request, or small
request or small configuration change) or many large packets in configuration change) or many consecutive large packets (e.g., a
sequence (e.g. a firmware upgrade across one or thousands of firmware upgrade across one or even thousands of devices).
devices).
While smart metering applications typically do not have hard real- While smart metering applications typically do not have hard real-
time constraints, they are often subject to stringent latency and time constraints, they are often subject to stringent latency and
reliability service level agreements. Some applications also have reliability service level agreements.
stringent latency requirements to function properly.
2.2.2. Distribution Automation 2.2.2. Distribution Automation
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. The DA devices may or may not be in close
physical proximity. physical proximity.
DA applications typically have more stringent latency requirements DA applications typically have more stringent latency requirements
than MDM applications. than MDM applications.
2.2.3. Emerging Applications 2.2.3. Emerging Applications
There are a number of emerging applications (e.g. Electric Vehicle There are a number of emerging applications such as electric vehicle
charging) that may involve P2P communication as well. These charging. These applications may require P2P communication and may
applications may eventually have more stringent latency requirements eventually have more stringent latency requirements than MDM
than MDM 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.
o The routing protocol MUST provide mechanisms to support o The routing protocol MUST provide mechanisms to support
configuration of the routing protocol itself. configuration of the routing protocol itself.
o The routing protocol SHOULD support and utilize the large number o The routing protocol SHOULD support and utilize the large number
of highly direct flows to a few head-end servers to handle of highly directed flows to a few head-end servers to handle
scalability. scalability.
o The routing protocol MUST dynamically compute and select effective o The routing protocol MUST dynamically compute and select effective
routes composed of low-power and lossy links. Local network routes composed of low-power and lossy links. Local network
dynamics SHOULD NOT impact the entire network. The routing dynamics SHOULD NOT impact the entire network. The routing
protocol MUST compute multiple paths when possible. protocol MUST compute multiple paths when possible.
o The routing protocol MUST support multicast and anycast o The routing protocol MUST support multicast and anycast
addressing. The routing protocol SHOULD support formation and addressing. The routing protocol SHOULD support formation and
identification of groups of field devices in the network. identification of groups of field devices in the network.
RPL efficiently supports scalability and highly directed traffic RPL supports:
flows between every smart meter and the few head-end servers by
building a Directed Acyclic Graph (DAG) rooted at each LBR.
RPL supports zero-touch configuration by providing in-band methods o Large-scale networks characterized by highly directed traffic
for configuring RPL variables using DIO messages. flows between each smart meter and the head-end servers in the
utility network. To this end, RPL builds a Directed Acyclic Graph
(DAG) rooted at each LBR.
RPL supports time-varying link qualities by allowing the use of o Zero-touch configuration. This is done through in-band methods
metrics that effectively characterize the quality of a path (e.g. for configuring RPL variables using DIO messages.
Estimated Transmission Count (ETX)). RPL limits the impact of
changing local conditions by discovering and maintaining multiple DAG o The use of links with time-varying quality characteristics. This
parents and providing a local repair mechanism when all parents have is accomplished by allowing the use of metrics that effectively
been dropped. capture the quality of a path (e.g., Expected Transmission Count
(ETX)) and by limiting the impact of changing local conditions by
discovering and maintaining multiple DAG parents, and by using
local repair mechanisms when DAG links break.
4. RPL Profile 4. RPL Profile
This section outlines a RPL profile for most representative AMI This section outlines a RPL profile for a representative AMI
deployments. deployment.
4.1. RPL Features 4.1. RPL Features
4.1.1. Storing vs. Non-Storing Mode 4.1.1. RPL Instances
In most scenarios, electric meters can utilize the power they are RPL operation is defined for a single RPL instance. However,
monitoring for their own processing and computation and are not as multiple RPL instances can be supported in multi-service networks
constrained in energy consumption. Instead, the capabilities of an where different applications may require the use of different routing
electric meter are primarily constrained by cost. As a result, metrics and constraints, e.g., a network carrying both MDM and DA
different AMI deployments can vary significantly in terms of the traffic.
memory, computational, and communication trade-offs that were made
for their devices. For this reason, the use of RPL storing or non- 4.1.2. Storing vs. Non-Storing Mode
storing mode SHOULD be deployment specific.
In most scenarios, electric meters are powered by the electric grid
they are monitoring and are not energy-constrained. Instead, the
capabilities of an electric meter are primarily determined by cost.
As a result, different AMI deployments can vary significantly in
terms of the memory, computation, and communication trade-offs that
they embody. For this reason, the use of RPL storing or non-storing
mode SHOULD be deployment specific.
When meters are memory constrained and cannot adequately store route When meters are memory constrained and cannot adequately store route
tables to support downward routing, non-storing mode is preferred. tables to support downward routing, non-storing mode is preferred.
However, when nodes are capable of adequately storing such routing However, when nodes are capable of adequately storing such routing
tables, storing mode can lead to shorter paths and reduce channel tables, storing mode can lead to reduced overhead and shorter route
utilization near the root. repair latency.
4.1.2. DAO Policy 4.1.3. DAO Policy
Two-way communication is required in AMI systems. As a result, Two-way communication is a requirement in AMI systems. As a result,
electric meters SHOULD send DAO messages to establish downward paths nodes SHOULD send DAO messages to establish downward paths from the
back to themselves. root to themselves.
4.1.3. Path Metrics 4.1.4. Path Metrics
Smart metering deployments utilize link technologies that can exhibit Smart metering deployments utilize link technologies that can exhibit
significant packet loss. To characterize a path over such link significant packet loss. 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 cannot rely on a powered
infrastructure, energy constraints may require simpler metrics that infrastructure, energy constraints may require simpler metrics that
do not require as much energy to compute. In particular, Hop Count do not require as much energy to compute. In particular, hop count
and Link Quality Level may be more suitable in such deployments. and link quality level may be more suitable in such deployments.
Other metrics may be vendor-specific or defined at a later time into Other possible metrics to use may be vendor-specific or defined at a
companion RFCs. later time in companion RFCs.
4.1.4. 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 but 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: network. Two basic objective functions for RPL have been defined at
the time of this writing, OF0 and MRHOF, both of which define the
selection of a preferred parent and backup parents, and are suitable
for a basic AMI deployment. Neither of these supports multiple
metrics that might be required in heterogeneous networks (i.e.
networks composed of devices with different energy constraints). A
new objective function can be defined to meet this requirement.
o OF0 which does not deal with any metric, 4.1.6. DODAG Repair
o MRHOF which deals with a single metric. To effectively handle time-varying link characteristics and
availability, AMI deployments SHOULD utilize the local repair
mechanisms in RPL.
Both of them define the selection of a preferred parent and backup The first mechanism for local repair when a node loses connectivity
parents. Note that these Objective Functions do not support multiple to its parents is to detach from a DODAG then re-attach to the same
metrics that might be required in heterogeneous networks (i.e. or to a different DODAG at a later time. While detached, a node
networks composed of devices with varying energy constraints). While advertises an infinite rank value so that its children can select a
RPL provides the flexibility to support additional metrics, a new different parent. This process is known as poisoning and described
Objective Function MAY be specified to properly handle additional in Section 8.2.2.5 of [I-D.ietf-roll-rpl]. While RPL provides an
metrics. 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.
4.1.5. DODAG Repair The second local repair mechanism controls how much a node can
increase its rank within a given DODAG Version. Setting the
DAGMaxRankIncrease to a non-zero value enables this mechanism, and
setting it to a value of less than infinity limits the cost of count-
to-infinity scenarios when they occur.
To effectively handle time-varying link characteristics, AMI The third local repair mechanism enables loop detection, and is
deployments SHOULD utilize the local repair mechanisms in RPL. implemented by including the rank value of the transmitting node in
packets forwarded towards the root (in the packet's RPL Packet
Information option [I-D.ietf-6man-rpl-option]). Note that loop
detection is not needed when sending packets using strict source
routing.
The first mechanism for local repair when a node loses its parents is 4.1.7. Multicast
to detach from a DODAG then re-attach to the same or 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 mechanism is a limit on how much a node can increase its RPL defines multicast support for its storing mode of operation. The
rank within a given DODAG Version. Setting the DAGMaxRankIncrease to DODAG structure built for unicast packet dissemination is used for
a non-zero value enables this local repair mechanism. Setting multicast distribution as well. In particular, multicast forwarding
DAGMaxRankIncrease to a value less than infinity limits the cost of state creation is done through DAO messages with multicast target
count-to-infinity scenarios when they occur. options sent along the DODAG towards the root. Thereafter nodes with
forwarding state for a particular group forward multicast packets
along the DODAG by copying them to all children from which they have
received a DAO with a multicast target option for the group.
The third mechanism is loop detection, enabled by including the rank Multicast support for RPL in non-storing mode will be defined in
value of a node in packets forwarded towards the root in RPL Packet companion RFCs.
Information [I-D.ietf-6man-rpl-option]. Note that loop detection is
not needed when sending packets using strict source routing.
4.1.6. 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 technologies used within AMI
deployments typically provide security mechanisms to ensure deployments typically provide security mechanisms to ensure
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 security features.
4.2. RPL Options 4.2. RPL Options
4.3. Recommended Configuration Defaults and Ranges 4.3. Recommended Configuration Defaults and Ranges
o AMI deployments can involve densities of hundreds of devices o AMI deployments can involve densities of hundreds of devices
within communication range. As a result, such networks SHOULD set within communication range. As a result, such networks SHOULD set
the DIOIntervalMin to 16 or more, giving a Trickle Imin of 1 the DIOIntervalMin to 16 or more, resulting in a Trickle Imin of 1
minute or more. For low-energy consumption operations, such minute or more. In networks with low-energy consumption
networks SHOULD set DIOIntervalMin be set to a higher value. requirements, DIOIntervalMin SHOULD be set to a higher value.
o AMI deployments SHOULD set DIOIntervalDoublings to a value that o AMI deployments SHOULD set DIOIntervalDoublings to a value that
gives a Trickle Imax of 2 hours or more. For low-energy gives a Trickle Imax of 2 hours or more. In networks with low-
consumption operations, such networks SHOULD set energy consumption requirements, DIOIntervalDoublings SHOULD be
DIOIntervalDoublings to a value that gives a Trickle Imax of e.g. set to a value that results in a Trickle Imax of several (e.g., 2)
2 days. days.
o AMI deployments SHOULD set DIORedundancyConstant to a value of 10 o AMI deployments SHOULD set DIORedundancyConstant to a value of 10
or more. or more.
o AMI deployments SHOULD set MinHopRankIncrease to 256, giving 8 o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in
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. Other Related Protocols 5. Manageability Considerations
Network manageability is a critical aspect of smart grid network
deployment and operation. With millions of devices participating in
the smart grid network, many requiring real-time reachability,
automatic configuration, and lightweight network health monitoring
and management, are crucial for achieving network availability and
efficient operation.
RPL enables automatic and consistent configuration of RPL routers
through parameters specified by the DODAG root and dissemintated
through DIO packets. The use of Trickle for scheduling DIO
transmissions ensures lightweight yet timely propagation of important
network and parameter updates.
RPL specifies a number of variables and events that can be tracked
for purposes of network fault and performance monitoring of RPL
routers. Depending on the memory and processing capabilities of each
smart grid device, various subsets of these can be employed in the
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
Smart grid networks are subject to stringent security requirements as
they are considered a critical national infrastructure component. At
the same time, since they are composed of large numbers of resource-
constrained devices inter-connected with limited-throughput links,
many available security mechanisms are not practical for use in such
networks. As a result, the choice of security mechanisms is highly
dependent on the device and network capabilities characterizing a
particular deployment.
In contrast to other types of LLNs, in smart grid networks
centralized administrative control and access to a permanent secure
infrastructure is available. As a result link-layer security
mechanisms are typically in place and using RPL's secure mode is not
necessary. Smart grid networks are often secured at other layers as
well, including end-to-end at the application layer.
7. Other Related Protocols
This document contains no other related protocols. This document contains no other related protocols.
6. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 9. Security Considerations
This memo includes no security considerations. This memo includes no security considerations.
8. Acknowledgements 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 from Dominique Barthel.
9. References 11. References
9.1. Informative References 11.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-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
skipping to change at page 12, line 17 skipping to change at page 13, line 36
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.
9.2. Normative References 11.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
Issy-les-Moulineaux, Cedex, 92448
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
USA USA
Phone: +408 688 1428
Email: jorjeta.jetcheva@itron.com Email: jorjeta.jetcheva@itron.com
Nicolas Dejean Nicolas Dejean
Elster Elster SAS
Espace Concorde, 120 impasse JB Say
Perols, 34470
France
Email: nicolas.dejean@coronis.com Email: nicolas.dejean@coronis.com
Ruben Salazar Ruben Salazar
Landis+Gyr Landis+Gyr
30000 Mill Creek Ave # 100
Alpharetta, GA 30022
Email: ruben.salazar@landisgyr.com Email: ruben.salazar@landisgyr.com
Jonathan W. Hui Jonathan W. Hui
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Phone: +408 424 1547 Phone: +408 424 1547
Email: jonhui@cisco.com Email: jonhui@cisco.com
 End of changes. 70 change blocks. 
212 lines changed or deleted 282 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/