draft-ietf-roll-applicability-ami-11.txt   draft-ietf-roll-applicability-ami-12.txt 
Roll D. Popa Roll N. Cam-Winget, Ed.
Internet-Draft M. Gillmore Internet-Draft Cisco Systems
Intended status: Standards Track Itron, Inc Intended status: Standards Track J. Hui
Expires: February 4, 2016 L. Toutain Expires: September 22, 2016 Nest
Telecom Bretagne D. Popa
J. Hui Itron, Inc
Nest March 21, 2016
R. Ruben
Landis+Gyr
K. Monden
Hitachi, Ltd., Yokohama Research Laboratory
N. Cam-Winget, Ed.
Cisco Systems
August 3, 2015
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-11 draft-ietf-roll-applicability-ami-12
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 42 skipping to change at page 1, line 35
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 February 4, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Required Reading . . . . . . . . . . . . . . . . . . . . 3 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . 3
1.3. Out of scope requirements . . . . . . . . . . . . . . . . 4 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 3
2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4 2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4
3. Description of AMI networks for electric meters . . . . . . . 5 3. Description of AMI networks for electric meters . . . . . . . 5
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 5 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 5
4. Smart Grid Traffic Description . . . . . . . . . . . . . . . 7 4. Smart Grid Traffic Description . . . . . . . . . . . . . . . 7
4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7 4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7
4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8 4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8
4.3. RPL applicability per Smart Grid Traffic Characteristics 9 4.3. RPL applicability per Smart Grid Traffic Characteristics 9
5. Layer 2 applicability . . . . . . . . . . . . . . . . . . . . 9 5. Layer 2 applicability . . . . . . . . . . . . . . . . . . . . 9
5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9 5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9
5.2. IEEE PowerLine Communication (PLC) technology . . . . . . 10 5.2. IEEE PowerLine Communication (PLC) technology . . . . . . 9
6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10 6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10
7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11 7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11 7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11
7.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 11 7.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 11
7.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 12
7.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 12 7.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 12
7.1.5. Objective Function . . . . . . . . . . . . . . . . . 12 7.1.5. Objective Function . . . . . . . . . . . . . . . . . 12
7.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 7.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12
7.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 13 7.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 13
7.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 13 7.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 13
7.1.9. Peer-to-Peer communications . . . . . . . . . . . . . 13 7.1.9. Peer-to-Peer communications . . . . . . . . . . . . . 13
7.2. Description of Layer-two features . . . . . . . . . . . . 13 7.2. Description of Layer-two features . . . . . . . . . . . . 13
7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . 13 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . 13
7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 15 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 14
7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . 15 7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . 15
7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 17 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 17
7.4. Recommended Configuration Defaults and Ranges . . . . . . 17 7.4. Recommended Configuration Defaults and Ranges . . . . . . 17
7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17
7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 19 8. Manageability Considerations . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Security Considerations during initial deployment . . . . 20 9.1. Security Considerations during initial deployment . . . . 20
9.2. Security Considerations during incremental deployment . . 20 9.2. Security Considerations during incremental deployment . . 20
9.3. Security Considerations based on RPL's Threat Analysis . 20 9.3. Security Considerations based on RPL's Threat Analysis . 20
10. Other Related Protocols . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.1. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative references . . . . . . . . . . . . . . . . . 21
13.2. Normative references . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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,
skipping to change at page 3, line 43 skipping to change at page 3, line 35
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.2. Required Reading 1.2. Required Reading
[surveySG] gives an overview of Smart Grid architecture and related [surveySG] gives an overview of Smart Grid architecture and related
applications. applications.
NAN can use wireless communication technology in which case is using, NAN can use wireless communication technology in which case is using,
from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer from the IEEE 802.15.4 standard family, the [IEEE802.15.4g] PHY Layer
amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically amendment and [IEEE802.15.4e] MAC sub-layer amendment, specifically
adapted to smart grid networks. adapted to smart grid networks.
NAN can also use PLC (Power Line Communication) technology as an NAN can also use PLC (Power Line Communication) technology as an
alternative to wireless communications. Several standards for PLC alternatve to wireless communications. Several standards for PLC
technology have emerged, such as IEEE P1901.2. technology have emerged, such as [IEEE1901.2].
NAN can further use a mix of wireless and PLC technologies to NAN can further use a mix of wireless and PLC technologies to
increase the network coverage ratio, a critical requirement for AMI increase the network coverage ratio, a critical requirement for AMI
networks. networks.
1.3. Out of scope requirements 1.3. Out of scope requirements
The following are outside the scope of this document: The following are outside the scope of this document:
o Applicability statement for RPL in AMI networks composed of o Applicability statement for RPL in AMI networks composed of
battery-powered devices (i.e., gas/water meters). battery-powered devices (i.e., gas/water meters).
o Applicability statement for RPL in AMI networks composed of a mix o Applicability statement for RPL in AMI networks composed of a mix
of AC powered devices (i.e., electric meters) and battery-powered of AC powered devices (i.e., electric meters) and battery-powered
meters (i.e., gas/water meters). meters (i.e., gas/water meters).
o Applicability statement for RPL storing mode of operation in AMI o Applicability statement for RPL storing (vs. non-storing) mode of
networks. operation in AMI networks.
2. Routing Protocol for LLNs (RPL) 2. Routing Protocol for LLNs (RPL)
RPL provides routing functionality for mesh networks that can scale RPL provides routing functionality for mesh networks that can scale
up to thousands of resource-constrained devices, interconnected by up to thousands of resource-constrained devices, interconnected by
low power and lossy links, and communicating with the external low power and lossy links, and communicating with the external
network infrastructure through a common aggregation point(s) (e.g., a network infrastructure through a common aggregation point(s) (e.g., a
LBR). LLN Border Router or LBR).
RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at
a LBR (LLN Border Router), ensures loop-free routing, and provides a LBR (LLN Border Router), ensures loop-free routing, and provides
support for alternate routes, as well as, for a wide range of routing support for alternate routes, as well as, for a wide range of routing
metrics and policies. metrics and policies.
RPL was designed to operate in energy-constrained environments and RPL was 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. RPL's ability to support multiple different metrics aware metrics. RPL's ability to support multiple different metrics
and constraints at the same time enables it to run efficiently in and constraints at the same time enables it to run efficiently in
skipping to change at page 5, line 29 skipping to change at page 5, line 23
the device enables the utility company to control and query the the device enables the utility company to control and query the
electric meters themselves and can serve as a backhaul for all other electric meters themselves and can serve as a backhaul for all other
devices in the Smart Grid, e.g., water and gas meters, distribution devices in the Smart Grid, e.g., water and gas meters, distribution
automation and home area network devices. Electric meters may also automation and home area network devices. Electric meters may also
be used as sensors to monitor electric grid quality and to support be used as sensors to monitor electric grid quality and to support
applications such as Electric Vehicle charging. applications such as Electric Vehicle charging.
Electric meter networks can be composed of millions of smart meters Electric meter networks can be composed of millions of smart meters
(or nodes), each of which is resource-constrained in terms of (or nodes), each of which is resource-constrained in terms of
processing power, storage capabilities, and communication bandwidth, processing power, storage capabilities, and communication bandwidth,
due to a combination of factors including Federal Communications due to a combination of factors including regulations on spectrum
Commission (FCC) or other continents' regulations on spectrum use, use, and on meter behavior and performance, on heat emissions within
American National Standards Institute (ANSI) standards or other the meter, form factor and cost considerations. These constraints
continents' regulation on meter behavior and performance, on heat result in a compromise between range and throughput, with effective
emissions within the meter, form factor and cost considerations. link throughput of tens to a few hundred kilobits per second per
These constraints result in a compromise between range and link, a potentially significant portion of which is taken up by
throughput, with effective link throughput of tens to a few hundred protocol and encryption overhead when strong security measures are in
kilobits per second per link, a potentially significant portion of place.
which is taken 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 company network through a network aggregation point, the utility company network through a network aggregation point,
e.g., an LBR. e.g., an LBR.
3.1. Deployment Scenarios 3.1. Deployment Scenarios
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 can include both urban and rural environments. Such endpoints can include
skipping to change at page 6, line 42 skipping to change at page 6, line 32
Figure 1: Typical NAN Topology Figure 1: Typical NAN Topology
A typical AMI network architecture (see figure Figure 1) is composed A typical AMI network architecture (see figure Figure 1) is composed
of a MDMS (Meter Data Management System) connected through IP network of a MDMS (Meter Data Management System) connected through IP network
to a LBR, which can be located in the power substation or somewhere to a LBR, which can be located in the power substation or somewhere
else in the field. The power substation connects the households and else in the field. The power substation connects the households and
buildings. The physical topology of the electrical grid is a tree buildings. The physical topology of the electrical grid is a tree
structure, either due to the 3 different power phases coming through structure, either due to the 3 different power phases coming through
the sub-station or just to the electrical network topology. Meters the sub-station or just to the electrical network topology. Meters
(represented by a M in the previous figure) can also participate to a (represented by a M in the previous figure) can also participate in a
HAN (Home-Area Network). The scope of this document is the HAN (Home-Area Network). The scope of this document is the
communication between the LBR and the meters, i.e. the NAN (Neighbor- communication between the LBR and the meters, i.e. the NAN (Neighbor-
Area Network) segment. Area Network) segment.
Node density can vary significantly. For example, apartment Node density can vary significantly. For example, apartment
buildings in urban centers may have hundreds of meters in close buildings in urban centers may have hundreds of meters in close
proximity, whereas rural areas may have sparse node distributions and proximity, whereas rural areas may have sparse node distributions and
include nodes that only have a small number of network neighbors. include nodes that only have a small number of network neighbors.
Each routing domain is connected to the larger IP infrastructure Each routing domain is connected to the larger IP infrastructure
through one or more LBRs, which provide Wide Area Network (WAN) through one or more LBRs, which provide Wide Area Network (WAN)
skipping to change at page 8, line 4 skipping to change at page 7, line 44
frequency of large file transfers, e.g., firmware download of all frequency of large file transfers, e.g., firmware download of all
metering devices, is typically much lower than the frequency of metering devices, is typically much lower than the frequency of
sending configuration messages or queries. Each smart meter sending configuration messages or queries. Each smart meter
generates Smart Metering Data (SMD) traffic according to a schedule generates Smart Metering Data (SMD) traffic according to a schedule
(e.g., periodic meter reads), in response to on-demand queries (e.g., (e.g., periodic meter reads), in response to on-demand queries (e.g.,
on-demand meter reads), or in response to some local event (e.g., on-demand meter reads), or in response to some local event (e.g.,
power outage, leak detection). Such traffic is typically destined to power outage, leak detection). Such traffic is typically destined to
a single head-end server. The SMD traffic is thus highly asymmetric, a single head-end server. The SMD traffic is thus highly asymmetric,
where the majority of the traffic volume generated by the smart where the majority of the traffic volume generated by the smart
meters typically goes through the LBRs, and is directed from the meters typically goes through the LBRs, and is directed from the
smart meter devices to the head-end servers, in a MP2P fashion. smart meter devices to the head-end servers, in a MP2P (Mesh Peer to
Current SMD traffic patterns are fairly uniform and well-understood. Peer)fashion. Current SMD traffic patterns are fairly uniform and
The traffic generated by the head-end server and destined to metering well-understood. The traffic generated by the head-end server and
devices is dominated by periodic meter reads, while traffic generated destined to metering devices is dominated by periodic meter reads,
by the metering devices is typically uniformly spread over some while traffic generated by the metering devices is typically
periodic read time-window. uniformly spread over some periodic read time-window.
Smart metering applications typically do not have hard real-time Smart metering applications typically do not have hard real-time
constraints, but they are often subject to bounded latency and constraints, but they are often subject to bounded latency and
stringent reliability service level agreements. stringent reliability service level agreements.
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, and may or may not be in close physical Point (P2P) fashion, and may or may not be in close physical
proximity. DA applications typically have more stringent latency proximity. DA applications typically have more stringent latency
requirements than SMD applications. requirements than SMD applications.
skipping to change at page 9, line 18 skipping to change at page 9, line 10
C3) Normal Priority traffic for System Events including Faults, C3) Normal Priority traffic for System Events including Faults,
Configuration and Security require 98%+ packet delivery under 30s. Configuration and Security require 98%+ packet delivery under 30s.
Payload size < 200 bytes Payload size < 200 bytes
C4) Low Priority traffic for Recurrent Meter Reading require 98%+ C4) Low Priority traffic for Recurrent Meter Reading require 98%+
packet 2 hour delivery window 6 times per day. Payload size < 400 packet 2 hour delivery window 6 times per day. Payload size < 400
bytes bytes
C5) Background Priority traffic for firmware/software updates C5) Background Priority traffic for firmware/software updates
processed to 98%+ of devices with in 7 days. Average firmware processed to 98%+ of devices within 7 days. Average firmware
update is 1 MB. update is 1 MB.
4.3. RPL applicability per Smart Grid Traffic Characteristics 4.3. RPL applicability per Smart Grid Traffic Characteristics
RPL non-storing mode of operation naturally support upstream and RPL non-storing mode of operation naturally support upstream and
downstream forwarding of unicast traffic between the DODAG root and downstream forwarding of unicast traffic between the DODAG root and
each DODAG node, and between DODAG nodes and DODAG root, each DODAG node, and between DODAG nodes and DODAG root,
respectively. respectively.
Group communication model used in smart grid requires RPL non-storing Group communication model used in smart grid requires RPL non-storing
mode of operation to support downstream forwarding of multicast mode of operation to support downstream forwarding of multicast
traffic with a scope larger than link-local. The DODAG root is the traffic with a scope larger than link-local. The DODAG root is the
single device that injects multicast traffic, with a scope larger single device that injects multicast traffic, with a scope larger
than link-local, into the DODAG. than link-local, into the DODAG.
Although not currently used in metering applications, support of
peer- to-peer communications between DODAG nodes is identified as a
key feature to be supported in smart grid networks.
5. Layer 2 applicability 5. Layer 2 applicability
5.1. IEEE Wireless Technology 5.1. IEEE Wireless Technology
IEEE Std. 802.15.4g-2012 and IEEE 802.15.4e-2012 amendments to IEEE Std. 802.15.4g and IEEE 802.15.4e amendments to 802.15.4
802.15.2-2011 standard have been specifically developed for smart standard have been specifically developed for smart grid networks.
grid networks. They are the most common PHY and MAC layers used for They are the most common PHY and MAC layers used for wireless AMI
wireless AMI network. 802.15.4g specifies multiple modes of network. 802.15.4g specifies multiple modes of operation (FSK, OQPSK
operation (FSK, OQPSK and OFDM modulations) with speeds from 50kbps and OFDM modulations) with speeds from 50kbps to 600kbps, and allows
to 600kbps, and allows for transport of a full IPv6 packet (i.e., for transport of a full IPv6 packet (i.e., 1280 octets) without the
1280 octets) without the need for upper layer segmentation and re- need for upper layer segmentation and re-assembly.
assembly.
IEEE Std. 802.15.4e-2012 is an amendment to IEEE Std 802.15.4-2011 IEEE Std. 802.15.4e is an amendment to IEEE Std 802.15.4 that
that specifies additional media access control (MAC) behaviors and specifies additional media access control (MAC) behaviors and frame
frame formats that allow IEEE 802.15.4 devices to support a wide formats that allow IEEE 802.15.4 devices to support a wide range of
range of industrial and commercial applications that were not industrial and commercial applications that were not adequately
adequately supported prior to the release of this amendment. It is supported prior to the release of this amendment. It is important to
important to notice that 802.15.4e does not change the link-layer notice that 802.15.4e does not change the link-layer security scheme
security scheme defined in 802.15.4-2011 (and 802.15.4-2006). defined in the last two updates to 802.15.4 (e.g. 2006 and 2011
amendments).
5.2. IEEE PowerLine Communication (PLC) technology 5.2. IEEE PowerLine Communication (PLC) technology
The IEEE Std. 1901.2-2013 standard specifies communications for low The IEEE Std. 1901.2 standard specifies communications for low
frequency (less than 500 kHz) narrowband power line devices via frequency (less than 500 kHz) narrowband power line devices via
alternating current and direct current electric power lines. IEEE alternating current and direct current electric power lines. IEEE
Std P1901.2-2013 standard supports indoor and outdoor communications Std P1901.2 standard supports indoor and outdoor communications over
over low voltage line (line between transformer and meter, less than low voltage line (line between transformer and meter, less than 1000
1000 V), through transformer low-voltage to medium-voltage (1000 V up V), through transformer low-voltage to medium-voltage (1000 V up to
to 72 kV) and through transformer medium-voltage to low-voltage power 72 kV) and through transformer medium-voltage to low-voltage power
lines in both urban and in long distance (multi- kilometer) rural lines in both urban and in long distance (multi- kilometer) rural
communications. communications.
IEEE Std. 1901.2 defines the PHY layer and the MAC sub-layer of the IEEE Std. 1901.2 defines the PHY layer and the MAC sub-layer of the
data link layer. The MAC sub-layer endorses a sub-set of data link layer. The MAC sub-layer endorses a sub-set of 802.15.4
802.15.4-2006 and 802.15.4e-2012 MAC sub-layer features. and 802.15.4e MAC sub-layer features.
IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps
depending on the application requirements and type of encoding used. depending on the application requirements and type of encoding used.
IEEE Std. 1901.2 MAC layer allows for transport of a full IPv6 packet IEEE Std. 1901.2 MAC layer allows for transport of a full IPv6 packet
(i.e., 1280 octets) without the need for upper layer segmentation and (i.e., 1280 octets) without the need for upper layer segmentation and
re-assembly. re-assembly.
IEEE Std. 1901.2 specifies the necessary link-layer security features IEEE Std. 1901.2 specifies the necessary link-layer security features
that fully endorse 802.15.4-2006 MAC sub-layer security scheme. that fully endorse 802.15.4 MAC sub-layer security scheme.
6. Using RPL to Meet Functional Requirements 6. 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]. This section informallly highlights some
of the similarities:
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 directed flows to a few head-end servers to handle of highly directed flows to a few head-end servers to handle
skipping to change at page 11, line 23 skipping to change at page 11, line 12
RPL supports the following features: RPL supports the following features:
o Scalability: Large-scale networks characterized by highly directed o Scalability: Large-scale networks characterized by highly directed
traffic flows between each smart meter and the head-end servers in traffic flows between each smart meter and the head-end servers in
the utility network. To this end, RPL builds a Directed Acyclic the utility network. To this end, RPL builds a Directed Acyclic
Graph (DAG) rooted at each LBR. Graph (DAG) rooted at each LBR.
o Zero-touch configuration: This is done through in-band methods for o Zero-touch configuration: This is done through in-band methods for
configuring RPL variables using DIO messages, and DIO message configuring RPL variables using DIO messages, and DIO message
options. options [RFC6550].
o The use of links with time-varying quality characteristics: This o The use of links with time-varying quality characteristics: This
is accomplished by allowing the use of metrics that effectively is accomplished by allowing the use of metrics that effectively
capture the quality of a path (e.g., Expected Transmission Count capture the quality of a path (e.g., Expected Transmission Count
(ETX)) and by limiting the impact of changing local conditions by (ETX)) and by limiting the impact of changing local conditions by
discovering and maintaining multiple DAG parents, and by using discovering and maintaining multiple DAG parents, and by using
local repair mechanisms when DAG links break. local repair mechanisms when DAG links break.
7. RPL Profile 7. RPL Profile
skipping to change at page 11, line 52 skipping to change at page 11, line 41
traffic. traffic.
7.1.2. Storing vs. Non-Storing Mode 7.1.2. Storing vs. Non-Storing Mode
In most scenarios, electric meters are powered by the grid they are In most scenarios, electric meters are powered by the grid they are
monitoring and are not energy-constrained. Instead, electric meters monitoring and are not energy-constrained. Instead, electric meters
have hardware and communication capacity constraints that are have hardware and communication capacity constraints that are
primarily determined by cost, and secondarily by power consumption. primarily determined by cost, and secondarily by power consumption.
As a result, different AMI deployments can vary significantly in As a result, different AMI deployments can vary significantly in
terms of memory size, computation power and communication terms of memory size, computation power and communication
capabilities. For this reason, the use of RPL storing or non-storing capabilities. For this reason, the use of RPL non-storing mode
mode SHOULD be deployment specific. When meters are memory SHOULD be deployment specific. When meters are memory constrained
constrained and cannot adequately store the route tables necessary to and cannot adequately store the route tables necessary to support
support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. hop-by-hop routing, RPL non-storing mode SHOULD be preferred. On the
On the other hand, when nodes are capable of storing such routing other hand, when nodes are capable of storing such routing tables,
tables, the use of storing mode may lead to reduced overhead and the use of storing mode may lead to reduced overhead and route repair
route repair latency. However, in high-density environments, storing latency. However, in high-density environments, storing routes can
routes can be challenging because some nodes may have to maintain be challenging because some nodes may have to maintain routing
routing information for a large number of descendents. In this information for a large number of descendents. In this document, we
document, we only focus on non-storing mode of operation. only focus on non-storing mode of operation.
7.1.3. DAO Policy 7.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.
7.1.4. Path Metrics 7.1.4. Path Metrics
Smart metering deployments utilize link technologies that may exhibit Smart metering deployments utilize link technologies that may exhibit
skipping to change at page 14, line 23 skipping to change at page 14, line 13
significantly, e.g. use a direct link with slow robust modulation, significantly, e.g. use a direct link with slow robust modulation,
or use a relay meter with fast modulation and 12 disabled sub- or use a relay meter with fast modulation and 12 disabled sub-
carriers. In addition, IEEE 1901.2 technology offers a mechanism carriers. In addition, IEEE 1901.2 technology offers a mechanism
(adaptive tone map) for periodic exchanges on the link quality (adaptive tone map) for periodic exchanges on the link quality
between nodes to constantly react to channel fluctuations. Every between nodes to constantly react to channel fluctuations. Every
meter keeps a state of the quality of the link to each of its meter keeps a state of the quality of the link to each of its
neighbors by either piggybacking the tone mapping on the data neighbors by either piggybacking the tone mapping on the data
traffic, or by sending explicit tone map requests. traffic, or by sending explicit tone map requests.
IEEE 1901.2 MAC frame format shares most in common with the IEEE IEEE 1901.2 MAC frame format shares most in common with the IEEE
802.15.4-2006 MAC frame format [IEEE802.15.4], with a few exceptions 802.15.4 MAC frame format [IEEE802.15.4], with a few exceptions
described below. described below.
o IEEE 1901.2 MAC frame is obtained by prepending a Segment Control o IEEE 1901.2 MAC frame is obtained by prepending a Segment Control
Field to the IEEE 802.15.4-2006 MAC header. One function of the Field to the IEEE 802.15.4 MAC header. One function of the
Segment Control Field is to signal the use of the MAC sub-layer Segment Control Field is to signal the use of the MAC sub-layer
segmentation and reassembly. segmentation and reassembly.
o IEEE 1901.2 MAC frames uses only the 802.15.4 MAC addresses with a o IEEE 1901.2 MAC frames uses only the 802.15.4 MAC addresses with a
length of 16 and 64 bits. length of 16 and 64 bits.
o IEEE 1901.2 MAC sub-layer endorses the concept of Information o IEEE 1901.2 MAC sub-layer endorses the concept of Information
Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The Elements, as defined in [IEEE802.15.4e]. The format and use of
format and use of Information Elements are not relevant to RPL Information Elements are not relevant to RPL applicability
applicability statement. statement.
The IEEE 1901.2 PHY frame payload size varies as a function of the The IEEE 1901.2 PHY frame payload size varies as a function of the
modulation used to transmit the frame and the strength of the Forward modulation used to transmit the frame and the strength of the Forward
Error Correction scheme. Error Correction scheme.
The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY
settings in use (e.g. bandwidth, modulation, tones, etc). As quoted settings in use (e.g. bandwidth, modulation, tones, etc). As quoted
from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is
more than 247 octets for robust OFDM (ROBO) and Super-ROBO more than 247 octets for robust OFDM (ROBO) and Super-ROBO
modulations or more than 239 octets for all other modulations, the modulations or more than 239 octets for all other modulations, the
skipping to change at page 15, line 49 skipping to change at page 15, line 40
Since the MAC frame payload size limitation is given by the 4g PHY Since the MAC frame payload size limitation is given by the 4g PHY
frame payload size limitation (i.e.,2048 bytes) and MAC layer frame payload size limitation (i.e.,2048 bytes) and MAC layer
overhead (headers, trailers, Information Elements and security overhead (headers, trailers, Information Elements and security
overhead), the MAC frame payload MUST able to carry a full IPv6 overhead), the MAC frame payload MUST able to carry a full IPv6
packet of 1280 octets without upper layer fragmentation and re- packet of 1280 octets without upper layer fragmentation and re-
assembly. assembly.
7.2.3. IEEE MAC sub-layer Security Features 7.2.3. IEEE MAC sub-layer Security Features
Since IEEE 1901.2 standard is based on the 802.15.4-2006 MAC sub- Since IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer and
layer and fully endorses the security scheme defined in fully endorses the security scheme defined in 802.15.4, we only focus
802.15.4-2006, we only focus on description of IEEE 802.15.4 security on description of IEEE 802.15.4 security scheme.
scheme.
The IEEE 802.15.4 specification was designed to support a variety of The IEEE 802.15.4 specification was designed to support a variety of
applications, many of which are security sensitive. The IEEE applications, many of which are security sensitive. The IEEE
802.15.4 provides four basic security services: message 802.15.4 provides four basic security services: message
authentication, message integrity, message confidentiality, and authentication, message integrity, message confidentiality, and
freshness checks to avoid replay attacks. freshness checks to avoid replay attacks.
The 802.15.4 security layer is handled at the media access control The 802.15.4 security layer is handled at the media access control
layer, below 6LowPAN layer. The application specifies its security layer, below 6LowPAN layer. The application specifies its security
requirements by setting the appropriate control parameters into the requirements by setting the appropriate control parameters into the
skipping to change at page 20, line 7 skipping to change at page 19, line 45
they are considered a critical infrastructure component. At the same they are considered a critical infrastructure component. At 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, transport-layer infrastructure is available. As a result, smart grid networks are
and/or application-layer security mechanisms are typically in place deployed with security mechanisms such as link-layer, transport layer
and using RPL's secure mode is not necessary. and/or application-layer security mechanisms; while it is best
practice to secure all layers, using RPL's secure mode may not be
necessary. Failure to protect any of these layers can result in
various attacks; without strong authentication of devices in the
infrastructure can lead to uncontrolled and unauthorized access.
Similarly, failure to protect the communication layers can enable
passive (in wireless mediums) attacks as well as man-in-the-middle
and active attacks.
As this document describes the applicability of RPL non-storing mode, As this document describes the applicability of RPL non-storing mode,
the security considerations as defined in [RFC6550] also applies to the security considerations as defined in [RFC6550] also applies to
this document and to AMI deployments. this document and to AMI deployments.
9.1. Security Considerations during initial deployment 9.1. Security Considerations during initial deployment
During the manufacturing process, the meters are loaded with the During the manufacturing process, the meters are loaded with the
appropriate security credentials (keys, certificates). These appropriate security credentials (keys, certificates). These
security credentials are unique per device and only known by the security credentials are unique per device and only known by the
skipping to change at page 20, line 48 skipping to change at page 20, line 46
defined in Section 6 of [RFC7416]. defined in Section 6 of [RFC7416].
Like any secure network infrastructure, an AMI deployment's ability Like any secure network infrastructure, an AMI deployment's ability
to address node impersonation, active man-in-the-middle attacks to address node impersonation, active man-in-the-middle attacks
relies on mutual authentication and authorization process. The relies on mutual authentication and authorization process. The
credential management from the manufacturing imprint of security credential management from the manufacturing imprint of security
credentials of smart meters to all credentials of nodes in the credentials of smart meters to all credentials of nodes in the
infrastructure, all credentials must be appropriately managed and infrastructure, all credentials must be appropriately managed and
classified through the authorization process to ensure beyond the classified through the authorization process to ensure beyond the
identity of the nodes, that the nodes are behaving or 'acting' in identity of the nodes, that the nodes are behaving or 'acting' in
their assigned roles. their assigned roles. Known schemes
Similarly, to ensure that data has not been modified, confidentiality Similarly, to ensure that data has not been modified, confidentiality
and integrity at the suitable layers (e.g. link layer, application and integrity at the suitable layers (e.g. link layer, application
layer or both) should be used. layer or both) should be used.
10. Other Related Protocols To provide the security mechanisms to address these threats, an AMI
deployment must include the use of the security schemes as defined by
This section is intentionally left blank. IEEE 1901.2 (and IEEE 802.15.4). With IEEE 802.15.4 defining the
security mechanisms to afford mutual authentication, access control
(e.g. authorization) and transport confidentiality and integrity.
The credential management is afforded through the use of already
existing identity management solutions.
11. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Acknowledgements 11. Acknowledgements
The authors would like to acknowledge the review, feedback, and Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden
were contributors and noted as authors in earlier drafts. The
authors would also like to acknowledge the review, feedback, and
comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi
Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP
Vasseur. Vasseur.
13. References 12. References
13.1. Informative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
12.2. Informative references
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <http://www.rfc-editor.org/info/rfc5867>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>.
[surveySG] [surveySG]
Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C.,
Cecati, C., and G. Hancke, "A Survey on Smart Grid Cecati, C., and G. Hancke, "A Survey on Smart Grid
Potential Applications and Communication Requirements", Potential Applications and Communication Requirements",
Feb 2013. Feb 2013.
[IEEE802.15.4] [IEEE802.15.4]
"IEEE Standard for Information technology-- Local and "IEEE Standard for Information technology-- Local and
metropolitan area networks-- Specific requirements-- Part metropolitan area networks-- Specific requirements-- Part
skipping to change at page 21, line 44 skipping to change at page 22, line 35
Layer (PHY) Specifications for Low Rate Wireless Personal Layer (PHY) Specifications for Low Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September Area Networks (WPANs)", IEEE Standard 802.15.4, September
2006. 2006.
[IEEE802.15.4e] [IEEE802.15.4e]
"IEEE Standard for Local and metropolitan area networks-- "IEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 1: MAC sublayer", IEEE Standard WPANs) Amendment 1: MAC sublayer", IEEE Standard
802.15.4e, April 2012. 802.15.4e, April 2012.
[IEEE802.15.4g]
"IEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 3: Physical Layer (PHY) Specifications
for Low-Data-Rate, Wireless, Smart Metering Utility
Networks", IEEE Standard 802.15.4g, November 2012.
[IEEE1901.2] [IEEE1901.2]
"IEEE Standard for Low-Frequency (less than 500 kHz) "IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid Narrowband Power Line Communications for Smart Grid
Applications", IEEE Standard 1901.2, December 2013. Applications", IEEE Standard 1901.2, December 2013.
13.2. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <http://www.rfc-editor.org/info/rfc5548>. 2009, <http://www.rfc-editor.org/info/rfc5548>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>. March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
skipping to change at page 22, line 34 skipping to change at page 23, line 22
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <http://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<http://www.rfc-editor.org/info/rfc6551>. <http://www.rfc-editor.org/info/rfc6551>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <http://www.rfc-editor.org/info/rfc5867>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
Hysteresis Objective Function", RFC 6719, Hysteresis Objective Function", RFC 6719,
DOI 10.17487/RFC6719, September 2012, DOI 10.17487/RFC6719, September 2012,
<http://www.rfc-editor.org/info/rfc6719>. <http://www.rfc-editor.org/info/rfc6719>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>. <http://www.rfc-editor.org/info/rfc6552>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-editor.org/info/rfc6282>.
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-12 (work in progress), June 2015. mcast-12 (work in progress), June 2015.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<http://www.rfc-editor.org/info/rfc7416>. <http://www.rfc-editor.org/info/rfc7416>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget (editor)
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
US
Daniel Popa Email: ncamwing@cisco.com
Itron, Inc
52, rue Camille Desmoulins
Issy les Moulineaux 92130
FR
Email: daniel.popa@itron.com
Matthew Gillmore
Itron, Inc
2111 N Molter Rd.
Liberty Lake, WA 99019
USA
Email: matthew.gillmore@itron.com
Laurent Toutain
Telecom Bretagne
2 rue de la Chataigneraie
Cesson Sevigne 35510
FR
Email: laurent.toutain@telecom-bretagne.eu
Jonathan Hui Jonathan Hui
Nest Nest
3400 Hillview Ave 3400 Hillview Ave
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: jonhui@nestlabs.com Email: jonhui@nestlabs.com
Ruben Salazar Daniel Popa
Landys+Gyr Itron, Inc
30000 Mill Creek Ave # 100 52, rue Camille Desmoulins
Alpharetta, GA 30022 Issy les Moulineaux 92130
USA FR
Email: ruben.salazar@landisgyr.com
Kazuya Monden
Hitachi, Ltd., Yokohama Research Laboratory
292, Yoshida-cho, Totsuka-ku, Yokohama-shi
Kanagawa-ken 244-0817
Japan
Email: kazuya.monden.vw@hitachi.com
Nancy Cam-Winget (editor)
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
US
Email: ncamwing@cisco.com Email: daniel.popa@itron.com
 End of changes. 48 change blocks. 
186 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/