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