draft-ietf-roll-applicability-ami-13.txt   draft-ietf-roll-applicability-ami-14.txt 
Roll N. Cam-Winget, Ed. Roll N. Cam-Winget, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Hui Intended status: Standards Track J. Hui
Expires: October 27, 2016 Nest Expires: March 30, 2017 Nest
D. Popa D. Popa
Itron, Inc Itron, Inc
April 25, 2016 September 26, 2016
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-13 draft-ietf-roll-applicability-ami-14
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 35 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 October 27, 2016. This Internet-Draft will expire on March 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . 3 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 . . . . . . . 4
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 . . . . . . 9 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Objective Function . . . . . . . . . . . . . . . . . 11 7.1.4. Objective Function . . . . . . . . . . . . . . . . . 11
7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12
7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12 7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12
7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 12 7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 16 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 16
7.4. Recommended Configuration Defaults and Ranges . . . . . . 16 7.4. Recommended Configuration Defaults and Ranges . . . . . . 17
7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 16 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17
7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 18 8. Manageability Considerations . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Security Considerations during initial deployment . . . . 19 9.1. Security Considerations during initial deployment . . . . 19
9.2. Security Considerations during incremental deployment . . 19 9.2. Security Considerations during incremental deployment . . 19
9.3. Security Considerations based on RPL's Threat Analysis . 20 9.3. Security Considerations based on RPL's Threat Analysis . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Informative references . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative 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 49 skipping to change at page 4, line 5
technology have emerged, such as [IEEE1901.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 (Routing Protocol for Low Power
battery-powered devices (i.e., gas/water meters). and Lossy Networks) [RFC6550] in AMI networks composed of 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 (vs. non-storing) mode of o Applicability statement for RPL storing mode of operation in AMI
operation in AMI networks. 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
LLN Border Router or 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
skipping to change at page 4, line 33 skipping to change at page 4, line 37
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
heterogeneous networks composed of nodes and links with vastly heterogeneous networks composed of nodes and links with vastly
different characteristics [RFC6551]. different characteristics [RFC6551].
This document describes the applicability of RPL non-storing mode (as This document describes the applicability of RPL non-storing mode (as
defined in [RFC6550]) to AMI deployments. RPL was designed to meet defined in [RFC6550]) to AMI deployments. The Routing Requirements
the following application requirements: for Urban Low-Power and Lossy Networks are applicable to AMI networks
as well. The terminology used in this document is defined in
o Routing Requirements for Urban Low-Power and Lossy Networks [RFC7102].
[RFC5548].
o Industrial Routing Requirements in Low-Power and Lossy Networks
[RFC5673].
o Home Automation Routing Requirements in Low-Power and Lossy
Networks [RFC5826].
o Building Automation Routing Requirements in Low-Power and Lossy
Networks [RFC5867].
The Routing Requirements for Urban Low-Power and Lossy Networks are
applicable to AMI networks as well. The terminology used in this
document is defined in [RFC7102].
3. Description of AMI networks for electric meters 3. Description of AMI networks for electric meters
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
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
skipping to change at page 7, line 4 skipping to change at page 7, line 4
the mesh between a network node and the nearest LBR may be composed 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 of several hops or even several tens of hops. Powered from the main
line, electric meters have less energy constraints than battery line, electric meters have less energy constraints than battery
powered devices, such as gas and water meters, and can afford the powered devices, such as gas and water meters, and can afford the
additional resources required to route packets. additional resources required to route packets.
As a function of the technology used to exchange information, the As a function of the technology used to exchange information, the
logical network topology will not necessarily match the electric grid logical network topology will not necessarily match the electric grid
topology. If meters exchange information through radio technologies topology. If meters exchange information through radio technologies
such as in IEEE 802.15.4 family, the topology is a meshed network, such as in IEEE 802.15.4 family, the topology is a meshed network,
where nodes belonging to the same DODAG can be connected to the grid where nodes belonging to the same DODAG (Destination Oriented
through different substations. If narrowband PLC technology is used, Directed Acyclic Graph ) can be connected to the grid through
it will follow more or less the physical tree structure since different substations. If narrowband PLC technology is used, it will
diaphony may allow one phase to communicate with the other. This is follow more or less the physical tree structure since diaphony may
particularly true near the LBR. Some mixed topology can also be allow one phase to communicate with the other. This is particularly
observed, since some LBRs may be strategically installed in the field true near the LBR. Some mixed topology can also be observed, since
to avoid all the communications going through a single LBR. some LBRs may be strategically installed in the field to avoid all
Nethertheless, the short propagation range forces meters to relay the the communications going through a single LBR. Nethertheless, the
information. short propagation range forces meters to relay the information.
4. Smart Grid Traffic Description 4. Smart Grid Traffic Description
4.1. Smart Grid Traffic Characteristics 4.1. Smart Grid Traffic Characteristics
In current AMI deployments, metering applications typically require In current AMI deployments, metering applications typically require
all smart meters to communicate with a few head-end servers, deployed all smart meters to communicate with a few head-end servers, deployed
in the utility company data center. Head-end servers generate data in the utility company data center. Head-end servers generate data
traffic to configure smart data reading or initiate queries, and use traffic to configure smart data reading or initiate queries, and use
unicast and multicast to efficiently communicate with a single device unicast and multicast to efficiently communicate with a single device
(i.e. Point-to-Point (P2P) communications) or groups of devices (i.e. Point-to-Point (P2P) communications) or groups of devices
respectively (i.e., Point-to-Multipoint (P2MP) communication). The respectively (i.e., Point-to-Multipoint (P2MP) communication). The
head-end server may send a single small packet at a time to the head-end server may send a single small packet at a time to the
meters (e.g., a meter read request, a small configuration change, meters (e.g., a meter read request, a small configuration change,
service switch command) or a series of large packets (e.g., a service switch command) or a series of large packets (e.g., a
firmware download across one or even thousands of devices). The firmware download across one or even thousands of devices). The
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 (Mesh Peer to smart meter devices to the head-end servers, in a MP2P (Mesh Peer to
Peer)fashion. Current SMD traffic patterns are fairly uniform and Peer)fashion. Current SMD traffic patterns are fairly uniform and
skipping to change at page 11, line 8 skipping to change at page 11, line 8
identification of groups of field devices in the network. identification of groups of field devices in the network.
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 (DODAG Information Object)
options [RFC6550]. messages, and DIO message 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 12, line 49 skipping to change at page 12, line 49
Multicast support for RPL in non-storing mode are being developed in Multicast support for RPL in non-storing mode are being developed in
companion RFCs (see [RFC7731]). companion RFCs (see [RFC7731]).
7.1.7. Security 7.1.7. 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 layer, transport layer and security. For this reason, the link layer, transport layer and
application layer technologies utilized within AMI networks typically application layer technologies utilized within AMI networks typically
provide security mechanisms to ensure authentication, 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; they
could rely on link layer and higher layer security features. MUST include, at a minimum, link layer security such as that defined
by IEEE 1901.2 and IEEE 802.15.4.
7.2. Description of Layer-two features 7.2. Description of Layer-two features
7.2.1. IEEE 1901.2 PHY and MAC sub-layer features 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features
The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and
defines a time frequency interleaver over the entire PHY frame defines a time frequency interleaver over the entire PHY frame
coupled with a Reed Solomon and Viterbi Forward Error Correction for coupled with a Reed Solomon and Viterbi Forward Error Correction for
maximum robustness. Since the noise level in each OFDM sub-carrier maximum robustness. Since the noise level in each OFDM sub-carrier
can vary significantly, IEEE 1901.2 specifies two complementary can vary significantly, IEEE 1901.2 specifies two complementary
skipping to change at page 14, line 34 skipping to change at page 14, line 34
carry up to 2048 octets. carry up to 2048 octets.
The IEEE Std 802.15.4g defines the following modulations: MR-FSK The IEEE Std 802.15.4g defines the following modulations: MR-FSK
(Multi- Rate FSK), MR-OFDM (Multi-Rate OFDM) and MR-O-QPSK (Multi- (Multi- Rate FSK), MR-OFDM (Multi-Rate OFDM) and MR-O-QPSK (Multi-
Rate O-QPSK). The (over-the-air) bit rates for these modulations Rate O-QPSK). The (over-the-air) bit rates for these modulations
range from 4.8 to 600kbps for MR-FSK, from 50 to 600kbps for MR-OFDM range from 4.8 to 600kbps for MR-FSK, from 50 to 600kbps for MR-OFDM
and from 6.25 to 500kbps for MR-O-QPSK. and from 6.25 to 500kbps for MR-O-QPSK.
The MAC sub-layer running on top of a 4g radio link is based on IEEE The MAC sub-layer running on top of a 4g radio link is based on IEEE
802.15.4e. The 802.15.4e MAC allows for a variety of modes for 802.15.4e. The 802.15.4e MAC allows for a variety of modes for
operation. These include: Timetimeslotslotted channel hopping operation. These include:
(TSCH), specifically designed for application domains such as process
automation, Low latency deterministic networks (LLDN), for o Timetimeslotslotted channel hopping (TSCH): specifically designed
application domains such as factory automation, Deterministic and for application domains such as process automation
synchronous multi-channel extension (DSME), for general industrial
and commercial application domains that includes Channel diversity to o Low latency deterministic networks (LLDN): for application domains
increase network robustness, and Asynchronous multi-channel such as factory automation
adaptation (AMCA), for large infrastructure application domains.
o Deterministic and synchronous multi-channel extension (DSME): for
general industrial and commercial application domains that
includes Channel diversity to increase network robustness
o Asynchronous multi-channel adaptation (AMCA): for large
infrastructure application domains.
The MAC addressing scheme supports short (16-bits) addresses along The MAC addressing scheme supports short (16-bits) addresses along
with extended (64-bits) addresses. These addresses are assigned in with extended (64-bits) addresses. These addresses are assigned in
different ways and is specified by specific standards organizations. different ways and is specified by specific standards organizations.
Information Elements, Enhanced Beacons and frame version 2, as Information Elements, Enhanced Beacons and frame version 2, as
defined in 802.15.4e, MUST be supported. defined in 802.15.4e, MUST be supported.
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
skipping to change at page 16, line 49 skipping to change at page 17, line 9
AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all
of the IPv6 Header Compression schemes specified in [RFC6282] of the IPv6 Header Compression schemes specified in [RFC6282]
Section 3 and all of the IPv6 Next Header compression schemes Section 3 and all of the IPv6 Next Header compression schemes
specified in [RFC6282] Section 4, if reducing over the air/wire specified in [RFC6282] Section 4, if reducing over the air/wire
overhead is a requirement. overhead is a requirement.
7.4. Recommended Configuration Defaults and Ranges 7.4. Recommended Configuration Defaults and Ranges
7.4.1. Trickle Parameters 7.4.1. Trickle Parameters
Trickle was designed to be density-aware and perform well in networks Trickle [RFC6206] was designed to be density-aware and perform well
characterized by a wide range of node densities. The combination of in networks characterized by a wide range of node densities. The
DIO packet suppression and adaptive timers for sending updates allows combination of DIO packet suppression and adaptive timers for sending
Trickle to perform well in both sparse and dense environments. Node updates allows Trickle to perform well in both sparse and dense
densities in AMI deployments can vary greatly, from nodes having only environments. Node densities in AMI deployments can vary greatly,
one or a handful of neighbors to nodes having several hundred from nodes having only one or a handful of neighbors to nodes having
neighbors. In high density environments, relatively low values for several hundred neighbors. In high density environments, relatively
Imin may cause a short period of congestion when an inconsistency is low values for Imin may cause a short period of congestion when an
detected and DIO updates are sent by a large number of neighboring inconsistency is detected and DIO updates are sent by a large number
nodes nearly simultaneously. While the Trickle timer will of neighboring nodes nearly simultaneously. While the Trickle timer
exponentially backoff, some time may elapse before the congestion will exponentially backoff, some time may elapse before the
subsides. While some link layers employ contention mechanisms that congestion subsides. While some link layers employ contention
attempt to avoid congestion, relying solely on the link layer to mechanisms that attempt to avoid congestion, relying solely on the
avoid congestion caused by a large number of DIO updates can result link layer to avoid congestion caused by a large number of DIO
in increased communication latency for other control and data traffic updates can result in increased communication latency for other
in the network. To mitigate this kind of short-term congestion, this control and data traffic in the network. To mitigate this kind of
document recommends a more conservative set of values for the Trickle short-term congestion, this document recommends a more conservative
parameters than those specified in [RFC6206]. In particular, set of values for the Trickle parameters than those specified in
DIOIntervalMin is set to a larger value to avoid periods of [RFC6206]. In particular, DIOIntervalMin is set to a larger value to
congestion in dense environments, and DIORedundancyConstant is avoid periods of congestion in dense environments, and
parameterized accordingly as described below. These values are DIORedundancyConstant is parameterized accordingly as described
appropriate for the timely distribution of DIO updates in both sparse below. These values are appropriate for the timely distribution of
and dense scenarios while avoiding the short-term congestion that DIO updates in both sparse and dense scenarios while avoiding the
might arise in dense scenarios. Because the actual link capacity short-term congestion that might arise in dense scenarios. Because
depends on the particular link technology used within an AMI the actual link capacity depends on the particular link technology
deployment, the Trickle parameters are specified in terms of the used within an AMI deployment, the Trickle parameters are specified
link's maximum capacity for transmitting link-local multicast in terms of the link's maximum capacity for transmitting link-local
messages. If the link can transmit m link-local multicast packets multicast messages. If the link can transmit m link-local multicast
per second on average, the expected time it takes to transmit a link- packets per second on average, the expected time it takes to transmit
local multicast packet is 1/m seconds. a link-local multicast packet is 1/m seconds.
DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that
the Trickle Imin is at least 50 times as long as it takes to 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 transmit a link-local multicast packet. This value is larger than
that recommended in [RFC6206] to avoid congestion in dense urban that recommended in [RFC6206] to avoid congestion in dense urban
deployments as described above. deployments as described above.
DIOIntervalDoublings: AMI deployments SHOULD set DIOIntervalDoublings: AMI deployments SHOULD set
DIOIntervalDoublings such that the Trickle Imax is at least 2 DIOIntervalDoublings such that the Trickle Imax is at least 2
hours or more. hours or more.
skipping to change at page 19, line 9 skipping to change at page 19, line 13
behavior to evolve during the lifetime of the network. RPL specifies behavior to evolve during the lifetime of the network. RPL specifies
a number of variables and events that can be tracked for purposes of a number of variables and events that can be tracked for purposes of
network fault and performance monitoring of RPL routers. Depending network fault and performance monitoring of RPL routers. Depending
on the memory and processing capabilities of each smart grid device, on the memory and processing capabilities of each smart grid device,
various subsets of these can be employed in the field. various subsets of these can be employed in the field.
9. Security Considerations 9. 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 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, they are composed of large numbers of resource- constrained
constrained devices inter-connected with limited-throughput links, devices inter-connected with limited-throughput links. As a result,
many available security mechanisms are not practical for use in such the choice of security mechanisms is highly dependent on the device
networks. As a result, the choice of security mechanisms is highly and network capabilities characterizing a particular deployment.
dependent on the device and network capabilities characterizing a
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, smart grid networks are infrastructure is available. As a result, smart grid networks are
deployed with security mechanisms such as link-layer, transport layer deployed with security mechanisms such as link-layer, transport layer
and/or application-layer security mechanisms; while it is best and/or application-layer security mechanisms; while it is best
practice to secure all layers, using RPL's secure mode may not be practice to secure all layers, using RPL's secure mode may not be
necessary. Failure to protect any of these layers can result in necessary. Failure to protect any of these layers can result in
various attacks; without strong authentication of devices in the various attacks; without strong authentication of devices in the
infrastructure can lead to uncontrolled and unauthorized access. infrastructure can lead to uncontrolled and unauthorized access.
skipping to change at page 19, line 36 skipping to change at page 19, line 38
passive (in wireless mediums) attacks as well as man-in-the-middle passive (in wireless mediums) attacks as well as man-in-the-middle
and active attacks. 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). The
security credentials are unique per device and only known by the configured security credentials during manufacturing are used by the
device itself and the head-end security appliances. The devices to authenticate with the system and to further negotiate
manufacturing security credentials are then used by the devices to operational security credentials, for both network and application
authenticate with the system and negotiate operational security layers.
credentials, for both network and application layers.
9.2. Security Considerations during incremental deployment 9.2. Security Considerations during incremental deployment
If during the system operation a device fails or is compromised, it If during the system operation a device fails or is known to be
is replaced with a new device. The new device does not take over the compromised, it is replaced with a new device. The new device does
security identity of the replaced device. The security credentials not take over the security identity of the replaced device. The
associated with the failed/compromised device are removed from the security credentials associated with the failed/compromised device
security appliances. are removed from the security appliances.
9.3. Security Considerations based on RPL's Threat Analysis 9.3. Security Considerations based on RPL's Threat Analysis
[RFC7416] defines a set of security considerations for RPL security. [RFC7416] defines a set of security considerations for RPL security.
This document defines how it leverages the device's link layer and This document defines how it leverages the device's link layer and
application layer security mechanisms to address the threats as application layer security mechanisms to address the threats as
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
skipping to change at page 20, line 31 skipping to change at page 20, line 31
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.
To provide the security mechanisms to address these threats, an AMI To provide the security mechanisms to address these threats, an AMI
deployment MUST include the use of the security schemes as defined by deployment MUST include the use of the security schemes as defined by
IEEE 1901.2 (and IEEE 802.15.4). With IEEE 802.15.4 defining the IEEE 1901.2 (and IEEE 802.15.4). With IEEE 802.15.4 defining the
security mechanisms to afford mutual authentication, access control security mechanisms to afford mutual authentication, access control
(e.g. authorization) and transport confidentiality and integrity. (e.g. authorization) and transport confidentiality and integrity.
The credential management is afforded through the use of already
existing identity management solutions.
10. IANA Considerations 10. Privacy Considerations
Privacy of information flowing through smart grid networks are
subject to consideration. An evolving a set of recommendations and
requirements are deing defined by different groups and consortiums;
for example, the U.S. Department of Energy issued a document
[DOEVCC] defining a process and set of recommendations to address
privacy issues. As this document describes the applicability of RPL,
the privacy considerations as defined in [RFC6550] and [I-D.thaler-
6lo-privacy-considerations] apply to this document and to AMI
deployments.
11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgements 12. Acknowledgements
Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden
were contributors and noted as authors in earlier drafts. The were contributors and noted as authors in earlier drafts. The
authors would also like to acknowledge the review, feedback, and 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.
12. References 13. References
12.1. Normative References
13.1. 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
skipping to change at page 21, line 44 skipping to change at page 22, line 5
Part 15.4: Low-Rate Wireless Personal Area Networks (LR- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 3: Physical Layer (PHY) Specifications WPANs) Amendment 3: Physical Layer (PHY) Specifications
for Low-Data-Rate, Wireless, Smart Metering Utility for Low-Data-Rate, Wireless, Smart Metering Utility
Networks", IEEE Standard 802.15.4g, November 2012. 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.
12.2. Informative references [surveySG]
Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C.,
Cecati, C., and G. Hancke, "A Survey on Smart Grid
Potential Applications and Communication Requirements",
Feb 2013.
13.2. Informative references
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>. 2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., Ed., 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, DOI 10.17487/RFC5867, June Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <http://www.rfc-editor.org/info/rfc5867>. 2010, <http://www.rfc-editor.org/info/rfc5867>.
skipping to change at page 22, line 29 skipping to change at page 22, line 42
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>. <http://www.rfc-editor.org/info/rfc6997>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>. February 2016, <http://www.rfc-editor.org/info/rfc7731>.
[surveySG]
Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C.,
Cecati, C., and G. Hancke, "A Survey on Smart Grid
Potential Applications and Communication Requirements",
Feb 2013.
[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>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
skipping to change at page 23, line 26 skipping to change at page 23, line 32
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>.
[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>.
[I-D.thaler-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 over Networks
of Resource-Constrained Nodes", draft-thaler-6lo-privacy-
considerations-01 (work in progress), October 2015.
[DOEVCC] "Voluntary Code of Conduct (VCC) Final Concepts and
Principles", Jan 2015,
<http://energy.gov/sites/prod/files/2015/01/f19/VCC%20Conc
epts%20and%20Principles%202015_01_08%20FINAL.pdf>.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget (editor) Nancy Cam-Winget (editor)
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US US
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
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
Daniel Popa Daniel Popa
Itron, Inc Itron, Inc
 End of changes. 27 change blocks. 
118 lines changed or deleted 131 lines changed or added

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