idnits 2.17.1 draft-ietf-roll-applicability-ami-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2016) is 2758 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.15.4' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.15.4e' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.15.4g' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1901.2' == Outdated reference: A later version (-04) exists of draft-ietf-6lo-privacy-considerations-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Roll N. Cam-Winget, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Hui 5 Expires: April 9, 2017 Nest 6 D. Popa 7 Itron, Inc 8 October 6, 2016 10 Applicability Statement for the Routing Protocol for Low Power and Lossy 11 Networks (RPL) in AMI Networks 12 draft-ietf-roll-applicability-ami-15 14 Abstract 16 This document discusses the applicability of RPL in Advanced Metering 17 Infrastructure (AMI) networks. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 3 57 2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4 58 3. Description of AMI networks for electric meters . . . . . . . 4 59 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 5 60 4. Smart Grid Traffic Description . . . . . . . . . . . . . . . 7 61 4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7 62 4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8 63 4.3. RPL applicability per Smart Grid Traffic Characteristics 9 64 5. Layer 2 applicability . . . . . . . . . . . . . . . . . . . . 9 65 5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9 66 5.2. IEEE PowerLine Communication (PLC) technology . . . . . . 9 67 6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10 68 7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11 71 7.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . 11 72 7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11 73 7.1.4. Objective Function . . . . . . . . . . . . . . . . . 11 74 7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 75 7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 12 77 7.2. Description of Layer-two features . . . . . . . . . . . . 13 78 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . 13 79 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 14 80 7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . 15 81 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 16 82 7.4. Recommended Configuration Defaults and Ranges . . . . . . 17 83 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17 84 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18 85 8. Manageability Considerations . . . . . . . . . . . . . . . . 18 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 9.1. Security Considerations during initial deployment . . . . 19 88 9.2. Security Considerations during incremental deployment . . 19 89 9.3. Security Considerations based on RPL's Threat Analysis . 20 90 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 95 13.2. Informative references . . . . . . . . . . . . . . . . . 22 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 Advanced Metering Infrastructure (AMI) systems enable the 102 measurement, configuration, and control of energy, gas and water 103 consumption and distribution, through two-way scheduled, on 104 exception, and on-demand communication. 106 AMI networks are composed of millions of endpoints, including meters, 107 distribution automation elements, and eventually home area network 108 devices. They are typically inter-connected using some combination 109 of wireless and power-line communications, forming the so-called 110 Neighbor Area Network (NAN) along with a backhaul network providing 111 connectivity to "command-and-control" management software 112 applications at the utility company back office. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 [RFC2119]. 121 1.2. Required Reading 123 [surveySG] gives an overview of Smart Grid architecture and related 124 applications. 126 NAN can use wireless communication technology in which case is using, 127 from the IEEE 802.15.4 standard family, the [IEEE802.15.4g] PHY Layer 128 amendment and [IEEE802.15.4e] MAC sub-layer amendment, specifically 129 adapted to smart grid networks. 131 NAN can also use PLC (Power Line Communication) technology as an 132 alternatve to wireless communications. Several standards for PLC 133 technology have emerged, such as [IEEE1901.2]. 135 NAN can further use a mix of wireless and PLC technologies to 136 increase the network coverage ratio, a critical requirement for AMI 137 networks. 139 1.3. Out of scope requirements 141 The following are outside the scope of this document: 143 o Applicability statement for RPL (Routing Protocol for Low Power 144 and Lossy Networks) [RFC6550] in AMI networks composed of battery- 145 powered devices (i.e., gas/water meters). 147 o Applicability statement for RPL in AMI networks composed of a mix 148 of AC powered devices (i.e., electric meters) and battery-powered 149 meters (i.e., gas/water meters). 151 o Applicability statement for RPL storing mode of operation in AMI 152 networks. 154 2. 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 LLN Border Router or LBR). 162 RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at 163 a LBR (LLN Border Router), ensures loop-free routing, and provides 164 support for alternate routes, as well as, for a wide range of routing 165 metrics and policies. 167 RPL was designed to operate in energy-constrained environments and 168 includes energy-saving mechanisms (e.g., Trickle timers) and energy- 169 aware metrics. RPL's ability to support multiple different metrics 170 and constraints at the same time enables it to run efficiently in 171 heterogeneous networks composed of nodes and links with vastly 172 different characteristics [RFC6551]. 174 This document describes the applicability of RPL non-storing mode (as 175 defined in [RFC6550]) to AMI deployments. The Routing Requirements 176 for Urban Low-Power and Lossy Networks are applicable to AMI networks 177 as well. The terminology used in this document is defined in 178 [RFC7102]. 180 3. Description of AMI networks for electric meters 182 In many deployments, in addition to measuring energy consumption, the 183 electric meter network plays a central role in the Smart Grid since 184 the device enables the utility company to control and query the 185 electric meters themselves and can serve as a backhaul for all other 186 devices in the Smart Grid, e.g., water and gas meters, distribution 187 automation and home area network devices. Electric meters may also 188 be used as sensors to monitor electric grid quality and to support 189 applications such as Electric Vehicle charging. 191 Electric meter networks can be composed of millions of smart meters 192 (or nodes), each of which is resource-constrained in terms of 193 processing power, storage capabilities, and communication bandwidth, 194 due to a combination of factors including regulations on spectrum 195 use, and on meter behavior and performance, on heat emissions within 196 the meter, form factor and cost considerations. These constraints 197 result in a compromise between range and throughput, with effective 198 link throughput of tens to a few hundred kilobits per second per 199 link, a potentially significant portion of which is taken up by 200 protocol and encryption overhead when strong security measures are in 201 place. 203 Electric meters are often interconnected into multi-hop mesh 204 networks, each of which is connected to a backhaul network leading to 205 the utility company network through a network aggregation point, 206 e.g., an LBR. 208 3.1. Deployment Scenarios 210 AMI networks are composed of millions of endpoints distributed across 211 both urban and rural environments. Such endpoints can include 212 electric, gas, and water meters, distribution automation elements, 213 and home area network devices. 215 Devices in the network communicate directly with other devices in 216 close proximity using a variety of low-power and/or lossy link 217 technologies that are both wireless and wired (e.g., IEEE 802.15.4g, 218 IEEE 802.15.4e, IEEE 1901.2, IEEE 802.11). In addition to serving as 219 sources and destinations of packets, many network elements typically 220 also forward packets and thus form a mesh topology. 222 In a typical AMI deployment, groups of meters within physical 223 proximity form routing domains, each in the order of a 1,000 to 224 10,000 meters. Thus, each electric meter mesh typically has several 225 thousand wireless endpoints, with densities varying based on the area 226 and the terrain. 228 | 229 +M 230 | 231 M M M M | M 232 /-----------\ /---+---+---+---+--+-+- phase 1 233 +----+ ( Internet ) +-----+ / M M M M 234 |MDMS|---( )----| LBR |/----+----+----+----+---- phase 2 235 +----+ ( WAN ) +-----+\ 236 \----------/ \ M M M M 237 \--+--+----+-+---+----- phase 3 238 \ M M 239 +--+---+-- 240 <-----------------------------> 241 RPL 243 Figure 1: Typical NAN Topology 245 A typical AMI network architecture (see figure Figure 1) is composed 246 of a MDMS (Meter Data Management System) connected through IP network 247 to a LBR, which can be located in the power substation or somewhere 248 else in the field. The power substation connects the households and 249 buildings. The physical topology of the electrical grid is a tree 250 structure, either due to the 3 different power phases coming through 251 the sub-station or just to the electrical network topology. Meters 252 (represented by a M in the previous figure) can also participate in a 253 HAN (Home-Area Network). The scope of this document is the 254 communication between the LBR and the meters, i.e. the NAN (Neighbor- 255 Area Network) segment. 257 Node density can vary significantly. For example, apartment 258 buildings in urban centers may have hundreds of meters in close 259 proximity, whereas rural areas may have sparse node distributions and 260 include nodes that only have a small number of network neighbors. 261 Each routing domain is connected to the larger IP infrastructure 262 through one or more LBRs, which provide Wide Area Network (WAN) 263 connectivity through various traditional network technologies, e.g., 264 Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in 265 the mesh between a network node and the nearest LBR may be composed 266 of several hops or even several tens of hops. Powered from the main 267 line, electric meters have less energy constraints than battery 268 powered devices, such as gas and water meters, and can afford the 269 additional resources required to route packets. 271 As a function of the technology used to exchange information, the 272 logical network topology will not necessarily match the electric grid 273 topology. If meters exchange information through radio technologies 274 such as in IEEE 802.15.4 family, the topology is a meshed network, 275 where nodes belonging to the same DODAG (Destination Oriented 276 Directed Acyclic Graph ) can be connected to the grid through 277 different substations. If narrowband PLC technology is used, it will 278 follow more or less the physical tree structure since diaphony may 279 allow one phase to communicate with the other. This is particularly 280 true near the LBR. Some mixed topology can also be observed, since 281 some LBRs may be strategically installed in the field to avoid all 282 the communications going through a single LBR. Nethertheless, the 283 short propagation range forces meters to relay the information. 285 4. Smart Grid Traffic Description 287 4.1. Smart Grid Traffic Characteristics 289 In current AMI deployments, metering applications typically require 290 all smart meters to communicate with a few head-end servers, deployed 291 in the utility company data center. Head-end servers generate data 292 traffic to configure smart data reading or initiate queries, and use 293 unicast and multicast to efficiently communicate with a single device 294 (i.e. Point-to-Point (P2P) communications) or groups of devices 295 respectively (i.e., Point-to-Multipoint (P2MP) communication). The 296 head-end server may send a single small packet at a time to the 297 meters (e.g., a meter read request, a small configuration change, 298 service switch command) or a series of large packets (e.g., a 299 firmware download across one or even thousands of devices). The 300 frequency of large file transfers (e.g., firmware download of all 301 metering devices) is typically much lower than the frequency of 302 sending configuration messages or queries. Each smart meter 303 generates Smart Metering Data (SMD) traffic according to a schedule 304 (e.g., periodic meter reads), in response to on-demand queries (e.g., 305 on-demand meter reads), or in response to some local event (e.g., 306 power outage, leak detection). Such traffic is typically destined to 307 a single head-end server. The SMD traffic is thus highly asymmetric, 308 where the majority of the traffic volume generated by the smart 309 meters typically goes through the LBRs, and is directed from the 310 smart meter devices to the head-end servers, in a MP2P (Mesh Peer to 311 Peer)fashion. Current SMD traffic patterns are fairly uniform and 312 well-understood. The traffic generated by the head-end server and 313 destined to metering devices is dominated by periodic meter reads, 314 while traffic generated by the metering devices is typically 315 uniformly spread over some 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 Distribution Automation (DA) applications typically involve a small 322 number of devices that communicate with each other in a Point-to- 323 Point (P2P) fashion, and may or may not be in close physical 324 proximity. DA applications typically have more stringent latency 325 requirements than SMD applications. 327 There are also a number of emerging applications such as electric 328 vehicle charging. These applications may require P2P communication 329 and may eventually have more stringent latency requirements than SMD 330 applications. 332 4.2. Smart Grid Traffic QoS Requirements 334 As described previously, the two main traffic families in a NAN are: 336 A) Meter-initiated traffic (Meter-to-head-end - M2HE) 338 B) Head-end-initiated traffic (Head-end-to-meter - HE2M) 340 B1) request is sent in point-to-point to a specific meter 342 B2) request is sent in multicast to a subset of meters 344 B3) request is sent in multicast to all meters 346 The M2HE are event-based, while the HE2M are mostly command-response. 347 In most cases, M2HE traffic is more critical than HE2M one, but there 348 can be exceptions. 350 Regarding priority, traffic may also be decomposed into several 351 classes : 353 C1) Highly Priority Critical traffic for Power System Outage, 354 Pricing Events and Emergency Messages require a 98%+ packet 355 delivery under 5 s. Payload size < 100 bytes 357 C2) Critical Priority traffic Power Quality Events, Meter Service 358 Connection and Disconnection require 98%+ packet delivery under 359 10s. Payload size < 150 bytes 361 C3) Normal Priority traffic for System Events including Faults, 362 Configuration and Security require 98%+ packet delivery under 30s. 363 Payload size < 200 bytes 365 C4) Low Priority traffic for Recurrent Meter Reading require 98%+ 366 packet 2 hour delivery window 6 times per day. Payload size < 400 367 bytes 369 C5) Background Priority traffic for firmware/software updates 370 processed to 98%+ of devices within 7 days. Average firmware 371 update is 1 MB. 373 4.3. RPL applicability per Smart Grid Traffic Characteristics 375 RPL non-storing mode of operation naturally support upstream and 376 downstream forwarding of unicast traffic between the DODAG root and 377 each DODAG node, and between DODAG nodes and DODAG root, 378 respectively. 380 Group communication model used in smart grid requires RPL non-storing 381 mode of operation to support downstream forwarding of multicast 382 traffic with a scope larger than link-local. The DODAG root is the 383 single device that injects multicast traffic, with a scope larger 384 than link-local, into the DODAG. 386 5. Layer 2 applicability 388 5.1. IEEE Wireless Technology 390 IEEE Std. 802.15.4g and IEEE 802.15.4e amendments to 802.15.4 391 standard have been specifically developed for smart grid networks. 392 They are the most common PHY and MAC layers used for wireless AMI 393 network. 802.15.4g specifies multiple modes of operation (FSK, OQPSK 394 and OFDM modulations) with speeds from 50kbps to 600kbps, and allows 395 for transport of a full IPv6 packet (i.e., 1280 octets) without the 396 need for upper layer segmentation and re-assembly. 398 IEEE Std. 802.15.4e is an amendment to IEEE Std 802.15.4 that 399 specifies additional media access control (MAC) behaviors and frame 400 formats that allow IEEE 802.15.4 devices to support a wide range of 401 industrial and commercial applications that were not adequately 402 supported prior to the release of this amendment. It is important to 403 notice that 802.15.4e does not change the link-layer security scheme 404 defined in the last two updates to 802.15.4 (e.g. 2006 and 2011 405 amendments). 407 5.2. IEEE PowerLine Communication (PLC) technology 409 The IEEE Std. 1901.2 standard specifies communications for low 410 frequency (less than 500 kHz) narrowband power line devices via 411 alternating current and direct current electric power lines. IEEE 412 Std P1901.2 standard supports indoor and outdoor communications over 413 low voltage line (line between transformer and meter, less than 1000 414 V), through transformer low-voltage to medium-voltage (1000 V up to 415 72 kV) and through transformer medium-voltage to low-voltage power 416 lines in both urban and in long distance (multi- kilometer) rural 417 communications. 419 IEEE Std. 1901.2 defines the PHY layer and the MAC sub-layer of the 420 data link layer. The MAC sub-layer endorses a sub-set of 802.15.4 421 and 802.15.4e MAC sub-layer features. 423 IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps 424 depending on the application requirements and type of encoding used. 426 IEEE Std. 1901.2 MAC layer allows for transport of a full IPv6 packet 427 (i.e., 1280 octets) without the need for upper layer segmentation and 428 re-assembly. 430 IEEE Std. 1901.2 specifies the necessary link-layer security features 431 that fully endorse 802.15.4 MAC sub-layer security scheme. 433 6. Using RPL to Meet Functional Requirements 435 The functional requirements for most AMI deployments are similar to 436 those listed in [RFC5548]. This section informallly highlights some 437 of the similarities: 439 o The routing protocol MUST be capable of supporting the 440 organization of a large number of nodes into regions containing on 441 the order of 10^2 to 10^4 nodes each. 443 o The routing protocol MUST provide mechanisms to support 444 configuration of the routing protocol itself. 446 o The routing protocol SHOULD support and utilize the large number 447 of highly directed flows to a few head-end servers to handle 448 scalability. 450 o The routing protocol MUST dynamically compute and select effective 451 routes composed of low-power and lossy links. Local network 452 dynamics SHOULD NOT impact the entire network. The routing 453 protocol MUST compute multiple paths when possible. 455 o The routing protocol MUST support multicast and unicast 456 addressing. The routing protocol SHOULD support formation and 457 identification of groups of field devices in the network. 459 RPL supports the following features: 461 o Scalability: Large-scale networks characterized by highly directed 462 traffic flows between each smart meter and the head-end servers in 463 the utility network. To this end, RPL builds a Directed Acyclic 464 Graph (DAG) rooted at each LBR. 466 o Zero-touch configuration: This is done through in-band methods for 467 configuring RPL variables using DIO (DODAG Information Object) 468 messages, and DIO message options [RFC6550]. 470 o The use of links with time-varying quality characteristics: This 471 is accomplished by allowing the use of metrics that effectively 472 capture the quality of a path (e.g., Expected Transmission Count 473 (ETX)) and by limiting the impact of changing local conditions by 474 discovering and maintaining multiple DAG parents, and by using 475 local repair mechanisms when DAG links break. 477 7. RPL Profile 479 7.1. RPL Features 481 7.1.1. RPL Instances 483 RPL operation is defined for a single RPL instance. However, 484 multiple RPL instances can be supported in multi-service networks 485 where different applications may require the use of different routing 486 metrics and constraints, e.g., a network carrying both SDM and DA 487 traffic. 489 7.1.2. DAO Policy 491 Two-way communication is a requirement in AMI systems. As a result, 492 nodes SHOULD send DAO messages to establish downward paths from the 493 root to themselves. 495 7.1.3. Path Metrics 497 Smart metering deployments utilize link technologies that may exhibit 498 significant packet loss and thus require routing metrics that take 499 packet loss into account. To characterize a path over such link 500 technologies, AMI deployments can use the Expected Transmission Count 501 (ETX) metric as defined in [RFC6551]. 503 Additional metrics may be defined in companion RFCs. 505 7.1.4. Objective Function 507 RPL relies on an Objective Function for selecting parents and 508 computing path costs and rank. This objective function is decoupled 509 from the core RPL mechanisms and also from the metrics in use in the 510 network. Two objective functions for RPL have been defined at the 511 time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of 512 which define the selection of a preferred parent and backup parents, 513 and are suitable for AMI deployments. 515 Additional objective functions may be defined in companion RFCs. 517 7.1.5. DODAG Repair 519 To effectively handle time-varying link characteristics and 520 availability, AMI deployments SHOULD utilize the local repair 521 mechanisms in RPL. Local repair is triggered by broken link 522 detection. The first local repair mechanism consists of a node 523 detaching from a DODAG and then re-attaching to the same or to a 524 different DODAG at a later time. While detached, a node advertises 525 an infinite rank value so that its children can select a different 526 parent. This process is known as poisoning and is described in 527 Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a 528 local DODAG, doing so in AMI for electric meters is of little benefit 529 since AMI applications typically communicate through a LBR. After 530 the detached node has made sufficient effort to send notification to 531 its children that it is detached, the node can rejoin the same DODAG 532 with a higher rank value. The configured duration of the poisoning 533 mechanism needs to take into account the disconnection time 534 applications running over the network can tolerate. Note that when 535 joining a different DODAG, the node need not perform poisoning. The 536 second local repair mechanism controls how much a node can increase 537 its rank within a given DODAG Version (e.g., after detaching from the 538 DODAG as a result of broken link or loop detection). Setting the 539 DAGMaxRankIncrease to a non-zero value enables this mechanism, and 540 setting it to a value of less than infinity limits the cost of count- 541 to-infinity scenarios when they occur, thus controlling the duration 542 of disconnection applications may experience. 544 7.1.6. Multicast 546 Multicast support for RPL in non-storing mode are being developed in 547 companion RFCs (see [RFC7731]). 549 7.1.7. Security 551 AMI deployments operate in areas that do not provide any physical 552 security. For this reason, the link layer, transport layer and 553 application layer technologies utilized within AMI networks typically 554 provide security mechanisms to ensure authentication, 555 confidentiality, integrity, and freshness. As a result, AMI 556 deployments may not need to implement RPL's security mechanisms; they 557 MUST include, at a minimum, link layer security such as that defined 558 by IEEE 1901.2 and IEEE 802.15.4. 560 7.2. Description of Layer-two features 562 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features 564 The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and 565 defines a time frequency interleaver over the entire PHY frame 566 coupled with a Reed Solomon and Viterbi Forward Error Correction for 567 maximum robustness. Since the noise level in each OFDM sub-carrier 568 can vary significantly, IEEE 1901.2 specifies two complementary 569 mechanisms allowing to fine-tune the robustness/performance tradeoff 570 implicit in such systems. More specifically, the first (coarse- 571 grained) mechanism, defines the modulation from several possible 572 choices (robust (super-ROBO, ROBO), BPSK, QPSK,...). The second 573 (fine-grained) maps the sub-carriers which are too noisy and 574 deactivates them. 576 The existence of multiple modulations and dynamic frequency exclusion 577 renders the problem of selecting a path between two nodes non- 578 trivial, as the possible number of combinations increases 579 significantly, e.g. use a direct link with slow robust modulation, 580 or use a relay meter with fast modulation and 12 disabled sub- 581 carriers. In addition, IEEE 1901.2 technology offers a mechanism 582 (adaptive tone map) for periodic exchanges on the link quality 583 between nodes to constantly react to channel fluctuations. Every 584 meter keeps a state of the quality of the link to each of its 585 neighbors by either piggybacking the tone mapping on the data 586 traffic, or by sending explicit tone map requests. 588 IEEE 1901.2 MAC frame format shares most in common with the IEEE 589 802.15.4 MAC frame format [IEEE802.15.4], with a few exceptions 590 described below. 592 o IEEE 1901.2 MAC frame is obtained by prepending a Segment Control 593 Field to the IEEE 802.15.4 MAC header. One function of the 594 Segment Control Field is to signal the use of the MAC sub-layer 595 segmentation and reassembly. 597 o IEEE 1901.2 MAC frames uses only the 802.15.4 MAC addresses with a 598 length of 16 and 64 bits. 600 o IEEE 1901.2 MAC sub-layer endorses the concept of Information 601 Elements, as defined in [IEEE802.15.4e]. The format and use of 602 Information Elements are not relevant to RPL applicability 603 statement. 605 The IEEE 1901.2 PHY frame payload size varies as a function of the 606 modulation used to transmit the frame and the strength of the Forward 607 Error Correction scheme. 609 The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY 610 settings in use (e.g. bandwidth, modulation, tones, etc). As quoted 611 from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is 612 more than 247 octets for robust OFDM (ROBO) and Super-ROBO 613 modulations or more than 239 octets for all other modulations, the 614 MAC layer shall divide the MSDU into multiple segments as described 615 in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the 616 following conditions: a) For ROBO and Super-ROBO modulations, the 617 MSDU size is more than 247 octets but less than 494 octets, b) For 618 all other modulations, the MSDU size is more than 239 octets but less 619 than 478 octets. 621 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features 623 IEEE Std 802.15.4g defines multiple modes of operation, where each 624 mode uses different modulation and has multiple data rates. 625 Additionally, 802.15.4g PHY layer includes mechanisms to improve the 626 robustness of the radio communications, such as data whitening and 627 Forward Error Correction coding. The 802.15.4g PHY frame payload can 628 carry up to 2048 octets. 630 The IEEE Std 802.15.4g defines the following modulations: MR-FSK 631 (Multi- Rate FSK), MR-OFDM (Multi-Rate OFDM) and MR-O-QPSK (Multi- 632 Rate O-QPSK). The (over-the-air) bit rates for these modulations 633 range from 4.8 to 600kbps for MR-FSK, from 50 to 600kbps for MR-OFDM 634 and from 6.25 to 500kbps for MR-O-QPSK. 636 The MAC sub-layer running on top of a 4g radio link is based on IEEE 637 802.15.4e. The 802.15.4e MAC allows for a variety of modes for 638 operation. These include: 640 o Timetimeslotslotted channel hopping (TSCH): specifically designed 641 for application domains such as process automation 643 o Low latency deterministic networks (LLDN): for application domains 644 such as factory automation 646 o Deterministic and synchronous multi-channel extension (DSME): for 647 general industrial and commercial application domains that 648 includes Channel diversity to increase network robustness 650 o Asynchronous multi-channel adaptation (AMCA): for large 651 infrastructure application domains. 653 The MAC addressing scheme supports short (16-bits) addresses along 654 with extended (64-bits) addresses. These addresses are assigned in 655 different ways and is specified by specific standards organizations. 657 Information Elements, Enhanced Beacons and frame version 2, as 658 defined in 802.15.4e, MUST be supported. 660 Since the MAC frame payload size limitation is given by the 4g PHY 661 frame payload size limitation (i.e.,2048 bytes) and MAC layer 662 overhead (headers, trailers, Information Elements and security 663 overhead), the MAC frame payload MUST able to carry a full IPv6 664 packet of 1280 octets without upper layer fragmentation and re- 665 assembly. 667 7.2.3. IEEE MAC sub-layer Security Features 669 Since IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer and 670 fully endorses the security scheme defined in 802.15.4, we only focus 671 on description of IEEE 802.15.4 security scheme. 673 The IEEE 802.15.4 specification was designed to support a variety of 674 applications, many of which are security sensitive. The IEEE 675 802.15.4 provides four basic security services: message 676 authentication, message integrity, message confidentiality, and 677 freshness checks to avoid replay attacks. 679 The 802.15.4 security layer is handled at the media access control 680 layer, below 6LowPAN layer. The application specifies its security 681 requirements by setting the appropriate control parameters into the 682 radio/PLC stack. The 802.15.4 defines four packet types: beacon 683 frames, data frames, acknowledgments frame, and command frames for 684 the media access control layer. The 802.15.4 specification does not 685 support security for acknowledgement frames; data frames, beacon 686 frames and command frames can support integrity protection and 687 confidentiality protection for the frames's data field. An 688 application has a choice of security suites that control the type of 689 security protection that is provided for the transmitted MAC frame. 690 Each security suite offers a different set of security properties and 691 guarantees, and ultimately different MAC frame formats. The 802.15.4 692 specification defines eight different security suites, outlined 693 bellow. We can broadly classify the suites by the properties that 694 they offer: no security, encryption only (AES-CTR), authentication 695 only (AES-CBC-MAC), and encryption and authentication (AES-CCM). 696 Each category that supports authentication comes in three variants 697 depending on the size of the MAC (Message Authentication Control) 698 that it offers. The MAC can be either 4, 8, or 16 bytes long. 699 Additionally, for each suite that offers encryption, the recipient 700 can optionally enable replay protection. 702 o Null = No security. 704 o AES-CTR = Encryption only, CTR mode. 706 o AES-CBC-MAC-128 = No encryption, 128-bit MAC. 708 o AES-CBC-MAC-64 = No encryption, 64-bit MAC. 710 o AES-CCM-128 = Encryption and 128-bit MAC. 712 o AES-CCM-64 = Encryption and 64-bit MAC. 714 o AES-CCM-32 = Encryption and 32-bit MAC. 716 Note that AES-CCM-32 is the most commonly used cipher in these 717 deployments today. 719 To achieve authentication, any device can maintain an Access Control 720 List (ACL) which is a list of trusted nodes from which the device 721 wishes to receive data. Data encryption is done by encryption of 722 Message Authentication Control (MAC) frame payload using the key 723 shared between two devices, or among a group of peers. If the key is 724 to be shared between two peers, it is stored with each entry in the 725 ACL list; otherwise, the key is stored as the default key. Thus, the 726 device can make sure that its data can not be read by devices that do 727 not possess the corresponding key. However, device addresses are 728 always transmitted unencrypted, which makes attacks that rely on 729 device identity somewhat easier to launch. Integrity service is 730 applied by appending a Message Integrity Code (MIC) generated from 731 blocks of encrypted message text. This ensures that a frame can not 732 be modified by a receiver device that does not share a key with the 733 sender. Finally, sequential freshness uses a frame counter and key 734 sequence counter to ensure the freshness of the incoming frame and 735 guard against replay attacks. 737 A cryptographic MAC is used to authenticate messages. While longer 738 MACs lead to improved resiliency of the code, they also make packet 739 size larger and thus take up bandwidth in the network. In 740 constrained environments such as metering infrastructures, an optimum 741 balance between security requirements and network throughput must be 742 found. 744 7.3. 6LowPAN Options 746 AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all 747 of the IPv6 Header Compression schemes specified in [RFC6282] 748 Section 3 and all of the IPv6 Next Header compression schemes 749 specified in [RFC6282] Section 4, if reducing over the air/wire 750 overhead is a requirement. 752 7.4. Recommended Configuration Defaults and Ranges 754 7.4.1. Trickle Parameters 756 Trickle [RFC6206] was designed to be density-aware and perform well 757 in networks characterized by a wide range of node densities. The 758 combination of DIO packet suppression and adaptive timers for sending 759 updates allows Trickle to perform well in both sparse and dense 760 environments. Node densities in AMI deployments can vary greatly, 761 from nodes having only one or a handful of neighbors to nodes having 762 several hundred neighbors. In high density environments, relatively 763 low values for Imin may cause a short period of congestion when an 764 inconsistency is detected and DIO updates are sent by a large number 765 of neighboring nodes nearly simultaneously. While the Trickle timer 766 will exponentially backoff, some time may elapse before the 767 congestion subsides. While some link layers employ contention 768 mechanisms that attempt to avoid congestion, relying solely on the 769 link layer to avoid congestion caused by a large number of DIO 770 updates can result in increased communication latency for other 771 control and data traffic in the network. To mitigate this kind of 772 short-term congestion, this document recommends a more conservative 773 set of values for the Trickle parameters than those specified in 774 [RFC6206]. In particular, DIOIntervalMin is set to a larger value to 775 avoid periods of congestion in dense environments, and 776 DIORedundancyConstant is parameterized accordingly as described 777 below. These values are appropriate for the timely distribution of 778 DIO updates in both sparse and dense scenarios while avoiding the 779 short-term congestion that might arise in dense scenarios. Because 780 the actual link capacity depends on the particular link technology 781 used within an AMI deployment, the Trickle parameters are specified 782 in terms of the link's maximum capacity for transmitting link-local 783 multicast messages. If the link can transmit m link-local multicast 784 packets per second on average, the expected time it takes to transmit 785 a link-local multicast packet is 1/m seconds. 787 DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that 788 the Trickle Imin is at least 50 times as long as it takes to 789 transmit a link-local multicast packet. This value is larger than 790 that recommended in [RFC6206] to avoid congestion in dense urban 791 deployments as described above. 793 DIOIntervalDoublings: AMI deployments SHOULD set 794 DIOIntervalDoublings such that the Trickle Imax is at least 2 795 hours or more. 797 DIORedundancyConstant: AMI deployments SHOULD set 798 DIORedundancyConstant to a value of at least 10. This is due to 799 the larger chosen value for DIOIntervalMin and the proportional 800 relationship between Imin and k suggested in [RFC6206]. This 801 increase is intended to compensate for the increased communication 802 latency of DIO updates caused by the increase in the 803 DIOIntervalMin value, though the proportional relationship between 804 Imin and k suggested in [RFC6206] is not preserved. Instead, 805 DIORedundancyConstant is set to a lower value in order to reduce 806 the number of packet transmissions in dense environments. 808 7.4.2. Other Parameters 810 o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 811 8 bits of resolution (e.g., for the ETX metric). 813 o To enable local repair, AMI deployments SHOULD set MaxRankIncrease 814 to a value that allows a device to move a small number of hops 815 away from the root. With a MinHopRankIncrease of 256, a 816 MaxRankIncrease of 1024 would allow a device to move up to 4 hops 817 away. 819 8. Manageability Considerations 821 Network manageability is a critical aspect of smart grid network 822 deployment and operation. With millions of devices participating in 823 the smart grid network, many requiring real-time reachability, 824 automatic configuration, and lightweight network health monitoring 825 and management are crucial for achieving network availability and 826 efficient operation. RPL enables automatic and consistent 827 configuration of RPL routers through parameters specified by the 828 DODAG root and disseminated through DIO packets. The use of Trickle 829 for scheduling DIO transmissions ensures lightweight yet timely 830 propagation of important network and parameter updates and allows 831 network operators to choose the trade-off point they are comfortable 832 with respect to overhead vs. reliability and timeliness of network 833 updates. The metrics in use in the network along with the Trickle 834 Timer parameters used to control the frequency and redundancy of 835 network updates can be dynamically varied by the root during the 836 lifetime of the network. To that end, all DIO messages SHOULD 837 contain a Metric Container option for disseminating the metrics and 838 metric values used for DODAG setup. In addition, DIO messages SHOULD 839 contain a DODAG Configuration option for disseminating the Trickle 840 Timer parameters throughout the network. The possibility of 841 dynamically updating the metrics in use in the network as well as the 842 frequency of network updates allows deployment characteristics (e.g., 843 network density) to be discovered during network bring-up and to be 844 used to tailor network parameters once the network is operational 845 rather than having to rely on precise pre- configuration. This also 846 allows the network parameters and the overall routing protocol 847 behavior to evolve during the lifetime of the network. RPL specifies 848 a number of variables and events that can be tracked for purposes of 849 network fault and performance monitoring of RPL routers. Depending 850 on the memory and processing capabilities of each smart grid device, 851 various subsets of these can be employed in the field. 853 9. Security Considerations 855 Smart grid networks are subject to stringent security requirements as 856 they are considered a critical infrastructure component. At the same 857 time, they are composed of large numbers of resource- constrained 858 devices inter-connected with limited-throughput links. As a result, 859 the choice of security mechanisms is highly dependent on the device 860 and network capabilities characterizing a particular deployment. 862 In contrast to other types of LLNs, in smart grid networks 863 centralized administrative control and access to a permanent secure 864 infrastructure is available. As a result, smart grid networks are 865 deployed with security mechanisms such as link-layer, transport layer 866 and/or application-layer security mechanisms; while it is best 867 practice to secure all layers, using RPL's secure mode may not be 868 necessary. Failure to protect any of these layers can result in 869 various attacks; without strong authentication of devices in the 870 infrastructure can lead to uncontrolled and unauthorized access. 871 Similarly, failure to protect the communication layers can enable 872 passive (in wireless mediums) attacks as well as man-in-the-middle 873 and active attacks. 875 As this document describes the applicability of RPL non-storing mode, 876 the security considerations as defined in [RFC6550] also applies to 877 this document and to AMI deployments. 879 9.1. Security Considerations during initial deployment 881 During the manufacturing process, the meters are loaded with the 882 appropriate security credentials (keys, certificates). The 883 configured security credentials during manufacturing are used by the 884 devices to authenticate with the system and to further negotiate 885 operational security credentials, for both network and application 886 layers. 888 9.2. Security Considerations during incremental deployment 890 If during the system operation a device fails or is known to be 891 compromised, it is replaced with a new device. The new device does 892 not take over the security identity of the replaced device. The 893 security credentials associated with the failed/compromised device 894 are removed from the security appliances. 896 9.3. Security Considerations based on RPL's Threat Analysis 898 [RFC7416] defines a set of security considerations for RPL security. 899 This document defines how it leverages the device's link layer and 900 application layer security mechanisms to address the threats as 901 defined in Section 6 of [RFC7416]. 903 Like any secure network infrastructure, an AMI deployment's ability 904 to address node impersonation, active man-in-the-middle attacks 905 relies on mutual authentication and authorization process. The 906 credential management from the manufacturing imprint of security 907 credentials of smart meters to all credentials of nodes in the 908 infrastructure, all credentials must be appropriately managed and 909 classified through the authorization process to ensure beyond the 910 identity of the nodes, that the nodes are behaving or 'acting' in 911 their assigned roles. 913 Similarly, to ensure that data has not been modified, confidentiality 914 and integrity at the suitable layers (e.g. link layer, application 915 layer or both) should be used. 917 To provide the security mechanisms to address these threats, an AMI 918 deployment MUST include the use of the security schemes as defined by 919 IEEE 1901.2 (and IEEE 802.15.4). With IEEE 802.15.4 defining the 920 security mechanisms to afford mutual authentication, access control 921 (e.g. authorization) and transport confidentiality and integrity. 923 10. Privacy Considerations 925 Privacy of information flowing through smart grid networks are 926 subject to consideration. An evolving a set of recommendations and 927 requirements are deing defined by different groups and consortiums; 928 for example, the U.S. Department of Energy issued a document 929 [DOEVCC] defining a process and set of recommendations to address 930 privacy issues. As this document describes the applicability of RPL, 931 the privacy considerations as defined in 932 [I-D.ietf-6lo-privacy-considerations] and [EUPR] apply to this 933 document and to AMI deployments. 935 11. IANA Considerations 937 This memo includes no request to IANA. 939 12. Acknowledgements 941 Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden 942 were contributors and noted as authors in earlier drafts. The 943 authors would also like to acknowledge the review, feedback, and 944 comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi 945 Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP 946 Vasseur. 948 13. References 950 13.1. Normative References 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, 954 DOI 10.17487/RFC2119, March 1997, 955 . 957 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 958 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 959 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 960 Low-Power and Lossy Networks", RFC 6550, 961 DOI 10.17487/RFC6550, March 2012, 962 . 964 [IEEE802.15.4] 965 "IEEE Standard for Information technology-- Local and 966 metropolitan area networks-- Specific requirements-- Part 967 15.4: Wireless Medium Access Control (MAC) and Physical 968 Layer (PHY) Specifications for Low Rate Wireless Personal 969 Area Networks (WPANs)", IEEE Standard 802.15.4, September 970 2006. 972 [IEEE802.15.4e] 973 "IEEE Standard for Local and metropolitan area networks-- 974 Part 15.4: Low-Rate Wireless Personal Area Networks (LR- 975 WPANs) Amendment 1: MAC sublayer", IEEE Standard 976 802.15.4e, April 2012. 978 [IEEE802.15.4g] 979 "IEEE Standard for Local and metropolitan area networks-- 980 Part 15.4: Low-Rate Wireless Personal Area Networks (LR- 981 WPANs) Amendment 3: Physical Layer (PHY) Specifications 982 for Low-Data-Rate, Wireless, Smart Metering Utility 983 Networks", IEEE Standard 802.15.4g, November 2012. 985 [IEEE1901.2] 986 "IEEE Standard for Low-Frequency (less than 500 kHz) 987 Narrowband Power Line Communications for Smart Grid 988 Applications", IEEE Standard 1901.2, December 2013. 990 [surveySG] 991 Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., 992 Cecati, C., and G. Hancke, "A Survey on Smart Grid 993 Potential Applications and Communication Requirements", 994 Feb 2013. 996 13.2. Informative references 998 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 999 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1000 February 2016, . 1002 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1003 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1004 2014, . 1006 [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and 1007 D. Barthel, Ed., "Routing Requirements for Urban Low-Power 1008 and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 1009 2009, . 1011 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1012 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 1013 March 2011, . 1015 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1016 and D. Barthel, "Routing Metrics Used for Path Calculation 1017 in Low-Power and Lossy Networks", RFC 6551, 1018 DOI 10.17487/RFC6551, March 2012, 1019 . 1021 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 1022 Hysteresis Objective Function", RFC 6719, 1023 DOI 10.17487/RFC6719, September 2012, 1024 . 1026 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 1027 Protocol for Low-Power and Lossy Networks (RPL)", 1028 RFC 6552, DOI 10.17487/RFC6552, March 2012, 1029 . 1031 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1032 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1033 DOI 10.17487/RFC6282, September 2011, 1034 . 1036 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1037 and M. Richardson, Ed., "A Security Threat Analysis for 1038 the Routing Protocol for Low-Power and Lossy Networks 1039 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1040 . 1042 [I-D.ietf-6lo-privacy-considerations] 1043 Thaler, D., "Privacy Considerations for IPv6 over Networks 1044 of Resource-Constrained Nodes", draft-ietf-6lo-privacy- 1045 considerations-03 (work in progress), September 2016. 1047 [DOEVCC] "Voluntary Code of Conduct (VCC) Final Concepts and 1048 Principles", Jan 2015, 1049 . 1052 [EUPR] "Information for investors and data controllers", Jun 1053 2016, . 1055 Authors' Addresses 1057 Nancy Cam-Winget (editor) 1058 Cisco Systems 1059 3550 Cisco Way 1060 San Jose, CA 95134 1061 US 1063 Email: ncamwing@cisco.com 1065 Jonathan Hui 1066 Nest 1067 3400 Hillview Ave 1068 Palo Alto, CA 94304 1069 USA 1071 Email: jonhui@nestlabs.com 1073 Daniel Popa 1074 Itron, Inc 1075 52, rue Camille Desmoulins 1076 Issy les Moulineaux 92130 1077 FR 1079 Email: daniel.popa@itron.com