--- 1/draft-ietf-roll-applicability-ami-09.txt 2015-01-30 14:14:53.265018374 -0800 +++ 2/draft-ietf-roll-applicability-ami-10.txt 2015-01-30 14:14:53.321019740 -0800 @@ -1,27 +1,29 @@ Roll D. Popa Internet-Draft M. Gillmore Intended status: Standards Track Itron, Inc -Expires: January 23, 2015 L. Toutain +Expires: August 3, 2015 L. Toutain Telecom Bretagne J. Hui Cisco R. Ruben Landis+Gyr K. Monden Hitachi, Ltd., Yokohama Research Laboratory - July 22, 2014 + N. Cam-Winget, Ed. + Cisco Systems + January 30, 2015 Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks - draft-ietf-roll-applicability-ami-09 + draft-ietf-roll-applicability-ami-10 Abstract This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -29,25 +31,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 23, 2015. + This Internet-Draft will expire on August 3, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -76,37 +78,38 @@ 7.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 11 7.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 12 7.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 12 7.1.5. Objective Function . . . . . . . . . . . . . . . . . 12 7.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 7.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 13 7.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 13 7.1.9. Peer-to-Peer communications . . . . . . . . . . . . . 13 7.2. Description of Layer-two features . . . . . . . . . . . . 13 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . 13 - 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 14 + 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 15 7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . 15 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 17 7.4. Recommended Configuration Defaults and Ranges . . . . . . 17 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18 8. Manageability Considerations . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. Security Considerations during initial deployment . . . . 20 9.2. Security Considerations during incremental deployment . . 20 - 10. Other Related Protocols . . . . . . . . . . . . . . . . . . . 20 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 13.1. Informative References . . . . . . . . . . . . . . . . . 20 - 13.2. Normative references . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.3. Security Considerations based on RPL's Threat Analysis . 20 + 10. Other Related Protocols . . . . . . . . . . . . . . . . . . . 21 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 13.1. Informative References . . . . . . . . . . . . . . . . . 21 + 13.2. Normative references . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Advanced Metering Infrastructure (AMI) systems enable the measurement, configuration, and control of energy, gas and water consumption and distribution, through two-way scheduled, on exception, and on-demand communication. AMI networks are composed of millions of endpoints, including meters, distribution automation elements, and eventually home area network @@ -185,21 +188,21 @@ [RFC5673]. o Home Automation Routing Requirements in Low-Power and Lossy Networks [RFC5826]. o Building Automation Routing Requirements in Low-Power and Lossy Networks [RFC5867]. The Routing Requirements for Urban Low-Power and Lossy Networks are applicable to AMI networks as well. The terminology used in this - document is defined in [I-D.ietf-roll-terminology-13]. + document is defined in [I-D.ietf-roll-terminology]. 3. Description of AMI networks for electric meters In many deployments, in addition to measuring energy consumption, the electric meter network plays a central role in the Smart Grid since the device enables the utility company to control and query the electric meters themselves and can serve as a backhaul for all other devices in the Smart Grid, e.g., water and gas meters, distribution automation and home area network devices. Electric meters may also be used as sensors to monitor electric grid quality and to support @@ -242,102 +245,103 @@ proximity form routing domains, each in the order of a 1,000 to 10,000 meters. Thus, each electric meter mesh typically has several thousand wireless endpoints, with densities varying based on the area and the terrain. | +M | M M M M | M /-----------\ /---+---+---+---+--+-+- phase 1 - +----+ ( Internet ) +----+ / M M M M + +----+ ( Internet ) +-----+ / M M M M |MDMS|---( )----|LBR |/----+----+----+----+---- phase 2 - +----+ ( WAN ) +----+\ + +----+ ( WAN ) +-----+\ \----------/ \ M M M M \--+--+----+-+---+----- phase 3 \ M M +--+---+-- - <----------------------------> + <-----------------------------> RPL Figure 1: Typical NAN Topology A typical AMI network architecture (see figure Figure 1) is composed of a MDMS (Meter Data Management System) connected through IP network to a LBR, which can be located in the power substation or somewhere else in the field. The power substation connects the households and buildings. The physical topology of the electrical grid is a tree structure, either due to the 3 different power phases coming through the sub-station or just to the electrical network topology. Meters (represented by a M in the previous figure) can also participate to a HAN (Home-Area Network). The scope of this document is the - communication between the LBR and the meters,i.e., the NAN segment. + communication between the LBR and the meters, i.e. the NAN (Neighbor- + Area Network) segment. Node density can vary significantly. For example, apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have a small number of network neighbors. Each routing domain is connected to the larger IP infrastructure through one or more LBRs, which provide Wide Area Network (WAN) connectivity through various traditional network technologies, e.g., Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in the mesh between a network node and the nearest LBR may be composed of several hops or even several tens of hops. Powered from the main line, electric meters have less energy constraints than battery powered devices, such as gas and water meters, and can afford the additional resources required to route packets. - As a function of the the technology used to exchange information, the - logical network topology will not necessarily match the eletric grid + As a function of the technology used to exchange information, the + logical network topology will not necessarily match the electric grid topology. If meters exchange information through radio technologies such as in IEEE 802.15.4 family, the topology is a meshed network, where nodes belonging to the same DODAG can be connected to the grid through different substations. If narrowband PLC technology is used, it will follow more or less the physical tree structure since diaphony may allow one phase to communicate with the other. This is - particularly true near the LBR. Some mixt topology can also be - observed, since some LBR may be strategically installed in the field + particularly true near the LBR. Some mixed topology can also be + observed, since some LBRs may be strategically installed in the field to avoid all the communications going through a single LBR. Nethertheless, the short propagation range forces meters to relay the information. 4. Smart Grid Traffic Description 4.1. Smart Grid Traffic Characteristics In current AMI deployments, metering applications typically require all smart meters to communicate with a few head-end servers, deployed in the utility company data center. Head-end servers generate data - traffic to configure smart meter data reading or initiate queries, - and use unicast and multicast to efficiently communicate with a - single device (i.e., Point-to-Point (P2P) communications) or groups - of devices respectively (i.e., Point-to-Multipoint (P2MP) - communication). The head-end server may send a single small packet - at a time to the meters (e.g., a meter read request, a small - configuration change, service switch command) or a series of large - packets (e.g., a firmware download across one or even thousands of - devices). The frequency of large file transfers, e.g., firmware - download of all metering devices, is typically much lower than the - frequency of sending configuration messages or queries. Each smart - meter generates Smart Metering Data (SMD) traffic according to a - schedule (e.g., periodic meter reads), in response to on-demand - queries (e.g., on-demand meter reads), or in response to some local - event (e.g., power outage, leak detection). Such traffic is - typically destined to a single head-end server. The SMD traffic is - thus highly asymmetric, where the majority of the traffic volume - generated by the smart meters typically goes through the LBRs, and is - directed from the smart meter devices to the head-end servers, in a - MP2P fashion. Current SMD traffic patterns are fairly uniform and - well-understood. The traffic generated by the head-end server and - destined to metering devices is dominated by periodic meter reads, - while traffic generated by the metering devices is typically - uniformly spread over some periodic read time-window. + traffic to configure smart data reading or initiate queries, and use + unicast and multicast to efficiently communicate with a single device + (i.e. Point-to-Point (P2P) communications) or groups of devices + respectively (i.e., Point-to-Multipoint (P2MP) communication). The + head-end server may send a single small packet at a time to the + meters (e.g., a meter read request, a small configuration change, + service switch command) or a series of large packets (e.g., a + firmware download across one or even thousands of devices). The + frequency of large file transfers, e.g., firmware download of all + metering devices, is typically much lower than the frequency of + sending configuration messages or queries. Each smart meter + generates Smart Metering Data (SMD) traffic according to a schedule + (e.g., periodic meter reads), in response to on-demand queries (e.g., + on-demand meter reads), or in response to some local event (e.g., + power outage, leak detection). Such traffic is typically destined to + a single head-end server. The SMD traffic is thus highly asymmetric, + where the majority of the traffic volume generated by the smart + meters typically goes through the LBRs, and is directed from the + smart meter devices to the head-end servers, in a MP2P fashion. + Current SMD traffic patterns are fairly uniform and well-understood. + The traffic generated by the head-end server and destined to metering + devices is dominated by periodic meter reads, while traffic generated + by the metering devices is typically uniformly spread over some + periodic read time-window. Smart metering applications typically do not have hard real-time constraints, but they are often subject to bounded latency and stringent reliability service level agreements. Distribution Automation (DA) applications typically involve a small number of devices that communicate with each other in a Point-to- Point (P2P) fashion, and may or may not be in close physical proximity. DA applications typically have more stringent latency requirements than SMD applications. @@ -394,69 +398,70 @@ downstream forwarding of unicast traffic between the DODAG root and each DODAG node, and between DODAG nodes and DODAG root, respectively. Group communication model used in smart grid requires RPL non-storing mode of operation to support downstream forwarding of multicast traffic with a scope larger than link-local. The DODAG root is the single device that injects multicast traffic, with a scope larger than link-local, into the DODAG. - Altough not currently used in metering applications, support of peer- - to-peer communications between DODAG nodes is identified as a key - feature to be supported in smart grid networks. + Although not currently used in metering applications, support of + peer- to-peer communications between DODAG nodes is identified as a + key feature to be supported in smart grid networks. 5. Layer 2 applicability 5.1. IEEE Wireless Technology IEEE Std. 802.15.4g-2012 and IEEE 802.15.4e-2012 amendments to 802.15.2-2011 standard have been specifically developed for smart grid networks. They are the most common PHY and MAC layers used for - wireless AMI network. 802.15.4g specifies multiple mode of operation - (FSK, OQPSK and OFDM modulations) with speeds from 50kbps to 600kbps, - and allows for transport of a full IPv6 packet (i.e., 1280 octets) - without the need for upper layer segmentation and re-assembly. + wireless AMI network. 802.15.4g specifies multiple modes of + operation (FSK, OQPSK and OFDM modulations) with speeds from 50kbps + to 600kbps, and allows for transport of a full IPv6 packet (i.e., + 1280 octets) without the need for upper layer segmentation and re- + assembly. IEEE Std. 802.15.4e-2012 is an amendment to IEEE Std 802.15.4-2011 that specifies additional media access control (MAC) behaviors and frame formats that allow IEEE 802.15.4 devices to support a wide range of industrial and commercial applications that were not adequately supported prior to the release of this amendment. It is important to notice that 802.15.4e does not change the link-layer security scheme defined in 802.15.4-2011 (and 802.15.4-2006). 5.2. IEEE PowerLine Communication (PLC) technology - The IEEE Std 1901.2-2013 standard specifies communications for low + The IEEE Std. 1901.2-2013 standard specifies communications for low frequency (less than 500 kHz) narrowband power line devices via alternating current and direct current electric power lines. IEEE - Std 1901.2-2013 standard supports indoor and outdoor communications + Std P1901.2-2013 standard supports indoor and outdoor communications over low voltage line (line between transformer and meter, less than 1000 V), through transformer low-voltage to medium-voltage (1000 V up to 72 kV) and through transformer medium-voltage to low-voltage power lines in both urban and in long distance (multi- kilometer) rural communications. - IEEE Std 1901.2 defines the PHY layer and the MAC sub-layer of the + IEEE Std. 1901.2 defines the PHY layer and the MAC sub-layer of the data link layer. The MAC sub-layer endorses a sub-set of 802.15.4-2006 and 802.15.4e-2012 MAC sub-layer features. - IEEE Std 1901.2 PHY Layer bit rates are scalable up to 500 kbps + IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps depending on the application requirements and type of encoding used. - IEEE Std 1901.2 MAC layer allows for transport of a full IPv6 packet + IEEE Std. 1901.2 MAC layer allows for transport of a full IPv6 packet (i.e., 1280 octets) without the need for upper layer segmentation and - reassembly. + re-assembly. - IEEE Std 1901.2 standard specifies link-layer security features that - fully endorse 802.15.4-2006 MAC sub-layer security scheme. + IEEE Std. 1901.2 specifies the necessary link-layer security features + that fully endorse 802.15.4-2006 MAC sub-layer security scheme. 6. Using RPL to Meet Functional Requirements The functional requirements for most AMI deployments are similar to those listed in [RFC5548]: o The routing protocol MUST be capable of supporting the organization of a large number of nodes into regions containing on the order of 10^2 to 10^4 nodes each. @@ -516,21 +521,21 @@ terms of memory size, computation power and communication capabilities. For this reason, the use of RPL storing or non-storing mode SHOULD be deployment specific. When meters are memory constrained and cannot adequately store the route tables necessary to support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. On the other hand, when nodes are capable of storing such routing tables, the use of storing mode may lead to reduced overhead and route repair latency. However, in high-density environments, storing routes can be challenging because some nodes may have to maintain routing information for a large number of descendents. In this - document we only focus on non-storing mode of operation. + document, we only focus on non-storing mode of operation. 7.1.3. DAO Policy Two-way communication is a requirement in AMI systems. As a result, nodes SHOULD send DAO messages to establish downward paths from the root to themselves. 7.1.4. Path Metrics Smart metering deployments utilize link technologies that may exhibit @@ -542,22 +547,23 @@ Additional metrics may be defined in companion RFCs. 7.1.5. Objective Function RPL relies on an Objective Function for selecting parents and computing path costs and rank. This objective function is decoupled from the core RPL mechanisms and also from the metrics in use in the network. Two objective functions for RPL have been defined at the time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of which define the selection of a preferred parent and backup parents, - and are suitable for AMI deployments. Additional objective functions - may be defined in companion RFCs. + and are suitable for AMI deployments. + + Additional objective functions may be defined in companion RFCs. 7.1.6. DODAG Repair To effectively handle time-varying link characteristics and availability, AMI deployments SHOULD utilize the local repair mechanisms in RPL. Local repair is triggered by broken link detection. The first local repair mechanism consists of a node detaching from a DODAG and then re-attaching to the same or to a different DODAG at a later time. While detached, a node advertises an infinite rank value so that its children can select a different @@ -575,21 +581,21 @@ its rank within a given DODAG Version (e.g., after detaching from the DODAG as a result of broken link or loop detection). Setting the DAGMaxRankIncrease to a non-zero value enables this mechanism, and setting it to a value of less than infinity limits the cost of count- to-infinity scenarios when they occur, thus controlling the duration of disconnection applications may experience. 7.1.7. Multicast Multicast support for RPL in non-storing mode are being developed in - companion RFCs (see [draft-ietf-roll-trickle-mcast-06]). + companion RFCs (see [I-D.ietf-roll-trickle-mcast]). 7.1.8. Security AMI deployments operate in areas that do not provide any physical security. For this reason, the link layer, transport layer and application layer technologies utilized within AMI networks typically provide security mechanisms to ensure authentication, confidentiality, integrity, and freshness. As a result, AMI deployments may not need to implement RPL's security mechanisms and could rely on link layer and higher layer security features. @@ -597,31 +603,31 @@ 7.1.9. Peer-to-Peer communications Basic peer-to-peer capabilities are already defined in the RPL [RFC6550]. Additional mechanisms for peer-to-peer communications are proposed in companion RFCs (see [RFC6997]). 7.2. Description of Layer-two features 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features - The IEEE Std 1901.2 PHY layer is based on OFDM modulation and defines - a time frequency interleaver over the entire PHY frame coupled with a - Reed Solomon and Viterbi Forward Error Correction for maximum - robustness. Since the noise level in each OFDM sub-carrier can vary - significantly IEEE 1901.2 specifies two complementary mechanisms - allowing to fine-tune the robustness/performance tradeoff implicit in - such systems. More specifically, the first (coarse-grained) - mechanism, defines the modulation from several possible choices - (robust (super-ROBO, ROBO), BPSK, QPSK,...). The second (fine- - grained) maps the sub-carriers which are too noisy and deactivates - them. + The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and + defines a time frequency interleaver over the entire PHY frame + coupled with a Reed Solomon and Viterbi Forward Error Correction for + maximum robustness. Since the noise level in each OFDM sub-carrier + can vary significantly, IEEE 1901.2 specifies two complementary + mechanisms allowing to fine-tune the robustness/performance tradeoff + implicit in such systems. More specifically, the first (coarse- + grained) mechanism, defines the modulation from several possible + choices (robust (super-ROBO, ROBO), BPSK, QPSK,...). The second + (fine-grained) maps the sub-carriers which are too noisy and + deactivates them. The existence of multiple modulations and dynamic frequency exclusion renders the problem of selecting a path between two nodes non- trivial, as the possible number of combinations increases significantly, e.g. use a direct link with slow robust modulation, or use a relay meter with fast modulation and 12 disabled sub- carriers. In addition, IEEE 1901.2 technology offers a mechanism (adaptive tone map) for periodic exchanges on the link quality between nodes to constantly react to channel fluctuations. Every meter keeps a state of the quality of the link to each of its @@ -714,29 +720,31 @@ layer, below 6LowPAN layer. The application specifies its security requirements by setting the appropriate control parameters into the radio/PLC stack. The 802.15.4 defines four packet types: beacon frames, data frames, acknowledgments frame, and command frames for the media access control layer. The 802.15.4 specification does not support security for acknowledgement frames; data frames, beacon frames and command frames can support integrity protection and confidentiality protection for the frames's data field. An application has a choice of security suites that control the type of security protection that is provided for the transmitted MAC frame. - The 802.15.4 specification defines eight different security suites, - outlined bellow. We can broadly classify the suites by the - properties that they offer: no security, encryption only (AES-CTR), - authentication only (AES-CBC-MAC), and encryption and authentication - (AES-CCM). Each category that supports authentication comes in three - variants depending on the size of the MAC (Message Authentication - Control) that it offers. The MAC can be either 4, 8, or 16 bytes - long. Additionally, for each suite that offers encryption, the - recipient can optionally enable replay protection. + Each security suite offers a different set of security properties and + guarantees, and ultimately different MAC frame formats. The 802.15.4 + specification defines eight different security suites, outlined + bellow. We can broadly classify the suites by the properties that + they offer: no security, encryption only (AES-CTR), authentication + only (AES-CBC-MAC), and encryption and authentication (AES-CCM). + Each category that supports authentication comes in three variants + depending on the size of the MAC (Message Authentication Control) + that it offers. The MAC can be either 4, 8, or 16 bytes long. + Additionally, for each suite that offers encryption, the recipient + can optionally enable replay protection. o Null = No security. o AES-CTR = Encryption only, CTR mode. o AES-CBC-MAC-128 = No encryption, 128-bit MAC. o AES-CBC-MAC-64 = No encryption, 64-bit MAC. o AES-CCM-128 = Encryption and 128-bit MAC. @@ -889,44 +897,71 @@ 9. Security Considerations Smart grid networks are subject to stringent security requirements as they are considered a critical infrastructure component. At the same time, since they are composed of large numbers of resource- constrained devices inter-connected with limited-throughput links, many available security mechanisms are not practical for use in such networks. As a result, the choice of security mechanisms is highly dependent on the device and network capabilities characterizing a - particular deployment. In contrast to other types of LLNs, in smart - grid networks centralized administrative control and access to a - permanent secure infrastructure is available. As a result link- - layer, transport-layer and/or application-layer security mechanisms - are typically in place and using RPL's secure mode is not necessary. + particular deployment. + + In contrast to other types of LLNs, in smart grid networks + centralized administrative control and access to a permanent secure + infrastructure is available. As a result link-layer, transport-layer + and/or application-layer security mechanisms are typically in place + and using RPL's secure mode is not necessary. + + As this document describes the applicability of RPL non-storing mode, + the security considerations as defined in [RFC6550] also applies to + this document and to AMI deployments. 9.1. Security Considerations during initial deployment During the manufacturing process, the meters are loaded with the appropriate security credentials (keys, certificates). These security credentials are unique per device and only known by the device itself and the head-end security appliances. The manufacturing security credentials are then used by the devices to authenticate with the system and negotiate operational security credentials, for both network and application layers. 9.2. Security Considerations during incremental deployment If during the system operation a device fails or is compromised, it is replaced with a new device. The new device does not take over the security identity of the replaced device. The security credentials associated with the failed/compromised device are removed from the security appliances. +9.3. Security Considerations based on RPL's Threat Analysis + + [RFC7416] defines a set of security considerations for RPL security. + This document defines how it leverages the device's link layer and + application layer security mechanisms to address the threats as + defined in Section 6 of [RFC7416]. + + Like any secure network infrastructure, an AMI deployment's ability + to address node impersonation, active man-in-the-middle attacks + relies on mutual authentication and authorization process. The + credential management from the manufacturing imprint of security + credentials of smart meters to all credentials of nodes in the + infrastructure, all credentials must be appropriately managed and + classified through the authorization process to ensure beyond the + identity of the nodes, that the nodes are behaving or 'acting' in + their assigned roles. + + Similarly, to ensure that data has not been modified, confidentiality + and integrity at the suitable layers (e.g. link layer, application + layer or both) should be used. + 10. Other Related Protocols This section is intentionally left blank. 11. IANA Considerations This memo includes no request to IANA. 12. Acknowledgements @@ -939,36 +974,37 @@ 13.1. Informative References [surveySG] Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., Cecati, C., and G. Hancke, "A Survey on Smart Grid Potential Applications and Communication Requirements", Feb 2013. [IEEE802.15.4] - IEEE SA, "IEEE Standard for Information technology-- Local - and metropolitan area networks-- Specific requirements-- - Part 15.4: Wireless Medium Access Control (MAC) and - Physical Layer (PHY) Specifications for Low Rate Wireless - Personal Area Networks (WPANs)", September 2006. + "IEEE Standard for Information technology-- Local and + metropolitan area networks-- Specific requirements-- Part + 15.4: Wireless Medium Access Control (MAC) and Physical + Layer (PHY) Specifications for Low Rate Wireless Personal + Area Networks (WPANs)", IEEE Standard 802.15.4, September + 2006. [IEEE802.15.4e] - IEEE SA, "IEEE Standard for Local and metropolitan area - networks--Part 15.4: Low-Rate Wireless Personal Area - Networks (LR-WPANs) Amendment 1: MAC sublayer", April - 2012. + "IEEE Standard for Local and metropolitan area networks-- + Part 15.4: Low-Rate Wireless Personal Area Networks (LR- + WPANs) Amendment 1: MAC sublayer", IEEE Standard + 802.15.4e, April 2012. [IEEE1901.2] - IEEE SA, "IEEE Standard for Low-Frequency (less than 500 - kHz) Narrowband Power Line Communications for Smart Grid - Applications", December 2013. + "IEEE Standard for Low-Frequency (less than 500 kHz) + Narrowband Power Line Communications for Smart Grid + Applications", IEEE Standard 1901.2, December 2013. 13.2. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. @@ -989,30 +1025,49 @@ Lossy Networks", RFC 5867, June 2010. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. - [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. - Martocci, "Reactive Discovery of Point-to-Point Routes in - Low-Power and Lossy Networks", RFC 6997, August 2013. + [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with + Hysteresis Objective Function", RFC 6719, September 2012. [RFC6552] Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012. - [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with - Hysteresis Objective Function", RFC 6719, September 2012. + [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. + Martocci, "Reactive Discovery of Point-to-Point Routes in + Low-Power and Lossy Networks", RFC 6997, August 2013. + + [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 + Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, + September 2011. + + [I-D.ietf-roll-trickle-mcast] + Hui, J. and R. Kelsey, "Multicast Protocol for Low power + and Lossy Networks (MPL)", draft-ietf-roll-trickle- + mcast-11 (work in progress), November 2014. + + [I-D.ietf-roll-terminology] + Vasseur, J., "Terms used in Routing for Low power And + Lossy Networks", draft-ietf-roll-terminology-13 (work in + progress), October 2013. + + [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., + and M. Richardson, "A Security Threat Analysis for the + Routing Protocol for Low-Power and Lossy Networks (RPLs)", + RFC 7416, January 2015. Authors' Addresses Daniel Popa Itron, Inc 52, rue Camille Desmoulins Issy les Moulineaux 92130 FR Email: daniel.popa@itron.com @@ -1048,10 +1103,18 @@ Email: ruben.salazar@landisgyr.com Kazuya Monden Hitachi, Ltd., Yokohama Research Laboratory 292, Yoshida-cho, Totsuka-ku, Yokohama-shi Kanagawa-ken 244-0817 Japan Email: kazuya.monden.vw@hitachi.com + + Nancy Cam-Winget (editor) + Cisco Systems + 3550 Cisco Way + San Jose, CA 95134 + US + + Email: ncamwing@cisco.com