One document matched: draft-ietf-roll-applicability-ami-12.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC7210 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.RFC7102.xml">
<!ENTITY I-D.ietf-roll-trickle-mcast SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-trickle-mcast.xml">
]>
<?rfc toc="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-roll-applicability-ami-12">
<front>
<title abbrev="RPL Applicability for AMI">
Applicability Statement for the Routing Protocol for Low Power and Lossy
Networks (RPL) in AMI Networks
</title>
<author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget" role="editor">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3550 Cisco Way</street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
<!-- Reorder-->
</postal>
<email>ncamwing@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author initials="J." surname="Hui" fullname="Jonathan Hui">
<organization abbrev="Nest">Nest </organization>
<address>
<postal>
<street> 3400 Hillview Ave </street>
<city>Palo Alto, CA</city>
<code>94304</code>
<country>USA</country>
</postal>
<email>jonhui@nestlabs.com</email>
</address>
</author>
<author initials="D." surname="Popa" fullname="Daniel Popa">
<organization abbrev="Itron, Inc">Itron, Inc</organization>
<address>
<postal>
<street>52, rue Camille Desmoulins </street>
<city>Issy les Moulineaux</city>
<code>92130</code>
<country>FR</country>
</postal>
<email>daniel.popa@itron.com</email>
</address>
</author>
<date month="March" year="2016"/>
<area>Routing Area</area>
<workgroup>Roll</workgroup>
<abstract>
<t>
This document discusses the applicability of RPL in Advanced Metering
Infrastructure (AMI) networks.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Advanced Metering Infrastructure (AMI) systems enable the
measurement, configuration, and control of energy, gas and water
consumption and distribution, through two-way scheduled, on
exception, and on-demand communication. </t>
<t>
AMI networks are composed of millions of endpoints, including meters,
distribution automation elements, and eventually home area network devices.
They are typically inter-connected using some combination of wireless
and power-line communications, forming the so-called Neighbor Area Network (NAN)
along with a backhaul
network providing connectivity to "command-and-control" management
software applications at the utility company back office.
</t>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" />.
</t>
</section>
<section title="Required Reading">
<t>
<xref target="surveySG"/> gives an overview of Smart Grid architecture and
related applications. </t>
<t> NAN can use wireless communication technology in which case is using, from the IEEE 802.15.4 standard
family, the <xref target="IEEE802.15.4g"/> PHY Layer amendment and <xref target="IEEE802.15.4e"/> MAC sub-layer amendment, specifically
adapted to smart grid networks.</t>
<t> NAN can also use PLC (Power Line Communication) technology as an alternatve to wireless communications.
Several standards for PLC technology have emerged, such as <xref target="IEEE1901.2"/>. </t>
<t> NAN can further use a mix of wireless and PLC technologies to increase the network coverage ratio, a critical requirement for AMI networks.
</t>
</section>
<section title="Out of scope requirements">
<t>
The following are outside the scope of this document:
<list style="symbols">
<t> Applicability statement for RPL in AMI networks composed of battery-powered devices (i.e., gas/water meters).</t>
<t> Applicability statement for RPL in AMI networks composed of a mix of AC powered devices (i.e., electric meters) and battery-powered meters (i.e., gas/water meters).</t>
<t> Applicability statement for RPL storing (vs. non-storing) mode of operation in AMI networks.</t>
</list>
</t>
</section>
</section>
<section title="Routing Protocol for LLNs (RPL)">
<t>
RPL provides routing functionality for mesh networks that can scale
up to thousands of resource-constrained devices, interconnected by
low power and lossy links, and communicating with the external
network infrastructure through a common aggregation point(s) (e.g., a
LLN Border Router or LBR). </t>
<t>
RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at
a LBR (LLN Border Router), ensures loop-free routing, and provides support for
alternate routes, as well as, for a wide range of routing metrics and
policies.</t>
<t>
RPL was designed to operate in energy-constrained environments and
includes energy-saving mechanisms (e.g., Trickle timers) and energy-
aware metrics. RPL's ability to support multiple different metrics and
constraints at the same time enables it to run efficiently in
heterogeneous networks composed of nodes and links with vastly
different characteristics <xref target="RFC6551" />. </t>
<t>
This document describes the applicability of RPL non-storing mode (as defined in
<xref target="RFC6550" />) to AMI deployments. RPL was designed to meet
the following application requirements:
<list style="symbols">
<t>Routing Requirements for Urban Low-Power and Lossy Networks
<xref target="RFC5548"/>.
</t>
<t>Industrial Routing Requirements in Low-Power and Lossy Networks
<xref target="RFC5673" />.
</t>
<t>Home Automation Routing Requirements in Low-Power and Lossy Networks
<xref target="RFC5826" />.
</t>
<t> Building Automation Routing Requirements in Low-Power and Lossy Networks
<xref target="RFC5867" />.
</t>
</list>
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 <xref target="RFC7102"/>.
</t>
</section>
<section title="Description of AMI networks for electric meters">
<t>
In many deployments, in addition to measuring energy consumption, the
electric meter network plays a central role in the Smart Grid since
the device enables the utility company to control and query the electric
meters themselves and can serve as a backhaul for all
other devices in the Smart Grid, e.g., water and gas meters,
distribution automation and home area network devices. Electric
meters may also be used as sensors to monitor electric grid quality
and to support applications such as Electric Vehicle charging.</t>
<t>
Electric meter networks can be composed of millions of smart meters (or
nodes), each of which is resource-constrained in terms of processing
power, storage capabilities, and communication bandwidth, due to a combination of factors including regulations on spectrum use, and on meter behavior and performance, on heat emissions within the meter, form factor and cost considerations. These
constraints result in a compromise between range and throughput, with
effective link throughput of tens to a few hundred kilobits per
second per link, a potentially significant portion of which is taken
up by protocol and encryption overhead when strong security measures
are in place.</t>
<t>
Electric meters are often interconnected into multi-hop mesh
networks, each of which is connected to a backhaul network leading to
the utility company network through a network aggregation point,
e.g., an LBR.
</t>
<section title="Deployment Scenarios">
<t>
AMI networks are composed of millions of endpoints distributed across
both urban and rural environments. Such endpoints can include electric,
gas, and water meters, distribution automation elements, and home
area network devices. </t>
<t> Devices in the network communicate directly
with other devices in close proximity using a variety of low-power
and/or lossy link technologies that are both wireless and wired
(e.g., IEEE 802.15.4g, IEEE 802.15.4e, IEEE 1901.2, IEEE 802.11). In addition to
serving as sources and destinations of packets, many network elements
typically also forward packets and thus form a mesh topology.</t>
<t>
In a typical AMI deployment, groups of meters within physical
proximity form routing domains, each in the order of a 1,000 to
10,000 meters. Thus, each electric meter mesh typically has several
thousand wireless endpoints, with densities varying based on the area
and the terrain. </t>
<figure anchor="Meterarchi"
title="Typical NAN Topology">
<artwork><![CDATA[
|
+M
|
M M M M | M
/-----------\ /---+---+---+---+--+-+- phase 1
+----+ ( Internet ) +-----+ / M M M M
|MDMS|---( )----| LBR |/----+----+----+----+---- phase 2
+----+ ( WAN ) +-----+\
\----------/ \ M M M M
\--+--+----+-+---+----- phase 3
\ M M
+--+---+--
<----------------------------->
RPL
]]></artwork>
</figure>
<t>
A typical AMI network architecture (see figure <xref target="Meterarchi"/>)
is composed of a MDMS (Meter Data Management
System) connected through IP network to a LBR, which can be located in
the power substation or somewhere else in the field.
The power substation connects the households and
buildings. The physical topology of the electrical grid is a tree structure,
either due to the 3 different power phases coming through the sub-station or
just to the electrical network topology. Meters (represented by a M in the
previous figure) can also participate in a HAN (Home-Area Network). The scope
of this document is the communication between the LBR and the meters,
i.e. the NAN (Neighbor-Area Network) segment.
</t>
<t>
Node density can vary significantly. For example, apartment buildings in urban centers
may have hundreds of meters in close proximity, whereas rural areas
may have sparse node distributions and include nodes that only have a
small number of network neighbors.
Each routing domain is connected to the larger IP infrastructure
through one or more LBRs, which provide Wide Area Network (WAN)
connectivity through various traditional network technologies, e.g.,
Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in the mesh between a network
node and the nearest LBR may be composed of several hops or even
several tens of hops.
Powered from the main line, electric meters have less energy
constraints than battery powered devices, such as gas and water
meters, and can afford the additional resources required to route
packets.
</t>
<t>
As a function of the technology used to exchange information, the logical
network topology will not necessarily match the electric grid topology.
If meters exchange information through
radio technologies 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 through different substations.
If narrowband PLC technology is used, it will follow more or less the physical tree
structure since diaphony may allow one phase to communicate with the other.
This is particularly true near the LBR. Some mixed topology can also be
observed, since some LBRs may be strategically installed in the field to avoid all the
communications going through a single LBR.
Nethertheless, the short propagation range forces meters to
relay the information.
</t>
</section>
</section>
<section title="Smart Grid Traffic Description">
<section title="Smart Grid Traffic Characteristics">
<t>
In current AMI deployments, metering applications typically require
all smart meters to communicate with a few head-end servers, deployed
in the utility company data center.
Head-end servers generate data traffic to configure smart data reading
or initiate queries, and use unicast and multicast to
efficiently communicate with a single device (i.e. Point-to-Point (P2P) communications)
or groups of devices
respectively (i.e., Point-to-Multipoint (P2MP) communication). 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,
service switch command) or a series of large packets (e.g., a
firmware download across one or even thousands of devices). The
frequency of large file transfers, e.g., firmware download of all
metering devices, is typically much lower than the frequency of
sending configuration messages or queries.
Each smart meter generates Smart Metering Data (SMD) traffic
according to a schedule (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., power outage, leak detection). Such traffic
is typically destined to a single head-end server.
<!-- The bulk of the SMD traffic tends to be directed towards the LBR,
both in terms of bytes (since reports are typically much larger than
queries) and in terms of number of packets, e.g., some reports have
to be split into multiple packets due to packet size limitations,
periodic reports can be sent without requiring a query to be sent for
each one first, unsolicited events like alarms and outage
notifications are only generated by the meters and sent towards the
LBR. -->
The SMD traffic is thus highly asymmetric, where the majority
of the traffic volume generated by the smart 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 Peer)fashion.
Current SMD traffic patterns are fairly uniform and well-understood.
The traffic generated by the head-end server and destined to metering
devices is dominated by periodic meter reads, while traffic generated
by the metering devices is typically uniformly spread over some
periodic read time-window. </t>
<t>
Smart metering applications typically do not have hard real-time
constraints, but they are often subject to bounded latency and
stringent reliability service level agreements.
<!-- From a routing perspective, SMD applications require efficient P2MP
communication between the devices in the network and one or more
LBRs. In addition, timely loop resolution and broken link repair are
needed to meet latency requirements. Finally, the availability of
redundant paths is important for increasing network reliability. -->
</t>
<t>
Distribution Automation (DA) applications typically involve a small
number of devices that communicate with each other in a Point-to-
Point (P2P) fashion, and may or may not be in close physical
proximity. DA applications typically have more stringent latency
requirements than SMD applications.</t>
<t>
There are also a number of emerging applications such as electric
vehicle charging. These applications may require P2P communication
and may eventually have more stringent latency requirements than SMD
applications.
</t>
</section>
<section title="Smart Grid Traffic QoS Requirements">
<t>
As described previously, the two main traffic families in a NAN are:
<list style="hanging">
<t hangText="A)"> Meter-initiated traffic (Meter-to-head-end - M2HE)</t>
<t hangText="B)"> Head-end-initiated traffic (Head-end-to-meter - HE2M)
<list style="hanging">
<t hangText="B1)"> request is sent in point-to-point to a specific meter</t>
<t hangText="B2)"> request is sent in multicast to a subset of meters</t>
<t hangText="B3)"> request is sent in multicast to all meters</t>
</list></t>
</list>
The M2HE are event-based, while the HE2M are mostly command-response.
In most cases, M2HE traffic is more critical than HE2M one, but there can be exceptions.
</t>
<t> Regarding priority, traffic may also be decomposed into several classes :
<list style="hanging">
<t hangText="C1)">
Highly Priority Critical traffic for Power System Outage,
Pricing Events and Emergency Messages require a 98%+ packet
delivery under 5 s.
Payload size < 100 bytes</t>
<t hangText="C2)">
Critical Priority traffic Power Quality Events, Meter Service
Connection and Disconnection require 98%+ packet delivery under 10s.
Payload size < 150 bytes</t>
<t hangText="C3)">
Normal Priority traffic for System Events including Faults,
Configuration and Security require 98%+ packet delivery under 30s.
Payload size < 200 bytes</t>
<t hangText="C4)">
Low Priority traffic for Recurrent Meter Reading require 98%+
packet 2 hour delivery window 6 times per day.
Payload size < 400 bytes</t>
<t hangText="C5)">
Background Priority traffic for firmware/software updates
processed to 98%+ of devices within 7 days. Average firmware
update is 1 MB.
</t>
</list>
</t>
</section>
<section title="RPL applicability per Smart Grid Traffic Characteristics">
<t>RPL non-storing mode of operation naturally support upstream and
downstream forwarding of unicast traffic between the DODAG root and
each DODAG node, and between DODAG nodes and DODAG root,
respectively.</t>
<t>
Group communication model used in smart grid requires RPL non-storing
mode of operation to support downstream forwarding of multicast
traffic with a scope larger than link-local. The DODAG root is the
single device that injects multicast traffic, with a scope larger
than link-local, into the DODAG.</t>
</section>
</section>
<section title="Layer 2 applicability">
<section title="IEEE Wireless Technology">
<t>
IEEE Std. 802.15.4g and IEEE 802.15.4e amendments to 802.15.4
standard have been specifically developed for smart grid networks.
They are the most common PHY and MAC layers used for wireless AMI network. 802.15.4g
specifies multiple modes of operation (FSK, OQPSK and OFDM modulations) with speeds from
50kbps to 600kbps, and allows for transport of a full IPv6 packet (i.e., 1280 octets) without the need for upper layer segmentation and re-assembly. </t>
<t>
IEEE Std. 802.15.4e is an amendment to IEEE Std 802.15.4 that
specifies additional media access control (MAC) behaviors and frame
formats that allow IEEE 802.15.4 devices to support a wide range of
industrial and commercial applications that were not adequately
supported prior to the release of this amendment.
It is important to notice that 802.15.4e does not change the link-layer security scheme defined in the last two updates to 802.15.4 (e.g. 2006 and 2011 amendments).
</t>
</section>
<section title="IEEE PowerLine Communication (PLC) technology">
<t>
The IEEE Std. 1901.2 standard specifies communications for low frequency (less than
500 kHz) narrowband power line devices via alternating current and
direct current electric power lines. IEEE Std P1901.2 standard supports indoor
and outdoor communications over low voltage line (line between
transformer and meter, less than 1000 V), through transformer low-voltage to
medium-voltage (1000 V up to 72 kV) and through
transformer medium-voltage to low-voltage power lines in both urban
and in long distance (multi- kilometer) rural communications. </t>
<t>
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 802.15.4 and 802.15.4e MAC sub-layer features. </t>
<t>
IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps depending on the application requirements and type of encoding used.</t>
<t>
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 re-assembly.</t>
<t>
IEEE Std. 1901.2 specifies the necessary link-layer security features that fully endorse 802.15.4 MAC sub-layer security scheme.
</t>
</section>
</section>
<section title="Using RPL to Meet Functional Requirements ">
<t>
The functional requirements for most AMI deployments are similar to
those listed in <xref target="RFC5548" />. This section informallly highlights
some of the similarities:
<list style="symbols">
<t>The routing protocol MUST be capable of supporting the
organization of a large number of nodes into regions containing on
the order of 10^2 to 10^4 nodes each.</t>
<t>The routing protocol MUST provide mechanisms to support
configuration of the routing protocol itself.</t>
<t>The routing protocol SHOULD support and utilize the large number
of highly directed flows to a few head-end servers to handle
scalability.</t>
<t>The routing protocol MUST dynamically compute and select effective
routes composed of low-power and lossy links. Local network
dynamics SHOULD NOT impact the entire network. The routing
protocol MUST compute multiple paths when possible.</t>
<t>The routing protocol MUST support multicast and unicast
addressing. The routing protocol SHOULD support formation and
identification of groups of field devices in the network.</t>
</list>
RPL supports the following features:
<list style="symbols">
<t>Scalability: Large-scale networks characterized by highly directed traffic
flows between each smart meter and the head-end servers in the
utility network. To this end, RPL builds a Directed Acyclic Graph
(DAG) rooted at each LBR.</t>
<t>Zero-touch configuration: This is done through in-band methods
for configuring RPL variables using DIO messages, and DIO message options
<xref target="RFC6550" />.</t>
<t> The use of links with time-varying quality characteristics: This
is accomplished by allowing the use of metrics that effectively
capture the quality of a path (e.g., Expected Transmission Count
(ETX)) and by limiting the impact of changing local conditions by
discovering and maintaining multiple DAG parents, and by using
local repair mechanisms when DAG links break.</t>
</list>
</t>
</section>
<section title="RPL Profile">
<section title="RPL Features ">
<section title="RPL Instances ">
<t>
RPL operation is defined for a single RPL instance. However,
multiple RPL instances can be supported in multi-service networks
where different applications may require the use of different routing
metrics and constraints, e.g., a network carrying both SDM and DA
traffic.
</t>
</section>
<section title="Storing vs. Non-Storing Mode">
<t>
In most scenarios, electric meters are powered by the grid they are
monitoring and are not energy-constrained. Instead, electric meters
have hardware and communication capacity constraints that are
primarily determined by cost, and secondarily by power consumption.
As a result, different AMI deployments can vary significantly in
terms of memory size, computation power and communication
capabilities. For this reason, the use of RPL non-storing
mode SHOULD be deployment specific.
When meters are memory constrained and cannot adequately store the
route tables necessary to support hop-by-hop routing, RPL non-storing
mode SHOULD be preferred. On the other hand, when nodes are capable
of storing such routing tables, the use of storing mode may lead to
reduced overhead and route repair latency. However, in high-density
environments, storing routes can be challenging because some nodes
may have to maintain routing information for a large number of
descendents. In this document, we only focus on non-storing mode of operation.
</t>
</section>
<section title="DAO Policy">
<t>
Two-way communication is a requirement in AMI systems. As a result,
nodes SHOULD send DAO messages to establish downward paths from the
root to themselves.
</t>
</section>
<section title="Path Metrics ">
<t>
Smart metering deployments utilize link technologies that may exhibit
significant packet loss and thus require routing metrics that take
packet loss into account. To characterize a path over such link
technologies, AMI deployments can use the Expected Transmission Count
(ETX) metric as defined in <xref target="RFC6551" />.
</t><t>
Additional metrics may be defined in companion RFCs.
</t>
</section>
<section title="Objective Function ">
<t>
RPL relies on an Objective Function for selecting parents and
computing path costs and rank. This objective function is decoupled
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
time of this writing, OF0 <xref target="RFC6552"/> and MRHOF <xref target="RFC6719"/>,
both of which define the
selection of a preferred parent and backup parents, and are suitable
for AMI deployments.
</t><t>
Additional objective functions may be defined in companion RFCs.
</t>
</section>
<section title="DODAG Repair ">
<t>
To effectively handle time-varying link characteristics and
availability, AMI deployments SHOULD utilize the local repair
mechanisms in RPL.
Local repair is triggered by broken link detection.
The first local repair mechanism consists of a node 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 an infinite rank value
so that its children can select a different parent. This process is
known as poisoning and is described in Section 8.2.2.5 of
<xref target="RFC6550" />. While RPL provides an option to form a local
DODAG, doing so in AMI for electric meters is of little benefit since AMI
applications typically communicate through a LBR. After the detached
node has made sufficient effort to send notification to its children
that it is detached, the node can rejoin the same DODAG with a higher
rank value. The configured duration of the poisoning mechanism needs
to take into account the disconnection time applications running over
the network can tolerate. Note that when joining a different DODAG,
the node need not perform poisoning.
The second local repair mechanism controls how much a node can
increase 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 DAGMaxRankIncrease to a non-zero value enables this
mechanism, and setting it to a value of less than infinity limits the
cost of count-to-infinity scenarios when they occur, thus controlling
the duration of disconnection applications may experience.
</t>
</section>
<section title="Multicast ">
<t>
Multicast support for RPL in non-storing mode are being developed in
companion RFCs (see <xref target="I-D.ietf-roll-trickle-mcast"/>).
</t>
</section>
<section title="Security ">
<t>
AMI deployments operate in areas that do not provide any physical
security. For this reason, the link layer, transport layer and
application layer technologies utilized within AMI networks typically
provide security mechanisms to ensure authentication,
confidentiality, integrity, and freshness. As a result, AMI
deployments may not need to implement RPL's security mechanisms and
could rely on link layer and higher layer security features.
</t>
</section>
<section title="Peer-to-Peer communications ">
<t>
Basic peer-to-peer capabilities are already defined in the RPL
<xref target="RFC6550" />. Additional mechanisms for peer-to-peer communications are
proposed in companion RFCs (see <xref target="RFC6997" />).
</t>
</section>
</section>
<section title="Description of Layer-two features">
<section title="IEEE 1901.2 PHY and MAC sub-layer features">
<t>
The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and defines
a time frequency interleaver over the entire
PHY frame coupled with a Reed Solomon and Viterbi Forward Error
Correction for maximum robustness. Since the noise level in each OFDM sub-carrier
can vary significantly, IEEE 1901.2 specifies two complementary
mechanisms allowing to fine-tune the robustness/performance tradeoff
implicit in such systems. More specifically, the first (coarse-grained)
mechanism, defines the modulation from several possible choices
(robust (super-ROBO, ROBO), BPSK, QPSK,...). The second (fine-grained) maps the
sub-carriers which are too noisy and deactivates them.
</t>
<t>
The existence of multiple modulations and dynamic frequency exclusion
renders the problem of selecting a path between two nodes non-trivial,
as the possible number of combinations increases significantly, e.g.
use a direct link with slow robust modulation, or use a relay meter
with fast modulation and 12 disabled sub-carriers. In addition,
IEEE 1901.2 technology offers a mechanism (adaptive tone map) for
periodic exchanges on the link quality between nodes to constantly
react to channel fluctuations. Every meter keeps a state of the
quality of the link to each of its neighbors by either piggybacking
the tone mapping on the data traffic, or by sending explicit tone map requests.
</t>
<t>
IEEE 1901.2 MAC frame format shares most in common with the IEEE
802.15.4 MAC frame format [IEEE802.15.4], with a few exceptions
described below. </t>
<t> <list style="symbols">
<t> IEEE 1901.2 MAC frame is obtained by prepending a Segment Control
Field to the IEEE 802.15.4 MAC header. One function of the
Segment Control Field is to signal the use of the MAC sub-layer
segmentation and reassembly. </t>
<t> IEEE 1901.2 MAC frames uses only the 802.15.4 MAC addresses with a
length of 16 and 64 bits. </t>
<t> IEEE 1901.2 MAC sub-layer endorses the concept of Information
Elements, as defined in <xref target="IEEE802.15.4e" />. The
format and use of Information Elements are not relevant to RPL
applicability statement. </t>
</list></t>
<t>
The IEEE 1901.2 PHY frame payload size varies as a function of the
modulation used to transmit the frame and the strength of the Forward
Error Correction scheme.</t>
<t>
The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY settings in use (e.g.
bandwidth, modulation, tones, etc). As quoted from the IEEE 1901.2 specification:
For CENELEC A/B, if MSDU size is more than 247 octets for robust OFDM (ROBO) and Super-ROBO modulations or more than 239 octets for all other modulations, the MAC layer shall divide the MSDU into
multiple segments as described in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the following conditions:
a) For ROBO and Super-ROBO modulations, the MSDU size is more than 247 octets but less than 494 octets,
b) For all other modulations, the MSDU size is more than 239 octets but less than 478 octets.</t>
</section>
<section title="IEEE 802.15.4 (g + e) PHY and MAC features">
<t>
IEEE Std 802.15.4g defines multiple modes of operation, where each
mode uses different modulation and has multiple data rates.
Additionally, 802.15.4g PHY layer includes mechanisms to improve the
robustness of the radio communications, such as data whitening and
Forward Error Correction coding. The 802.15.4g PHY frame payload can
carry up to 2048 octets. </t>
<t>
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-
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
and from 6.25 to 500kbps for MR-O-QPSK.</t>
<t>
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
operation. These include: Timetimeslotslotted channel hopping
(TSCH), specifically designed for application domains such as process
automation, Low latency deterministic networks (LLDN), for
application domains such as factory automation, Deterministic and
synchronous multi-channel extension (DSME), for general industrial
and commercial application domains that includes Channel diversity to
increase network robustness, and Asynchronous multi-channel
adaptation (AMCA), for large infrastructure application domains.</t>
<t>
The MAC addressing scheme supports short (16-bits) addresses along
with extended (64-bits) addresses. These addresses are assigned in different ways
and is specified by specific standards organizations.</t>
<t>
Information Elements, Enhanced Beacons and frame version 2, as
defined in 802.15.4e, MUST be supported.</t>
<t>
Since the MAC frame payload size limitation is given by the 4g PHY
frame payload size limitation (i.e.,2048 bytes) and MAC layer
overhead (headers, trailers, Information Elements and security
overhead), the MAC frame payload MUST able to carry a full IPv6
packet of 1280 octets without upper layer fragmentation and re-
assembly.</t>
</section>
<section title="IEEE MAC sub-layer Security Features">
<t>
Since IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer and
fully endorses the security scheme defined in 802.15.4, we only focus
on description of IEEE 802.15.4 security scheme.
</t>
<t>
The IEEE 802.15.4 specification was designed to support a variety of applications, many of
which are security sensitive. The IEEE 802.15.4 provides four basic security services: message authentication,
message integrity, message confidentiality, and freshness checks to avoid replay attacks.
</t>
<t>
The 802.15.4 security layer is handled at the media access control layer,
below 6LowPAN layer. The application specifies its security requirements
by setting the appropriate control parameters into the radio/PLC stack.
The 802.15.4 defines four packet types: beacon frames, data frames,
acknowledgments frame, and command frames for the media access control layer.
The 802.15.4 specification does not support security for acknowledgement frames; data
frames, beacon frames and command frames can support integrity protection and confidentiality
protection for the frames's data field.
An application has a choice of security suites that control the type of security
protection that is provided for the transmitted MAC frame. Each security suite offers
a different set of security properties and guarantees, and ultimately different
MAC frame formats. The 802.15.4 specification defines eight different security suites,
outlined bellow. We can broadly classify the suites by the properties that they
offer: no security, encryption only (AES-CTR), authentication only (AES-CBC-MAC),
and encryption and authentication (AES-CCM). Each category that supports
authentication comes in three variants depending on the size of the
MAC (Message Authentication Control) 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.
<list style="symbols">
<t>
Null = No security.
</t>
<t>
AES-CTR = Encryption only, CTR mode.
</t>
<t>
AES-CBC-MAC-128 = No encryption, 128-bit MAC.
</t>
<t>
AES-CBC-MAC-64 = No encryption, 64-bit MAC.
</t>
<t>
AES-CCM-128 = Encryption and 128-bit MAC.
</t>
<t>
AES-CCM-64 = Encryption and 64-bit MAC.
</t>
<t>
AES-CCM-32 = Encryption and 32-bit MAC.
</t>
</list>
</t>
<t> Note that AES-CCM-32 is the most commonly used cipher in these deployments today.</t>
<t>
To achieve authentication, any device can maintain an Access Control List (ACL)
which is a list of trusted nodes from which the device wishes to receive data. Data
encryption is done by encryption of Message Authentication Control (MAC) frame
payload using the key shared between two devices, or among a group of
peers. If the key is to be shared between two peers, it is stored with each entry in the
ACL list; otherwise, the key is stored as the default key. Thus, the device can make
sure that its data can not be read by devices that do not possess the corresponding
key. However, device addresses are always transmitted unencrypted, which makes
attacks that rely on device identity somewhat easier to launch. Integrity service
is applied by appending a Message Integrity Code (MIC) generated from blocks of
encrypted message text. This ensures that a frame can not be modified by a receiver
device that does not share a key with the sender. Finally, sequential freshness uses
a frame counter and key sequence counter to ensure the freshness of the incoming
frame and guard against replay attacks.
</t>
<t>
A cryptographic MAC is used to authenticate messages. While longer MACs lead
to improved resiliency of the code, they also make packet size larger and thus take
up bandwidth in the network. In constrained environments such as metering infrastructures, an optimum balance
between security requirements and network throughput must be found.
</t>
</section>
</section>
<section title="6LowPAN Options">
<t>
AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all
of the IPv6 Header Compression schemes specified in <xref target="RFC6282"/>
Section 3 and all of the IPv6 Next Header compression schemes
specified in <xref target="RFC6282"/> Section 4, if reducing over the air/wire
overhead is a requirement.
<!-- However, since the link-layer MTU in both
wireless and PLC links supports the transmission of a full IPv6
packet, the use of 6LowPAN fragmentation is NOT RECOMMENDED.
-->
</t>
</section>
<section title="Recommended Configuration Defaults and Ranges">
<section title="Trickle Parameters ">
<t>
Trickle was designed to be density-aware and perform well in networks
characterized by a wide range of node densities. The combination of
DIO packet suppression and adaptive timers for sending updates allows
Trickle to perform well in both sparse and dense environments.
Node densities in AMI deployments can vary greatly, from nodes having
only one or a handful of neighbors to nodes having several hundred
neighbors. In high density environments, relatively low values for
Imin may cause a short period of congestion when an inconsistency is
detected and DIO updates are sent by a large number of neighboring
nodes nearly simultaneously. While the Trickle timer will
exponentially backoff, some time may elapse before the congestion
subsides. While some link layers employ contention mechanisms that
attempt to avoid congestion, relying solely on the link layer to
avoid congestion caused by a large number of DIO updates can result
in increased communication latency for other control and data traffic
in the network.
To mitigate this kind of short-term congestion, this document
recommends a more conservative set of values for the Trickle
parameters than those specified in [RFC6206]. In particular,
DIOIntervalMin is set to a larger value to avoid periods of
congestion in dense environments, and DIORedundancyConstant is
parameterized accordingly as described below. These values are
appropriate for the timely distribution of DIO updates in both sparse
and dense scenarios while avoiding the short-term congestion that
might arise in dense scenarios.
Because the actual link capacity depends on the particular link
technology used within an AMI deployment, the Trickle parameters are
specified in terms of the link's maximum capacity for transmitting
link-local multicast messages. If the link can transmit m link-local
multicast packets per second on average, the expected time it takes
to transmit a link-local multicast packet is 1/m seconds.
<list style="hanging">
<t hangText="DIOIntervalMin:"> AMI deployments SHOULD set DIOIntervalMin such that
the Trickle Imin is at least 50 times as long as it takes to
transmit a link-local multicast packet. This value is larger than
that recommended in <xref target="RFC6206" /> to avoid congestion in dense urban
deployments as described above.</t>
<t hangText="DIOIntervalDoublings:"> AMI deployments SHOULD set
DIOIntervalDoublings such that the Trickle Imax is at least 2
hours or more. </t>
<t hangText="DIORedundancyConstant:"> AMI deployments SHOULD set
DIORedundancyConstant to a value of at least 10. This is due to
the larger chosen value for DIOIntervalMin and the proportional
relationship between Imin and k suggested in [RFC6206]. This
increase is intended to compensate for the increased communication
latency of DIO updates caused by the increase in the
DIOIntervalMin value, though the proportional relationship between
Imin and k suggested in <xref target="RFC6206" /> is not preserved. Instead,
DIORedundancyConstant is set to a lower value in order to reduce
the number of packet transmissions in dense environments. </t>
</list>
</t>
</section>
<section title="Other Parameters ">
<t>
<list style="symbols">
<t>AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in
8 bits of resolution (e.g., for the ETX metric).</t>
<t>To enable local repair, AMI deployments SHOULD set MaxRankIncrease
to a value that allows a device to move a small number of hops
away from the root. With a MinHopRankIncrease of 256, a
MaxRankIncrease of 1024 would allow a device to move up to 4 hops
away.</t>
</list>
</t>
</section>
</section>
</section>
<section title="Manageability Considerations">
<t>
Network manageability is a critical aspect of smart grid network
deployment and operation. With millions of devices participating in
the smart grid network, many requiring real-time reachability,
automatic configuration, and lightweight network health monitoring
and management are crucial for achieving network availability and
efficient operation.
RPL enables automatic and consistent configuration of RPL routers
through parameters specified by the DODAG root and disseminated
through DIO packets. The use of Trickle for scheduling DIO
transmissions ensures lightweight yet timely propagation of important
network and parameter updates and allows network operators to choose
the trade-off point they are comfortable with respect to overhead vs.
reliability and timeliness of network updates.
The metrics in use in the network along with the Trickle Timer
parameters used to control the frequency and redundancy of network
updates can be dynamically varied by the root during the lifetime of
the network. To that end, all DIO messages SHOULD contain a Metric
Container option for disseminating the metrics and metric values used
for DODAG setup. In addition, DIO messages SHOULD contain a DODAG
Configuration option for disseminating the Trickle Timer parameters
throughout the network.
The possibility of dynamically updating the metrics in use in the
network as well as the frequency of network updates allows deployment
characteristics (e.g., network density) to be discovered during
network bring-up and to be used to tailor network parameters once the
network is operational rather than having to rely on precise pre-
configuration. This also allows the network parameters and the
overall routing protocol behavior to evolve during the lifetime of
the network.
RPL specifies a number of variables and events that can be tracked
for purposes of network fault and performance monitoring of RPL
routers. Depending on the memory and processing capabilities of each
smart grid device, various subsets of these can be employed in the
field.
</t>
</section>
<section title="Security Considerations ">
<t>
Smart grid networks are subject to stringent security requirements as
they are considered a critical infrastructure component. At the same
time, since they are composed of large numbers of resource-
constrained devices inter-connected with limited-throughput links,
many available security mechanisms are not practical for use in such
networks. As a result, the choice of security mechanisms is highly
dependent on the device and network capabilities characterizing a
particular deployment. </t>
<t>
In contrast to other types of LLNs, in smart grid networks
centralized administrative control and access to a permanent secure
infrastructure is available. As a result, smart grid networks are deployed
with security mechanisms such as link-layer, transport layer and/or application-layer
security mechanisms; while it is best practice to secure all layers, using RPL's
secure mode may not be necessary. Failure to protect any of these layers can
result in various attacks; without strong authentication of devices in the infrastructure
can lead to uncontrolled and unauthorized access. Similarly, failure to protect the
communication layers can enable passive (in wireless mediums) attacks as well as
man-in-the-middle and active attacks.
</t>
<t>
As this document describes the applicability of RPL non-storing mode, the
security considerations as defined in
<xref target="RFC6550" /> also applies to this document and to AMI deployments.
</t>
<section title="Security Considerations during initial deployment">
<t>
During the manufacturing process, the meters are loaded with the
appropriate security credentials (keys, certificates). These
security credentials are unique per device and only known by the
device itself and the head-end security appliances. The
manufacturing security credentials are then used by the devices to
authenticate with the system and negotiate operational security
credentials, for both network and application layers.
</t>
</section>
<section title="Security Considerations during incremental deployment ">
<t>
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
security identity of the replaced device. The security credentials
associated with the failed/compromised device are removed from the
security appliances.
</t>
</section>
<section title="Security Considerations based on RPL's Threat Analysis">
<t>
<xref target="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 <xref target="RFC7416" />.
</t>
<t>
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. Known schemes </t>
<t> 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. </t>
<t> To provide
the security mechanisms to address these threats, an AMI 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 security mechanisms to afford mutual authentication, access control (e.g. authorization) and transport confidentiality and integrity. The credential management
is afforded through the use of already existing identity management solutions.</t>
</section>
</section>
<!--
<section title="Other Related Protocols">
<t> This section is intentionally left blank.
</t> </section>
-->
<section title="IANA Considerations">
<t> This memo includes no request to IANA. </t>
</section>
<section title="Acknowledgements">
<t>
Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden were contributors
and noted as authors in earlier drafts.
The authors would also like to acknowledge the review, feedback, and
comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi
Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP Vasseur.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<!--
&I-D.ietf-roll-terminology;
&I-D.ietf-roll-trickle-mcast;
-->
</references>
<references title="Informative references">
<?rfc include="reference.RFC.5673" ?>
<?rfc include="reference.RFC.5867" ?>
<?rfc include="reference.RFC.5826" ?>
<?rfc include="reference.RFC.7102" ?>
<?rfc include="reference.RFC.6997" ?>
<reference anchor="surveySG">
<front>
<title>A Survey on Smart Grid Potential Applications and Communication Requirements</title>
<author initials ="V" surname = "Gungor"> </author>
<author initials ="D" surname = "Sahin"> </author>
<author initials ="T" surname = "Kocak"> </author>
<author initials ="S" surname = "Ergut"> </author>
<author initials ="C" surname = "Buccella"> </author>
<author initials ="C" surname = "Cecati"> </author>
<author initials ="G.P" surname = "Hancke"> </author>
<date month='Feb' year='2013'></date>
</front>
</reference>
<reference anchor="IEEE802.15.4">
<front>
<title>IEEE Standard for Information technology-- Local
and metropolitan area networks-- Specific requirements--
Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low Rate Wireless
Personal Area Networks (WPANs)
</title>
<author>
<organization/>
</author>
<date month='September' year='2006'></date>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4" />
</reference>
<reference anchor="IEEE802.15.4e">
<front>
<title>IEEE Standard for Local and metropolitan area
networks--Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer
</title>
<author>
<organization/>
</author>
<date month='April' year='2012'></date>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4e" />
</reference>
<reference anchor="IEEE802.15.4g">
<front>
<title>IEEE Standard for Local and metropolitan area
networks--Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 3: Physical Layer (PHY) Specifications
for Low-Data-Rate, Wireless, Smart Metering Utility Networks
</title>
<author>
<organization/>
</author>
<date month='November' year='2012'></date>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4g" />
</reference>
<reference anchor="IEEE1901.2">
<front>
<title>IEEE Standard for Low-Frequency (less than 500
kHz) Narrowband Power Line Communications for Smart Grid
Applications
</title>
<author>
<organization/>
</author>
<date month='December' year='2013'></date>
</front>
<seriesInfo name="IEEE" value="Standard 1901.2" />
</reference>
<?rfc include="reference.RFC.5548" ?>
<?rfc include="reference.RFC.6206" ?>
<?rfc include="reference.RFC.6550" ?>
<?rfc include="reference.RFC.6551" ?>
<?rfc include="reference.RFC.6719" ?>
<?rfc include="reference.RFC.6552" ?>
<?rfc include="reference.RFC.6282" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-trickle-mcast.xml" ?>
<?rfc include="reference.RFC.7416" ?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 21:40:33 |