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