idnits 2.17.1 draft-ietf-roll-applicability-ami-02.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 (September 14, 2011) is 4601 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 670, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 676, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6man-rpl-option-03 == 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-05 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: March 17, 2012 N. Dejean 6 Elster SAS 7 R. Salazar 8 Landis+Gyr 9 J. Hui 10 Cisco 11 September 14, 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-02 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 March 17, 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 . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10 76 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10 77 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 10 78 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 79 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 13 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 14 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 SMD traffic is thus highly asymmetric, where the majority of the 307 traffic generated by the smart meters typically goes through the 308 LBRs, and is directed from the smart meter devices to the head-end 309 servers, in a Multipoint-to-Point (MP2P) fashion. 311 Current SMD traffic patterns are fairly uniform and well-understood. 312 The traffic generated by the head-end server and destined to metering 313 devices is dominated by periodic meter reads, while traffic generated 314 by the metering devices is typically uniformly spread over some 315 periodic read time-window. 317 Smart metering applications typically do not have hard real-time 318 constraints, but they are often subject to bounded latency and 319 stringent reliability service level agreements. 321 From a routing perspective, SMD applications require efficient P2MP 322 communication between the devices in the network and one or more 323 LBRs. In addition, timely loop resolution and broken link repair are 324 needed to meet latency requirements. Finally, the availability of 325 redundant paths is important for increasing network reliability. 327 2.2.2. Distribution Automation Communication 329 Distribution Automation (DA) applications typically involve a small 330 number of devices that communicate with each other in a Point-to- 331 Point (P2P) fashion, and may or may not be in close physical 332 proximity. 334 DA applications typically have more stringent latency requirements 335 than SMD applications. 337 2.2.3. Emerging Applications 339 There are a number of emerging applications such as electric vehicle 340 charging. These applications may require P2P communication and may 341 eventually have more stringent latency requirements than SMD 342 applications. 344 3. Using RPL to Meet Functional Requirements 346 The functional requirements for most AMI deployments are similar to 347 those listed in [RFC5548]: 349 o The routing protocol MUST be capable of supporting the 350 organization of a large number of nodes into regions containing on 351 the order of 10^2 to 10^4 nodes each. 353 o The routing protocol MUST provide mechanisms to support 354 configuration of the routing protocol itself. 356 o The routing protocol SHOULD support and utilize the large number 357 of highly directed flows to a few head-end servers to handle 358 scalability. 360 o The routing protocol MUST dynamically compute and select effective 361 routes composed of low-power and lossy links. Local network 362 dynamics SHOULD NOT impact the entire network. The routing 363 protocol MUST compute multiple paths when possible. 365 o The routing protocol MUST support multicast and anycast 366 addressing. The routing protocol SHOULD support formation and 367 identification of groups of field devices in the network. 369 RPL supports: 371 o Large-scale networks characterized by highly directed traffic 372 flows between each smart meter and the head-end servers in the 373 utility network. To this end, RPL builds a Directed Acyclic Graph 374 (DAG) rooted at each LBR. 376 o Zero-touch configuration. This is done through in-band methods 377 for configuring RPL variables using DIO messages. 379 o The use of links with time-varying quality characteristics. This 380 is accomplished by allowing the use of metrics that effectively 381 capture the quality of a path (e.g., Expected Transmission Count 382 (ETX)) and by limiting the impact of changing local conditions by 383 discovering and maintaining multiple DAG parents, and by using 384 local repair mechanisms when DAG links break. 386 4. RPL Profile 388 This section outlines a RPL profile for a representative AMI 389 deployment. 391 4.1. RPL Features 393 4.1.1. RPL Instances 395 RPL operation is defined for a single RPL instance. However, 396 multiple RPL instances can be supported in multi-service networks 397 where different applications may require the use of different routing 398 metrics and constraints, e.g., a network carrying both SDM and DA 399 traffic. 401 4.1.2. Storing vs. Non-Storing Mode 403 In most scenarios, electric meters are powered by the electric grid 404 they are monitoring and are not energy-constrained. Instead, the 405 capabilities of an electric meter are primarily determined by cost. 406 As a result, different AMI deployments can vary significantly in 407 terms of the memory, computation, and communication trade-offs they 408 embody. For this reason, the use of RPL storing or non-storing mode 409 SHOULD be deployment specific. 411 For example, when meters are memory constrained and cannot adequately 412 store the route tables necessary to support downward routing in a 413 typical deployment, non-storing mode is preferred. When nodes are 414 capable of storing such routing tables, storing mode may lead to 415 reduced overhead and route repair latency. 417 4.1.3. DAO Policy 419 Two-way communication is a requirement in AMI systems. As a result, 420 nodes SHOULD send DAO messages to establish downward paths from the 421 root to themselves. 423 4.1.4. Path Metrics 425 Smart metering deployments utilize link technologies that may exhibit 426 significant packet loss and thus require routing metrics that take 427 packet loss into account. To characterize a path over such link 428 technologies, AMI deployments can use the Expected Transmission Count 429 (ETX) metric as defined in[I-D.ietf-roll-routing-metrics]. 431 For water- and gas-only networks that do not rely on powered 432 infrastructure, simpler metrics that require less energy to compute 433 would be more appropriate. In particular, hop count and link quality 434 level may be more suitable. Additional metrics specifically designed 435 for such networks may be defined in companion RFCs. 437 4.1.5. Objective Function 439 RPL relies on an Objective Function for selecting parents and 440 computing path costs and rank. This objective function is decoupled 441 from the core RPL mechanisms and also from the metrics in use in the 442 network. Two objective functions for RPL have been defined at the 443 time of this writing, OF0 and MRHOF, both of which define the 444 selection of a preferred parent and backup parents, and are suitable 445 for AMI deployments. 447 Neither of the currently defined objective functions supports 448 multiple metrics that might be required in heterogeneous networks 449 (e.g., networks composed of devices with different energy 450 constraints). Additional objective functions specifically designed 451 for such networks may be defined in companion RFCs. 453 4.1.6. DODAG Repair 455 To effectively handle time-varying link characteristics and 456 availability, AMI deployments SHOULD utilize the local repair 457 mechanisms in RPL. 459 Local repair is triggered by broken link detection and in storing 460 mode by loop detection as well. 462 The first local repair mechanism consists of a node detaching from a 463 DODAG and then re-attaching to the same or to a different DODAG at a 464 later time. While detached, a node advertises an infinite rank value 465 so that its children can select a different parent. This process is 466 known as poisoning and is described in Section 8.2.2.5 of 467 [I-D.ietf-roll-rpl]. While RPL provides an option to form a local 468 DODAG, doing so in AMI deployments is of little benefit since AMI 469 applications typically communicate through a LBR. After the detached 470 node has made sufficient effort to send notification to its children 471 that it is detached, the node can rejoin the same DODAG with a higher 472 rank value. The configured duration of the poisoning mechanism needs 473 to take into account the disconnection time applications running over 474 the network can tolerate. Note that when joining a different DODAG, 475 the node need not perform poisoning. 477 The second local repair mechanism controls how much a node can 478 increase its rank within a given DODAG Version (e.g., after detaching 479 from the DODAG as a result of broken link or loop detection). 480 Setting the DAGMaxRankIncrease to a non-zero value enables this 481 mechanism, and setting it to a value of less than infinity limits the 482 cost of count-to-infinity scenarios when they occur, thus controlling 483 the duration of disconnection applications may experience. 485 4.1.7. Multicast 487 RPL defines multicast support for its storing mode of operation, 488 where the DODAG structure built for unicast packet dissemination is 489 used for multicast distribution as well. In particular, multicast 490 forwarding state creation is done through DAO messages with multicast 491 target options sent along the DODAG towards the root. Thereafter 492 nodes with forwarding state for a particular group forward multicast 493 packets along the DODAG by copying them to all children from which 494 they have received a DAO with a multicast target option for the 495 group. 497 Multicast support for RPL in non-storing mode will be defined in 498 companion RFCs. 500 4.1.8. Security 502 AMI deployments operate in areas that do not provide any physical 503 security. For this reason, the link layer, transport layer and 504 application layer technologies utilized within AMI networks typically 505 provide security mechanisms to ensure authentication, 506 confidentiality, integrity, and freshness. As a result, AMI 507 deployments may not need to implement RPL's security mechanisms and 508 could rely on link layer and higher layer security features. 510 4.1.9. P2P communications 512 Distribution Automation and other emerging applications may require 513 efficient P2P communications. Basic P2P capabilities are already 514 defined in the RPL RFC [I-D.ietf-roll-rpl]. Additional mechanisms 515 for efficient P2P communication are being developed in companion 516 RFCs. 518 4.2. Recommended Configuration Defaults and Ranges 520 4.2.1. Trickle Parameters 522 Trickle was designed to be density-aware and perform well in networks 523 characterized by a wide range of node densities. The combination of 524 DIO packet suppression and adaptive timers for sending updates allows 525 Trickle to perform well in both sparse and dense environments. 527 Node densities in AMI deployments can vary greatly, from nodes having 528 only one or a handful of neighbors to nodes having several hundred 529 neighbors. In high density environments, relatively low values for 530 Imin may cause a short period of congestion when an inconsistency is 531 detected and DIO updates are sent by a large number of neighboring 532 nodes nearly simultaneously. While the Trickle timer will 533 exponentially backoff, some time may elapse before the congestion 534 subsides. While some link layers employ contention mechanisms that 535 attempt to avoid congestion, relying solely on the link layer to 536 avoid congestion caused by a large number of DIO updates can result 537 in increased communication latency for other control and data traffic 538 in the network. 540 To mitigate this kind of short-term congestion, this document 541 recommends a more conservative set of values for the Trickle 542 parameters than those specified in [RFC6206]. In particular, 543 DIOIntervalMin is set to a larger value to avoid periods of 544 congestion in dense environments, and DIORefundancyConstant is 545 parameterized accordingly as described below. These values are 546 appropriate for the timely distribution of DIO updates in both sparse 547 and dense scenarios while avoiding the short-term congestion that 548 might arise in dense scenarios. 550 Because the actual link capacity depends on the particular link 551 technology used within an AMI deployment, the Trickle parameters are 552 specified in terms of the link's maximum capacity for transmitting 553 link-local multicast messages. If the link can transmit m link-local 554 multicast packets per second on average, the expected time it takes 555 to transmit a link-local multicast packet is 1/m seconds. 557 DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that 558 the Trickle Imin is at least 50 times as long as it takes to 559 transmit a link-local multicast packet. This value is larger than 560 that recommended in [RFC6206] to avoid congestion in dense urban 561 deployments as described above. In energy-constrained deployments 562 (e.g., in water and gas battery-based routing infrastructure), 563 DIOIntervalMin MAY be set to a value resulting in a Trickle Imin 564 of several (e.g. 2) hours. 566 DIOIntervalDoublings: AMI deployments SHOULD set 567 DIOIntervalDoublings such that the Trickle Imax is at least 2 568 hours or more. For very energy constrained deployments (e.g., 569 water and gas battery-based routing infrastructure), 570 DIOIntervalDoublings MAY be set to a value resulting in a Trickle 571 Imax of several (e.g., 2) days. 573 DIORedundancyConstant: AMI deployments SHOULD set 574 DIORedundancyConstant to a value of at least 10. This is due to 575 the larger chosen value for DIOIntervalMin and the proportional 576 relationship between Imin and k suggested in [RFC6206]. This 577 increase is intended to compensate for the increased communication 578 latency of DIO updates caused by the increase in the 579 DIOIntervalMin value, though the proportional relationship between 580 Imin and k suggested in [RFC6206] is not preserved. Instead, 581 DIORedundancyConstant is set to a lower value in order to reduce 582 the number of packet transmissions in dense environments. 584 4.2.2. Other Parameters 586 o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 587 8 bits of resolution (e.g., for the ETX metric). 589 o To enable local repair, AMI deployments SHOULD set MaxRankIncrease 590 to a value that allows a device to move a small number of hops 591 away from the root. With a MinHopRankIncrease of 256, a 592 MaxRankIncrease of 1024 would allow a device to move up to 4 hops 593 away. 595 5. Manageability Considerations 597 Network manageability is a critical aspect of smart grid network 598 deployment and operation. With millions of devices participating in 599 the smart grid network, many requiring real-time reachability, 600 automatic configuration, and lightweight network health monitoring 601 and management are crucial for achieving network availability and 602 efficient operation. 604 RPL enables automatic and consistent configuration of RPL routers 605 through parameters specified by the DODAG root and disseminated 606 through DIO packets. The use of Trickle for scheduling DIO 607 transmissions ensures lightweight yet timely propagation of important 608 network and parameter updates and allows network operators to choose 609 the trade-off point they are comfortable with respect to overhead vs. 610 reliability and timeliness of network updates. 612 The metrics in use in the network along with the Trickle Timer 613 parameters used to control the frequency and redundancy of network 614 updates can be dynamically varied by the root during the lifetime of 615 the network. To that end, all DIO messages SHOULD contain a Metric 616 Container option for disseminating the metrics and metric values used 617 for DODAG setup. In addition, DIO messages SHOULD contain a DODAG 618 Configuration option for disseminating the Trickle Timer parameters 619 throughout the network. 621 The possibility of dynamically updating the metrics in use in the 622 network as well as the frequency of network updates allows deployment 623 characteristics (e.g., network density) to be discovered during 624 network bring-up and to be used to tailor network parameters once the 625 network is operational rather than having to rely on precise pre- 626 configuration. This also allows the network parameters and the 627 overall routing protocol behavior to evolve during the lifetime of 628 the network. 630 RPL specifies a number of variables and events that can be tracked 631 for purposes of network fault and performance monitoring of RPL 632 routers. Depending on the memory and processing capabilities of each 633 smart grid device, various subsets of these can be employed in the 634 field. 636 6. Security Considerations 638 Smart grid networks are subject to stringent security requirements as 639 they are considered a critical infrastructure component. At the same 640 time, since they are composed of large numbers of resource- 641 constrained devices inter-connected with limited-throughput links, 642 many available security mechanisms are not practical for use in such 643 networks. As a result, the choice of security mechanisms is highly 644 dependent on the device and network capabilities characterizing a 645 particular deployment. 647 In contrast to other types of LLNs, in smart grid networks 648 centralized administrative control and access to a permanent secure 649 infrastructure is available. As a result link-layer, transport-layer 650 and/or application-layer security mechanisms are typically in place 651 and using RPL's secure mode is not necessary. 653 7. Other Related Protocols 655 This document contains no other related protocols. 657 8. IANA Considerations 659 This memo includes no request to IANA. 661 9. Acknowledgements 663 The authors would like to acknowledge the review, feedback, and 664 comments of Dominique Barthel, Philip Levis, and Jari Arkko. 666 10. References 668 10.1. Informative References 670 [I-D.ietf-6man-rpl-option] 671 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 672 Information in Data-Plane Datagrams", 673 draft-ietf-6man-rpl-option-03 (work in progress), 674 March 2011. 676 [I-D.ietf-roll-p2p-rpl] 677 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie, 678 R., and J. Martocci, "Reactive Discovery of Point-to-Point 679 Routes in Low Power and Lossy Networks", 680 draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011. 682 [I-D.ietf-roll-routing-metrics] 683 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 684 Barthel, "Routing Metrics used for Path Calculation in Low 685 Power and Lossy Networks", 686 draft-ietf-roll-routing-metrics-19 (work in progress), 687 March 2011. 689 [I-D.ietf-roll-rpl] 690 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 691 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 692 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 693 Lossy Networks", draft-ietf-roll-rpl-19 (work in 694 progress), March 2011. 696 [I-D.ietf-roll-terminology] 697 Vasseur, J., "Terminology in Low power And Lossy 698 Networks", draft-ietf-roll-terminology-05 (work in 699 progress), March 2011. 701 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 702 "Routing Requirements for Urban Low-Power and Lossy 703 Networks", RFC 5548, May 2009. 705 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 706 "Industrial Routing Requirements in Low-Power and Lossy 707 Networks", RFC 5673, October 2009. 709 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 710 Routing Requirements in Low-Power and Lossy Networks", 711 RFC 5826, April 2010. 713 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 714 "Building Automation Routing Requirements in Low-Power and 715 Lossy Networks", RFC 5867, June 2010. 717 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 718 "The Trickle Algorithm", RFC 6206, March 2011. 720 10.2. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 Authors' Addresses 727 Daniel Popa 728 Itron 729 52 Rue Camille Desmoulins 730 92448 Issy les Moulineaux 731 France 733 Email: daniel.popa@itron.com 735 Jorjeta Jetcheva 736 Itron 737 2111 N Molter Rd. 738 Liberty Lake, WA 99019 739 USA 741 Email: jorjeta.jetcheva@itron.com 742 Nicolas Dejean 743 Elster SAS 744 Espace Concorde, 120 impasse JB Say 745 Perols, 34470 746 France 748 Email: nicolas.dejean@coronis.com 750 Ruben Salazar 751 Landis+Gyr 752 30000 Mill Creek Ave # 100 753 Alpharetta, GA 30022 755 Email: ruben.salazar@landisgyr.com 757 Jonathan W. Hui 758 Cisco 759 170 West Tasman Drive 760 San Jose, California 95134 761 USA 763 Phone: +408 424 1547 764 Email: jonhui@cisco.com