idnits 2.17.1 draft-ietf-roll-applicability-ami-08.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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 == Line 265 has weird spacing: '...al grid is a ...' == Line 349 has weird spacing: '...amilies in a ...' == Line 440 has weird spacing: '...port of a ful...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 2014) is 3723 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) == Missing Reference: 'I-D.ietf-roll-terminology-13' is mentioned on line 194, but not defined == Missing Reference: 'RFC6282' is mentioned on line 733, but not defined == Unused Reference: 'IEEE1901.2' is defined on line 902, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5548 ** Downref: Normative reference to an Informational RFC: RFC 5867 ** Downref: Normative reference to an Informational RFC: RFC 5826 ** Downref: Normative reference to an Informational RFC: RFC 5673 ** Downref: Normative reference to an Experimental RFC: RFC 6997 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Roll D. Popa 3 Internet-Draft M. Gillmore 4 Intended status: Standards Track Itron, Inc 5 Expires: August 03, 2014 L. Toutain 6 Telecom Bretagne 7 J. Hui 8 Cisco 9 R. Ruben 10 Landis+Gyr 11 K. Monden 12 Hitachi, Ltd., Yokohama Research Laboratory 13 February 2014 15 Applicability Statement for the Routing Protocol for Low Power and Lossy 16 Networks (RPL) in AMI Networks 17 draft-ietf-roll-applicability-ami-08 19 Abstract 21 This document discusses the applicability of RPL in Advanced Metering 22 Infrastructure (AMI) networks. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 03, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 3 61 2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4 62 3. Description of AMI networks for electric meters . . . . . . . 4 63 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5 64 4. Smart Grid Traffic Description . . . . . . . . . . . . . . . . 7 65 4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . . 7 66 4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8 67 4.3. RPL applicability per Smart Grid Traffic Characteristics . 8 68 5. Layer 2 applicability. . . . . . . . . . . . . . . . . . . . . 9 69 5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . . 9 70 5.2. IEEE PowerLine Communication (PLC) technology . . . . . . 9 71 6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10 72 7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11 75 7.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 11 76 7.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 11 78 7.1.5. Objective Function . . . . . . . . . . . . . . . . . . 12 79 7.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 12 80 7.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 13 81 7.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.1.9. Peer-to-Peer communications . . . . . . . . . . . . . 13 83 7.2. Description of Layer-two features . . . . . . . . . . . . 13 84 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . . 13 85 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . . 14 86 7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . . 14 87 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 16 88 7.4. Recommended Configuration Defaults and Ranges . . . . . . 16 89 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 16 90 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . . 18 91 8. Manageability Considerations . . . . . . . . . . . . . . . . . 18 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 9.1. Security Considerations during initial deployment . . . . 19 94 9.2. Security Considerations during incremental deployment . . 19 95 10. Other Related Protocols . . . . . . . . . . . . . . . . . . . 20 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 13.1. Informative References . . . . . . . . . . . . . . . . . 20 100 13.2. Normative references . . . . . . . . . . . . . . . . . . 20 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 103 1. Introduction 105 Advanced Metering Infrastructure (AMI) systems enable the 106 measurement, configuration, and control of energy, gas and water 107 consumption and distribution, through two-way scheduled, on 108 exception, and on-demand communication. 110 AMI networks are composed of millions of endpoints, including meters, 111 distribution automation elements, and eventually home area network 112 devices. They are typically inter-connected using some combination 113 of wireless and power-line communications, forming the so-called 114 Neighbor Area Network (NAN) along with a backhaul network providing 115 connectivity to "command-and-control" management software 116 applications at the utility company back office. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 1.2. Required Reading 126 [surveySG] gives an overview of Smart Grid architecture and related 127 applications. 129 NAN can use wireless communication technology in which case is using, 130 from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer 131 amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically 132 adapted to smart grid networks. 134 NAN can also use PLC (Power Line Communication) technology as an 135 alternative to wireless communications. Several standards for PLC 136 technology have emerged, such as IEEE P1901.2. 138 NAN can further use a mix of wireless and PLC technologies to 139 increase the network coverage ratio, a critical requirement for AMI 140 networks. 142 1.3. Out of scope requirements 144 The following are outside the scope of this document: 146 o Applicability statement for RPL in AMI networks composed of 147 battery-powered devices (i.e., gas/water meters). 149 o Applicability statement for RPL in AMI networks composed of a mix 150 of AC powered devices (i.e., electric meters) and battery-powered 151 meters (i.e., gas/water meters). 153 o Applicability statement for RPL storing mode of operation in AMI 154 networks. 156 2. Routing Protocol for LLNs (RPL) 158 RPL provides routing functionality for mesh networks that can scale 159 up to thousands of resource-constrained devices, interconnected by 160 low power and lossy links, and communicating with the external 161 network infrastructure through a common aggregation point(s) (e.g., a 162 LBR). 164 RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at 165 a LBR (LLN Border Router), ensures loop-free routing, and provides 166 support for alternate routes, as well as, for a wide range of routing 167 metrics and policies. 169 RPL was designed to operate in energy-constrained environments and 170 includes energy-saving mechanisms (e.g., Trickle timers) and energy- 171 aware metrics. RPL's ability to support multiple different metrics 172 and constraints at the same time enables it to run efficiently in 173 heterogeneous networks composed of nodes and links with vastly 174 different characteristics [RFC6551]. 176 This document describes the applicability of RPL non-storing mode (as 177 defined in [RFC6550]) to AMI deployments. RPL was designed to meet 178 the following application requirements: 180 o Routing Requirements for Urban Low-Power and Lossy Networks 181 [RFC5548]. 183 o Industrial Routing Requirements in Low-Power and Lossy Networks 184 [RFC5673]. 186 o Home Automation Routing Requirements in Low-Power and Lossy 187 Networks [RFC5826]. 189 o Building Automation Routing Requirements in Low-Power and Lossy 190 Networks [RFC5867]. 192 The Routing Requirements for Urban Low-Power and Lossy Networks are 193 applicable to AMI networks as well. The terminology used in this 194 document is defined in [I-D.ietf-roll-terminology-13]. 196 3. Description of AMI networks for electric meters 198 In many deployments, in addition to measuring energy consumption, the 199 electric meter network plays a central role in the Smart Grid since 200 the device enables the utility company to control and query the 201 electric meters themselves and can serve as a backhaul for all other 202 devices in the Smart Grid, e.g., water and gas meters, distribution 203 automation and home area network devices. Electric meters may also 204 be used as sensors to monitor electric grid quality and to support 205 applications such as Electric Vehicle charging. 207 Electric meter networks can be composed of millions of smart meters 208 (or nodes), each of which is resource-constrained in terms of 209 processing power, storage capabilities, and communication bandwidth, 210 due to a combination of factors including Federal Communications 211 Commission (FCC) or other continents' regulations on spectrum use, 212 American National Standards Institute (ANSI) standards or other 213 continents' regulation on meter behavior and performance, on heat 214 emissions within the meter, form factor and cost considerations. 215 These constraints result in a compromise between range and 216 throughput, with effective link throughput of tens to a few hundred 217 kilobits per second per link, a potentially significant portion of 218 which is taken up by protocol and encryption overhead when strong 219 security measures are in place. 221 Electric meters are often interconnected into multi-hop mesh 222 networks, each of which is connected to a backhaul network leading to 223 the utility company network through a network aggregation point, 224 e.g., an LBR. 226 3.1. Deployment Scenarios 228 AMI networks are composed of millions of endpoints distributed across 229 both urban and rural environments. Such endpoints can include 230 electric, gas, and water meters, distribution automation elements, 231 and home area network devices. 233 Devices in the network communicate directly with other devices in 234 close proximity using a variety of low-power and/or lossy link 235 technologies that are both wireless and wired (e.g., IEEE 802.15.4g, 236 IEEE 802.15.4e, IEEE 1901.2, IEEE 802.11). In addition to serving as 237 sources and destinations of packets, many network elements typically 238 also forward packets and thus form a mesh topology. 240 In a typical AMI deployment, groups of meters within physical 241 proximity form routing domains, each in the order of a 1,000 to 242 10,000 meters. Thus, each electric meter mesh typically has several 243 thousand wireless endpoints, with densities varying based on the area 244 and the terrain. 246 | 247 +M 248 | 249 M M M M | M 250 /-----------\ /---+---+---+---+--+-+- phase 1 251 +----+ ( Internet ) +----+ / M M M M 252 |MDMS|---( )----|LBR |/----+----+----+----+---- phase 2 253 +----+ ( WAN ) +----+\ 254 \----------/ \ M M M M 255 \--+--+----+-+---+----- phase 3 256 \ M M 257 +--+---+-- 258 <----------------------------> 259 RPL 261 A typical AMI network architecture (see figure Figure 1) is composed 262 of a MDMS (Meter Data Management System) connected through IP network 263 to a LBR, which can be located in the power substation or somewhere 264 else in the field. The power substation connects the households and 265 buildings. The physical topology of the electrical grid is a tree 266 structure, either due to the 3 different power phases coming through 267 the sub-station or just to the electrical network topology. Meters 268 (represented by a M in the previous figure) can also participate to a 269 HAN (Home-Area Network). The scope of this document is the 270 communication between the LBR and the meters,i.e., the NAN segment. 272 Node density can vary significantly. For example, apartment 273 buildings in urban centers may have hundreds of meters in close 274 proximity, whereas rural areas may have sparse node distributions and 275 include nodes that only have a small number of network neighbors. 276 Each routing domain is connected to the larger IP infrastructure 277 through one or more LBRs, which provide Wide Area Network (WAN) 278 connectivity through various traditional network technologies, e.g., 279 Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in 280 the mesh between a network node and the nearest LBR may be composed 281 of several hops or even several tens of hops. Powered from the main 282 line, electric meters have less energy constraints than battery 283 powered devices, such as gas and water meters, and can afford the 284 additional resources required to route packets. 286 As a function of the the technology used to exchange information, the 287 logical network topology will not necessarily match the eletric grid 288 topology. If meters exchange information through radio technologies 289 such as in IEEE 802.15.4 family, the topology is a meshed network, 290 where nodes belonging to the same DODAG can be connected to the grid 291 through different substations. If narrowband PLC technology is used, 292 it will follow more or less the physical tree structure since 293 diaphony may allow one phase to communicate with the other. This is 294 particularly true near the LBR. Some mixt topology can also be 295 observed, since some LBR may be strategically installed in the field 296 to avoid all the communications going through a single LBR. 297 Nethertheless, the short propagation range forces meters to relay the 298 information. 300 4. Smart Grid Traffic Description 302 4.1. Smart Grid Traffic Characteristics 304 In current AMI deployments, metering applications typically require 305 all smart meters to communicate with a few head-end servers, deployed 306 in the utility company data center. Head-end servers generate data 307 traffic to configure smart meter data reading or initiate queries, 308 and use unicast and multicast to efficiently communicate with a 309 single device (i.e., Point-to-Point (P2P) communications) or groups 310 of devices respectively (i.e., Point-to-Multipoint (P2MP) 311 communication). The head-end server may send a single small packet 312 at a time to the meters (e.g., a meter read request, a small 313 configuration change, service switch command) or a series of large 314 packets (e.g., a firmware download across one or even thousands of 315 devices). The frequency of large file transfers, e.g., firmware 316 download of all metering devices, is typically much lower than the 317 frequency of sending configuration messages or queries. Each smart 318 meter generates Smart Metering Data (SMD) traffic according to a 319 schedule (e.g., periodic meter reads), in response to on-demand 320 queries (e.g., on-demand meter reads), or in response to some local 321 event (e.g., power outage, leak detection). Such traffic is 322 typically destined to a single head-end server. The SMD traffic is 323 thus highly asymmetric, where the majority of the traffic volume 324 generated by the smart meters typically goes through the LBRs, and is 325 directed from the smart meter devices to the head-end servers, in a 326 MP2P fashion. Current SMD traffic patterns are fairly uniform and 327 well-understood. The traffic generated by the head-end server and 328 destined to metering devices is dominated by periodic meter reads, 329 while traffic generated by the metering devices is typically 330 uniformly spread over some periodic read time-window. 332 Smart metering applications typically do not have hard real-time 333 constraints, but they are often subject to bounded latency and 334 stringent reliability service level agreements. 336 Distribution Automation (DA) applications typically involve a small 337 number of devices that communicate with each other in a Point-to- 338 Point (P2P) fashion, and may or may not be in close physical 339 proximity. DA applications typically have more stringent latency 340 requirements than SMD applications. 342 There are also a number of emerging applications such as electric 343 vehicle charging. These applications may require P2P communication 344 and may eventually have more stringent latency requirements than SMD 345 applications. 347 4.2. Smart Grid Traffic QoS Requirements 349 As described previously, the two main traffic families in a NAN are: 351 A) Meter-initiated traffic (Meter-to-head-end - M2HE) 353 B) Head-end-initiated traffic (Head-end-to-meter - HE2M) 355 B1) request is sent in point-to-point to a specific meter 357 B2) request is sent in multicast to a subset of meters 359 B3) request is sent in multicast to all meters 361 The M2HE are event-based, while the HE2M are mostly command-response. 362 In most cases, M2HE traffic is more critical than HE2M one, but there 363 can be exceptions. 365 Regarding priority, traffic may also be decomposed into several 366 classes : 368 C1) Highly Priority Critical traffic for Power System Outage, Pricing 369 Events and Emergency Messages require a 98%+ packet delivery under 370 5 s. Payload size < 100 bytes 372 C2) Critical Priority traffic Power Quality Events, Meter Service 373 Connection and Disconnection require 98%+ packet delivery under 374 10s. Payload size < 150 bytes 376 C3) Normal Priority traffic for System Events including Faults, 377 Configuration and Security require 98%+ packet delivery under 30s. 378 Payload size < 200 bytes 380 C4) Low Priority traffic for Recurrent Meter Reading require 98%+ 381 packet 2 hour delivery window 6 times per day. Payload size < 400 382 bytes 384 C5) Background Priority traffic for firmware/software updates 385 processed to 98%+ of devices with in 7 days. Average firmware 386 update is 1 MB. 388 4.3. RPL applicability per Smart Grid Traffic Characteristics 389 RPL non-storing mode of operation naturally support upstream and 390 downstream forwarding of unicast traffic between the DODAG root and 391 each DODAG node, and between DODAG nodes and DODAG root, 392 respectively. 394 Group communication model used in smart grid requires RPL non-storing 395 mode of operation to support downstream forwarding of multicast 396 traffic with a scope larger than link-local. The DODAG root is the 397 single device that injects multicast traffic, with a scope larger 398 than link-local, into the DODAG. 400 Altough not currently used in metering applications, support of peer- 401 to-peer communications between DODAG nodes is identified as a key 402 feature to be supported in smart grid networks. 404 5. Layer 2 applicability. 406 5.1. IEEE Wireless Technology 408 IEEE Std. 802.15.4g-2012 and IEEE 802.15.4e-2012 amendments to 409 802.15.2-2011 standard have been specifically developed for smart 410 grid networks. They are the most common PHY and MAC layers used for 411 wireless AMI network. 802.15.4g specifies multiple mode of operation 412 (FSK, OQPSK and OFDM modulations) with speeds from 50kbps to 600kbps, 413 and allows for transport of a full IPv6 packet (i.e., 1280 octets) 414 without the need for upper layer segmentation and re-assembly. 416 IEEE Std. 802.15.4e-2012 is an amendment to IEEE Std 802.15.4-2011 417 that specifies additional media access control (MAC) behaviors and 418 frame formats that allow IEEE 802.15.4 devices to support a wide 419 range of industrial and commercial applications that were not 420 adequately supported prior to the release of this amendment. It is 421 important to notice that 802.15.4e does not change the link-layer 422 security scheme defined in 802.15.4-2011 (and 802.15.4-2006). 424 5.2. IEEE PowerLine Communication (PLC) technology 426 The IEEE Std 1901.2-2013 standard specifies communications for low 427 frequency (less than 500 kHz) narrowband power line devices via 428 alternating current and direct current electric power lines. IEEE 429 Std 1901.2-2013 standard supports indoor and outdoor communications 430 over low voltage line (line between transformer and meter, less than 431 1000 V), through transformer low- voltage to medium-voltage (1000 V 432 up to 72 kV) and through transformer medium-voltage to low-voltage 433 power lines in both urban and in long distance (multi- kilometer) 434 rural communications. IEEE Std 1901.2 defines the PHY layer and the 435 MAC sub-layer of the data link layer. The MAC sub-layer endorses a 436 sub-set of 802.15.4-2006 and 802.15.4e-2012 MAC sub-layer features. 438 1901.2 PHY Layer bit rates defined in 1901.2 are scalable to 500 kbps 439 depending on the application requirements and type of encoding used. 440 1901.2 MAC layer allows for transport of a full IPv6 packets (i.e., 441 1280 octets) without the need for upper layer segmentation and re- 442 assembly. 1901.2 standard specifies link-layer security features 443 that fully endorse 802.15.4-2006 MAC sub-layer security scheme. 445 6. Using RPL to Meet Functional Requirements 447 The functional requirements for most AMI deployments are similar to 448 those listed in [RFC5548]: 450 o The routing protocol MUST be capable of supporting the 451 organization of a large number of nodes into regions containing on 452 the order of 10^2 to 10^4 nodes each. 454 o The routing protocol MUST provide mechanisms to support 455 configuration of the routing protocol itself. 457 o The routing protocol SHOULD support and utilize the large number 458 of highly directed flows to a few head-end servers to handle 459 scalability. 461 o The routing protocol MUST dynamically compute and select effective 462 routes composed of low-power and lossy links. Local network 463 dynamics SHOULD NOT impact the entire network. The routing 464 protocol MUST compute multiple paths when possible. 466 o The routing protocol MUST support multicast and unicast 467 addressing. The routing protocol SHOULD support formation and 468 identification of groups of field devices in the network. 470 RPL supports the following features: 472 o Scalability: Large-scale networks characterized by highly directed 473 traffic flows between each smart meter and the head-end servers in 474 the utility network. To this end, RPL builds a Directed Acyclic 475 Graph (DAG) rooted at each LBR. 477 o Zero-touch configuration: This is done through in-band methods 478 for configuring RPL variables using DIO messages, and DIO message 479 options. 481 o The use of links with time-varying quality characteristics: This 482 is accomplished by allowing the use of metrics that effectively 483 capture the quality of a path (e.g., Expected Transmission Count 484 (ETX)) and by limiting the impact of changing local conditions by 485 discovering and maintaining multiple DAG parents, and by using 486 local repair mechanisms when DAG links break. 488 7. RPL Profile 490 7.1. RPL Features 492 7.1.1. RPL Instances 494 RPL operation is defined for a single RPL instance. However, 495 multiple RPL instances can be supported in multi-service networks 496 where different applications may require the use of different routing 497 metrics and constraints, e.g., a network carrying both SDM and DA 498 traffic. 500 7.1.2. Storing vs. Non-Storing Mode 502 In most scenarios, electric meters are powered by the grid they are 503 monitoring and are not energy-constrained. Instead, electric meters 504 have hardware and communication capacity constraints that are 505 primarily determined by cost, and secondarily by power consumption. 506 As a result, different AMI deployments can vary significantly in 507 terms of memory size, computation power and communication 508 capabilities. For this reason, the use of RPL storing or non-storing 509 mode SHOULD be deployment specific. When meters are memory 510 constrained and cannot adequately store the route tables necessary to 511 support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. 512 On the other hand, when nodes are capable of storing such routing 513 tables, the use of storing mode may lead to reduced overhead and 514 route repair latency. However, in high-density environments, storing 515 routes can be challenging because some nodes may have to maintain 516 routing information for a large number of descendents. In this 517 document we only focus on non-storing mode of operation. 519 7.1.3. DAO Policy 521 Two-way communication is a requirement in AMI systems. As a result, 522 nodes SHOULD send DAO messages to establish downward paths from the 523 root to themselves. 525 7.1.4. Path Metrics 527 Smart metering deployments utilize link technologies that may exhibit 528 significant packet loss and thus require routing metrics that take 529 packet loss into account. To characterize a path over such link 530 technologies, AMI deployments can use the Expected Transmission Count 531 (ETX) metric as defined in [RFC6551]. 533 Additional metrics may be defined in companion RFCs. 535 7.1.5. Objective Function 537 RPL relies on an Objective Function for selecting parents and 538 computing path costs and rank. This objective function is decoupled 539 from the core RPL mechanisms and also from the metrics in use in the 540 network. Two objective functions for RPL have been defined at the 541 time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of 542 which define the selection of a preferred parent and backup parents, 543 and are suitable for AMI deployments. Additional objective functions 544 may be defined in companion RFCs. 546 7.1.6. DODAG Repair 548 To effectively handle time-varying link characteristics and 549 availability, AMI deployments SHOULD utilize the local repair 550 mechanisms in RPL. Local repair is triggered by broken link 551 detection. The first local repair mechanism consists of a node 552 detaching from a DODAG and then re-attaching to the same or to a 553 different DODAG at a later time. While detached, a node advertises 554 an infinite rank value so that its children can select a different 555 parent. This process is known as poisoning and is described in 556 Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a 557 local DODAG, doing so in AMI for electric meters is of little benefit 558 since AMI applications typically communicate through a LBR. After 559 the detached node has made sufficient effort to send notification to 560 its children that it is detached, the node can rejoin the same DODAG 561 with a higher rank value. The configured duration of the poisoning 562 mechanism needs to take into account the disconnection time 563 applications running over the network can tolerate. Note that when 564 joining a different DODAG, the node need not perform poisoning. The 565 second local repair mechanism controls how much a node can increase 566 its rank within a given DODAG Version (e.g., after detaching from the 567 DODAG as a result of broken link or loop detection). Setting the 568 DAGMaxRankIncrease to a non-zero value enables this mechanism, and 569 setting it to a value of less than infinity limits the cost of count- 570 to-infinity scenarios when they occur, thus controlling the duration 571 of disconnection applications may experience. 573 7.1.7. Multicast 575 Multicast support for RPL in non-storing mode are being developed in 576 companion RFCs (see [draft-ietf-roll-trickle-mcast-06]). 578 7.1.8. Security 580 AMI deployments operate in areas that do not provide any physical 581 security. For this reason, the link layer, transport layer and 582 application layer technologies utilized within AMI networks typically 583 provide security mechanisms to ensure authentication, 584 confidentiality, integrity, and freshness. As a result, AMI 585 deployments may not need to implement RPL's security mechanisms and 586 could rely on link layer and higher layer security features. 588 7.1.9. Peer-to-Peer communications 590 Basic peer-to-peer capabilities are already defined in the RPL 591 [RFC6550]. Additional mechanisms for peer-to-peer communications are 592 proposed in companion RFCs (see [RFC6997]). 594 7.2. Description of Layer-two features 596 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features 598 IEEE 1901.2 physical is based on OFDM modulation and defines a time 599 frequency interleaver over the entire PHY frame coupled with a Reed 600 Solomon and Viterbi Forward Error Correction for maximum robustness. 601 Since the noise level in each OFDM sub-carrier can vary significantly 602 IEEE 1901.2 specifies two complementary mechanisms allowing to fine- 603 tune the robustness/performance tradeoff implicit in such systems. 605 More specifically, the first (coarse-grained) mechanism, defines the 606 modulation from several possible choices (robust (super-ROBO, ROBO), 607 BPSK, QPSK,...). The second (fine-grained) maps the sub-carriers 608 which are too noisy and deactivates them. 610 The existence of multiple modulations and dynamic frequency exclusion 611 renders the problem of selecting a path between two nodes non- 612 trivial, as the possible number of combinations increases 613 significantly, e.g. use a direct link with slow robust modulation, 614 or use a relay meter with fast modulation and 12 disabled sub- 615 carriers. In addition, IEEE 1901.2 technology offers a mechanism 616 (adaptive tone map) for periodic exchanges on the link quality 617 between nodes to constantly react to channel fluctuations. Every 618 meter keeps a state of the quality of the link to each of its 619 neighbors by either piggybacking the tone mapping on the data 620 traffic, or by sending explicit tone map requests. 622 IEEE 1901.2 MAC frame format shares most in common with the IEEE 623 802.15.4-2006 MAC frame format [IEEE802.15.4], with a few exceptions 624 described bellow. 626 o IEEE 1901.2 MAC frame is obtained by prepending a Segment Control 627 Field to the IEEE 802.15.4-2006 MAC header. One function of the 628 Segment Control Field is to signal the use of the MAC sub-layer 629 segmentation and reassembly. 631 o IEEE 1901.2 MAC frames uses only the 802.15.4 MAC addresses with a 632 length of 16 and 64 bits. 634 o IEEE 1901.2 MAC sub-layer endorses the concept of Information 635 Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The 636 format and use of Information Elements are not relevant to RPL 637 applicability statement. 639 The IEEE 1901.2 PHY frame payload size varies as a function of the 640 modulation used to transmit the frame and the strength of the Forward 641 Error Correction scheme. 643 The maximum IEEE 1901.2 PHY frame payload is 512 bytes. The maximum 644 IEEE 1901.2 MAC frame payload is 1280 bytes, which supports the IPv6 645 minimum MTU requirement. 647 When there is a mistmatch between the PHY frame payload size and the 648 size of a MAC frame carrying an IPv6 packet, IEEE 1901.2 specifies a 649 MAC sub-layer segmentation and re-assembly mechanism that provides a 650 reliable one-hop transfer of that MAC frame segments. 652 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features 654 This section is intentionally left blank. 656 7.2.3. IEEE MAC sub-layer Security Features 657 Since IEEE 1901.2 standard is based on the 802.15.4-2006 MAC sub- 658 layer and fully endorses the security scheme defined in 659 802.15.4-2006, we only focus on description of IEEE 802.15.4 security 660 scheme. 662 The IEEE 802.15.4 specification was designed to support a variety of 663 applications, many of which are security sensitive. The IEEE 664 802.15.4 provides four basic security services: message 665 authentication, message integrity, message confidentiality, and 666 freshness checks to avoid replay attacks. 668 The 802.15.4 security layer is handled at the media access control 669 layer, below 6LowPAN layer. The application specifies its security 670 requirements by setting the appropriate control parameters into the 671 radio/PLC stack. The 802.15.4 defines four packet types: beacon 672 frames, data frames, acknowledgments frame, and command frames for 673 the media access control layer. The 802.15.4 specification does not 674 support security for acknowledgement frames; data frames, beacon 675 frames and command frames can support integrity protection and 676 confidentiality protection for the frames's data field. An 677 application has a choice of security suites that control the type of 678 security protection that is provided for the transmitted MAC frame. 679 The 802.15.4 specification defines eight different security suites, 680 outlined bellow. We can broadly classify the suites by the 681 properties that they offer: no security, encryption only (AES-CTR), 682 authentication only (AES-CBC-MAC), and encryption and authentication 683 (AES-CCM). Each category that supports authentication comes in three 684 variants depending on the size of the MAC (Message Authentication 685 Control) that it offers. The MAC can be either 4, 8, or 16 bytes 686 long. Additionally, for each suite that offers encryption, the 687 recipient can optionally enable replay protection. 689 o Null = No security. 691 o AES-CTR = Encryption only, CTR mode. 693 o AES-CBC-MAC-128 = No encryption, 128-bit MAC. 695 o AES-CBC-MAC-64 = No encryption, 64-bit MAC. 697 o AES-CCM-128 = Encryption and 128-bit MAC. 699 o AES-CCM-64 = Encryption and 64-bit MAC. 701 o AES-CCM-32 = Encryption and 32-bit MAC. 703 To achieve authentication, any device can maintain an Access Control 704 List (ACL) which is a list of trusted nodes from which the device 705 wishes to receive data. Data encryption is done by encryption of 706 Message Authentication Control (MAC) frame payload using the key 707 shared between two devices, or among a group of peers. If the key is 708 to be shared between two peers, it is stored with each entry in the 709 ACL list; otherwise, the key is stored as the default key. Thus, the 710 device can make sure that its data can not be read by devices that do 711 not possess the corresponding key. However, device addresses are 712 always transmitted unencrypted, which makes attacks that rely on 713 device identity somewhat easier to launch. Integrity service is 714 applied by appending a Message Integrity Code (MIC) generated from 715 blocks of encrypted message text. This ensures that a frame can not 716 be modified by a receiver device that does not share a key with the 717 sender. Finally, sequential freshness uses a frame counter and key 718 sequence counter to ensure the freshness of the incoming frame and 719 guard against replay attacks. 721 A cryptographic MAC is used to authenticate messages. While longer 722 MACs lead to improved resiliency of the code, they also make packet 723 size larger and thus take up bandwidth in the network. In 724 constrained environments such as metering infrastructures, an optimum 725 balance between security requirements and network throughput must be 726 found. 728 7.3. 6LowPAN Options 730 AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all 731 of the IPv6 Header Compression schemes specified in [RFC6282] Section 732 3 and all of the IPv6 Next Header compression schemes specified in 733 [RFC6282] Section 4, if reducing over the air/wire overhead is a 734 requirement. However, since the link-layer MTU in both wireless and 735 PLC links supports the transmission of a full IPv6 packet, the use of 736 6LowPAN fragmentation is NOT RECOMMENDED. 738 7.4. Recommended Configuration Defaults and Ranges 740 7.4.1. Trickle Parameters 741 Trickle was designed to be density-aware and perform well in networks 742 characterized by a wide range of node densities. The combination of 743 DIO packet suppression and adaptive timers for sending updates allows 744 Trickle to perform well in both sparse and dense environments. Node 745 densities in AMI deployments can vary greatly, from nodes having only 746 one or a handful of neighbors to nodes having several hundred 747 neighbors. In high density environments, relatively low values for 748 Imin may cause a short period of congestion when an inconsistency is 749 detected and DIO updates are sent by a large number of neighboring 750 nodes nearly simultaneously. While the Trickle timer will 751 exponentially backoff, some time may elapse before the congestion 752 subsides. While some link layers employ contention mechanisms that 753 attempt to avoid congestion, relying solely on the link layer to 754 avoid congestion caused by a large number of DIO updates can result 755 in increased communication latency for other control and data traffic 756 in the network. To mitigate this kind of short-term congestion, this 757 document recommends a more conservative set of values for the Trickle 758 parameters than those specified in [RFC6206]. In particular, 759 DIOIntervalMin is set to a larger value to avoid periods of 760 congestion in dense environments, and DIORedundancyConstant is 761 parameterized accordingly as described below. These values are 762 appropriate for the timely distribution of DIO updates in both sparse 763 and dense scenarios while avoiding the short-term congestion that 764 might arise in dense scenarios. Because the actual link capacity 765 depends on the particular link technology used within an AMI 766 deployment, the Trickle parameters are specified in terms of the 767 link's maximum capacity for transmitting link-local multicast 768 messages. If the link can transmit m link-local multicast packets 769 per second on average, the expected time it takes to transmit a link- 770 local multicast packet is 1/m seconds. 772 DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that 773 the Trickle Imin is at least 50 times as long as it takes to 774 transmit a link-local multicast packet. This value is larger than 775 that recommended in [RFC6206] to avoid congestion in dense urban 776 deployments as described above. In energy-constrained deployments 777 (e.g., in water and gas battery-based routing infrastructure), 778 DIOIntervalMin MAY be set to a value resulting in a Trickle Imin 779 of several (e.g. 2) hours. 781 DIOIntervalDoublings: AMI deployments SHOULD set DIOIntervalDoublings 782 such that the Trickle Imax is at least 2 hours or more. For very 783 energy constrained deployments (e.g., water and gas battery-based 784 routing infrastructure), DIOIntervalDoublings MAY be set to a 785 value resulting in a Trickle Imax of several (e.g., 2) days. 787 DIORedundancyConstant: AMI deployments SHOULD set 788 DIORedundancyConstant to a value of at least 10. This is due to 789 the larger chosen value for DIOIntervalMin and the proportional 790 relationship between Imin and k suggested in [RFC6206]. This 791 increase is intended to compensate for the increased communication 792 latency of DIO updates caused by the increase in the 793 DIOIntervalMin value, though the proportional relationship between 794 Imin and k suggested in [RFC6206] is not preserved. Instead, 795 DIORedundancyConstant is set to a lower value in order to reduce 796 the number of packet transmissions in dense environments. 798 7.4.2. Other Parameters 800 o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 801 8 bits of resolution (e.g., for the ETX metric). 803 o To enable local repair, AMI deployments SHOULD set MaxRankIncrease 804 to a value that allows a device to move a small number of hops 805 away from the root. With a MinHopRankIncrease of 256, a 806 MaxRankIncrease of 1024 would allow a device to move up to 4 hops 807 away. 809 8. Manageability Considerations 810 Network manageability is a critical aspect of smart grid network 811 deployment and operation. With millions of devices participating in 812 the smart grid network, many requiring real-time reachability, 813 automatic configuration, and lightweight network health monitoring 814 and management are crucial for achieving network availability and 815 efficient operation. RPL enables automatic and consistent 816 configuration of RPL routers through parameters specified by the 817 DODAG root and disseminated through DIO packets. The use of Trickle 818 for scheduling DIO transmissions ensures lightweight yet timely 819 propagation of important network and parameter updates and allows 820 network operators to choose the trade-off point they are comfortable 821 with respect to overhead vs. reliability and timeliness of network 822 updates. The metrics in use in the network along with the Trickle 823 Timer parameters used to control the frequency and redundancy of 824 network updates can be dynamically varied by the root during the 825 lifetime of the network. To that end, all DIO messages SHOULD 826 contain a Metric Container option for disseminating the metrics and 827 metric values used for DODAG setup. In addition, DIO messages SHOULD 828 contain a DODAG Configuration option for disseminating the Trickle 829 Timer parameters throughout the network. The possibility of 830 dynamically updating the metrics in use in the network as well as the 831 frequency of network updates allows deployment characteristics (e.g., 832 network density) to be discovered during network bring-up and to be 833 used to tailor network parameters once the network is operational 834 rather than having to rely on precise pre- configuration. This also 835 allows the network parameters and the overall routing protocol 836 behavior to evolve during the lifetime of the network. RPL specifies 837 a number of variables and events that can be tracked for purposes of 838 network fault and performance monitoring of RPL routers. Depending 839 on the memory and processing capabilities of each smart grid device, 840 various subsets of these can be employed in the field. 842 9. Security Considerations 844 Smart grid networks are subject to stringent security requirements as 845 they are considered a critical infrastructure component. At the same 846 time, since they are composed of large numbers of resource- 847 constrained devices inter-connected with limited-throughput links, 848 many available security mechanisms are not practical for use in such 849 networks. As a result, the choice of security mechanisms is highly 850 dependent on the device and network capabilities characterizing a 851 particular deployment. In contrast to other types of LLNs, in smart 852 grid networks centralized administrative control and access to a 853 permanent secure infrastructure is available. As a result link- 854 layer, transport-layer and/or application-layer security mechanisms 855 are typically in place and using RPL's secure mode is not necessary. 857 9.1. Security Considerations during initial deployment 859 This section is intentionally left blank. 861 9.2. Security Considerations during incremental deployment 862 This section is intentionally left blank. 864 10. Other Related Protocols 866 This section is intentionally left blank. 868 11. IANA Considerations 870 This memo includes no request to IANA. 872 12. Acknowledgements 874 The authors would like to acknowledge the review, feedback, and 875 comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi 876 Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP 877 Vasseur. 879 13. References 881 13.1. Informative References 883 [surveySG] 884 Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., 885 Cecati, C. and G.P. Hancke, "A Survey on Smart Grid 886 Potential Applications and Communication Requirements", 887 Feb 2013. 889 [IEEE802.15.4] 890 IEEE SA, "IEEE Standard for Information technology-- Local 891 and metropolitan area networks-- Specific requirements-- 892 Part 15.4: Wireless Medium Access Control (MAC) and 893 Physical Layer (PHY) Specifications for Low Rate Wireless 894 Personal Area Networks (WPANs)", September 2006. 896 [IEEE802.15.4e] 897 IEEE SA , "IEEE Standard for Local and metropolitan area 898 networks--Part 15.4: Low-Rate Wireless Personal Area 899 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 900 2012. 902 [IEEE1901.2] 903 IEEE SA , "IEEE Standard for Low-Frequency (less than 500 904 kHz) Narrowband Power Line Communications for Smart Grid 905 Applications", December 2013. 907 13.2. Normative references 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, March 1997. 912 [RFC5548] Dohler, M., Watteyne, T., Winter, T. and D. Barthel, 913 "Routing Requirements for Urban Low-Power and Lossy 914 Networks", RFC 5548, May 2009. 916 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O. and J. Ko, 917 "The Trickle Algorithm", RFC 6206, March 2011. 919 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 920 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 921 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 922 Lossy Networks", RFC 6550, March 2012. 924 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N. and D. 925 Barthel, "Routing Metrics Used for Path Calculation in 926 Low-Power and Lossy Networks", RFC 6551, March 2012. 928 [RFC5867] Martocci, J., De Mil, P., Riou, N. and W. Vermeylen, 929 "Building Automation Routing Requirements in Low-Power and 930 Lossy Networks", RFC 5867, June 2010. 932 [RFC5826] Brandt, A., Buron, J. and G. Porcu, "Home Automation 933 Routing Requirements in Low-Power and Lossy Networks", RFC 934 5826, April 2010. 936 [RFC5673] Pister, K., Thubert, P., Dwars, S. and T. Phinney, 937 "Industrial Routing Requirements in Low-Power and Lossy 938 Networks", RFC 5673, October 2009. 940 [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A. and J. 941 Martocci, "Reactive Discovery of Point-to-Point Routes in 942 Low-Power and Lossy Networks", RFC 6997, August 2013. 944 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 945 Protocol for Low-Power and Lossy Networks (RPL)", RFC 946 6552, March 2012. 948 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 949 Hysteresis Objective Function", RFC 6719, September 2012. 951 Authors' Addresses 953 Daniel Popa 954 Itron, Inc 955 52, rue Camille Desmoulins 956 Issy les Moulineaux, 92130 957 FR 959 Email: daniel.popa@itron.com 961 Matthew Gillmore 962 Itron, Inc 963 2111 N Molter Rd. 964 Liberty Lake, WA, 99019 965 USA 967 Email: matthew.gillmore@itron.com 968 Laurent Toutain 969 Telecom Bretagne 970 2 rue de la Chataigneraie 971 Cesson Sevigne, 35510 972 FR 974 Email: laurent.toutain@telecom-bretagne.eu 976 Jonathan Hui 977 Cisco 978 170 West Tasman Drive 979 San Jose, CA, 95134 980 USA 982 Email: johui@cisco.com 984 Ruben Salazar 985 Landys+Gyr 986 30000 Mill Creek Ave # 100 987 Alpharetta, GA, 30022 988 USA 990 Email: ruben.salazar@landisgyr.com 992 Kazuya Monden 993 Hitachi, Ltd., Yokohama Research Laboratory 994 292, Yoshida-cho, Totsuka-ku, Yokohama-shi 995 Kanagawa-ken , 244-0817 996 Japan 998 Email: kazuya.monden.vw@hitachi.com