One document matched: draft-ietf-roll-applicability-ami-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5548 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5548.xml">
<!ENTITY RFC5673 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5673.xml">
<!ENTITY RFC5826 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5826.xml">
<!ENTITY RFC5867 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5867.xml">
<!ENTITY RFC6206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6206.xml">
<!ENTITY I-D.ietf-6man-rpl-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rpl-option.xml">
<!ENTITY I-D.ietf-roll-rpl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-rpl.xml">
<!ENTITY I-D.ietf-roll-routing-metrics SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-routing-metrics.xml">
<!ENTITY I-D.ietf-roll-p2p-rpl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-p2p-rpl.xml">
<!ENTITY I-D.ietf-roll-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-terminology.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-roll-applicability-ami-03"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="RPL Applicability for AMI">Applicability Statement for the
Routing Protocol for Low Power and Lossy Networks (RPL) in AMI
Networks</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Daniel Popa" initials="D.P." surname="Popa">
<organization>Itron</organization>
<address>
<postal>
<street>52 Rue Camille Desmoulins</street>
<city>92448 Issy les Moulineaux</city>
<country>France</country>
</postal>
<email>daniel.popa@itron.com</email>
</address>
</author>
<author fullname="Jorjeta Jetcheva" initials="J.J." surname="Jetcheva">
<organization>Itron</organization>
<address>
<postal>
<street>2111 N Molter Rd.</street>
<city>Liberty Lake</city>
<region>WA 99019</region>
<country>USA</country>
</postal>
<email>jorjeta.jetcheva@itron.com</email>
</address>
</author>
<author fullname="Nicolas Dejean" initials="N.D." surname="Dejean">
<organization>Elster SAS</organization>
<address>
<postal>
<street>Espace Concorde, 120 impasse JB Say</street>
<region>Perols, 34470</region>
<country>France</country>
</postal>
<email>nicolas.dejean@coronis.com</email>
</address>
</author>
<author fullname="Ruben Salazar" initials="R.S." surname="Salazar">
<organization>Landis+Gyr</organization>
<address>
<postal>
<street>30000 Mill Creek Ave # 100</street>
<city>Alpharetta</city>
<region>GA</region>
<code>30022</code>
</postal>
<email>ruben.salazar@landisgyr.com</email>
</address>
</author>
<author fullname="Jonathan W. Hui" initials="J.H." surname="Hui">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+408 424 1547</phone>
<email>jonhui@cisco.com</email>
</address>
</author>
<date year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing Area</area>
<workgroup>ROLL</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<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 home area network devices. They
are typically inter-connected using some combination of wireless
technologies and power-line communications, along with a backhaul
network providing connectivity to "command-and-control" management
software applications at the utility company back office.</t>
<section title="Electric Metering">
<t>In many deployments, in addition to measuring energy consumption,
the electric meter network plays a central role in the Smart Grid
since it enables the utility company to control and query the electric
meters themselves and also since it can serve as a backhaul for all
other devices in the Smart Grid, e.g., water and gas meters,
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 are 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 Federal Communications
Commission (FCC) or other continents' regulations on spectrum use,
American National Standards Institute (ANSI) standards or other
continents' regulation 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 (LLN Border Router).</t>
</section>
<section title="Gas and Water Metering">
<t>While electric meters typically consume electricity from the same
electric feed that they are monitoring, gas and water meters typically
run on a modest source of stored energy (e.g., batteries).</t>
<t>In some scenarios, gas and water meters are integrated into the
same AMI network as the electric meters and may operate as network
endpoints (rather than routers) in order to prolong their own
lifetime. In other scenarios, however, such meters may not have the
luxury of relying on a fully powered AMI routing infrastructure but
must communicate through a dedicated infrastructure to reach a LBR.
This infrastructure can be either powered by the electricity grid, by
battery-based devices, or ones relying on alternative sources of
energy (e.g., solar power).</t>
</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
LBR).</t>
<t>RPL builds a Directed Acyclic Graph (DAG) routing structure rooted
at the LBR, 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 desgined to operate in energy-constrained environments and
includes energy-saving mechanisms (e.g., Trickle timers) and
energy-aware metrics. Its ability to support multiple different
metrics and constraints at the same time enables it to run efficiently
in heterogeneous networks composed of nodes and links with vastly
different characteristics<xref
target="I-D.ietf-roll-routing-metrics"></xref>.</t>
<t>This note describes the applicability of RPL (as defined in <xref
target="I-D.ietf-roll-rpl"></xref>) 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"></xref>.</t>
<t>Industrial Routing Requirements in Low-Power and Lossy Networks
<xref target="RFC5673"></xref>.</t>
<t>Home Automation Routing Requirements in Low-Power and Lossy
Networks <xref target="RFC5826"></xref>.</t>
<t>Building Automation Routing Requirements in Low-Power and Lossy
Networks <xref target="RFC5867"></xref>.</t>
</list> The Routing Requirements for Urban Low-Power and Lossy
Networks are applicable to AMI networks as well.</t>
<t>The terminology used in this document is defined in <xref
target="I-D.ietf-roll-terminology"></xref>.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Deployment Scenarios">
<section title="Network Topology">
<t>AMI networks are composed of millions of endpoints distributed
across both urban and rural environments. Such endpoints include
electric, gas, and water meters, distribution automation elements, and
home area network devices. 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 wired and wireless (e.g.,
IEEE 802.15.4, IEEE P1901.2, and 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>
<section title="Electric Meter Network">
<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. 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.</t>
<t>Each routing domain is connected to the larger IP infrastructure
through one or more LBRs, which provide Wide Area Network (WAN)
connectivity through various traditional network technologies, e.g.,
Ethernet, cellular, private WAN. Paths in the mesh between a network
node and the nearest LBR may be composed of several hops or even
several tens of hops.</t>
<t>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. In mixed environments, electric meters can provide the
routing topology while gas and water meters can operate as leaf
nodes.</t>
<t>Electric meter networks may also serve as transit networks for
other types of devices, including distribution automation elements
(e.g., sensors and actuators), and in-home devices. These other
devices may utilize a different link-layer technology than the one
used in the meter network.</t>
<t>The routing protocol operating in networks with the topology
characteristics described above needs to be able to scale with
network size and number of forwarding hops, and have the ability to
handle a wide range of network densities.</t>
</section>
<section title="Energy-Constrained Network Infrastructure">
<t>In the absence of a co-located electric meter network, gas and
water meters must either connect directly to the larger IP network
infrastructure or rely on a dedicated routing infrastructure.
Deploying such infrastructures is a challenging task as the routing
devices can sometimes only be placed in specific locations and thus
do not always have access to a continous energy source.
Battery-operated or energy-harvesting (e.g., equipped with solar
panels) routers are thus often used in these kinds of scenarios.</t>
<t>Due to the expected lifetime (10 to 20 years) of such networks
and their reliance on alternative sources of energy, energy
consumption needs to be taken into account when designing and
deploying them. There are a number of challenging trade-offs and
considerations that exist in that respect. One such consideration is
that managing a higher number of meters per router leads to
increased energy consumption. However, increasing the number of
routers in the network and thus reducing the number of meters
managed by each router increases deployment and maintenance costs.
At the same time, the use of a sparser routing infrastructure
necessitates the use of higher transmit power levels at nodes in the
network, which causes increased energy consumption.</t>
<t>The deployment and operational needs of energy-constrained
network infrastructure require the use of routing mechanisms that
take into account energy consumption, minimize energy use and
prolong network lifetime.</t>
</section>
</section>
<section title="Traffic Characteristics">
<section title="Smart Metering Data">
<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.</t>
<t>Head-end servers generate data traffic to configure smart
metering devices or initiate queries, and use unicast and multicast
to efficiently communicate with a single device 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) or
a series of large packets (e.g., a firmware upgrade across one or
even thousands of devices). The frequency of large file transfers,
e.g., firmware upgrade of all metering devices, is typically much
lower than the frequency of sending configuration messages or
queries.</t>
<t>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. </t>
<t>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 Multipoint-to-Point (MP2P) fashion.</t>
<t>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.</t>
<t>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>
</section>
<section title="Distribution Automation Communication">
<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.</t>
<t>DA applications typically have more stringent latency
requirements than SMD applications.</t>
</section>
<section title="Emerging Applications">
<t>There are 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>
</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"></xref>:<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 anycast
addressing. The routing protocol SHOULD support formation and
identification of groups of field devices in the network.</t>
</list></t>
<t>RPL supports: <list style="symbols">
<t>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.</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">
<t>This section outlines a RPL profile for a representative AMI
deployment.</t>
<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 electric
grid they are monitoring and are not energy-constrained. Instead,
the capabilities of an electric meter are primarily determined by
cost. As a result, different AMI deployments can vary significantly
in terms of the memory, computation, and communication trade-offs
they embody. For this reason, the use of RPL storing or non-storing
mode SHOULD be deployment specific.</t>
<t>For example, when meters are memory constrained and cannot
adequately store the route tables necessary to support downward
routing in a typical deployment, non-storing mode is preferred. When
nodes are capable of storing such routing tables, storing mode may
lead to reduced overhead and route repair latency.</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="I-D.ietf-roll-routing-metrics"></xref>.</t>
<t>For water- and gas-only networks that do not rely on powered
infrastructure, simpler metrics that require less energy to compute
would be more appropriate. In particular, a combination of hop count
and link quality can satisfy this requirement. As minimizing energy
consumption is critical in these types of networks, available node
energy should also be used in conjunction with these two metrics.
The usage of additional metrics specifically designed for such
networks 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 and MRHOF, both of which define the
selection of a preferred parent and backup parents, and are suitable
for AMI deployments.</t>
<t>Neither of the currently defined objective functions supports
multiple metrics that might be required in heterogeneous networks
(e.g., networks composed of devices with different energy
constraints) or combination of metrics that might be required for
water- and gas-only networks. Additional objective functions
specifically designed for such networks 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.</t>
<t>Local repair is triggered by broken link detection and in storing
mode by loop detection as well.</t>
<t>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="I-D.ietf-roll-rpl"></xref>. While RPL provides an
option to form a local DODAG, doing so in AMI deployments is of
little benefit since AMI applications typically communicate through
a LBR. After the detached node has made sufficient effort to send
notification to its children that it is detached, the node can
rejoin the same DODAG with a higher rank value. The configured
duration of the poisoning mechanism needs to take into account the
disconnection time applications running over the network can
tolerate. Note that when joining a different DODAG, the node need
not perform poisoning.</t>
<t>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>RPL defines multicast support for its storing mode of operation,
where the DODAG structure built for unicast packet dissemination is
used for multicast distribution as well. In particular, multicast
forwarding state creation is done through DAO messages with
multicast target options sent along the DODAG towards the root.
Thereafter nodes with forwarding state for a particular group
forward multicast packets along the DODAG by copying them to all
children from which they have received a DAO with a multicast target
option for the group.</t>
<t>Multicast support for RPL in non-storing mode will be defined in
companion RFCs.</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="P2P communications">
<t>Distribution Automation and other emerging applications may
require efficient P2P communications. Basic P2P capabilities are
already defined in the RPL RFC <xref
target="I-D.ietf-roll-rpl"></xref>. Additional mechanisms for
efficient P2P communication are being developed in companion
RFCs.</t>
</section>
</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.</t>
<t>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.</t>
<t>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 <xref target="RFC6206"></xref>.
In particular, DIOIntervalMin is set to a larger value to avoid
periods of congestion in dense environments, and
DIORefundancyConstant is parameterized accordingly as described
below. These values are appropriate for the timely distribution of
DIO updates in both sparse and dense scenarios while avoiding the
short-term congestion that might arise in dense scenarios.</t>
<t>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"></xref> to avoid congestion in dense urban
deployments as described above. In energy-constrained
deployments (e.g., in water and gas battery-based routing
infrastructure), DIOIntervalMin MAY be set to a value resulting
in a Trickle Imin of several (e.g. 2) hours.</t>
<t hangText="DIOIntervalDoublings:">AMI deployments SHOULD set
DIOIntervalDoublings such that the Trickle Imax is at least 2
hours or more. For very energy constrained deployments (e.g.,
water and gas battery-based routing infrastructure),
DIOIntervalDoublings MAY be set to a value resulting in a
Trickle Imax of several (e.g., 2) days.</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 <xref
target="RFC6206"></xref>. 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"></xref> 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 link-layer, transport-layer
and/or application-layer security mechanisms are typically in place and
using RPL’s secure mode is not necessary.</t>
</section>
<section title="Other Related Protocols">
<t>This document contains no other related protocols.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to acknowledge the review, feedback, and
comments of Jari Arkko, Dominique Barthel, Cédric Chauvenet,
Philip Levis, and JP Vasseur.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
&RFC5548;
&RFC5673;
&RFC5826;
&RFC5867;
&RFC6206;
&I-D.ietf-6man-rpl-option;
&I-D.ietf-roll-rpl;
&I-D.ietf-roll-routing-metrics;
&I-D.ietf-roll-p2p-rpl;
&I-D.ietf-roll-terminology;
</references>
<references title="Normative References">
&RFC2119;
</references>
</back>
</rfc>
<!-- LocalWords: unicast anycast
-->
| PAFTECH AB 2003-2026 | 2026-04-23 21:40:35 |