idnits 2.17.1 draft-ietf-roll-applicability-ami-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2011) is 4538 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 697, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6man-rpl-option-04 == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-04 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL D. Popa 3 Internet-Draft J. Jetcheva 4 Intended status: Standards Track Itron 5 Expires: April 27, 2012 N. Dejean 6 Elster SAS 7 R. Salazar 8 Landis+Gyr 9 J. Hui 10 Cisco 11 October 25, 2011 13 Applicability Statement for the Routing Protocol for Low Power and Lossy 14 Networks (RPL) in AMI Networks 15 draft-ietf-roll-applicability-ami-04 17 Abstract 19 This document discusses the applicability of RPL in Advanced Metering 20 Infrastructure (AMI) networks. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 27, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 3 59 1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4 60 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.1. Electric Meter Network . . . . . . . . . . . . . . . . 5 64 2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6 65 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 66 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7 67 2.2.2. Distribution Automation Communication . . . . . . . . 8 68 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8 69 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8 70 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9 73 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9 74 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10 76 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10 77 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 11 78 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 79 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12 81 4.2. Recommended Configuration Defaults and Ranges . . . . . . 12 82 4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12 83 4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13 84 5. Manageability Considerations . . . . . . . . . . . . . . . . . 14 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 91 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 Advanced Metering Infrastructure (AMI) systems enable the 97 measurement, configuration, and control of energy, gas and water 98 consumption and distribution, through two-way scheduled, on 99 exception, and on-demand communication. 101 AMI networks are composed of millions of endpoints, including meters, 102 distribution automation elements, and home area network devices. 103 They are typically inter-connected using some combination of wireless 104 technologies and power-line communications, along with a backhaul 105 network providing connectivity to "command-and-control" management 106 software applications at the utility company back office. 108 1.1. Electric Metering 110 In many deployments, in addition to measuring energy consumption, the 111 electric meter network plays a central role in the Smart Grid since 112 it enables the utility company to control and query the electric 113 meters themselves and also since it can serve as a backhaul for all 114 other devices in the Smart Grid, e.g., water and gas meters, 115 distribution automation and home area network devices. Electric 116 meters may also be used as sensors to monitor electric grid quality 117 and to support applications such as Electric Vehicle charging. 119 Electric meter networks are composed of millions of smart meters (or 120 nodes), each of which is resource-constrained in terms of processing 121 power, storage capabilities, and communication bandwidth, due to a 122 combination of factors including Federal Communications Commission 123 (FCC) or other continents' regulations on spectrum use, American 124 National Standards Institute (ANSI) standards or other continents' 125 regulation on meter behavior and performance, on heat emissions 126 within the meter, form factor and cost considerations. These 127 constraints result in a compromise between range and throughput, with 128 effective link throughput of tens to a few hundred kilobits per 129 second per link, a potentially significant portion of which is taken 130 up by protocol and encryption overhead when strong security measures 131 are in place. 133 Electric meters are often interconnected into multi-hop mesh 134 networks, each of which is connected to a backhaul network leading to 135 the utility company network through a network aggregation point, 136 e.g., an LBR (LLN Border Router). 138 1.2. Gas and Water Metering 140 While electric meters typically consume electricity from the same 141 electric feed that they are monitoring, gas and water meters 142 typically run on a modest source of stored energy (e.g., batteries). 144 In some scenarios, gas and water meters are integrated into the same 145 AMI network as the electric meters and may operate as network 146 endpoints (rather than routers) in order to prolong their own 147 lifetime. In other scenarios, however, such meters may not have the 148 luxury of relying on a fully powered AMI routing infrastructure but 149 must communicate through a dedicated infrastructure to reach a LBR. 150 This infrastructure can be either powered by the electricity grid, by 151 battery-based devices, or ones relying on alternative sources of 152 energy (e.g., solar power). 154 1.3. Routing Protocol for LLNs (RPL) 156 RPL provides routing functionality for mesh networks that can scale 157 up to thousands of resource-constrained devices, interconnected by 158 low power and lossy links, and communicating with the external 159 network infrastructure through a common aggregation point(s) (e.g., a 160 LBR). 162 RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at 163 the LBR, ensures loop-free routing, and provides support for 164 alternate routes, as well as, for a wide range of routing metrics and 165 policies. 167 RPL was desgined to operate in energy-constrained environments and 168 includes energy-saving mechanisms (e.g., Trickle timers) and energy- 169 aware metrics. Its ability to support multiple different metrics and 170 constraints at the same time enables it to run efficiently in 171 heterogeneous networks composed of nodes and links with vastly 172 different characteristics[I-D.ietf-roll-routing-metrics]. 174 This note describes the applicability of RPL (as defined in 175 [I-D.ietf-roll-rpl]) to AMI deployments. RPL was designed to meet 176 the following application requirements: 178 o Routing Requirements for Urban Low-Power and Lossy Networks 179 [RFC5548]. 181 o Industrial Routing Requirements in Low-Power and Lossy Networks 182 [RFC5673]. 184 o Home Automation Routing Requirements in Low-Power and Lossy 185 Networks [RFC5826]. 187 o Building Automation Routing Requirements in Low-Power and Lossy 188 Networks [RFC5867]. 190 The Routing Requirements for Urban Low-Power and Lossy Networks are 191 applicable to AMI networks as well. 193 The terminology used in this document is defined in 194 [I-D.ietf-roll-terminology]. 196 1.4. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119 [RFC2119]. 202 2. Deployment Scenarios 204 2.1. Network Topology 206 AMI networks are composed of millions of endpoints distributed across 207 both urban and rural environments. Such endpoints include electric, 208 gas, and water meters, distribution automation elements, and home 209 area network devices. Devices in the network communicate directly 210 with other devices in close proximity using a variety of low-power 211 and/or lossy link technologies that are both wired and wireless 212 (e.g., IEEE 802.15.4, IEEE P1901.2, and 802.11). In addition to 213 serving as sources and destinations of packets, many network elements 214 typically also forward packets and thus form a mesh topology. 216 2.1.1. Electric Meter Network 218 In a typical AMI deployment, groups of meters within physical 219 proximity form routing domains, each in the order of a 1,000 to 220 10,000 meters. Thus, each electric meter mesh typically has several 221 thousand wireless endpoints, with densities varying based on the area 222 and the terrain. For example, apartment buildings in urban centers 223 may have hundreds of meters in close proximity, whereas rural areas 224 may have sparse node distributions and include nodes that only have a 225 small number of network neighbors. 227 Each routing domain is connected to the larger IP infrastructure 228 through one or more LBRs, which provide Wide Area Network (WAN) 229 connectivity through various traditional network technologies, e.g., 230 Ethernet, cellular, private WAN. Paths in the mesh between a network 231 node and the nearest LBR may be composed of several hops or even 232 several tens of hops. 234 Powered from the main line, electric meters have less energy 235 constraints than battery powered devices, such as gas and water 236 meters, and can afford the additional resources required to route 237 packets. In mixed environments, electric meters can provide the 238 routing topology while gas and water meters can operate as leaf 239 nodes. 241 Electric meter networks may also serve as transit networks for other 242 types of devices, including distribution automation elements (e.g., 243 sensors and actuators), and in-home devices. These other devices may 244 utilize a different link-layer technology than the one used in the 245 meter network. 247 The routing protocol operating in networks with the topology 248 characteristics described above needs to be able to scale with 249 network size and number of forwarding hops, and have the ability to 250 handle a wide range of network densities. 252 2.1.2. Energy-Constrained Network Infrastructure 254 In the absence of a co-located electric meter network, gas and water 255 meters must either connect directly to the larger IP network 256 infrastructure or rely on a dedicated routing infrastructure. 257 Deploying such infrastructures is a challenging task as the routing 258 devices can sometimes only be placed in specific locations and thus 259 do not always have access to a continous energy source. Battery- 260 operated or energy-harvesting (e.g., equipped with solar panels) 261 routers are thus often used in these kinds of scenarios. 263 Due to the expected lifetime (10 to 20 years) of such networks and 264 their reliance on alternative sources of energy, energy consumption 265 needs to be taken into account when designing and deploying them. 266 There are a number of challenging trade-offs and considerations that 267 exist in that respect. One such consideration is that managing a 268 higher number of meters per router leads to increased energy 269 consumption. However, increasing the number of routers in the 270 network and thus reducing the number of meters managed by each router 271 increases deployment and maintenance costs. At the same time, the 272 use of a sparser routing infrastructure necessitates the use of 273 higher transmit power levels at nodes in the network, which causes 274 increased energy consumption. 276 The deployment and operational needs of energy-constrained network 277 infrastructure require the use of routing mechanisms that take into 278 account energy consumption, minimize energy use and prolong network 279 lifetime. 281 2.2. Traffic Characteristics 282 2.2.1. Smart Metering Data 284 In current AMI deployments, metering applications typically require 285 all smart meters to communicate with a few head-end servers, deployed 286 in the utility company data center. 288 Head-end servers generate data traffic to configure smart metering 289 devices or initiate queries, and use unicast and multicast to 290 efficiently communicate with a single device or groups of devices 291 respectively (i.e., Point-to-Multipoint (P2MP) communication). The 292 head-end server may send a single small packet at a time to the 293 meters (e.g., a meter read request, a small configuration change) or 294 a series of large packets (e.g., a firmware upgrade across one or 295 even thousands of devices). The frequency of large file transfers, 296 e.g., firmware upgrade of all metering devices, is typically much 297 lower than the frequency of sending configuration messages or 298 queries. 300 Each smart meter generates Smart Metering Data (SMD) traffic 301 according to a schedule (e.g., periodic meter reads), in response to 302 on-demand queries (e.g., on-demand meter reads), or in response to 303 some local event (e.g., power outage, leak detection). Such traffic 304 is typically destined to a single head-end server. 306 The bulk of the SMD traffic tends to be directed towards the LBR, 307 both in terms of bytes (since reports are typically much larger than 308 queries) and in terms of number of packets, e.g., some reports have 309 to be split into multiple packets due to packet size limitations, 310 periodic reports can be sent without requiring a query to be sent for 311 each one first, unsolicited events like alarms and outage 312 notifications are only generated by the meters and sent towards the 313 LBR. The SMD traffic is thus highly asymmetric, where the majority 314 of the traffic volume generated by the smart meters typically goes 315 through the LBRs, and is directed from the smart meter devices to the 316 head-end servers, in a Multipoint-to-Point (MP2P) fashion. 318 Current SMD traffic patterns are fairly uniform and well-understood. 319 The traffic generated by the head-end server and destined to metering 320 devices is dominated by periodic meter reads, while traffic generated 321 by the metering devices is typically uniformly spread over some 322 periodic read time-window. 324 Smart metering applications typically do not have hard real-time 325 constraints, but they are often subject to bounded latency and 326 stringent reliability service level agreements. 328 From a routing perspective, SMD applications require efficient P2MP 329 communication between the devices in the network and one or more 330 LBRs. In addition, timely loop resolution and broken link repair are 331 needed to meet latency requirements. Finally, the availability of 332 redundant paths is important for increasing network reliability. 334 2.2.2. Distribution Automation Communication 336 Distribution Automation (DA) applications typically involve a small 337 number of devices that communicate with each other in a Point-to- 338 Point (P2P) fashion, and may or may not be in close physical 339 proximity. 341 DA applications typically have more stringent latency requirements 342 than SMD applications. 344 2.2.3. Emerging Applications 346 There are a number of emerging applications such as electric vehicle 347 charging. These applications may require P2P communication and may 348 eventually have more stringent latency requirements than SMD 349 applications. 351 3. Using RPL to Meet Functional Requirements 353 The functional requirements for most AMI deployments are similar to 354 those listed in [RFC5548]: 356 o The routing protocol MUST be capable of supporting the 357 organization of a large number of nodes into regions containing on 358 the order of 10^2 to 10^4 nodes each. 360 o The routing protocol MUST provide mechanisms to support 361 configuration of the routing protocol itself. 363 o The routing protocol SHOULD support and utilize the large number 364 of highly directed flows to a few head-end servers to handle 365 scalability. 367 o The routing protocol MUST dynamically compute and select effective 368 routes composed of low-power and lossy links. Local network 369 dynamics SHOULD NOT impact the entire network. The routing 370 protocol MUST compute multiple paths when possible. 372 o The routing protocol MUST support multicast and anycast 373 addressing. The routing protocol SHOULD support formation and 374 identification of groups of field devices in the network. 376 RPL supports: 378 o Large-scale networks characterized by highly directed traffic 379 flows between each smart meter and the head-end servers in the 380 utility network. To this end, RPL builds a Directed Acyclic Graph 381 (DAG) rooted at each LBR. 383 o Zero-touch configuration. This is done through in-band methods 384 for configuring RPL variables using DIO messages. 386 o The use of links with time-varying quality characteristics. This 387 is accomplished by allowing the use of metrics that effectively 388 capture the quality of a path (e.g., Expected Transmission Count 389 (ETX)) and by limiting the impact of changing local conditions by 390 discovering and maintaining multiple DAG parents, and by using 391 local repair mechanisms when DAG links break. 393 4. RPL Profile 395 This section outlines a RPL profile for a representative AMI 396 deployment. 398 4.1. RPL Features 400 4.1.1. RPL Instances 402 RPL operation is defined for a single RPL instance. However, 403 multiple RPL instances can be supported in multi-service networks 404 where different applications may require the use of different routing 405 metrics and constraints, e.g., a network carrying both SDM and DA 406 traffic. 408 4.1.2. Storing vs. Non-Storing Mode 410 In most scenarios, electric meters are powered by the grid they are 411 monitoring and are not energy-constrained. Instead, electric meters 412 have hardware and communication capacity constraints that are 413 primarily determined by cost, and secondarily by power consumption. 414 As a result, different AMI deployments can vary significantly in 415 terms of memory size, computation power and communication 416 capabilities. For this reason, the use of RPL storing or non-storing 417 mode SHOULD be deployment specific. 419 When meters are memory constrained and cannot adequately store the 420 route tables necessary to support hop-by-hop routing, RPL non-storing 421 mode SHOULD be preferred. On the other hand, when nodes are capable 422 of storing such routing tables, the use of storing mode may lead to 423 reduced overhead and route repair latency. However, in high-density 424 environments, storing routes can be challenging because some nodes 425 may have to maintain routing information for a large number of 426 descendents. When the routing table size becomes challenging, it is 427 RECOMMENDED that nodes perform route aggregation, similarly to the 428 approach taken by other routing protocols, although the required set 429 of mechanism may differ. 431 4.1.3. DAO Policy 433 Two-way communication is a requirement in AMI systems. As a result, 434 nodes SHOULD send DAO messages to establish downward paths from the 435 root to themselves. 437 4.1.4. Path Metrics 439 Smart metering deployments utilize link technologies that may exhibit 440 significant packet loss and thus require routing metrics that take 441 packet loss into account. To characterize a path over such link 442 technologies, AMI deployments can use the Expected Transmission Count 443 (ETX) metric as defined in[I-D.ietf-roll-routing-metrics]. 445 For water- and gas-only networks that do not rely on powered 446 infrastructure, simpler metrics that require less energy to compute 447 would be more appropriate. In particular, a combination of hop count 448 and link quality can satisfy this requirement. As minimizing energy 449 consumption is critical in these types of networks, available node 450 energy should also be used in conjunction with these two metrics. 451 The usage of additional metrics specifically designed for such 452 networks may be defined in companion RFCs, e.g., 453 [I-D.ietf-roll-routing-metrics] . 455 4.1.5. Objective Function 457 RPL relies on an Objective Function for selecting parents and 458 computing path costs and rank. This objective function is decoupled 459 from the core RPL mechanisms and also from the metrics in use in the 460 network. Two objective functions for RPL have been defined at the 461 time of this writing, OF0 and MRHOF, both of which define the 462 selection of a preferred parent and backup parents, and are suitable 463 for AMI deployments. 465 Neither of the currently defined objective functions supports 466 multiple metrics that might be required in heterogeneous networks 467 (e.g., networks composed of devices with different energy 468 constraints) or combination of metrics that might be required for 469 water- and gas-only networks. Additional objective functions 470 specifically designed for such networks may be defined in companion 471 RFCs. 473 4.1.6. DODAG Repair 475 To effectively handle time-varying link characteristics and 476 availability, AMI deployments SHOULD utilize the local repair 477 mechanisms in RPL. 479 Local repair is triggered by broken link detection and in storing 480 mode by loop detection as well. 482 The first local repair mechanism consists of a node detaching from a 483 DODAG and then re-attaching to the same or to a different DODAG at a 484 later time. While detached, a node advertises an infinite rank value 485 so that its children can select a different parent. This process is 486 known as poisoning and is described in Section 8.2.2.5 of 487 [I-D.ietf-roll-rpl]. While RPL provides an option to form a local 488 DODAG, doing so in AMI deployments is of little benefit since AMI 489 applications typically communicate through a LBR. After the detached 490 node has made sufficient effort to send notification to its children 491 that it is detached, the node can rejoin the same DODAG with a higher 492 rank value. The configured duration of the poisoning mechanism needs 493 to take into account the disconnection time applications running over 494 the network can tolerate. Note that when joining a different DODAG, 495 the node need not perform poisoning. 497 The second local repair mechanism controls how much a node can 498 increase its rank within a given DODAG Version (e.g., after detaching 499 from the DODAG as a result of broken link or loop detection). 500 Setting the DAGMaxRankIncrease to a non-zero value enables this 501 mechanism, and setting it to a value of less than infinity limits the 502 cost of count-to-infinity scenarios when they occur, thus controlling 503 the duration of disconnection applications may experience. 505 4.1.7. Multicast 507 RPL defines multicast support for its storing mode of operation, 508 where the DODAG structure built for unicast packet dissemination is 509 used for multicast distribution as well. In particular, multicast 510 forwarding state creation is done through DAO messages with multicast 511 target options sent along the DODAG towards the root. Thereafter 512 nodes with forwarding state for a particular group forward multicast 513 packets along the DODAG by copying them to all children from which 514 they have received a DAO with a multicast target option for the 515 group. 517 Multicast support for RPL in non-storing mode will be defined in 518 companion RFCs. 520 4.1.8. Security 522 AMI deployments operate in areas that do not provide any physical 523 security. For this reason, the link layer, transport layer and 524 application layer technologies utilized within AMI networks typically 525 provide security mechanisms to ensure authentication, 526 confidentiality, integrity, and freshness. As a result, AMI 527 deployments may not need to implement RPL's security mechanisms and 528 could rely on link layer and higher layer security features. 530 4.1.9. P2P communications 532 Distribution Automation and other emerging applications may require 533 efficient P2P communications. Basic P2P capabilities are already 534 defined in the RPL RFC [I-D.ietf-roll-rpl]. Additional mechanisms 535 for efficient P2P communication are being developed in companion 536 RFCs. 538 4.2. Recommended Configuration Defaults and Ranges 540 4.2.1. Trickle Parameters 542 Trickle was designed to be density-aware and perform well in networks 543 characterized by a wide range of node densities. The combination of 544 DIO packet suppression and adaptive timers for sending updates allows 545 Trickle to perform well in both sparse and dense environments. 547 Node densities in AMI deployments can vary greatly, from nodes having 548 only one or a handful of neighbors to nodes having several hundred 549 neighbors. In high density environments, relatively low values for 550 Imin may cause a short period of congestion when an inconsistency is 551 detected and DIO updates are sent by a large number of neighboring 552 nodes nearly simultaneously. While the Trickle timer will 553 exponentially backoff, some time may elapse before the congestion 554 subsides. While some link layers employ contention mechanisms that 555 attempt to avoid congestion, relying solely on the link layer to 556 avoid congestion caused by a large number of DIO updates can result 557 in increased communication latency for other control and data traffic 558 in the network. 560 To mitigate this kind of short-term congestion, this document 561 recommends a more conservative set of values for the Trickle 562 parameters than those specified in [RFC6206]. In particular, 563 DIOIntervalMin is set to a larger value to avoid periods of 564 congestion in dense environments, and DIORefundancyConstant is 565 parameterized accordingly as described below. These values are 566 appropriate for the timely distribution of DIO updates in both sparse 567 and dense scenarios while avoiding the short-term congestion that 568 might arise in dense scenarios. 570 Because the actual link capacity depends on the particular link 571 technology used within an AMI deployment, the Trickle parameters are 572 specified in terms of the link's maximum capacity for transmitting 573 link-local multicast messages. If the link can transmit m link-local 574 multicast packets per second on average, the expected time it takes 575 to transmit a link-local multicast packet is 1/m seconds. 577 DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that 578 the Trickle Imin is at least 50 times as long as it takes to 579 transmit a link-local multicast packet. This value is larger than 580 that recommended in [RFC6206] to avoid congestion in dense urban 581 deployments as described above. In energy-constrained deployments 582 (e.g., in water and gas battery-based routing infrastructure), 583 DIOIntervalMin MAY be set to a value resulting in a Trickle Imin 584 of several (e.g. 2) hours. 586 DIOIntervalDoublings: AMI deployments SHOULD set 587 DIOIntervalDoublings such that the Trickle Imax is at least 2 588 hours or more. For very energy constrained deployments (e.g., 589 water and gas battery-based routing infrastructure), 590 DIOIntervalDoublings MAY be set to a value resulting in a Trickle 591 Imax of several (e.g., 2) days. 593 DIORedundancyConstant: AMI deployments SHOULD set 594 DIORedundancyConstant to a value of at least 10. This is due to 595 the larger chosen value for DIOIntervalMin and the proportional 596 relationship between Imin and k suggested in [RFC6206]. This 597 increase is intended to compensate for the increased communication 598 latency of DIO updates caused by the increase in the 599 DIOIntervalMin value, though the proportional relationship between 600 Imin and k suggested in [RFC6206] is not preserved. Instead, 601 DIORedundancyConstant is set to a lower value in order to reduce 602 the number of packet transmissions in dense environments. 604 4.2.2. Other Parameters 606 o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 607 8 bits of resolution (e.g., for the ETX metric). 609 o To enable local repair, AMI deployments SHOULD set MaxRankIncrease 610 to a value that allows a device to move a small number of hops 611 away from the root. With a MinHopRankIncrease of 256, a 612 MaxRankIncrease of 1024 would allow a device to move up to 4 hops 613 away. 615 5. Manageability Considerations 617 Network manageability is a critical aspect of smart grid network 618 deployment and operation. With millions of devices participating in 619 the smart grid network, many requiring real-time reachability, 620 automatic configuration, and lightweight network health monitoring 621 and management are crucial for achieving network availability and 622 efficient operation. 624 RPL enables automatic and consistent configuration of RPL routers 625 through parameters specified by the DODAG root and disseminated 626 through DIO packets. The use of Trickle for scheduling DIO 627 transmissions ensures lightweight yet timely propagation of important 628 network and parameter updates and allows network operators to choose 629 the trade-off point they are comfortable with respect to overhead vs. 630 reliability and timeliness of network updates. 632 The metrics in use in the network along with the Trickle Timer 633 parameters used to control the frequency and redundancy of network 634 updates can be dynamically varied by the root during the lifetime of 635 the network. To that end, all DIO messages SHOULD contain a Metric 636 Container option for disseminating the metrics and metric values used 637 for DODAG setup. In addition, DIO messages SHOULD contain a DODAG 638 Configuration option for disseminating the Trickle Timer parameters 639 throughout the network. 641 The possibility of dynamically updating the metrics in use in the 642 network as well as the frequency of network updates allows deployment 643 characteristics (e.g., network density) to be discovered during 644 network bring-up and to be used to tailor network parameters once the 645 network is operational rather than having to rely on precise pre- 646 configuration. This also allows the network parameters and the 647 overall routing protocol behavior to evolve during the lifetime of 648 the network. 650 RPL specifies a number of variables and events that can be tracked 651 for purposes of network fault and performance monitoring of RPL 652 routers. Depending on the memory and processing capabilities of each 653 smart grid device, various subsets of these can be employed in the 654 field. 656 6. Security Considerations 658 Smart grid networks are subject to stringent security requirements as 659 they are considered a critical infrastructure component. At the same 660 time, since they are composed of large numbers of resource- 661 constrained devices inter-connected with limited-throughput links, 662 many available security mechanisms are not practical for use in such 663 networks. As a result, the choice of security mechanisms is highly 664 dependent on the device and network capabilities characterizing a 665 particular deployment. 667 In contrast to other types of LLNs, in smart grid networks 668 centralized administrative control and access to a permanent secure 669 infrastructure is available. As a result link-layer, transport-layer 670 and/or application-layer security mechanisms are typically in place 671 and using RPL's secure mode is not necessary. 673 7. Other Related Protocols 675 This document contains no other related protocols. 677 8. IANA Considerations 679 This memo includes no request to IANA. 681 9. Acknowledgements 683 The authors would like to acknowledge the review, feedback, and 684 comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Philip 685 Levis, and JP Vasseur. 687 10. References 689 10.1. Informative References 691 [I-D.ietf-6man-rpl-option] 692 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 693 Information in Data-Plane Datagrams", 694 draft-ietf-6man-rpl-option-04 (work in progress), 695 October 2011. 697 [I-D.ietf-roll-p2p-rpl] 698 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie, 699 R., and J. Martocci, "Reactive Discovery of Point-to-Point 700 Routes in Low Power and Lossy Networks", 701 draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011. 703 [I-D.ietf-roll-routing-metrics] 704 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 705 Barthel, "Routing Metrics used for Path Calculation in Low 706 Power and Lossy Networks", 707 draft-ietf-roll-routing-metrics-19 (work in progress), 708 March 2011. 710 [I-D.ietf-roll-rpl] 711 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 712 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 713 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 714 Lossy Networks", draft-ietf-roll-rpl-19 (work in 715 progress), March 2011. 717 [I-D.ietf-roll-terminology] 718 Vasseur, J., "Terminology in Low power And Lossy 719 Networks", draft-ietf-roll-terminology-06 (work in 720 progress), September 2011. 722 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 723 "Routing Requirements for Urban Low-Power and Lossy 724 Networks", RFC 5548, May 2009. 726 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 727 "Industrial Routing Requirements in Low-Power and Lossy 728 Networks", RFC 5673, October 2009. 730 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 731 Routing Requirements in Low-Power and Lossy Networks", 732 RFC 5826, April 2010. 734 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 735 "Building Automation Routing Requirements in Low-Power and 736 Lossy Networks", RFC 5867, June 2010. 738 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 739 "The Trickle Algorithm", RFC 6206, March 2011. 741 10.2. Normative References 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, March 1997. 746 Authors' Addresses 748 Daniel Popa 749 Itron 750 52 Rue Camille Desmoulins 751 92448 Issy les Moulineaux 752 France 754 Email: daniel.popa@itron.com 756 Jorjeta Jetcheva 757 Itron 758 2111 N Molter Rd. 759 Liberty Lake, WA 99019 760 USA 762 Email: jorjeta.jetcheva@itron.com 764 Nicolas Dejean 765 Elster SAS 766 Espace Concorde, 120 impasse JB Say 767 Perols, 34470 768 France 770 Email: nicolas.dejean@coronis.com 772 Ruben Salazar 773 Landis+Gyr 774 30000 Mill Creek Ave # 100 775 Alpharetta, GA 30022 777 Email: ruben.salazar@landisgyr.com 779 Jonathan W. Hui 780 Cisco 781 170 West Tasman Drive 782 San Jose, California 95134 783 USA 785 Phone: +408 424 1547 786 Email: jonhui@cisco.com