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