| ROLL | D.P. Popa |
| Internet-Draft | J.J. Jetcheva |
| Intended status: Standards Track | Itron |
| Expires: March 30, 2012 | N.D. Dejean |
| Elster SAS | |
| R.S. Salazar | |
| Landis+Gyr | |
| J.H. Hui | |
| Cisco | |
| September 27, 2011 |
Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks
draft-ietf-roll-applicability-ami-03
This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks.
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 http://datatracker.ietf.org/drafts/current/.
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 March 30, 2012.
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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.
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.
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.
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.
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.
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).
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).
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).
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).
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.
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[I-D.ietf-roll-routing-metrics].
This note describes the applicability of RPL (as defined in [I-D.ietf-roll-rpl]) to AMI deployments. RPL was designed to meet the following application requirements:
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 [I-D.ietf-roll-terminology].
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 RFC 2119 [RFC2119].
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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 Multipoint-to-Point (MP2P) 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.
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.
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.
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.
The functional requirements for most AMI deployments are similar to those listed in [RFC5548]:
RPL supports:
This section outlines a RPL profile for a representative AMI deployment.
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.
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.
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.
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.
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[I-D.ietf-roll-routing-metrics].
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.
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.
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.
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 and in storing mode by loop detection as well.
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 [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. 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.
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.
Multicast support for RPL in non-storing mode will be defined in companion RFCs.
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.
Distribution Automation and other emerging applications may require efficient P2P communications. Basic P2P capabilities are already defined in the RPL RFC [I-D.ietf-roll-rpl]. Additional mechanisms for efficient P2P communication are being developed in companion RFCs.
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 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.
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.
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.
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.
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.
This document contains no other related protocols.
This memo includes no request to IANA.
The authors would like to acknowledge the review, feedback, and comments of Jari Arkko, Dominique Barthel, Cédric Chauvenet, Philip Levis, and JP Vasseur.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |