draft-ietf-roll-applicability-ami-09.txt   draft-ietf-roll-applicability-ami-10.txt 
Roll D. Popa Roll D. Popa
Internet-Draft M. Gillmore Internet-Draft M. Gillmore
Intended status: Standards Track Itron, Inc Intended status: Standards Track Itron, Inc
Expires: January 23, 2015 L. Toutain Expires: August 3, 2015 L. Toutain
Telecom Bretagne Telecom Bretagne
J. Hui J. Hui
Cisco Cisco
R. Ruben R. Ruben
Landis+Gyr Landis+Gyr
K. Monden K. Monden
Hitachi, Ltd., Yokohama Research Laboratory Hitachi, Ltd., Yokohama Research Laboratory
July 22, 2014 N. Cam-Winget, Ed.
Cisco Systems
January 30, 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-09 draft-ietf-roll-applicability-ami-10
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 40 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 23, 2015. This Internet-Draft will expire on August 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 41 skipping to change at page 2, line 45
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 . . . . . 14 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 15
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 . . . . . . . . . . . . . . . . 19
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
10. Other Related Protocols . . . . . . . . . . . . . . . . . . . 20 9.3. Security Considerations based on RPL's Threat Analysis . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Other Related Protocols . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Informative References . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Normative references . . . . . . . . . . . . . . . . . . 21 13.1. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 13.2. Normative references . . . . . . . . . . . . . . . . . . 22
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,
distribution automation elements, and eventually home area network distribution automation elements, and eventually home area network
skipping to change at page 5, line 10 skipping to change at page 5, line 13
[RFC5673]. [RFC5673].
o Home Automation Routing Requirements in Low-Power and Lossy o Home Automation Routing Requirements in Low-Power and Lossy
Networks [RFC5826]. Networks [RFC5826].
o Building Automation Routing Requirements in Low-Power and Lossy o Building Automation Routing Requirements in Low-Power and Lossy
Networks [RFC5867]. Networks [RFC5867].
The Routing Requirements for Urban Low-Power and Lossy Networks are The Routing Requirements for Urban Low-Power and Lossy Networks are
applicable to AMI networks as well. The terminology used in this applicable to AMI networks as well. The terminology used in this
document is defined in [I-D.ietf-roll-terminology-13]. document is defined in [I-D.ietf-roll-terminology].
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 6, line 18 skipping to change at page 6, line 23
proximity form routing domains, each in the order of a 1,000 to proximity form routing domains, each in the order of a 1,000 to
10,000 meters. Thus, each electric meter mesh typically has several 10,000 meters. Thus, each electric meter mesh typically has several
thousand wireless endpoints, with densities varying based on the area thousand wireless endpoints, with densities varying based on the area
and the terrain. and the terrain.
| |
+M +M
| |
M M M M | M M M M M | M
/-----------\ /---+---+---+---+--+-+- phase 1 /-----------\ /---+---+---+---+--+-+- phase 1
+----+ ( Internet ) +----+ / M M M M +----+ ( Internet ) +-----+ / M M M M
|MDMS|---( )----|LBR |/----+----+----+----+---- phase 2 |MDMS|---( )----| LBR |/----+----+----+----+---- phase 2
+----+ ( WAN ) +----+\ +----+ ( WAN ) +-----+\
\----------/ \ M M M M \----------/ \ M M M M
\--+--+----+-+---+----- phase 3 \--+--+----+-+---+----- phase 3
\ M M \ M M
+--+---+-- +--+---+--
<----------------------------> <----------------------------->
RPL RPL
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 to 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 segment. communication between the LBR and the meters, i.e. the NAN (Neighbor-
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)
connectivity through various traditional network technologies, e.g., connectivity through various traditional network technologies, e.g.,
Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in
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 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 eletric 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 can be connected to the grid
through different substations. If narrowband PLC technology is used, through different substations. If narrowband PLC technology is used,
it will follow more or less the physical tree structure since it will follow more or less the physical tree structure since
diaphony may allow one phase to communicate with the other. This is diaphony may allow one phase to communicate with the other. This is
particularly true near the LBR. Some mixt topology can also be particularly true near the LBR. Some mixed topology can also be
observed, since some LBR may be strategically installed in the field observed, since some LBRs may be strategically installed in the field
to avoid all the communications going through a single LBR. to avoid all the communications going through a single LBR.
Nethertheless, the short propagation range forces meters to relay the Nethertheless, the short propagation range forces meters to relay the
information. 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 meter data reading or initiate queries, traffic to configure smart data reading or initiate queries, and use
and use unicast and multicast to efficiently communicate with a unicast and multicast to efficiently communicate with a single device
single device (i.e., Point-to-Point (P2P) communications) or groups (i.e. Point-to-Point (P2P) communications) or groups of devices
of devices respectively (i.e., Point-to-Multipoint (P2MP) respectively (i.e., Point-to-Multipoint (P2MP) communication). The
communication). The head-end server may send a single small packet head-end server may send a single small packet at a time to the
at a time to the meters (e.g., a meter read request, a small meters (e.g., a meter read request, a small configuration change,
configuration change, service switch command) or a series of large service switch command) or a series of large packets (e.g., a
packets (e.g., a firmware download across one or even thousands of firmware download across one or even thousands of devices). The
devices). The frequency of large file transfers, e.g., firmware frequency of large file transfers, e.g., firmware download of all
download of all metering devices, is typically much lower than the metering devices, is typically much lower than the frequency of
frequency of sending configuration messages or queries. Each smart sending configuration messages or queries. Each smart meter
meter generates Smart Metering Data (SMD) traffic according to a generates Smart Metering Data (SMD) traffic according to a schedule
schedule (e.g., periodic meter reads), in response to on-demand (e.g., periodic meter reads), in response to on-demand queries (e.g.,
queries (e.g., on-demand meter reads), or in response to some local on-demand meter reads), or in response to some local event (e.g.,
event (e.g., power outage, leak detection). Such traffic is power outage, leak detection). Such traffic is typically destined to
typically destined to a single head-end server. The SMD traffic is a single head-end server. The SMD traffic is thus highly asymmetric,
thus highly asymmetric, where the majority of the traffic volume where the majority of the traffic volume generated by the smart
generated by the smart meters typically goes through the LBRs, and is meters typically goes through the LBRs, and is directed from the
directed from the smart meter devices to the head-end servers, in a smart meter devices to the head-end servers, in a MP2P fashion.
MP2P fashion. Current SMD traffic patterns are fairly uniform and Current SMD traffic patterns are fairly uniform and well-understood.
well-understood. The traffic generated by the head-end server and The traffic generated by the head-end server and destined to metering
destined to metering devices is dominated by periodic meter reads, devices is dominated by periodic meter reads, while traffic generated
while traffic generated by the metering devices is typically by the metering devices is typically uniformly spread over some
uniformly spread over some periodic read time-window. 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 30 skipping to change at page 9, line 34
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.
Altough not currently used in metering applications, support of peer- Although not currently used in metering applications, support of
to-peer communications between DODAG nodes is identified as a key peer- to-peer communications between DODAG nodes is identified as a
feature to be supported in smart grid networks. 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-2012 and IEEE 802.15.4e-2012 amendments to
802.15.2-2011 standard have been specifically developed for smart 802.15.2-2011 standard have been specifically developed for smart
grid networks. They are the most common PHY and MAC layers used for grid networks. They are the most common PHY and MAC layers used for
wireless AMI network. 802.15.4g specifies multiple mode of operation wireless AMI network. 802.15.4g specifies multiple modes of
(FSK, OQPSK and OFDM modulations) with speeds from 50kbps to 600kbps, operation (FSK, OQPSK and OFDM modulations) with speeds from 50kbps
and allows for transport of a full IPv6 packet (i.e., 1280 octets) to 600kbps, and allows for transport of a full IPv6 packet (i.e.,
without the need for upper layer segmentation and re-assembly. 1280 octets) without the need for upper layer segmentation and re-
assembly.
IEEE Std. 802.15.4e-2012 is an amendment to IEEE Std 802.15.4-2011 IEEE Std. 802.15.4e-2012 is an amendment to IEEE Std 802.15.4-2011
that specifies additional media access control (MAC) behaviors and that specifies additional media access control (MAC) behaviors and
frame formats that allow IEEE 802.15.4 devices to support a wide frame formats that allow IEEE 802.15.4 devices to support a wide
range of industrial and commercial applications that were not range of industrial and commercial applications that were not
adequately supported prior to the release of this amendment. It is adequately supported prior to the release of this amendment. It is
important to notice that 802.15.4e does not change the link-layer important to notice that 802.15.4e does not change the link-layer
security scheme defined in 802.15.4-2011 (and 802.15.4-2006). security scheme defined in 802.15.4-2011 (and 802.15.4-2006).
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-2013 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 1901.2-2013 standard supports indoor and outdoor communications Std P1901.2-2013 standard supports indoor and outdoor communications
over low voltage line (line between transformer and meter, less than over low voltage line (line between transformer and meter, less than
1000 V), through transformer low-voltage to medium-voltage (1000 V up 1000 V), through transformer low-voltage to medium-voltage (1000 V up
to 72 kV) and through transformer medium-voltage to low-voltage power to 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-2006 and 802.15.4e-2012 MAC sub-layer features. 802.15.4-2006 and 802.15.4e-2012 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
reassembly. re-assembly.
IEEE Std 1901.2 standard specifies link-layer security features that IEEE Std. 1901.2 specifies the necessary link-layer security features
fully endorse 802.15.4-2006 MAC sub-layer security scheme. that fully endorse 802.15.4-2006 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]:
o The routing protocol MUST be capable of supporting the o The routing protocol MUST be capable of supporting the
organization of a large number of nodes into regions containing on organization of a large number of nodes into regions containing on
the order of 10^2 to 10^4 nodes each. the order of 10^2 to 10^4 nodes each.
skipping to change at page 12, line 7 skipping to change at page 12, line 12
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 storing or non-storing
mode SHOULD be deployment specific. When meters are memory mode SHOULD be deployment specific. When meters are memory
constrained and cannot adequately store the route tables necessary to constrained and cannot adequately store the route tables necessary to
support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. support hop-by-hop routing, RPL non-storing mode SHOULD be preferred.
On the other hand, when nodes are capable of storing such routing On the other hand, when nodes are capable of storing such routing
tables, the use of storing mode may lead to reduced overhead and tables, the use of storing mode may lead to reduced overhead and
route repair latency. However, in high-density environments, storing route repair latency. However, in high-density environments, storing
routes can be challenging because some nodes may have to maintain routes can be challenging because some nodes may have to maintain
routing information for a large number of descendents. In this routing information for a large number of descendents. In this
document we only focus on non-storing mode of operation. document, we 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 12, line 33 skipping to change at page 12, line 38
Additional metrics may be defined in companion RFCs. Additional metrics may be defined in companion RFCs.
7.1.5. Objective Function 7.1.5. Objective Function
RPL relies on an Objective Function for selecting parents and RPL relies on an Objective Function for selecting parents and
computing path costs and rank. This objective function is decoupled computing path costs and rank. This objective function is decoupled
from the core RPL mechanisms and also from the metrics in use in the from the core RPL mechanisms and also from the metrics in use in the
network. Two objective functions for RPL have been defined at the network. Two objective functions for RPL have been defined at the
time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of
which define the selection of a preferred parent and backup parents, which define the selection of a preferred parent and backup parents,
and are suitable for AMI deployments. Additional objective functions and are suitable for AMI deployments.
may be defined in companion RFCs.
Additional objective functions may be defined in companion RFCs.
7.1.6. DODAG Repair 7.1.6. DODAG Repair
To effectively handle time-varying link characteristics and To effectively handle time-varying link characteristics and
availability, AMI deployments SHOULD utilize the local repair availability, AMI deployments SHOULD utilize the local repair
mechanisms in RPL. Local repair is triggered by broken link mechanisms in RPL. Local repair is triggered by broken link
detection. The first local repair mechanism consists of a node detection. The first local repair mechanism consists of a node
detaching from a DODAG and then re-attaching to the same or to a detaching from a DODAG and then re-attaching to the same or to a
different DODAG at a later time. While detached, a node advertises different DODAG at a later time. While detached, a node advertises
an infinite rank value so that its children can select a different an infinite rank value so that its children can select a different
skipping to change at page 13, line 18 skipping to change at page 13, line 24
its rank within a given DODAG Version (e.g., after detaching from the its rank within a given DODAG Version (e.g., after detaching from the
DODAG as a result of broken link or loop detection). Setting the DODAG as a result of broken link or loop detection). Setting the
DAGMaxRankIncrease to a non-zero value enables this mechanism, and DAGMaxRankIncrease to a non-zero value enables this mechanism, and
setting it to a value of less than infinity limits the cost of count- setting it to a value of less than infinity limits the cost of count-
to-infinity scenarios when they occur, thus controlling the duration to-infinity scenarios when they occur, thus controlling the duration
of disconnection applications may experience. of disconnection applications may experience.
7.1.7. Multicast 7.1.7. Multicast
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 [draft-ietf-roll-trickle-mcast-06]). companion RFCs (see [I-D.ietf-roll-trickle-mcast]).
7.1.8. Security 7.1.8. Security
AMI deployments operate in areas that do not provide any physical AMI deployments operate in areas that do not provide any physical
security. For this reason, the link 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 and
could rely on link layer and higher layer security features. could rely on link layer and higher layer security features.
skipping to change at page 13, line 40 skipping to change at page 13, line 46
7.1.9. Peer-to-Peer communications 7.1.9. Peer-to-Peer communications
Basic peer-to-peer capabilities are already defined in the RPL Basic peer-to-peer capabilities are already defined in the RPL
[RFC6550]. Additional mechanisms for peer-to-peer communications are [RFC6550]. Additional mechanisms for peer-to-peer communications are
proposed in companion RFCs (see [RFC6997]). proposed in companion RFCs (see [RFC6997]).
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 defines The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and
a time frequency interleaver over the entire PHY frame coupled with a defines a time frequency interleaver over the entire PHY frame
Reed Solomon and Viterbi Forward Error Correction for maximum coupled with a Reed Solomon and Viterbi Forward Error Correction for
robustness. Since the noise level in each OFDM sub-carrier can vary maximum robustness. Since the noise level in each OFDM sub-carrier
significantly IEEE 1901.2 specifies two complementary mechanisms can vary significantly, IEEE 1901.2 specifies two complementary
allowing to fine-tune the robustness/performance tradeoff implicit in mechanisms allowing to fine-tune the robustness/performance tradeoff
such systems. More specifically, the first (coarse-grained) implicit in such systems. More specifically, the first (coarse-
mechanism, defines the modulation from several possible choices grained) mechanism, defines the modulation from several possible
(robust (super-ROBO, ROBO), BPSK, QPSK,...). The second (fine- choices (robust (super-ROBO, ROBO), BPSK, QPSK,...). The second
grained) maps the sub-carriers which are too noisy and deactivates (fine-grained) maps the sub-carriers which are too noisy and
them. deactivates them.
The existence of multiple modulations and dynamic frequency exclusion The existence of multiple modulations and dynamic frequency exclusion
renders the problem of selecting a path between two nodes non- renders the problem of selecting a path between two nodes non-
trivial, as the possible number of combinations increases trivial, as the possible number of combinations increases
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
skipping to change at page 16, line 13 skipping to change at page 16, line 19
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
radio/PLC stack. The 802.15.4 defines four packet types: beacon radio/PLC stack. The 802.15.4 defines four packet types: beacon
frames, data frames, acknowledgments frame, and command frames for frames, data frames, acknowledgments frame, and command frames for
the media access control layer. The 802.15.4 specification does not the media access control layer. The 802.15.4 specification does not
support security for acknowledgement frames; data frames, beacon support security for acknowledgement frames; data frames, beacon
frames and command frames can support integrity protection and frames and command frames can support integrity protection and
confidentiality protection for the frames's data field. An confidentiality protection for the frames's data field. An
application has a choice of security suites that control the type of application has a choice of security suites that control the type of
security protection that is provided for the transmitted MAC frame. security protection that is provided for the transmitted MAC frame.
The 802.15.4 specification defines eight different security suites, Each security suite offers a different set of security properties and
outlined bellow. We can broadly classify the suites by the guarantees, and ultimately different MAC frame formats. The 802.15.4
properties that they offer: no security, encryption only (AES-CTR), specification defines eight different security suites, outlined
authentication only (AES-CBC-MAC), and encryption and authentication bellow. We can broadly classify the suites by the properties that
(AES-CCM). Each category that supports authentication comes in three they offer: no security, encryption only (AES-CTR), authentication
variants depending on the size of the MAC (Message Authentication only (AES-CBC-MAC), and encryption and authentication (AES-CCM).
Control) that it offers. The MAC can be either 4, 8, or 16 bytes Each category that supports authentication comes in three variants
long. Additionally, for each suite that offers encryption, the depending on the size of the MAC (Message Authentication Control)
recipient can optionally enable replay protection. that it offers. The MAC can be either 4, 8, or 16 bytes long.
Additionally, for each suite that offers encryption, the recipient
can optionally enable replay protection.
o Null = No security. o Null = No security.
o AES-CTR = Encryption only, CTR mode. o AES-CTR = Encryption only, CTR mode.
o AES-CBC-MAC-128 = No encryption, 128-bit MAC. o AES-CBC-MAC-128 = No encryption, 128-bit MAC.
o AES-CBC-MAC-64 = No encryption, 64-bit MAC. o AES-CBC-MAC-64 = No encryption, 64-bit MAC.
o AES-CCM-128 = Encryption and 128-bit MAC. o AES-CCM-128 = Encryption and 128-bit MAC.
skipping to change at page 19, line 48 skipping to change at page 20, line 5
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, 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. In contrast to other types of LLNs, in smart particular deployment.
grid networks centralized administrative control and access to a
permanent secure infrastructure is available. As a result link- In contrast to other types of LLNs, in smart grid networks
layer, transport-layer and/or application-layer security mechanisms centralized administrative control and access to a permanent secure
are typically in place and using RPL's secure mode is not necessary. infrastructure is available. As a result link-layer, transport-layer
and/or application-layer security mechanisms are typically in place
and using RPL's secure mode is not necessary.
As this document describes the applicability of RPL non-storing mode,
the security considerations as defined in [RFC6550] also applies to
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
device itself and the head-end security appliances. The device itself and the head-end security appliances. The
manufacturing security credentials are then used by the devices to manufacturing security credentials are then used by the devices to
authenticate with the system and negotiate operational security authenticate with the system and negotiate operational security
credentials, for both network and application 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 compromised, it
is replaced with a new device. The new device does not take over the is replaced with a new device. The new device does not take over the
security identity of the replaced device. The security credentials security identity of the replaced device. The security credentials
associated with the failed/compromised device are removed from the associated with the failed/compromised device are removed from the
security appliances. security appliances.
9.3. Security Considerations based on RPL's Threat Analysis
[RFC7416] defines a set of security considerations for RPL security.
This document defines how it leverages the device's link layer and
application layer security mechanisms to address the threats as
defined in Section 6 of [RFC7416].
Like any secure network infrastructure, an AMI deployment's ability
to address node impersonation, active man-in-the-middle attacks
relies on mutual authentication and authorization process. The
credential management from the manufacturing imprint of security
credentials of smart meters to all credentials of nodes in the
infrastructure, all credentials must be appropriately managed and
classified through the authorization process to ensure beyond the
identity of the nodes, that the nodes are behaving or 'acting' in
their assigned roles.
Similarly, to ensure that data has not been modified, confidentiality
and integrity at the suitable layers (e.g. link layer, application
layer or both) should be used.
10. Other Related Protocols 10. Other Related Protocols
This section is intentionally left blank. This section is intentionally left blank.
11. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Acknowledgements 12. Acknowledgements
skipping to change at page 21, line 6 skipping to change at page 21, line 35
13.1. Informative References 13.1. Informative References
[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 SA, "IEEE Standard for Information technology-- Local "IEEE Standard for Information technology-- Local and
and metropolitan area networks-- Specific requirements-- metropolitan area networks-- Specific requirements-- Part
Part 15.4: Wireless Medium Access Control (MAC) and 15.4: Wireless Medium Access Control (MAC) and Physical
Physical Layer (PHY) Specifications for Low Rate Wireless Layer (PHY) Specifications for Low Rate Wireless Personal
Personal Area Networks (WPANs)", September 2006. Area Networks (WPANs)", IEEE Standard 802.15.4, September
2006.
[IEEE802.15.4e] [IEEE802.15.4e]
IEEE SA, "IEEE Standard for Local and metropolitan area "IEEE Standard for Local and metropolitan area networks--
networks--Part 15.4: Low-Rate Wireless Personal Area Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
Networks (LR-WPANs) Amendment 1: MAC sublayer", April WPANs) Amendment 1: MAC sublayer", IEEE Standard
2012. 802.15.4e, April 2012.
[IEEE1901.2] [IEEE1901.2]
IEEE SA, "IEEE Standard for Low-Frequency (less than 500 "IEEE Standard for Low-Frequency (less than 500 kHz)
kHz) Narrowband Power Line Communications for Smart Grid Narrowband Power Line Communications for Smart Grid
Applications", December 2013. Applications", IEEE Standard 1901.2, December 2013.
13.2. Normative references 13.2. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
skipping to change at page 22, line 9 skipping to change at page 22, line 38
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", RFC Routing Requirements in Low-Power and Lossy Networks", RFC
5826, April 2010. 5826, April 2010.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
Martocci, "Reactive Discovery of Point-to-Point Routes in Hysteresis Objective Function", RFC 6719, September 2012.
Low-Power and Lossy Networks", RFC 6997, August 2013.
[RFC6552] Thubert, P., "Objective Function Zero for the Routing [RFC6552] Thubert, P., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", RFC Protocol for Low-Power and Lossy Networks (RPL)", RFC
6552, March 2012. 6552, March 2012.
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Hysteresis Objective Function", RFC 6719, September 2012. Martocci, "Reactive Discovery of Point-to-Point Routes in
Low-Power and Lossy Networks", RFC 6997, August 2013.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-11 (work in progress), November 2014.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terms used in Routing for Low power And
Lossy Networks", draft-ietf-roll-terminology-13 (work in
progress), October 2013.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, "A Security Threat Analysis for the
Routing Protocol for Low-Power and Lossy Networks (RPLs)",
RFC 7416, January 2015.
Authors' Addresses Authors' Addresses
Daniel Popa Daniel Popa
Itron, Inc Itron, Inc
52, rue Camille Desmoulins 52, rue Camille Desmoulins
Issy les Moulineaux 92130 Issy les Moulineaux 92130
FR FR
Email: daniel.popa@itron.com Email: daniel.popa@itron.com
skipping to change at line 1058 skipping to change at page 24, line 27
Email: ruben.salazar@landisgyr.com Email: ruben.salazar@landisgyr.com
Kazuya Monden Kazuya Monden
Hitachi, Ltd., Yokohama Research Laboratory Hitachi, Ltd., Yokohama Research Laboratory
292, Yoshida-cho, Totsuka-ku, Yokohama-shi 292, Yoshida-cho, Totsuka-ku, Yokohama-shi
Kanagawa-ken 244-0817 Kanagawa-ken 244-0817
Japan Japan
Email: kazuya.monden.vw@hitachi.com Email: kazuya.monden.vw@hitachi.com
Nancy Cam-Winget (editor)
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
US
Email: ncamwing@cisco.com
 End of changes. 35 change blocks. 
112 lines changed or deleted 167 lines changed or added

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