idnits 2.17.1 draft-ietf-roll-applicability-ami-00.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 (July 25, 2011) is 4653 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) == Outdated reference: A later version (-06) exists of draft-ietf-6man-rpl-option-03 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 26, 2012 N. Dejean 6 Elster 7 R. Salazar 8 Landis+Gyr 9 J. Hui 10 Cisco 11 July 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-00 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 January 26, 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 . . . . . . . . . . . . . . . . . . 4 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.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 64 2.2.1. Meter Data Management . . . . . . . . . . . . . . . . 6 65 2.2.2. Distribution Automation . . . . . . . . . . . . . . . 7 66 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 7 67 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 7 68 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1.1. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 8 71 4.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.4. Objective Function . . . . . . . . . . . . . . . . . . 9 74 4.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.6. Security . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. RPL Options . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.3. Recommended Configuration Defaults and Ranges . . . . . . 10 78 5. Other Related Protocols . . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Informative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Normative References . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Advanced Metering Infrastructure (AMI) systems measure, collect, and 90 analyze energy consumption information. An AMI system enables two- 91 way communication with electricity, water, gas, and/or heat meters. 92 The communication may be scheduled, on exception, or on-demand. 94 AMI networks are composed of millions of endpoints, including meters, 95 distribution automation elements, and home area network devices, 96 typically inter-connected using some combination of wireless 97 technologies and power-line communications, along with a wired or 98 wireless backhaul network providing connectivity to "command-and- 99 control" management software applications at the utility company back 100 office. 102 1.1. Electric Metering 104 In many deployments, in addition to measuring energy consumption, the 105 electric meter network plays a central role in the Smart Grid since 106 it enables the utility company to control and query the electric 107 meters themselves and also since it can serve as a backhaul for all 108 other devices in the Smart Grid, including water and gas meters, 109 distribution automation and home area network devices. Electric 110 meters may also be used as sensors to monitor electric grid quality 111 and support applications such as Electric Vehicle charging. 113 Electric meter networks are composed of millions of smart meters (or 114 nodes), each of which is resource constrained in terms of processing 115 power, storage capabilities, and communication bandwidth, due to a 116 combination of factors including Federal Communications Commission 117 (FCC) or other continents' regulations on spectrum use, American 118 National Standards Institute (ANSI) standards or other continents' 119 regulation on meter behavior and performance, on heat emissions 120 within the meter, form factor and cost considerations. This results 121 in a compromise between range and throughput, with effective link 122 throughput of tens to a few hundred kilobits per second per link, a 123 potentially significant portion of which is taken up by protocol and 124 encryption overhead when strong security measures are in place. 126 Electric meters are often interconnected into multi-hop mesh 127 networks, each of which is connected to a backhaul network leading to 128 the utility network through a network aggregation point (NAP) node. 129 These kinds of networks increase coverage and reduce installation 130 cost, time and complexity, as well as operational costs, as compared 131 to single-hop wireless networks relying on a wired or cellular 132 backhaul. Each electric meter mesh typically has in the order of 133 several thousand wireless endpoints, with densities varying based on 134 the area and the terrain, with apartment buildings in urban centers 135 having possibly hundreds of meters in close proximity, and rural 136 areas having sparse node distributions, including nodes that only 137 have one or two network neighbors. Mesh deployments can exhibit tens 138 of hops between a network device and the nearest aggregation point. 140 1.2. Gas and Water Metering 142 While electric meters can typically consume electricity from the same 143 electric feed that they are monitoring, gas and water meters 144 typically run on a modest source of stored energy (i.e. batteries). 145 In certain scenarios, gas and water meters are integrated with 146 electric meters in the same AMI network. In this scenario, gas and 147 water meters typically do not route messages or operate as hosts to 148 prolong their lifetime. 150 In other scenarios, however, gas and water meters do not have the 151 luxury of communicating with a powered routing infrastructure. 152 Instead, they must communicate through other battery powered devices 153 (i.e. through other gas and water meters) to reach a NAP. 154 Alternative scenarios also include water and/or gas meters 155 communicating directly to a sparsely deployed network infrastructure, 156 requiring increased transmit power levels for increased range that 157 significantly impacts energy consumption and battery lifetime. For 158 such networks, the routing protocol must configure routes with energy 159 consumption in mind. The NAPs, however, are typically mains powered 160 as in AMI networks with electric meters. 162 RPL is designed to operate in energy-constrained environments and 163 includes energy-saving mechanisms (e.g. Trickle timers) and energy- 164 aware metrics. By supporting a number of different metrics and 165 constraints, RPL is also designed to support networks composed of 166 nodes that have vastly different characteristics 167 [I-D.ietf-roll-routing-metrics]. 169 1.3. Routing Protocol for LLNs (RPL) 171 RPL provides routing functionality for mesh networks composed of a 172 large number of resource-constrained devices interconnected by low 173 power and lossy links. Constrained devices within the same network 174 typically communicate through a common aggregation point (e.g., a 175 border router). RPL builds a Directed Acyclic Graph (DAG) routing 176 structure rooted at the aggregation point. It ensures loop-free 177 routing, support for alternate routes, and a wide range of routing 178 metrics and policies. 180 This note describes the applicability of RPL defined in 181 [I-D.ietf-roll-rpl] to AMI deployments. RPL was designed to meet the 182 following application requirements: 184 o Routing Requirements for Urban Low-Power and Lossy Networks 185 [RFC5548]. 187 o Industrial Routing Requirements in Low-Power and Lossy Networks 188 [RFC5673]. 190 o Home Automation Routing Requirements in Low-Power and Lossy 191 Networks [RFC5826]. 193 o Building Automation Routing Requirements in Low-Power and Lossy 194 Networks [RFC5867]. 196 The Routing Requirements for Urban Low-Power and Lossy Networks is 197 most applicable to AMI networks. 199 The terminology used in this document is defined in 200 [I-D.ietf-roll-terminology]. 202 1.4. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in RFC 2119 [RFC2119]. 208 2. Deployment Scenarios 210 2.1. Network Topology 212 AMI networks are composed of millions of endpoints distributed across 213 both urban and rural environments. Such endpoints include electric, 214 gas, and water meters; distribution automation elements; and in-home 215 devices. Devices in the network communicate directly with other 216 devices in close proximity using a variety of low-power and/or lossy 217 link technologies that are both wired and wireless (e.g. IEEE 218 802.15.4, IEEE P1901.2, and WiFi). Network elements may not only 219 source and sink packets, but must also forward packets to reduce the 220 need for dedicated routers and associated deployment costs. 222 In a typical AMI deployment, groups of meters within physical 223 proximity form routing domains. The size of each group in a typical 224 AMI deployment can be from 1000 to 10000 or 15000 meters 226 Powered from the main line electric meters have less energy 227 constraints than battery powered devices and can afford the 228 additional resources required for routing packets. In mixed 229 environments, electric meters provide the routing topology while gas 230 and water meters operate as leaves. However, in networks that cannot 231 afford a powered infrastructure, gas and water meters must either 232 talk directly to a network infrastructure or form their own routing 233 topology, albeit with energy consumption in mind. 235 Each meter routing domain is connected to a larger IP infrastructure 236 through one or more LLN Border Routers (LBRs). The LBRs provide Wide 237 Area Network (WAN) connectivity through more traditional links (e.g. 238 Ethernet, Cellular, Private WAN) or other wireless technologies. 240 The meter networks may also serve as transit networks for other 241 devices, including battery powered gas and water meters, distribution 242 automation elements (i.e. distribution sensors and actuators), and 243 in-home devices. These other devices may utilize a different link- 244 layer technology than the one used in the metering network. 246 2.2. Traffic Characteristics 248 2.2.1. Meter Data Management 250 Meter Data Management (MDM) applications typically require every 251 smart meter to communicate with a few head-end servers deployed in a 252 utility data center. As a result, all smart metering traffic 253 typically flows through the LBRs. In general, the vast majority of 254 traffic flows from smart meter devices to the head-end servers with 255 limited traffic flowing from head-end servers to smart meter devices. 256 In RPL terminology, this traffic flow is also referred to as 257 Multipoint-to-point Traffic (MP2P). 259 Smart meters may generate traffic according to a schedule (e.g. meter 260 read reporting), in response to on-demand queries (e.g. on-demand 261 meter read), or in response to events (e.g. power outages or leak 262 detections). Such traffic is typically unicast since it is sent to a 263 single head-end server. 265 Head-end servers may generate traffic to configure smart metering 266 devices or initiate queries. Head-end servers generate both unicast 267 and multicast traffic to efficiently communicate with a single device 268 or groups of devices. In RPL terminology, this traffic flow is also 269 referred to as Point-to-Multipoint Traffic (P2MP). The head-end 270 server may send a single small packet at a time (e.g. a meter read 271 request or small configuration change) or many large packets in 272 sequence (e.g. a firmware upgrade across one or thousands of 273 devices). 275 While smart metering applications typically do not have hard real- 276 time constraints, they are often subject to stringent latency and 277 reliability service level agreements. Some applications also have 278 stringent latency requirements to function properly. 280 2.2.2. Distribution Automation 282 Distribution Automation (DA) applications typically involve a small 283 number of devices that communicate with each other in a Point-to- 284 Point (P2P) fashion. The DA devices may or may not be in close 285 physical proximity. 287 DA applications typically have more stringent latency requirements 288 than MDM applications. 290 2.2.3. Emerging Applications 292 There are a number of emerging applications (e.g. Electric Vehicle 293 charging) that may involve P2P communication as well. These 294 applications may eventually have more stringent latency requirements 295 than MDM applications. 297 3. Using RPL to Meet Functional Requirements 299 The functional requirements for most AMI deployments are similar to 300 those listed in [RFC5548]. 302 o The routing protocol MUST be capable of supporting the 303 organization of a large number of nodes into regions containing on 304 the order of 10^2 to 10^4 nodes each. 306 o The routing protocol MUST provide mechanisms to support 307 configuration of the routing protocol itself. 309 o The routing protocol SHOULD support and utilize the large number 310 of highly direct flows to a few head-end servers to handle 311 scalability. 313 o The routing protocol MUST dynamically compute and select effective 314 routes composed of low-power and lossy links. Local network 315 dynamics SHOULD NOT impact the entire network. The routing 316 protocol MUST compute multiple paths when possible. 318 o The routing protocol MUST support multicast and anycast 319 addressing. The routing protocol SHOULD support formation and 320 identification of groups of field devices in the network. 322 RPL efficiently supports scalability and highly directed traffic 323 flows between every smart meter and the few head-end servers by 324 building a Directed Acyclic Graph (DAG) rooted at each LBR. 326 RPL supports zero-touch configuration by providing in-band methods 327 for configuring RPL variables using DIO messages. 329 RPL supports time-varying link qualities by allowing the use of 330 metrics that effectively characterize the quality of a path (e.g. 331 Estimated Transmission Count (ETX)). RPL limits the impact of 332 changing local conditions by discovering and maintaining multiple DAG 333 parents and providing a local repair mechanism when all parents have 334 been dropped. 336 4. RPL Profile 338 This section outlines a RPL profile for most representative AMI 339 deployments. 341 4.1. RPL Features 343 4.1.1. Storing vs. Non-Storing Mode 345 In most scenarios, electric meters can utilize the power they are 346 monitoring for their own processing and computation and are not as 347 constrained in energy consumption. Instead, the capabilities of an 348 electric meter are primarily constrained by cost. As a result, 349 different AMI deployments can vary significantly in terms of the 350 memory, computational, and communication trade-offs that were made 351 for their devices. For this reason, the use of RPL storing or non- 352 storing mode SHOULD be deployment specific. 354 When meters are memory constrained and cannot adequately store route 355 tables to support downward routing, non-storing mode is preferred. 356 However, when nodes are capable of adequately storing such routing 357 tables, storing mode can lead to shorter paths and reduce channel 358 utilization near the root. 360 4.1.2. DAO Policy 362 Two-way communication is required in AMI systems. As a result, 363 electric meters SHOULD send DAO messages to establish downward paths 364 back to themselves. 366 4.1.3. Path Metrics 368 Smart metering deployments utilize link technologies that can exhibit 369 significant packet loss. To characterize a path over such link 370 technologies, AMI deployments can use the Expected Transmission Count 371 (ETX) metric as defined in[I-D.ietf-roll-routing-metrics]. 373 For water- and gas-only networks that cannot rely on a powered 374 infrastructure, energy constraints may require simpler metrics that 375 do not require as much energy to compute. In particular, Hop Count 376 and Link Quality Level may be more suitable in such deployments. 377 Other metrics may be vendor-specific or defined at a later time into 378 companion RFCs. 380 4.1.4. Objective Function 382 RPL relies on an Objective Function for selecting parents and 383 computing path costs and rank. This objective function is decoupled 384 from the core RPL mechanisms but also from the metrics in use in the 385 network. Two objective functions for RPL have been defined: 387 o OF0 which does not deal with any metric, 389 o MRHOF which deals with a single metric. 391 Both of them define the selection of a preferred parent and backup 392 parents. Note that these Objective Functions do not support multiple 393 metrics that might be required in heterogeneous networks (i.e. 394 networks composed of devices with varying energy constraints). While 395 RPL provides the flexibility to support additional metrics, a new 396 Objective Function MAY be specified to properly handle additional 397 metrics. 399 4.1.5. DODAG Repair 401 To effectively handle time-varying link characteristics, AMI 402 deployments SHOULD utilize the local repair mechanisms in RPL. 404 The first mechanism for local repair when a node loses its parents is 405 to detach from a DODAG then re-attach to the same or different DODAG 406 at a later time. While detached, a node advertises an infinite rank 407 value so that its children can select a different parent. This 408 process is known as poisoning and described in Section 8.2.2.5 of 409 [I-D.ietf-roll-rpl]. While RPL provides an option to form a local 410 DODAG, doing so in AMI deployments is of little benefit since AMI 411 applications typically communicate through a LBR. After the detached 412 node has made sufficient effort to send notification to its children 413 that it is detached, the node can rejoin the same DODAG with a higher 414 rank value. Note that when joining a different DODAG, the node need 415 not perform poisoning. 417 The second mechanism is a limit on how much a node can increase its 418 rank within a given DODAG Version. Setting the DAGMaxRankIncrease to 419 a non-zero value enables this local repair mechanism. Setting 420 DAGMaxRankIncrease to a value less than infinity limits the cost of 421 count-to-infinity scenarios when they occur. 423 The third mechanism is loop detection, enabled by including the rank 424 value of a node in packets forwarded towards the root in RPL Packet 425 Information [I-D.ietf-6man-rpl-option]. Note that loop detection is 426 not needed when sending packets using strict source routing. 428 4.1.6. Security 430 AMI deployments operate in areas that do not provide any physical 431 security. For this reason, the link technologies used within AMI 432 deployments typically provide security mechanisms to ensure 433 confidentiality, integrity, and freshness. As a result, AMI 434 deployments may not need to implement RPL's security mechanisms and 435 could rely on link layer security features. 437 4.2. RPL Options 439 4.3. Recommended Configuration Defaults and Ranges 441 o AMI deployments can involve densities of hundreds of devices 442 within communication range. As a result, such networks SHOULD set 443 the DIOIntervalMin to 16 or more, giving a Trickle Imin of 1 444 minute or more. For low-energy consumption operations, such 445 networks SHOULD set DIOIntervalMin be set to a higher value. 447 o AMI deployments SHOULD set DIOIntervalDoublings to a value that 448 gives a Trickle Imax of 2 hours or more. For low-energy 449 consumption operations, such networks SHOULD set 450 DIOIntervalDoublings to a value that gives a Trickle Imax of e.g. 451 2 days. 453 o AMI deployments SHOULD set DIORedundancyConstant to a value of 10 454 or more. 456 o AMI deployments SHOULD set MinHopRankIncrease to 256, giving 8 457 bits of resolution (e.g. for the ETX metric). 459 o To enable local repair, AMI deployments SHOULD set MaxRankIncrease 460 to a value that allows a device to move a small number of hops 461 away from the root. With a MinHopRankIncrease of 256, a 462 MaxRankIncrease of 1024 would allow a device to move up to 4 hops 463 away. 465 5. Other Related Protocols 467 This document contains no other related protocols. 469 6. IANA Considerations 471 This memo includes no request to IANA. 473 7. Security Considerations 475 This memo includes no security considerations. 477 8. Acknowledgements 479 The authors would like to acknowledge the review, feedback, and 480 comments from Dominique Barthel. 482 9. References 484 9.1. Informative References 486 [I-D.ietf-6man-rpl-option] 487 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 488 Information in Data-Plane Datagrams", 489 draft-ietf-6man-rpl-option-03 (work in progress), 490 March 2011. 492 [I-D.ietf-roll-routing-metrics] 493 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 494 Barthel, "Routing Metrics used for Path Calculation in Low 495 Power and Lossy Networks", 496 draft-ietf-roll-routing-metrics-19 (work in progress), 497 March 2011. 499 [I-D.ietf-roll-rpl] 500 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 501 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 502 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 503 Lossy Networks", draft-ietf-roll-rpl-19 (work in 504 progress), March 2011. 506 [I-D.ietf-roll-terminology] 507 Vasseur, J., "Terminology in Low power And Lossy 508 Networks", draft-ietf-roll-terminology-05 (work in 509 progress), March 2011. 511 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 512 "Routing Requirements for Urban Low-Power and Lossy 513 Networks", RFC 5548, May 2009. 515 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 516 "Industrial Routing Requirements in Low-Power and Lossy 517 Networks", RFC 5673, October 2009. 519 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 520 Routing Requirements in Low-Power and Lossy Networks", 521 RFC 5826, April 2010. 523 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 524 "Building Automation Routing Requirements in Low-Power and 525 Lossy Networks", RFC 5867, June 2010. 527 9.2. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 Authors' Addresses 534 Daniel Popa 535 Itron 537 Email: daniel.popa@itron.com 539 Jorjeta Jetcheva 540 Itron 541 2111 N Molter Rd. 542 Liberty Lake, WA 543 USA 545 Phone: +408 688 1428 546 Email: jorjeta.jetcheva@itron.com 548 Nicolas Dejean 549 Elster 551 Email: nicolas.dejean@coronis.com 553 Ruben Salazar 554 Landis+Gyr 556 Email: ruben.salazar@landisgyr.com 557 Jonathan W. Hui 558 Cisco 559 170 West Tasman Drive 560 San Jose, California 95134 561 USA 563 Phone: +408 424 1547 564 Email: jonhui@cisco.com