idnits 2.17.1 draft-ietf-roll-applicability-ami-10.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 30, 2015) is 3368 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 Experimental RFC: RFC 6997 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-11 ** Downref: Normative reference to an Informational draft: draft-ietf-roll-terminology (ref. 'I-D.ietf-roll-terminology') ** Downref: Normative reference to an Informational RFC: RFC 7416 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Roll D. Popa 3 Internet-Draft M. Gillmore 4 Intended status: Standards Track Itron, Inc 5 Expires: August 3, 2015 L. Toutain 6 Telecom Bretagne 7 J. Hui 8 Cisco 9 R. Ruben 10 Landis+Gyr 11 K. Monden 12 Hitachi, Ltd., Yokohama Research Laboratory 13 N. Cam-Winget, Ed. 14 Cisco Systems 15 January 30, 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-10 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 August 3, 2015. 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", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 1.2. Required Reading 130 [surveySG] gives an overview of Smart Grid architecture and related 131 applications. 133 NAN can use wireless communication technology in which case is using, 134 from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer 135 amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically 136 adapted to smart grid networks. 138 NAN can also use PLC (Power Line Communication) technology as an 139 alternative to wireless communications. Several standards for PLC 140 technology have emerged, such as IEEE P1901.2. 142 NAN can further use a mix of wireless and PLC technologies to 143 increase the network coverage ratio, a critical requirement for AMI 144 networks. 146 1.3. Out of scope requirements 148 The following are outside the scope of this document: 150 o Applicability statement for RPL in AMI networks composed of 151 battery-powered devices (i.e., gas/water meters). 153 o Applicability statement for RPL in AMI networks composed of a mix 154 of AC powered devices (i.e., electric meters) and battery-powered 155 meters (i.e., gas/water meters). 157 o Applicability statement for RPL storing mode of operation in AMI 158 networks. 160 2. Routing Protocol for LLNs (RPL) 162 RPL provides routing functionality for mesh networks that can scale 163 up to thousands of resource-constrained devices, interconnected by 164 low power and lossy links, and communicating with the external 165 network infrastructure through a common aggregation point(s) (e.g., a 166 LBR). 168 RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at 169 a LBR (LLN Border Router), ensures loop-free routing, and provides 170 support for alternate routes, as well as, for a wide range of routing 171 metrics and policies. 173 RPL was designed to operate in energy-constrained environments and 174 includes energy-saving mechanisms (e.g., Trickle timers) and energy- 175 aware metrics. RPL's ability to support multiple different metrics 176 and constraints at the same time enables it to run efficiently in 177 heterogeneous networks composed of nodes and links with vastly 178 different characteristics [RFC6551]. 180 This document describes the applicability of RPL non-storing mode (as 181 defined in [RFC6550]) to AMI deployments. RPL was designed to meet 182 the following application requirements: 184 o Routing Requirements for Urban Low-Power and Lossy Networks 185 [RFC5548]. 187 o Industrial Routing Requirements in Low-Power and Lossy Networks 188 [RFC5673]. 190 o Home Automation Routing Requirements in Low-Power and Lossy 191 Networks [RFC5826]. 193 o Building Automation Routing Requirements in Low-Power and Lossy 194 Networks [RFC5867]. 196 The Routing Requirements for Urban Low-Power and Lossy Networks are 197 applicable to AMI networks as well. The terminology used in this 198 document is defined in [I-D.ietf-roll-terminology]. 200 3. Description of AMI networks for electric meters 202 In many deployments, in addition to measuring energy consumption, the 203 electric meter network plays a central role in the Smart Grid since 204 the device enables the utility company to control and query the 205 electric meters themselves and can serve as a backhaul for all other 206 devices in the Smart Grid, e.g., water and gas meters, distribution 207 automation and home area network devices. Electric meters may also 208 be used as sensors to monitor electric grid quality and to support 209 applications such as Electric Vehicle charging. 211 Electric meter networks can be composed of millions of smart meters 212 (or nodes), each of which is resource-constrained in terms of 213 processing power, storage capabilities, and communication bandwidth, 214 due to a combination of factors including Federal Communications 215 Commission (FCC) or other continents' regulations on spectrum use, 216 American National Standards Institute (ANSI) standards or other 217 continents' regulation on meter behavior and performance, on heat 218 emissions within the meter, form factor and cost considerations. 219 These constraints result in a compromise between range and 220 throughput, with effective link throughput of tens to a few hundred 221 kilobits per second per link, a potentially significant portion of 222 which is taken up by protocol and encryption overhead when strong 223 security measures are in place. 225 Electric meters are often interconnected into multi-hop mesh 226 networks, each of which is connected to a backhaul network leading to 227 the utility company network through a network aggregation point, 228 e.g., an LBR. 230 3.1. Deployment Scenarios 232 AMI networks are composed of millions of endpoints distributed across 233 both urban and rural environments. Such endpoints can include 234 electric, gas, and water meters, distribution automation elements, 235 and home area network devices. 237 Devices in the network communicate directly with other devices in 238 close proximity using a variety of low-power and/or lossy link 239 technologies that are both wireless and wired (e.g., IEEE 802.15.4g, 240 IEEE 802.15.4e, IEEE 1901.2, IEEE 802.11). In addition to serving as 241 sources and destinations of packets, many network elements typically 242 also forward packets and thus form a mesh topology. 244 In a typical AMI deployment, groups of meters within physical 245 proximity form routing domains, each in the order of a 1,000 to 246 10,000 meters. Thus, each electric meter mesh typically has several 247 thousand wireless endpoints, with densities varying based on the area 248 and the terrain. 250 | 251 +M 252 | 253 M M M M | M 254 /-----------\ /---+---+---+---+--+-+- phase 1 255 +----+ ( Internet ) +-----+ / M M M M 256 |MDMS|---( )----| LBR |/----+----+----+----+---- phase 2 257 +----+ ( WAN ) +-----+\ 258 \----------/ \ M M M M 259 \--+--+----+-+---+----- phase 3 260 \ M M 261 +--+---+-- 262 <-----------------------------> 263 RPL 265 Figure 1: Typical NAN Topology 267 A typical AMI network architecture (see figure Figure 1) is composed 268 of a MDMS (Meter Data Management System) connected through IP network 269 to a LBR, which can be located in the power substation or somewhere 270 else in the field. The power substation connects the households and 271 buildings. The physical topology of the electrical grid is a tree 272 structure, either due to the 3 different power phases coming through 273 the sub-station or just to the electrical network topology. Meters 274 (represented by a M in the previous figure) can also participate to a 275 HAN (Home-Area Network). The scope of this document is the 276 communication between the LBR and the meters, i.e. the NAN (Neighbor- 277 Area Network) segment. 279 Node density can vary significantly. For example, apartment 280 buildings in urban centers may have hundreds of meters in close 281 proximity, whereas rural areas may have sparse node distributions and 282 include nodes that only have a small number of network neighbors. 283 Each routing domain is connected to the larger IP infrastructure 284 through one or more LBRs, which provide Wide Area Network (WAN) 285 connectivity through various traditional network technologies, e.g., 286 Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in 287 the mesh between a network node and the nearest LBR may be composed 288 of several hops or even several tens of hops. Powered from the main 289 line, electric meters have less energy constraints than battery 290 powered devices, such as gas and water meters, and can afford the 291 additional resources required to route packets. 293 As a function of the technology used to exchange information, the 294 logical network topology will not necessarily match the electric grid 295 topology. If meters exchange information through radio technologies 296 such as in IEEE 802.15.4 family, the topology is a meshed network, 297 where nodes belonging to the same DODAG can be connected to the grid 298 through different substations. If narrowband PLC technology is used, 299 it will follow more or less the physical tree structure since 300 diaphony may allow one phase to communicate with the other. This is 301 particularly true near the LBR. Some mixed topology can also be 302 observed, since some LBRs may be strategically installed in the field 303 to avoid all the communications going through a single LBR. 304 Nethertheless, the short propagation range forces meters to relay the 305 information. 307 4. Smart Grid Traffic Description 309 4.1. Smart Grid Traffic Characteristics 311 In current AMI deployments, metering applications typically require 312 all smart meters to communicate with a few head-end servers, deployed 313 in the utility company data center. Head-end servers generate data 314 traffic to configure smart data reading or initiate queries, and use 315 unicast and multicast to efficiently communicate with a single device 316 (i.e. Point-to-Point (P2P) communications) or groups of devices 317 respectively (i.e., Point-to-Multipoint (P2MP) communication). The 318 head-end server may send a single small packet at a time to the 319 meters (e.g., a meter read request, a small configuration change, 320 service switch command) or a series of large packets (e.g., a 321 firmware download across one or even thousands of devices). The 322 frequency of large file transfers, e.g., firmware download of all 323 metering devices, is typically much lower than the frequency of 324 sending configuration messages or queries. Each smart meter 325 generates Smart Metering Data (SMD) traffic according to a schedule 326 (e.g., periodic meter reads), in response to on-demand queries (e.g., 327 on-demand meter reads), or in response to some local event (e.g., 328 power outage, leak detection). Such traffic is typically destined to 329 a single head-end server. The SMD traffic is thus highly asymmetric, 330 where the majority of the traffic volume generated by the smart 331 meters typically goes through the LBRs, and is directed from the 332 smart meter devices to the head-end servers, in a MP2P fashion. 333 Current SMD traffic patterns are fairly uniform and well-understood. 334 The traffic generated by the head-end server and destined to metering 335 devices is dominated by periodic meter reads, while traffic generated 336 by the metering devices is typically uniformly spread over some 337 periodic read time-window. 339 Smart metering applications typically do not have hard real-time 340 constraints, but they are often subject to bounded latency and 341 stringent reliability service level agreements. 343 Distribution Automation (DA) applications typically involve a small 344 number of devices that communicate with each other in a Point-to- 345 Point (P2P) fashion, and may or may not be in close physical 346 proximity. DA applications typically have more stringent latency 347 requirements than SMD applications. 349 There are also a number of emerging applications such as electric 350 vehicle charging. These applications may require P2P communication 351 and may eventually have more stringent latency requirements than SMD 352 applications. 354 4.2. Smart Grid Traffic QoS Requirements 356 As described previously, the two main traffic families in a NAN are: 358 A) Meter-initiated traffic (Meter-to-head-end - M2HE) 360 B) Head-end-initiated traffic (Head-end-to-meter - HE2M) 362 B1) request is sent in point-to-point to a specific meter 364 B2) request is sent in multicast to a subset of meters 366 B3) request is sent in multicast to all meters 368 The M2HE are event-based, while the HE2M are mostly command-response. 369 In most cases, M2HE traffic is more critical than HE2M one, but there 370 can be exceptions. 372 Regarding priority, traffic may also be decomposed into several 373 classes : 375 C1) Highly Priority Critical traffic for Power System Outage, 376 Pricing Events and Emergency Messages require a 98%+ packet 377 delivery under 5 s. Payload size < 100 bytes 379 C2) Critical Priority traffic Power Quality Events, Meter Service 380 Connection and Disconnection require 98%+ packet delivery under 381 10s. Payload size < 150 bytes 383 C3) Normal Priority traffic for System Events including Faults, 384 Configuration and Security require 98%+ packet delivery under 30s. 385 Payload size < 200 bytes 387 C4) Low Priority traffic for Recurrent Meter Reading require 98%+ 388 packet 2 hour delivery window 6 times per day. Payload size < 400 389 bytes 391 C5) Background Priority traffic for firmware/software updates 392 processed to 98%+ of devices with in 7 days. Average firmware 393 update is 1 MB. 395 4.3. RPL applicability per Smart Grid Traffic Characteristics 397 RPL non-storing mode of operation naturally support upstream and 398 downstream forwarding of unicast traffic between the DODAG root and 399 each DODAG node, and between DODAG nodes and DODAG root, 400 respectively. 402 Group communication model used in smart grid requires RPL non-storing 403 mode of operation to support downstream forwarding of multicast 404 traffic with a scope larger than link-local. The DODAG root is the 405 single device that injects multicast traffic, with a scope larger 406 than link-local, into the DODAG. 408 Although not currently used in metering applications, support of 409 peer- to-peer communications between DODAG nodes is identified as a 410 key feature to be supported in smart grid networks. 412 5. Layer 2 applicability 414 5.1. IEEE Wireless Technology 416 IEEE Std. 802.15.4g-2012 and IEEE 802.15.4e-2012 amendments to 417 802.15.2-2011 standard have been specifically developed for smart 418 grid networks. They are the most common PHY and MAC layers used for 419 wireless AMI network. 802.15.4g specifies multiple modes of 420 operation (FSK, OQPSK and OFDM modulations) with speeds from 50kbps 421 to 600kbps, and allows for transport of a full IPv6 packet (i.e., 422 1280 octets) without the need for upper layer segmentation and re- 423 assembly. 425 IEEE Std. 802.15.4e-2012 is an amendment to IEEE Std 802.15.4-2011 426 that specifies additional media access control (MAC) behaviors and 427 frame formats that allow IEEE 802.15.4 devices to support a wide 428 range of industrial and commercial applications that were not 429 adequately supported prior to the release of this amendment. It is 430 important to notice that 802.15.4e does not change the link-layer 431 security scheme defined in 802.15.4-2011 (and 802.15.4-2006). 433 5.2. IEEE PowerLine Communication (PLC) technology 435 The IEEE Std. 1901.2-2013 standard specifies communications for low 436 frequency (less than 500 kHz) narrowband power line devices via 437 alternating current and direct current electric power lines. IEEE 438 Std P1901.2-2013 standard supports indoor and outdoor communications 439 over low voltage line (line between transformer and meter, less than 440 1000 V), through transformer low-voltage to medium-voltage (1000 V up 441 to 72 kV) and through transformer medium-voltage to low-voltage power 442 lines in both urban and in long distance (multi- kilometer) rural 443 communications. 445 IEEE Std. 1901.2 defines the PHY layer and the MAC sub-layer of the 446 data link layer. The MAC sub-layer endorses a sub-set of 447 802.15.4-2006 and 802.15.4e-2012 MAC sub-layer features. 449 IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps 450 depending on the application requirements and type of encoding used. 452 IEEE Std. 1901.2 MAC layer allows for transport of a full IPv6 packet 453 (i.e., 1280 octets) without the need for upper layer segmentation and 454 re-assembly. 456 IEEE Std. 1901.2 specifies the necessary link-layer security features 457 that fully endorse 802.15.4-2006 MAC sub-layer security scheme. 459 6. Using RPL to Meet Functional Requirements 461 The functional requirements for most AMI deployments are similar to 462 those listed in [RFC5548]: 464 o The routing protocol MUST be capable of supporting the 465 organization of a large number of nodes into regions containing on 466 the order of 10^2 to 10^4 nodes each. 468 o The routing protocol MUST provide mechanisms to support 469 configuration of the routing protocol itself. 471 o The routing protocol SHOULD support and utilize the large number 472 of highly directed flows to a few head-end servers to handle 473 scalability. 475 o The routing protocol MUST dynamically compute and select effective 476 routes composed of low-power and lossy links. Local network 477 dynamics SHOULD NOT impact the entire network. The routing 478 protocol MUST compute multiple paths when possible. 480 o The routing protocol MUST support multicast and unicast 481 addressing. The routing protocol SHOULD support formation and 482 identification of groups of field devices in the network. 484 RPL supports the following features: 486 o Scalability: Large-scale networks characterized by highly directed 487 traffic flows between each smart meter and the head-end servers in 488 the utility network. To this end, RPL builds a Directed Acyclic 489 Graph (DAG) rooted at each LBR. 491 o Zero-touch configuration: This is done through in-band methods for 492 configuring RPL variables using DIO messages, and DIO message 493 options. 495 o The use of links with time-varying quality characteristics: This 496 is accomplished by allowing the use of metrics that effectively 497 capture the quality of a path (e.g., Expected Transmission Count 498 (ETX)) and by limiting the impact of changing local conditions by 499 discovering and maintaining multiple DAG parents, and by using 500 local repair mechanisms when DAG links break. 502 7. RPL Profile 504 7.1. RPL Features 506 7.1.1. RPL Instances 508 RPL operation is defined for a single RPL instance. However, 509 multiple RPL instances can be supported in multi-service networks 510 where different applications may require the use of different routing 511 metrics and constraints, e.g., a network carrying both SDM and DA 512 traffic. 514 7.1.2. Storing vs. Non-Storing Mode 516 In most scenarios, electric meters are powered by the grid they are 517 monitoring and are not energy-constrained. Instead, electric meters 518 have hardware and communication capacity constraints that are 519 primarily determined by cost, and secondarily by power consumption. 520 As a result, different AMI deployments can vary significantly in 521 terms of memory size, computation power and communication 522 capabilities. For this reason, the use of RPL storing or non-storing 523 mode SHOULD be deployment specific. When meters are memory 524 constrained and cannot adequately store the route tables necessary to 525 support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. 526 On the other hand, when nodes are capable of storing such routing 527 tables, the use of storing mode may lead to reduced overhead and 528 route repair latency. However, in high-density environments, storing 529 routes can be challenging because some nodes may have to maintain 530 routing information for a large number of descendents. In this 531 document, we only focus on non-storing mode of operation. 533 7.1.3. DAO Policy 535 Two-way communication is a requirement in AMI systems. As a result, 536 nodes SHOULD send DAO messages to establish downward paths from the 537 root to themselves. 539 7.1.4. Path Metrics 541 Smart metering deployments utilize link technologies that may exhibit 542 significant packet loss and thus require routing metrics that take 543 packet loss into account. To characterize a path over such link 544 technologies, AMI deployments can use the Expected Transmission Count 545 (ETX) metric as defined in [RFC6551]. 547 Additional metrics may be defined in companion RFCs. 549 7.1.5. Objective Function 551 RPL relies on an Objective Function for selecting parents and 552 computing path costs and rank. This objective function is decoupled 553 from the core RPL mechanisms and also from the metrics in use in the 554 network. Two objective functions for RPL have been defined at the 555 time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of 556 which define the selection of a preferred parent and backup parents, 557 and are suitable for AMI deployments. 559 Additional objective functions may be defined in companion RFCs. 561 7.1.6. DODAG Repair 563 To effectively handle time-varying link characteristics and 564 availability, AMI deployments SHOULD utilize the local repair 565 mechanisms in RPL. Local repair is triggered by broken link 566 detection. The first local repair mechanism consists of a node 567 detaching from a DODAG and then re-attaching to the same or to a 568 different DODAG at a later time. While detached, a node advertises 569 an infinite rank value so that its children can select a different 570 parent. This process is known as poisoning and is described in 571 Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a 572 local DODAG, doing so in AMI for electric meters is of little benefit 573 since AMI applications typically communicate through a LBR. After 574 the detached node has made sufficient effort to send notification to 575 its children that it is detached, the node can rejoin the same DODAG 576 with a higher rank value. The configured duration of the poisoning 577 mechanism needs to take into account the disconnection time 578 applications running over the network can tolerate. Note that when 579 joining a different DODAG, the node need not perform poisoning. The 580 second local repair mechanism controls how much a node can increase 581 its rank within a given DODAG Version (e.g., after detaching from the 582 DODAG as a result of broken link or loop detection). Setting the 583 DAGMaxRankIncrease to a non-zero value enables this mechanism, and 584 setting it to a value of less than infinity limits the cost of count- 585 to-infinity scenarios when they occur, thus controlling the duration 586 of disconnection applications may experience. 588 7.1.7. Multicast 590 Multicast support for RPL in non-storing mode are being developed in 591 companion RFCs (see [I-D.ietf-roll-trickle-mcast]). 593 7.1.8. Security 595 AMI deployments operate in areas that do not provide any physical 596 security. For this reason, the link layer, transport layer and 597 application layer technologies utilized within AMI networks typically 598 provide security mechanisms to ensure authentication, 599 confidentiality, integrity, and freshness. As a result, AMI 600 deployments may not need to implement RPL's security mechanisms and 601 could rely on link layer and higher layer security features. 603 7.1.9. Peer-to-Peer communications 605 Basic peer-to-peer capabilities are already defined in the RPL 606 [RFC6550]. Additional mechanisms for peer-to-peer communications are 607 proposed in companion RFCs (see [RFC6997]). 609 7.2. Description of Layer-two features 611 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features 613 The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and 614 defines a time frequency interleaver over the entire PHY frame 615 coupled with a Reed Solomon and Viterbi Forward Error Correction for 616 maximum robustness. Since the noise level in each OFDM sub-carrier 617 can vary significantly, IEEE 1901.2 specifies two complementary 618 mechanisms allowing to fine-tune the robustness/performance tradeoff 619 implicit in such systems. More specifically, the first (coarse- 620 grained) mechanism, defines the modulation from several possible 621 choices (robust (super-ROBO, ROBO), BPSK, QPSK,...). The second 622 (fine-grained) maps the sub-carriers which are too noisy and 623 deactivates them. 625 The existence of multiple modulations and dynamic frequency exclusion 626 renders the problem of selecting a path between two nodes non- 627 trivial, as the possible number of combinations increases 628 significantly, e.g. use a direct link with slow robust modulation, 629 or use a relay meter with fast modulation and 12 disabled sub- 630 carriers. In addition, IEEE 1901.2 technology offers a mechanism 631 (adaptive tone map) for periodic exchanges on the link quality 632 between nodes to constantly react to channel fluctuations. Every 633 meter keeps a state of the quality of the link to each of its 634 neighbors by either piggybacking the tone mapping on the data 635 traffic, or by sending explicit tone map requests. 637 IEEE 1901.2 MAC frame format shares most in common with the IEEE 638 802.15.4-2006 MAC frame format [IEEE802.15.4], with a few exceptions 639 described below. 641 o IEEE 1901.2 MAC frame is obtained by prepending a Segment Control 642 Field to the IEEE 802.15.4-2006 MAC header. One function of the 643 Segment Control Field is to signal the use of the MAC sub-layer 644 segmentation and reassembly. 646 o IEEE 1901.2 MAC frames uses only the 802.15.4 MAC addresses with a 647 length of 16 and 64 bits. 649 o IEEE 1901.2 MAC sub-layer endorses the concept of Information 650 Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The 651 format and use of Information Elements are not relevant to RPL 652 applicability statement. 654 The IEEE 1901.2 PHY frame payload size varies as a function of the 655 modulation used to transmit the frame and the strength of the Forward 656 Error Correction scheme. 658 The maximum IEEE 1901.2 PHY frame payload is 512 bytes. The maximum 659 IEEE 1901.2 MAC frame payload is 1280 bytes, which supports the IPv6 660 minimum MTU requirement. 662 When there is a mistmatch between the PHY frame payload size and the 663 size of a MAC frame carrying an IPv6 packet, IEEE 1901.2 specifies a 664 MAC sub-layer segmentation and re-assembly mechanism that provides a 665 reliable one-hop transfer of that MAC frame segments. 667 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features 669 IEEE Std 802.15.4g defines multiple modes of operation, where each 670 mode uses different modulation and has multiple data rates. 671 Additionally, 802.15.4g PHY layer includes mechanisms to improve the 672 robustness of the radio communications, such as data whitening and 673 Forward Error Correction coding. The 802.15.4g PHY frame payload can 674 carry up to 2048 octets. 676 The IEEE Std 802.15.4g defines the following modulations: MR-FSK 677 (Multi- Rate FSK), MR-OFDM (Multi-Rate OFDM) and MR-O-QPSK (Multi- 678 Rate O-QPSK). The (over-the-air) bit rates for these modulations 679 range from 4.8 to 600kbps for MR-FSK, from 50 to 600kbps for MR-OFDM 680 and from 6.25 to 500kbps for MR-O-QPSK. 682 The MAC sub-layer running on top of a 4g radio link is based on IEEE 683 802.15.4e. The 802.15.4e MAC allows for a variety of modes for 684 operation. These include: Timetimeslotslotted channel hopping 685 (TSCH), specifically designed for application domains such as process 686 automation, Low latency deterministic networks (LLDN), for 687 application domains such as factory automation, Deterministic and 688 synchronous multi-channel extension (DSME), for general industrial 689 and commercial application domains that includes Channel diversity to 690 increase network robustness, and Asynchronous multi-channel 691 adaptation (AMCA), for large infrastructure application domains. 693 The MAC addressing scheme supports short (16-bits) addresses along 694 with extended (64-bits) addresses. 696 Information Elements, Enhanced Beacons and frame version 2, as 697 defined in 802.15.4e, MUST be supported. 699 Since the MAC frame payload size limitation is given by the 4g PHY 700 frame payload size limitation (i.e.,2048 bytes) and MAC layer 701 overhead (headers, trailers, Information Elements and security 702 overhead), the MAC frame payload MUST able to carry a full IPv6 703 packet of 1280 octets without upper layer fragmentation and re- 704 assembly. 706 7.2.3. IEEE MAC sub-layer Security Features 708 Since IEEE 1901.2 standard is based on the 802.15.4-2006 MAC sub- 709 layer and fully endorses the security scheme defined in 710 802.15.4-2006, we only focus on description of IEEE 802.15.4 security 711 scheme. 713 The IEEE 802.15.4 specification was designed to support a variety of 714 applications, many of which are security sensitive. The IEEE 715 802.15.4 provides four basic security services: message 716 authentication, message integrity, message confidentiality, and 717 freshness checks to avoid replay attacks. 719 The 802.15.4 security layer is handled at the media access control 720 layer, below 6LowPAN layer. The application specifies its security 721 requirements by setting the appropriate control parameters into the 722 radio/PLC stack. The 802.15.4 defines four packet types: beacon 723 frames, data frames, acknowledgments frame, and command frames for 724 the media access control layer. The 802.15.4 specification does not 725 support security for acknowledgement frames; data frames, beacon 726 frames and command frames can support integrity protection and 727 confidentiality protection for the frames's data field. An 728 application has a choice of security suites that control the type of 729 security protection that is provided for the transmitted MAC frame. 730 Each security suite offers a different set of security properties and 731 guarantees, and ultimately different MAC frame formats. The 802.15.4 732 specification defines eight different security suites, outlined 733 bellow. We can broadly classify the suites by the properties that 734 they offer: no security, encryption only (AES-CTR), authentication 735 only (AES-CBC-MAC), and encryption and authentication (AES-CCM). 736 Each category that supports authentication comes in three variants 737 depending on the size of the MAC (Message Authentication Control) 738 that it offers. The MAC can be either 4, 8, or 16 bytes long. 739 Additionally, for each suite that offers encryption, the recipient 740 can optionally enable replay protection. 742 o Null = No security. 744 o AES-CTR = Encryption only, CTR mode. 746 o AES-CBC-MAC-128 = No encryption, 128-bit MAC. 748 o AES-CBC-MAC-64 = No encryption, 64-bit MAC. 750 o AES-CCM-128 = Encryption and 128-bit MAC. 752 o AES-CCM-64 = Encryption and 64-bit MAC. 754 o AES-CCM-32 = Encryption and 32-bit MAC. 756 To achieve authentication, any device can maintain an Access Control 757 List (ACL) which is a list of trusted nodes from which the device 758 wishes to receive data. Data encryption is done by encryption of 759 Message Authentication Control (MAC) frame payload using the key 760 shared between two devices, or among a group of peers. If the key is 761 to be shared between two peers, it is stored with each entry in the 762 ACL list; otherwise, the key is stored as the default key. Thus, the 763 device can make sure that its data can not be read by devices that do 764 not possess the corresponding key. However, device addresses are 765 always transmitted unencrypted, which makes attacks that rely on 766 device identity somewhat easier to launch. Integrity service is 767 applied by appending a Message Integrity Code (MIC) generated from 768 blocks of encrypted message text. This ensures that a frame can not 769 be modified by a receiver device that does not share a key with the 770 sender. Finally, sequential freshness uses a frame counter and key 771 sequence counter to ensure the freshness of the incoming frame and 772 guard against replay attacks. 774 A cryptographic MAC is used to authenticate messages. While longer 775 MACs lead to improved resiliency of the code, they also make packet 776 size larger and thus take up bandwidth in the network. In 777 constrained environments such as metering infrastructures, an optimum 778 balance between security requirements and network throughput must be 779 found. 781 7.3. 6LowPAN Options 783 AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all 784 of the IPv6 Header Compression schemes specified in [RFC6282] 785 Section 3 and all of the IPv6 Next Header compression schemes 786 specified in [RFC6282] Section 4, if reducing over the air/wire 787 overhead is a requirement. However, since the link-layer MTU in both 788 wireless and PLC links supports the transmission of a full IPv6 789 packet, the use of 6LowPAN fragmentation is NOT RECOMMENDED. 791 7.4. Recommended Configuration Defaults and Ranges 793 7.4.1. Trickle Parameters 795 Trickle was designed to be density-aware and perform well in networks 796 characterized by a wide range of node densities. The combination of 797 DIO packet suppression and adaptive timers for sending updates allows 798 Trickle to perform well in both sparse and dense environments. Node 799 densities in AMI deployments can vary greatly, from nodes having only 800 one or a handful of neighbors to nodes having several hundred 801 neighbors. In high density environments, relatively low values for 802 Imin may cause a short period of congestion when an inconsistency is 803 detected and DIO updates are sent by a large number of neighboring 804 nodes nearly simultaneously. While the Trickle timer will 805 exponentially backoff, some time may elapse before the congestion 806 subsides. While some link layers employ contention mechanisms that 807 attempt to avoid congestion, relying solely on the link layer to 808 avoid congestion caused by a large number of DIO updates can result 809 in increased communication latency for other control and data traffic 810 in the network. To mitigate this kind of short-term congestion, this 811 document recommends a more conservative set of values for the Trickle 812 parameters than those specified in [RFC6206]. In particular, 813 DIOIntervalMin is set to a larger value to avoid periods of 814 congestion in dense environments, and DIORedundancyConstant is 815 parameterized accordingly as described below. These values are 816 appropriate for the timely distribution of DIO updates in both sparse 817 and dense scenarios while avoiding the short-term congestion that 818 might arise in dense scenarios. Because the actual link capacity 819 depends on the particular link technology used within an AMI 820 deployment, the Trickle parameters are specified in terms of the 821 link's maximum capacity for transmitting link-local multicast 822 messages. If the link can transmit m link-local multicast packets 823 per second on average, the expected time it takes to transmit a link- 824 local multicast packet is 1/m seconds. 826 DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that 827 the Trickle Imin is at least 50 times as long as it takes to 828 transmit a link-local multicast packet. This value is larger than 829 that recommended in [RFC6206] to avoid congestion in dense urban 830 deployments as described above. In energy-constrained deployments 831 (e.g., in water and gas battery-based routing infrastructure), 832 DIOIntervalMin MAY be set to a value resulting in a Trickle Imin 833 of several (e.g. 2) hours. 835 DIOIntervalDoublings: AMI deployments SHOULD set 836 DIOIntervalDoublings such that the Trickle Imax is at least 2 837 hours or more. For very energy constrained deployments (e.g., 838 water and gas battery-based routing infrastructure), 839 DIOIntervalDoublings MAY be set to a value resulting in a Trickle 840 Imax of several (e.g., 2) days. 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, March 1997. 1007 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1008 "Routing Requirements for Urban Low-Power and Lossy 1009 Networks", RFC 5548, May 2009. 1011 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1012 "The Trickle Algorithm", RFC 6206, March 2011. 1014 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1015 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1016 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1017 Lossy Networks", RFC 6550, March 2012. 1019 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1020 Barthel, "Routing Metrics Used for Path Calculation in 1021 Low-Power and Lossy Networks", RFC 6551, March 2012. 1023 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1024 "Building Automation Routing Requirements in Low-Power and 1025 Lossy Networks", RFC 5867, June 2010. 1027 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1028 Routing Requirements in Low-Power and Lossy Networks", RFC 1029 5826, April 2010. 1031 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1032 "Industrial Routing Requirements in Low-Power and Lossy 1033 Networks", RFC 5673, October 2009. 1035 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 1036 Hysteresis Objective Function", RFC 6719, September 2012. 1038 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1039 Protocol for Low-Power and Lossy Networks (RPL)", RFC 1040 6552, March 2012. 1042 [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 1043 Martocci, "Reactive Discovery of Point-to-Point Routes in 1044 Low-Power and Lossy Networks", RFC 6997, August 2013. 1046 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1047 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1048 September 2011. 1050 [I-D.ietf-roll-trickle-mcast] 1051 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1052 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1053 mcast-11 (work in progress), November 2014. 1055 [I-D.ietf-roll-terminology] 1056 Vasseur, J., "Terms used in Routing for Low power And 1057 Lossy Networks", draft-ietf-roll-terminology-13 (work in 1058 progress), October 2013. 1060 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1061 and M. Richardson, "A Security Threat Analysis for the 1062 Routing Protocol for Low-Power and Lossy Networks (RPLs)", 1063 RFC 7416, January 2015. 1065 Authors' Addresses 1067 Daniel Popa 1068 Itron, Inc 1069 52, rue Camille Desmoulins 1070 Issy les Moulineaux 92130 1071 FR 1073 Email: daniel.popa@itron.com 1075 Matthew Gillmore 1076 Itron, Inc 1077 2111 N Molter Rd. 1078 Liberty Lake, WA 99019 1079 USA 1081 Email: matthew.gillmore@itron.com 1083 Laurent Toutain 1084 Telecom Bretagne 1085 2 rue de la Chataigneraie 1086 Cesson Sevigne 35510 1087 FR 1089 Email: laurent.toutain@telecom-bretagne.eu 1090 Jonathan Hui 1091 Cisco 1092 170 West Tasman Drive 1093 San Jose, CA 95134 1094 USA 1096 Email: johui@cisco.com 1098 Ruben Salazar 1099 Landys+Gyr 1100 30000 Mill Creek Ave # 100 1101 Alpharetta, GA 30022 1102 USA 1104 Email: ruben.salazar@landisgyr.com 1106 Kazuya Monden 1107 Hitachi, Ltd., Yokohama Research Laboratory 1108 292, Yoshida-cho, Totsuka-ku, Yokohama-shi 1109 Kanagawa-ken 244-0817 1110 Japan 1112 Email: kazuya.monden.vw@hitachi.com 1114 Nancy Cam-Winget (editor) 1115 Cisco Systems 1116 3550 Cisco Way 1117 San Jose, CA 95134 1118 US 1120 Email: ncamwing@cisco.com