Internet Engineering Task Force (IETF) N. Cam-Winget, Ed. Request for Comments: 8036 Cisco Systems Category: Standards Track J. Hui ISSN: 2070-1721 Nest D. Popa Itron, Inc January 2017 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks
AbstractThis document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8036. Copyright Notice Copyright (c) 2017 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 described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . 3 1.3. Out-of-Scope Requirements . . . . . . . . . . . . . . . . 4 2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4 3. Description of AMI Networks for Electric Meters . . . . . . . 4 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 5 4. Smart Grid Traffic Description . . . . . . . . . . . . . . . 7 4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7 4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8 4.3. RPL Applicability per Smart Grid Traffic Characteristics 9 5. Layer-2 Applicability . . . . . . . . . . . . . . . . . . . . 9 5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9 5.2. IEEE Power Line Communication (PLC) Technology . . . . . 9 6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10 7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11 7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11 7.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . 11 7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11 7.1.4. Objective Function . . . . . . . . . . . . . . . . . 12 7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12 7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Description of Layer-2 Features . . . . . . . . . . . . . 13 7.2.1. IEEE 1901.2 PHY and MAC Sub-layer Features . . . . . 13 7.2.2. IEEE 802.15.4 (Amendments G and E) PHY and MAC Features . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. Security Considerations during Initial Deployment . . . . 20 9.2. Security Considerations during Incremental Deployment . . 20 9.3. Security Considerations Based on RPL's Threat Analysis . 20 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative references . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
RFC2119]. surveySG] gives an overview of Smart Grid architecture and related applications. A NAN can use wireless communication technology, which is based on the IEEE 802.15.4 standard family: more specifically, the Physical Layer (PHY) amendment [IEEE.802.15.4g] and the Media Access Control (MAC) sub-layer amendment [IEEE.802.15.4e], which are adapted to smart grid networks. NAN can also use Power Line Communication (PLC) technology as an alternative to wireless communications. Several standards for PLC technology have emerged, such as [IEEE.1901.2]. NAN can further use a mix of wireless and PLC technologies to increase the network coverage ratio, which is a critical requirement for AMI networks.
RFC6550] in AMI networks composed of battery-powered devices (i.e., gas/water meters). o Applicability statement for RPL in AMI networks composed of a mix of devices powered by alternating current (i.e., electric meters) and battery-powered meters (i.e., gas/water meters). o Applicability statement for RPL storing mode of operation in AMI networks. RFC6551]. This document describes the applicability of RPL non-storing mode (as defined in [RFC6550]) to AMI deployments. The Routing Requirements for Urban Low-Power and Lossy Networks [RFC5548] are applicable to AMI networks as well. The terminology used in this document is defined in [RFC7102].
sensors to monitor electric grid quality and to support applications such as electric vehicle charging. Electric meter networks can be composed of millions of smart meters (or nodes), each of which is resource constrained in terms of processing power, storage capabilities, and communication bandwidth due to a combination of factors including regulations on spectrum use; on meter behavior and performance; and on heat emissions within the meter, form factor, and cost considerations. These constraints result in a compromise between range and throughput with effective link throughput of tens to a few hundred kilobits per second per link, a potentially significant portion of which is taken up by protocol and encryption overhead when strong security measures are in place. Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility company network through a network aggregation point, e.g., an LBR. IEEE.802.11]). In addition to serving as sources and destinations of packets, many network elements typically also forward packets and thus form a mesh topology. In a typical AMI deployment, groups of meters within physical 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 |MDMS|---( )----| LBR |/----+----+----+----+---- phase 2 +----+ ( WAN ) +-----+\ \----------/ \ M M M M \--+--+----+-+---+----- phase 3 \ M M +--+---+-- <-----------------------------> RPL Figure 1: Typical NAN Topology A typical AMI network architecture (see Figure 1) is composed of a Meter Data Management System (MDMS) connected through an IP network to an 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 three different power phases coming through the substation or just to the electrical network topology. Meters (represented by a M in the previous figure) can also participate in a HAN. The scope of this document is the communication between the LBR and the meters, i.e., the NAN 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 may 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 WAN based on Worldwide Interoperability for Microwave Access (WiMAX), and 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 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 the IEEE 802.15.4 family, then the topology is a meshed
network where nodes belonging to the same Destination-Oriented DAG (DODAG) can be connected to the grid through different substations. If narrowband PLC technology is used, it will more or less follow the physical tree structure since crosstalk may allow one phase to communicate with the other. This is 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. Nevertheless, the short propagation range forces meters to relay the information.
Distribution Automation (DA) applications typically involve a small number of devices that communicate with each other in a P2P fashion and may or may not be in close physical proximity. DA applications typically have more stringent latency requirements than SMD applications. There are also a number of emerging applications such as electric vehicle charging. These applications may require P2P communication and may eventually have more stringent latency requirements than SMD applications.
C5) Background Priority traffic for firmware/software updates processed to 98%+ of devices within 7 days (average firmware update is 1 MB)
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 data link layer. The MAC sub-layer endorses a subset of IEEE Std 802.15.4 and IEEE 802.15.4e MAC sub-layer features. The IEEE Std 1901.2 PHY layer bit rates are scalable up to 500 kbps depending on the application requirements and type of encoding used. The 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. IEEE Std 1901.2 specifies the necessary link-layer security features that fully endorse the IEEE 802.15.4 MAC sub-layer security scheme. RFC5548]. This section informally highlights some of the similarities: 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. o The routing protocol MUST provide mechanisms to support configuration of the routing protocol itself. o The routing protocol SHOULD support and utilize the large number of highly directed flows to a few head-end servers to handle scalability. o The routing protocol MUST dynamically compute and select effective routes composed of low-power and lossy links. Local network dynamics SHOULD NOT impact the entire network. The routing protocol MUST compute multiple paths when possible. o The routing protocol MUST support multicast and unicast addressing. The routing protocol SHOULD support formation and identification of groups of field devices in the network.
RPL supports the following features: o Scalability: Large-scale networks characterized by highly directed traffic flows between each smart meter and the head-end servers in the utility network. To this end, RPL builds a Directed Acyclic Graph (DAG) rooted at each LBR. o Zero-touch configuration: This is done through in-band methods for configuring RPL variables using DIO (DODAG Information Object) messages and DIO message options [RFC6550]. o The use of links with time-varying quality characteristics: This is accomplished by allowing the use of metrics that effectively capture the quality of a path (e.g., Expected Transmission Count (ETX)) and by limiting the impact of changing local conditions by discovering and maintaining multiple DAG parents (and by using local repair mechanisms when DAG links break). RFC6551]. Additional metrics may be defined in companion RFCs.
RFC6552] and Minimum Rank with Hysteresis Objective Function (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. Section 184.108.40.206 of [RFC6550]. While RPL provides an option to form a local DODAG, doing so in AMI for electric meters is of little benefit since AMI applications typically communicate through an LBR. After the detached node has made sufficient effort to send a notification to its children that it is detached, the node can rejoin the same DODAG with a higher rank value. The configured duration of the poisoning mechanism needs to take into account the disconnection time that applications running over the network can tolerate. Note that when joining a different DODAG, the node need not perform poisoning. The second local repair mechanism controls how much a node can increase 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. RFC7731]).
IEEE.802.15.4]. A few exceptions are described below. o The IEEE 1901.2 MAC frame is obtained by prepending a Segment Control Field to the IEEE 802.15.4 MAC header. One function of the Segment Control Field is to signal the use of the MAC sub-layer segmentation and reassembly.
o IEEE 1901.2 MAC frames use only the 802.15.4 MAC addresses with a length of 16 and 64 bits. o The IEEE 1901.2 MAC sub-layer endorses the concept of Information Elements, as defined in [IEEE.802.15.4e]. The format and use of Information Elements are not relevant to the RPL applicability statement. The IEEE 1901.2 PHY frame payload size varies as a function of the modulation used to transmit the frame and the strength of the Forward Error Correction scheme. The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY settings in use (e.g., bandwidth, modulation, tones, etc). As quoted from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is more than 247 octets for robust OFDM (ROBO) and Super-ROBO modulations or more than 239 octets for all other modulations, the MAC layer shall divide the MSDU into multiple segments as described in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the following conditions: a) For ROBO and Super-ROBO modulations, the MSDU size is more than 247 octets but less than 494 octets, b) For all other modulations, the MSDU size is more than 239 octets but less than 478 octets.
o Low-Latency Deterministic Networks (LLDN): for application domains such as factory automation. o Deterministic and Synchronous Multi-channel Extension (DSME): for general industrial and commercial application domains that includes channel diversity to increase network robustness. o Asynchronous Multi-channel Adaptation (AMCA): for large infrastructure application domains. The MAC addressing scheme supports short (16-bit) addresses along with extended (64-bit) addresses. These addresses are assigned in different ways and are specified by specific standards organizations. Information Elements, Enhanced Beacons, and frame version 2, as defined in IEEE 802.15.4e, MUST be supported. Since the MAC frame payload size limitation is given by the 4g PHY frame payload size limitation (i.e., 2048 bytes) and MAC layer overhead (headers, trailers, Information Elements, and security overhead), the MAC frame payload MUST able to carry a full IPv6 packet of 1280 octets without upper-layer fragmentation and reassembly.
ultimately offers different MAC frame formats. The 802.15.4 specification defines eight different security suites, outlined below. 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 Message Authentication Code 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 o AES-CCM-64 = Encryption and 64-bit MAC o AES-CCM-32 = Encryption and 32-bit MAC Note that AES-CCM-32 is the most commonly used cipher in these deployments today. To achieve authentication, any device can maintain an Access Control List (ACL), which is a list of trusted nodes from which the device wishes to receive data. Data encryption is done by encryption of Message Authentication Control frame payload using the key shared between two devices or among a group of peers. If the key is to be shared between two peers, it is stored with each entry in the ACL list; otherwise, the key is stored as the default key. Thus, the device can make sure that its data cannot be read by devices that do not possess the corresponding key. However, device addresses are always transmitted unencrypted, which makes attacks that rely on device identity somewhat easier to launch. Integrity service is applied by appending a Message Integrity Code (MIC) generated from blocks of encrypted message text. This ensures that a frame cannot be modified by a receiver device that does not share a key with the sender. Finally, sequential freshness uses a frame counter and key sequence counter to ensure the freshness of the incoming frame and guard against replay attacks. A cryptographic Message Authentication Code (or keyed MIC) is used to authenticate messages. While longer MICs lead to improved resiliency
of the code, they also make the packet size larger and thus take up bandwidth in the network. In constrained environments such as metering infrastructures, an optimum balance between security requirements and network throughput must be found. Section 3 of [RFC6282] and all of the IPv6 Next Header compression schemes specified in Section 4 of [RFC6282], if reducing over the air/wire overhead is a requirement. RFC6206] was designed to be density aware and perform well in networks characterized by a wide range of node densities. The combination of DIO packet suppression and adaptive timers for sending updates allows Trickle to perform well in both sparse and dense environments. Node densities in AMI deployments can vary greatly, from nodes having only one or a handful of neighbors to nodes having several hundred neighbors. In high-density environments, relatively low values for Imin may cause a short period of congestion when an inconsistency is detected and DIO updates are sent by a large number of neighboring nodes nearly simultaneously. While the Trickle timer will exponentially backoff, some time may elapse before the congestion subsides. While some link layers employ contention mechanisms that attempt to avoid congestion, relying solely on the link layer to avoid congestion caused by a large number of DIO updates can result in increased communication latency for other control and data traffic in the network. To mitigate this kind of short-term congestion, this document recommends a more conservative set of values for the Trickle parameters than those specified in [RFC6206]. In particular, DIOIntervalMin is set to a larger value to avoid periods of congestion in dense environments, and DIORedundancyConstant is parameterized accordingly as described below. These values are appropriate for the timely distribution of DIO updates in both sparse and dense scenarios while avoiding the short-term congestion that might arise in dense scenarios. Because the actual link capacity depends on the particular link technology used within an AMI deployment, the Trickle parameters are specified in terms of the link's maximum capacity for transmitting link-local multicast messages. If the link can transmit m link-local multicast packets per second on average, the expected time it takes to transmit a link-local multicast packet is 1/m seconds.
DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that the Trickle Imin is at least 50 times as long as it takes to transmit a link-local multicast packet. This value is larger than that recommended in [RFC6206] to avoid congestion in dense urban deployments as described above. DIOIntervalDoublings: AMI deployments SHOULD set DIOIntervalDoublings such that the Trickle Imax is at least 2 hours or more. DIORedundancyConstant: AMI deployments SHOULD set DIORedundancyConstant to a value of at least 10. This is due to the larger chosen value for DIOIntervalMin and the proportional relationship between Imin and k suggested in [RFC6206]. This increase is intended to compensate for the increased communication latency of DIO updates caused by the increase in the DIOIntervalMin value, though the proportional relationship between Imin and k suggested in [RFC6206] is not preserved. Instead, DIORedundancyConstant is set to a lower value in order to reduce the number of packet transmissions in dense environments.
of network updates can be dynamically varied by the root during the lifetime of the network. To that end, all DIO messages SHOULD contain a Metric Container option for disseminating the metrics and metric values used for DODAG setup. In addition, DIO messages SHOULD contain a DODAG Configuration option for disseminating the Trickle Timer parameters throughout the network. The possibility of dynamically updating the metrics in use in the network as well as the frequency of network updates allows deployment characteristics (e.g., network density) to be discovered during network bring-up and to be used to tailor network parameters once the network is operational rather than having to rely on precise pre-configuration. This also allows the network parameters and the overall routing protocol behavior to evolve during the lifetime of the network. RPL specifies a number of variables and events that can be tracked for purposes of network fault and performance monitoring of RPL routers. Depending on the memory and processing capabilities of each smart grid device, various subsets of these can be employed in the field. RFC6550] also apply to this document and to AMI deployments.
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 and active man-in-the-middle attacks rely on a mutual authentication and authorization process. To enable strong mutual authentication, all nodes, from smart meters to nodes in the infrastructure, must have a credential. The credential may be bootstrapped at the time the node is manufactured but must be appropriately managed and classified through the authorization process. The management and authorization process ensures that the nodes are properly authenticated and 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., the link layer, the application layer, or both) should be used. To provide the security mechanisms to address these threats, an AMI deployment MUST include the use of the security schemes as defined by IEEE 1901.2 (and IEEE 802.15.4) with IEEE 802.15.4 defining the security mechanisms to afford mutual authentication, access control (e.g., authorization), and transport confidentiality and integrity.
DOEVCC] defining a process and set of recommendations to address privacy issues. As this document describes the applicability of RPL, the privacy considerations as defined in [PRIVACY] and [EUPR] apply to this document and to AMI deployments. [IEEE.1901.2] IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications", IEEE 1901.2-2013, DOI 10.1109/ieeestd.2013.6679210, December 2013, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6679208>. [IEEE.802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE 802.15.4-2011, DOI 10.1109/ieeestd.2011.6012487, September 2011, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>. [IEEE.802.15.4e] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE 802.15.4e-2012, DOI 10.1109/ieeestd.2012.6185525, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6185523>. [IEEE.802.15.4g] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 3: Physical Layer (PHY) Specifications for Low-Data-Rate, Wireless, Smart Metering Utility Networks", IEEE 802.15.4g-2012, DOI 10.1109/ieeestd.2012.6190698, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6190696>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>. [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", IEEE Transactions on Industrial Informatics Volume 9, Issue 1, pp. 28-42, DOI 10.1109/TII.2012.2218253, February 2013. [DOEVCC] "Voluntary Code of Conduct (VCC) Final Concepts and Principles", January 2015, <http://energy.gov/sites/prod/files/2015/01/f19/VCC%20Conc epts%20and%20Principles%202015_01_08%20FINAL.pdf>. [EUPR] "Information for investors and data controllers", June 2016, <https://ec.europa.eu/energy/node/1748>. [IEEE.802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, March 2012, <https://standards.ieee.org/getieee802/ download/802.11-2012.pdf>. [PRIVACY] Thaler, D., "Privacy Considerations for IPv6 Adaptation Layer Mechanisms", Work in Progress, draft-ietf-6lo- privacy-considerations-04, October 2016. [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 2009, <http://www.rfc-editor.org/info/rfc5548>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>. [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <http://www.rfc-editor.org/info/rfc6551>. [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, <http://www.rfc-editor.org/info/rfc6552>. [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with Hysteresis Objective Function", RFC 6719, DOI 10.17487/RFC6719, September 2012, <http://www.rfc-editor.org/info/rfc6719>. [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <http://www.rfc-editor.org/info/rfc7102>. [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, <http://www.rfc-editor.org/info/rfc7416>. [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, February 2016, <http://www.rfc-editor.org/info/rfc7731>.