ROLL                                                             D. Popa
Internet-Draft                                               J. Jetcheva
Intended status: Standards Track                                   Itron
Expires: January 26, 2012                                      N. Dejean
                                                              R. Salazar
                                                                  J. Hui
                                                           July 25, 2011

Applicability Statement for the Routing Protocol for Low Power and Lossy
                     Networks (RPL) in AMI Networks


   This document discusses the applicability of RPL in Advanced Metering
   Infrastructure (AMI) networks.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 26, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Popa, et al.            Expires January 26, 2012                [Page 1]

Internet-Draft          RPL Applicability for AMI              July 2011

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Electric Metering  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Gas and Water Metering . . . . . . . . . . . . . . . . . .  4
     1.3.  Routing Protocol for LLNs (RPL)  . . . . . . . . . . . . .  4
     1.4.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Network Topology . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Traffic Characteristics  . . . . . . . . . . . . . . . . .  6
       2.2.1.  Meter Data Management  . . . . . . . . . . . . . . . .  6
       2.2.2.  Distribution Automation  . . . . . . . . . . . . . . .  7
       2.2.3.  Emerging Applications  . . . . . . . . . . . . . . . .  7
   3.  Using RPL to Meet Functional Requirements  . . . . . . . . . .  7
   4.  RPL Profile  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  RPL Features . . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Storing vs. Non-Storing Mode . . . . . . . . . . . . .  8
       4.1.2.  DAO Policy . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.3.  Path Metrics . . . . . . . . . . . . . . . . . . . . .  8
       4.1.4.  Objective Function . . . . . . . . . . . . . . . . . .  9
       4.1.5.  DODAG Repair . . . . . . . . . . . . . . . . . . . . .  9
       4.1.6.  Security . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  RPL Options  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Recommended Configuration Defaults and Ranges  . . . . . . 10
   5.  Other Related Protocols  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Informative References . . . . . . . . . . . . . . . . . . 11
     9.2.  Normative References . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Popa, et al.            Expires January 26, 2012                [Page 2]

Internet-Draft          RPL Applicability for AMI              July 2011

1.  Introduction

   Advanced Metering Infrastructure (AMI) systems measure, collect, and
   analyze energy consumption information.  An AMI system enables two-
   way communication with electricity, water, gas, and/or heat meters.
   The communication may be scheduled, on exception, or on-demand.

   AMI networks are composed of millions of endpoints, including meters,
   distribution automation elements, and home area network devices,
   typically inter-connected using some combination of wireless
   technologies and power-line communications, along with a wired or
   wireless backhaul network providing connectivity to "command-and-
   control" management software applications at the utility company back

1.1.  Electric Metering

   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, including 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 support applications such as Electric Vehicle charging.

   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.  This results
   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.

   Electric meters are often interconnected into multi-hop mesh
   networks, each of which is connected to a backhaul network leading to
   the utility network through a network aggregation point (NAP) node.
   These kinds of networks increase coverage and reduce installation
   cost, time and complexity, as well as operational costs, as compared
   to single-hop wireless networks relying on a wired or cellular
   backhaul.  Each electric meter mesh typically has in the order of
   several thousand wireless endpoints, with densities varying based on
   the area and the terrain, with apartment buildings in urban centers

Popa, et al.            Expires January 26, 2012                [Page 3]

Internet-Draft          RPL Applicability for AMI              July 2011

   having possibly hundreds of meters in close proximity, and rural
   areas having sparse node distributions, including nodes that only
   have one or two network neighbors.  Mesh deployments can exhibit tens
   of hops between a network device and the nearest aggregation point.

1.2.  Gas and Water Metering

   While electric meters can 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 (i.e. batteries).
   In certain scenarios, gas and water meters are integrated with
   electric meters in the same AMI network.  In this scenario, gas and
   water meters typically do not route messages or operate as hosts to
   prolong their lifetime.

   In other scenarios, however, gas and water meters do not have the
   luxury of communicating with a powered routing infrastructure.
   Instead, they must communicate through other battery powered devices
   (i.e. through other gas and water meters) to reach a NAP.
   Alternative scenarios also include water and/or gas meters
   communicating directly to a sparsely deployed network infrastructure,
   requiring increased transmit power levels for increased range that
   significantly impacts energy consumption and battery lifetime.  For
   such networks, the routing protocol must configure routes with energy
   consumption in mind.  The NAPs, however, are typically mains powered
   as in AMI networks with electric meters.

   RPL is designed to operate in energy-constrained environments and
   includes energy-saving mechanisms (e.g.  Trickle timers) and energy-
   aware metrics.  By supporting a number of different metrics and
   constraints, RPL is also designed to support networks composed of
   nodes that have vastly different characteristics

1.3.  Routing Protocol for LLNs (RPL)

   RPL provides routing functionality for mesh networks composed of a
   large number of resource-constrained devices interconnected by low
   power and lossy links.  Constrained devices within the same network
   typically communicate through a common aggregation point (e.g., a
   border router).  RPL builds a Directed Acyclic Graph (DAG) routing
   structure rooted at the aggregation point.  It ensures loop-free
   routing, support for alternate routes, and a wide range of routing
   metrics and policies.

   This note describes the applicability of RPL defined in
   [I-D.ietf-roll-rpl] to AMI deployments.  RPL was designed to meet the
   following application requirements:

Popa, et al.            Expires January 26, 2012                [Page 4]

Internet-Draft          RPL Applicability for AMI              July 2011

   o  Routing Requirements for Urban Low-Power and Lossy Networks

   o  Industrial Routing Requirements in Low-Power and Lossy Networks

   o  Home Automation Routing Requirements in Low-Power and Lossy
      Networks [RFC5826].

   o  Building Automation Routing Requirements in Low-Power and Lossy
      Networks [RFC5867].

   The Routing Requirements for Urban Low-Power and Lossy Networks is
   most applicable to AMI networks.

   The terminology used in this document is defined in

1.4.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Deployment Scenarios

2.1.  Network Topology

   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 in-home
   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 WiFi).  Network elements may not only
   source and sink packets, but must also forward packets to reduce the
   need for dedicated routers and associated deployment costs.

   In a typical AMI deployment, groups of meters within physical
   proximity form routing domains.  The size of each group in a typical
   AMI deployment can be from 1000 to 10000 or 15000 meters

   Powered from the main line electric meters have less energy
   constraints than battery powered devices and can afford the
   additional resources required for routing packets.  In mixed
   environments, electric meters provide the routing topology while gas
   and water meters operate as leaves.  However, in networks that cannot

Popa, et al.            Expires January 26, 2012                [Page 5]

Internet-Draft          RPL Applicability for AMI              July 2011

   afford a powered infrastructure, gas and water meters must either
   talk directly to a network infrastructure or form their own routing
   topology, albeit with energy consumption in mind.

   Each meter routing domain is connected to a larger IP infrastructure
   through one or more LLN Border Routers (LBRs).  The LBRs provide Wide
   Area Network (WAN) connectivity through more traditional links (e.g.
   Ethernet, Cellular, Private WAN) or other wireless technologies.

   The meter networks may also serve as transit networks for other
   devices, including battery powered gas and water meters, distribution
   automation elements (i.e. distribution sensors and actuators), and
   in-home devices.  These other devices may utilize a different link-
   layer technology than the one used in the metering network.

2.2.  Traffic Characteristics

2.2.1.  Meter Data Management

   Meter Data Management (MDM) applications typically require every
   smart meter to communicate with a few head-end servers deployed in a
   utility data center.  As a result, all smart metering traffic
   typically flows through the LBRs.  In general, the vast majority of
   traffic flows from smart meter devices to the head-end servers with
   limited traffic flowing from head-end servers to smart meter devices.
   In RPL terminology, this traffic flow is also referred to as
   Multipoint-to-point Traffic (MP2P).

   Smart meters may generate traffic according to a schedule (e.g. meter
   read reporting), in response to on-demand queries (e.g. on-demand
   meter read), or in response to events (e.g. power outages or leak
   detections).  Such traffic is typically unicast since it is sent to a
   single head-end server.

   Head-end servers may generate traffic to configure smart metering
   devices or initiate queries.  Head-end servers generate both unicast
   and multicast traffic to efficiently communicate with a single device
   or groups of devices.  In RPL terminology, this traffic flow is also
   referred to as Point-to-Multipoint Traffic (P2MP).  The head-end
   server may send a single small packet at a time (e.g. a meter read
   request or small configuration change) or many large packets in
   sequence (e.g. a firmware upgrade across one or thousands of

   While smart metering applications typically do not have hard real-
   time constraints, they are often subject to stringent latency and
   reliability service level agreements.  Some applications also have
   stringent latency requirements to function properly.

Popa, et al.            Expires January 26, 2012                [Page 6]

Internet-Draft          RPL Applicability for AMI              July 2011

2.2.2.  Distribution Automation

   Distribution Automation (DA) applications typically involve a small
   number of devices that communicate with each other in a Point-to-
   Point (P2P) fashion.  The DA devices may or may not be in close
   physical proximity.

   DA applications typically have more stringent latency requirements
   than MDM applications.

2.2.3.  Emerging Applications

   There are a number of emerging applications (e.g.  Electric Vehicle
   charging) that may involve P2P communication as well.  These
   applications may eventually have more stringent latency requirements
   than MDM applications.

3.  Using RPL to Meet Functional Requirements

   The functional requirements for most AMI deployments are similar to
   those listed in [RFC5548].

   o  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.

   o  The routing protocol MUST provide mechanisms to support
      configuration of the routing protocol itself.

   o  The routing protocol SHOULD support and utilize the large number
      of highly direct flows to a few head-end servers to handle

   o  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.

   o  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.

   RPL efficiently supports scalability and highly directed traffic
   flows between every smart meter and the few head-end servers by
   building a Directed Acyclic Graph (DAG) rooted at each LBR.

   RPL supports zero-touch configuration by providing in-band methods

Popa, et al.            Expires January 26, 2012                [Page 7]

Internet-Draft          RPL Applicability for AMI              July 2011

   for configuring RPL variables using DIO messages.

   RPL supports time-varying link qualities by allowing the use of
   metrics that effectively characterize the quality of a path (e.g.
   Estimated Transmission Count (ETX)).  RPL limits the impact of
   changing local conditions by discovering and maintaining multiple DAG
   parents and providing a local repair mechanism when all parents have
   been dropped.

4.  RPL Profile

   This section outlines a RPL profile for most representative AMI

4.1.  RPL Features

4.1.1.  Storing vs. Non-Storing Mode

   In most scenarios, electric meters can utilize the power they are
   monitoring for their own processing and computation and are not as
   constrained in energy consumption.  Instead, the capabilities of an
   electric meter are primarily constrained by cost.  As a result,
   different AMI deployments can vary significantly in terms of the
   memory, computational, and communication trade-offs that were made
   for their devices.  For this reason, the use of RPL storing or non-
   storing mode SHOULD be deployment specific.

   When meters are memory constrained and cannot adequately store route
   tables to support downward routing, non-storing mode is preferred.
   However, when nodes are capable of adequately storing such routing
   tables, storing mode can lead to shorter paths and reduce channel
   utilization near the root.

4.1.2.  DAO Policy

   Two-way communication is required in AMI systems.  As a result,
   electric meters SHOULD send DAO messages to establish downward paths
   back to themselves.

4.1.3.  Path Metrics

   Smart metering deployments utilize link technologies that can exhibit
   significant packet loss.  To characterize a path over such link
   technologies, AMI deployments can use the Expected Transmission Count
   (ETX) metric as defined in[I-D.ietf-roll-routing-metrics].

   For water- and gas-only networks that cannot rely on a powered

Popa, et al.            Expires January 26, 2012                [Page 8]

Internet-Draft          RPL Applicability for AMI              July 2011

   infrastructure, energy constraints may require simpler metrics that
   do not require as much energy to compute.  In particular, Hop Count
   and Link Quality Level may be more suitable in such deployments.
   Other metrics may be vendor-specific or defined at a later time into
   companion RFCs.

4.1.4.  Objective Function

   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 but also from the metrics in use in the
   network.  Two objective functions for RPL have been defined:

   o  OF0 which does not deal with any metric,

   o  MRHOF which deals with a single metric.

   Both of them define the selection of a preferred parent and backup
   parents.  Note that these Objective Functions do not support multiple
   metrics that might be required in heterogeneous networks (i.e.
   networks composed of devices with varying energy constraints).  While
   RPL provides the flexibility to support additional metrics, a new
   Objective Function MAY be specified to properly handle additional

4.1.5.  DODAG Repair

   To effectively handle time-varying link characteristics, AMI
   deployments SHOULD utilize the local repair mechanisms in RPL.

   The first mechanism for local repair when a node loses its parents is
   to detach from a DODAG then re-attach to the same or 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 described in Section of
   [I-D.ietf-roll-rpl].  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.  Note that when joining a different DODAG, the node need
   not perform poisoning.

   The second mechanism is a limit on how much a node can increase its
   rank within a given DODAG Version.  Setting the DAGMaxRankIncrease to
   a non-zero value enables this local repair mechanism.  Setting
   DAGMaxRankIncrease to a value less than infinity limits the cost of
   count-to-infinity scenarios when they occur.

Popa, et al.            Expires January 26, 2012                [Page 9]

Internet-Draft          RPL Applicability for AMI              July 2011

   The third mechanism is loop detection, enabled by including the rank
   value of a node in packets forwarded towards the root in RPL Packet
   Information [I-D.ietf-6man-rpl-option].  Note that loop detection is
   not needed when sending packets using strict source routing.

4.1.6.  Security

   AMI deployments operate in areas that do not provide any physical
   security.  For this reason, the link technologies used within AMI
   deployments typically provide security mechanisms to ensure
   confidentiality, integrity, and freshness.  As a result, AMI
   deployments may not need to implement RPL's security mechanisms and
   could rely on link layer security features.

4.2.  RPL Options

4.3.  Recommended Configuration Defaults and Ranges

   o  AMI deployments can involve densities of hundreds of devices
      within communication range.  As a result, such networks SHOULD set
      the DIOIntervalMin to 16 or more, giving a Trickle Imin of 1
      minute or more.  For low-energy consumption operations, such
      networks SHOULD set DIOIntervalMin be set to a higher value.

   o  AMI deployments SHOULD set DIOIntervalDoublings to a value that
      gives a Trickle Imax of 2 hours or more.  For low-energy
      consumption operations, such networks SHOULD set
      DIOIntervalDoublings to a value that gives a Trickle Imax of e.g.
      2 days.

   o  AMI deployments SHOULD set DIORedundancyConstant to a value of 10
      or more.

   o  AMI deployments SHOULD set MinHopRankIncrease to 256, giving 8
      bits of resolution (e.g. for the ETX metric).

   o  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

5.  Other Related Protocols

   This document contains no other related protocols.

Popa, et al.            Expires January 26, 2012               [Page 10]

Internet-Draft          RPL Applicability for AMI              July 2011

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   This memo includes no security considerations.

8.  Acknowledgements

   The authors would like to acknowledge the review, feedback, and
   comments from Dominique Barthel.

9.  References

9.1.  Informative References

              Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
              Information in Data-Plane Datagrams",
              draft-ietf-6man-rpl-option-03 (work in progress),
              March 2011.

              Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
              Barthel, "Routing Metrics used for Path Calculation in Low
              Power and Lossy Networks",
              draft-ietf-roll-routing-metrics-19 (work in progress),
              March 2011.

              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-05 (work in
              progress), March 2011.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

Popa, et al.            Expires January 26, 2012               [Page 11]

Internet-Draft          RPL Applicability for AMI              July 2011

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

9.2.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Daniel Popa


   Jorjeta Jetcheva
   2111 N Molter Rd.
   Liberty Lake, WA

   Phone: +408 688 1428

   Nicolas Dejean


   Ruben Salazar


Popa, et al.            Expires January 26, 2012               [Page 12]

Internet-Draft          RPL Applicability for AMI              July 2011

   Jonathan W. Hui
   170 West Tasman Drive
   San Jose, California  95134

   Phone: +408 424 1547

Popa, et al.            Expires January 26, 2012               [Page 13]