RFC 8036
Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks
RFC 8036 🎀
Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks ✨
Okay bestie, here's the lineup 💅 The authors are N. Cam-Winget (Ed.) from Cisco Systems, J. Hui from Nest, and D. Popa from Itron, Inc. It's an Internet Standards Track document (ISSN 2070-1721), published in January 2017. The title block doesn't list anything it obsoletes or updates 🙈
Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . 24Abstract 🌸
This document talks about how well the Routing Protocol for Low-Power and Lossy Networks (RPL) fits into 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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 🫶
Info about the current status of this document, any errata, and how to send feedback is 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License. 💅
1. Introduction ✨
Advanced Metering Infrastructure (AMI) systems let utilities measure, configure, and control energy, gas, and water consumption and distribution, using two-way communication that runs on a schedule, on exception, or on demand. ⚡
AMI networks can have millions of endpoints, like meters, distribution automation elements, and eventually Home Area Network (HAN) devices. They're usually connected through some mix of wireless and power line communication. Together they form what's called the Neighbor Area Network (NAN), plus a backhaul network that links up to "command-and-control" management software at the utility company's back office. 🏢
1.1. Requirements Language 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🎀
1.2. Required Reading 📚
[surveySG] gives you an overview of Smart Grid architecture and its applications. 🔌
A NAN can run on wireless tech from the IEEE 802.15.4 standard family. Specifically, that means the Physical Layer (PHY) amendment [IEEE.802.15.4g] and the Media Access Control (MAC) sub-layer amendment [IEEE.802.15.4e], both adapted for smart grid networks. 📡
A NAN can also use Power Line Communication (PLC) instead of wireless. Several PLC standards have shown up, like [IEEE.1901.2]. ⚡
A NAN can even mix wireless and PLC to boost network coverage ratio, which is a critical requirement for AMI networks. 🧚
1.3. Out-of-Scope Requirements 🙅♀️
These things are outside the scope of this document:
- Applicability statement for RPL [RFC6550] in AMI networks made up of battery-powered devices (i.e., gas/water meters).
- Applicability statement for RPL in AMI networks made up of a mix of devices powered by alternating current (i.e., electric meters) and battery-powered meters (i.e., gas/water meters).
- Applicability statement for RPL storing mode of operation in AMI networks.
2. Routing Protocol for LLNs (RPL) 🕸️
RPL does routing for mesh networks that can scale up to thousands of resource-constrained devices. These devices are linked by low-power and lossy links, and they talk to the external network infrastructure through one or more common aggregation points (e.g., an LLN Border Router, or LBR). 🌐
RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at an LBR. It keeps routing loop-free, supports alternate routes, and works with a wide range of routing metrics and policies. 🌳
RPL was designed for energy-constrained environments, and it has energy-saving features (like Trickle timers) and energy-aware metrics. Because it can handle several different metrics and constraints at once, it runs efficiently in heterogeneous networks, where nodes and links can be wildly different from each other [RFC6551]. 💜
This document describes how RPL non-storing mode (as defined in [RFC6550]) applies to AMI deployments. The Routing Requirements for Urban Low-Power and Lossy Networks [RFC5548] apply to AMI networks too. The terminology used here is defined in [RFC7102]. 📖
3. Description of AMI Networks for Electric Meters ⚡
In lots of deployments, the electric meter network is a big deal in the Smart Grid, on top of measuring energy use. It lets the utility company control and query the electric meters themselves, and it can act as a backhaul for every other device in the Smart Grid, like water and gas meters, distribution automation, and HAN devices. Electric meters may also work as sensors that monitor grid quality and support things like electric vehicle charging. 🚗🔋
Electric meter networks can be made of millions of smart meters (or nodes). Each one is resource constrained when it comes to processing power, storage, and communication bandwidth. That comes from a mix of factors: spectrum use regulations, rules about meter behavior and performance, heat emissions inside the meter, form factor, and cost. All of that leads to a trade-off between range and throughput, with effective link throughput of tens to a few hundred kilobits per second per link. A chunk of that can get eaten up by protocol and encryption overhead when strong security measures are in place. 🥲
Electric meters often form multi-hop mesh networks. Each mesh connects to a backhaul network that leads to the utility company network through a network aggregation point, e.g., an LBR. 🕸️💖
3.1. Deployment Scenarios 🧚
okay so AMI networks are literally huge, bestie. We're talking millions of endpoints spread across both urban and rural areas 🌸 Those endpoints can be electric, gas, and water meters, distribution automation elements, and HAN devices.
Devices talk directly to other devices nearby using a bunch of low-power and/or lossy link technologies, both wireless and wired. Think IEEE 802.15.4g, IEEE 802.15.4e, IEEE 1901.2, and [IEEE.802.11] ✨ Lowkey the best part is that many of these network elements don't just send and receive their own packets. They also forward packets for everyone else, so they form a mesh topology 🕸️💜
In a typical AMI deployment, groups of meters that are physically close together form routing domains, each one on the order of 1,000 to 10,000 meters. So each electric meter mesh usually has several thousand wireless endpoints, and the density changes depending on the area and the terrain 🏔️
<pre> </pre>
Here's the typical NAN topology, periodt 👑
|
+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 TopologySo a typical AMI network (see Figure 1) has a Meter Data Management System (MDMS) connected over an IP network to an LBR 🔌 The LBR can sit in the power substation or somewhere else out in the field. The substation connects the households and buildings. The physical layout of the electrical grid is a tree structure, either because the three power phases come through the substation or just because of how the electrical network is wired. Meters (the little M's in the figure) can also be part of a HAN 🏠 This document is only about the communication between the LBR and the meters, which is the NAN segment. That's the whole focus, bestie.
Node density can vary a LOT. Apartment buildings in urban centers might have hundreds of meters packed close together, while rural areas can be sparse and have nodes with only a few network neighbors 🌾 Each routing domain connects to the bigger IP infrastructure through one or more LBRs. Those LBRs give you Wide Area Network (WAN) connectivity over different traditional network technologies, like Ethernet, cellular, private WAN based on Worldwide Interoperability for Microwave Access (WiMAX), and optical fiber 📡 The paths in the mesh between a node and its nearest LBR can be several hops, or even several tens of hops, long. That's a lot of hopping, honestly 🦋 Electric meters are powered from the main line, so they have fewer energy constraints than battery powered devices like gas and water meters. That means they can afford the extra resources needed to route packets ⚡
Here's the tea: the logical network topology won't always match the electric grid topology, and it depends on the technology used to exchange information 🫖 If meters talk over radio technologies from the IEEE 802.15.4 family, the topology is a meshed network. Nodes that belong to the same Destination-Oriented DAG (DODAG) can be connected to the grid through different substations. If narrowband PLC is used, it will more or less follow the physical tree structure, since crosstalk may let one phase talk to another. That's especially true near the LBR. You might also see a mixed topology, because some LBRs may be placed strategically in the field so that not all the communication has to go through a single LBR 🧩 Still, the short propagation range means meters have to relay the information for each other, iykyk 💅
4. Smart Grid Traffic Description ⚡
4.1. Smart Grid Traffic Characteristics 🎀
In current AMI deployments, metering applications usually require all smart meters to talk to a few head-end servers sitting in the utility company's data center 🏢 The head-end servers generate data traffic to configure smart data reading or to start queries. They use unicast and multicast to talk efficiently to a single device (that's Point-to-Point (P2P) communication) or to groups of devices (that's Point-to-Multipoint (P2MP) communication), respectively 💌 The head-end server might send one small packet at a time to the meters, like a meter read request, a small configuration change, or a service-switch command. Or it might send a series of large packets, like a firmware download across one device or even thousands of them 📦 Large file transfers, such as a firmware download to all metering devices, happen way less often than configuration messages or queries 🙈
Each smart meter generates Smart Metering Data (SMD) traffic on a schedule, like periodic meter reads. It can also respond to on-demand queries, like on-demand meter reads, or to a local event, like a power outage or leak detection 🚨 That traffic usually goes to one single head-end server. So the SMD traffic is super asymmetric 🫠 Most of the traffic volume from the smart meters goes through the LBRs and flows from the meters up to the head-end servers in a Mesh Peer-to-Peer (MP2P) fashion. The current SMD traffic patterns are pretty uniform and well understood, which is a mood 😌 Traffic from the head-end server to the metering devices is mostly periodic meter reads, while traffic from the metering devices is usually spread evenly over some periodic read time-window.
Smart metering apps usually don't have hard real-time constraints. They do often come with bounded latency and strict service level agreements about reliability 🤝
Distribution Automation (DA) apps usually involve a small number of devices that talk to each other in a P2P fashion. Those devices may or may not be physically close together 🧑🤝🧑 DA apps typically have stricter latency requirements than SMD apps, so they're a bit more demanding, ngl ⏱️
There are also a bunch of emerging apps, like electric vehicle charging 🚗💨 These may need P2P communication, and they may eventually have even stricter latency requirements than SMD apps.
4.2. Smart Grid Traffic QoS Requirements 📊
As we covered before, there are two main traffic families in a NAN:
- A) Meter-initiated traffic (Meter-to-Head-End - M2HE)
- B) Head-end-initiated traffic (Head-End-to-Meter - HE2M)
- B1) request is sent in P2P to a specific meter
- B2) request is sent in multicast to a subset of meters
- B3) request is sent in multicast to all meters
The M2HE traffic is event based, while the HE2M traffic is mostly command response 🎯 In most cases M2HE traffic is more critical than HE2M traffic, but there can be exceptions, bestie 🙃
Traffic can also be sorted into priority classes 🌈
- C1) High-Priority Critical traffic for Power System Outage, Pricing Events, and Emergency Messages requires 98%+ packet delivery under 5 s (payload size < 100 bytes) 🚨
- C2) Critical Priority traffic for Power Quality Events and Meter Service Connection and Disconnection requires 98%+ packet delivery under 10s (payload size < 150 bytes) ⚡
- C3) Normal Priority traffic for System Events including Faults, Configuration, and Security requires 98%+ packet delivery under 30 s (payload size < 200 bytes) 🛠️
- C4) Low Priority traffic for Recurrent Meter Reading requires 98%+ packet 2-hour delivery window 6 times per day (payload size < 400 bytes) 📖
- C5) Background Priority traffic for firmware/software updates processed to 98%+ of devices within 7 days (average firmware update is 1 MB) 💾
4.3. RPL Applicability per Smart Grid Traffic Characteristics 🧠
The RPL non-storing mode of operation naturally supports upstream and downstream forwarding of unicast traffic. Downstream is from the DODAG root to each DODAG node, and upstream is from DODAG nodes back to the DODAG root, respectively 🌳
The group communication model used in the smart grid needs the 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. Main character energy, for real 👑
5. Layer-2 Applicability 🦋
5.1. IEEE Wireless Technology 📶
IEEE amendments 802.15.4g and 802.15.4e to the standard IEEE 802.15.4 were specifically developed for smart grid networks 💖 They're the most common PHY and MAC layers used for wireless AMI networks. IEEE 802.15.4g specifies multiple modes of operation (FSK, OQPSK, and OFDM modulations) with speeds from 50 kbps to 600 kbps. It also lets you transport a full IPv6 packet (that's 1280 octets) without needing upper-layer segmentation and reassembly, which is so convenient 🎁
IEEE Std 802.15.4e is an amendment to IEEE Std 802.15.4 that specifies additional Media Access Control (MAC) behaviors and frame formats. These let IEEE 802.15.4 devices support a wide range of industrial and commercial applications that weren't well supported before this amendment came out 🏭 Important note: IEEE 802.15.4e does not change the link-layer security scheme defined in the last two updates to IEEE Std 802.15.4 (e.g., the 2006 and 2011 amendments). Security stays the same, so don't go thinking it changed 🔐
5.2. IEEE Power Line Communication (PLC) Technology ⚡🔌
IEEE Std 1901.2 specifies communications for low frequency (less than 500 kHz) narrowband power line devices over alternating current and direct current electric power lines 💫 It supports indoor and outdoor communications over a low voltage line (the line between the transformer and the meter, which is less than 1000 V). It also works through a transformer from low-voltage to medium-voltage (1000 V up to 72 kV), and through a transformer from medium-voltage to low-voltage power lines. That covers urban settings and long distance (multi-kilometer) rural communications, so it's really versatile 🌍
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 the 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 the type of encoding used 📈
The IEEE Std 1901.2 MAC layer lets you transport a full IPv6 packet (that's 1280 octets) without needing 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. Security is serious business, bestie 🔒✨
6. Using RPL to Meet Functional Requirements ✨
okay so the functional requirements for most AMI deployments are giving the same energy as the ones in [RFC5548] 💅 here's the informal tea on where they overlap:
- The routing protocol MUST be capable of supporting the organization of a large number of nodes into regions containing on the order of
10^2to10^4nodes each. 🌸 - The routing protocol MUST provide mechanisms to support configuration of the routing protocol itself. 🎀
- The routing protocol SHOULD support and utilize the large number of highly directed flows to a few head-end servers to handle scalability. 🦋
- 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. 🧚
- 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 brings these features to the party too:
- 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. 🌈
- 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]. ✨ - 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). 🔥
7. RPL Profile 👑
7.1. RPL Features 🎀
7.1.1. RPL Instances
RPL operation is defined for a single RPL instance. However, multiple RPL instances can be supported in multi-service networks where different applications may require the use of different routing metrics and constraints, e.g., a network carrying both SMD and DA traffic. 🧚
7.1.2. DAO Policy
Two-way communication is a requirement in AMI systems. As a result, nodes SHOULD send Destination Advertisement Object (DAO) messages to establish downward paths from the root to themselves. 🦋
7.1.3. Path Metrics
Smart metering deployments utilize link technologies that may exhibit significant packet loss and thus require routing metrics that take packet loss into account. To characterize a path over such link technologies, AMI deployments can use the ETX metric as defined in [RFC6551]. 📊
Additional metrics may be defined in companion RFCs.
7.1.4. 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, Objective Function 0 (OF0) [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.
7.1.5. 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 reattaching 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 parent. This process is known as "poisoning" and is described in Section 8.2.2.5 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. 🌀
7.1.6. Multicast
Multicast support for RPL in non-storing mode are being developed in companion RFCs (see [RFC7731]). 📡
7.1.7. 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; they MUST include, at a minimum, link-layer security such as that defined by IEEE 1901.2 and IEEE 802.15.4. 🔒
7.2. Description of Layer-2 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 subcarrier can vary significantly, IEEE 1901.2 specifies two complementary mechanisms that allow fine-tuning of 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, and so on). The second (fine-grained) mechanism maps the subcarriers that 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 subcarriers. 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 neighbors by either piggybacking the tone mapping on the data traffic or by sending explicit tone map requests. 🎧
The IEEE 1901.2 MAC frame format shares most in common with the IEEE 802.15.4 MAC frame format [IEEE.802.15.4]. A few exceptions are described below.
- The IEEE 1901.2 MAC frame is obtained by prepending a
Segment Control Fieldto the IEEE 802.15.4 MAC header. One function of theSegment Control Fieldis to signal the use of the MAC sub-layer segmentation and reassembly. 🧩 - IEEE 1901.2 MAC frames use only the 802.15.4 MAC addresses with a length of 16 and 64 bits. 🔢
- 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.7.2.2. IEEE 802.15.4 (Amendments G and E) PHY and MAC Features
IEEE Std 802.15.4g defines multiple modes of operation, where each mode uses different modulation and has multiple data rates. Additionally, the 802.15.4g PHY layer includes mechanisms to improve the robustness of the radio communications, such as data whitening and Forward Error Correction coding. The 802.15.4g PHY frame payload can carry up to 2048 octets. ⚡
IEEE Std 802.15.4g defines the following modulations: Multi-Rate and Multi-Regional FSK (MR-FSK), MR-OFDM, and MR-O-QPSK. The (over-the-air) bit rates for these modulations range from 4.8 to 600 kbps for MR-FSK, from 50 to 600 kbps for MR-OFDM, and from 6.25 to 500 kbps for MR-O-QPSK. 📶
The MAC sub-layer running on top of a 4g radio link is based on IEEE 802.15.4e. The 802.15.4e MAC allows for a variety of modes for operation. These include:
- Timetimeslotslotted Channel Hopping (TSCH): specifically designed for application domains such as process automation 🏭
- Low-Latency Deterministic Networks (LLDN): for application domains such as factory automation. 🤖
- Deterministic and Synchronous Multi-channel Extension (DSME): for general industrial and commercial application domains that includes channel diversity to increase network robustness. 🌐
- 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. 🌈
7.2.3. IEEE MAC Sub-layer Security Features
okay bestie, the IEEE 1901.2 standard is built on the 802.15.4 MAC sub-layer and fully endorses its security scheme 🔐 so we only zoom in on the IEEE 802.15.4 security scheme ✨
the 802.15.4 spec was made to support a bunch of different apps, and lots of them are seriously security sensitive 😭 so it gives four basic security services: message authentication, message integrity, message confidentiality, and freshness checks to avoid replay attacks 🛡️
the 802.15.4 security layer lives at the media access control layer, below the 6LowPAN (IPv6 over Low-Power Wireless Personal Area Network) layer. the app sets its security requirements by putting the right control parameters into the radio/PLC stack 💅 802.15.4 defines four packet types for the media access control layer: beacon frames, data frames, acknowledgment frames, and command frames. the 802.15.4 spec does not support security for acknowledgement frames 💀 but data frames, beacon frames, and command frames can support integrity protection and confidentiality protection for the frames' data field.
an app gets to choose from a bunch of security suites, and each one controls what kind of protection the transmitted MAC frame gets. every suite has its own set of security properties and guarantees, and ultimately its own MAC frame formats. the 802.15.4 spec defines eight different security suites, outlined below 🎀 we can sort them by what they offer: no security, encryption only (AES-CTR), authentication only (AES-CBC-MAC), and encryption and authentication (AES-CCM). every category that supports authentication comes in three variants depending on the size of the Message Authentication Code it offers. the MAC can be 4, 8, or 16 bytes long. also, for each suite that offers encryption, the recipient can optionally enable replay protection.
Null= No securityAES-CTR= Encryption only, CTR modeAES-CBC-MAC-128= No encryption, 128-bit MACAES-CBC-MAC-64= No encryption, 64-bit MACAES-CCM-128= Encryption and 128-bit MACAES-CCM-64= Encryption and 64-bit MACAES-CCM-32= Encryption and 32-bit MAC
note that AES-CCM-32 is the most commonly used cipher in these deployments today 👑
so how does the authentication part work? any device can maintain an Access Control List (ACL), which is a list of trusted nodes the device wants to receive data from 🫶 data encryption is done by encrypting the Message Authentication Control frame payload using the key shared between two devices or among a group of peers. if the key is shared between two peers, it's stored with each entry in the ACL list; otherwise, the key is stored as the default key. this way the device can make sure its data can't be read by devices that don't have the matching key 🔑 however, device addresses are always transmitted unencrypted, which makes attacks that rely on device identity somewhat easier to launch 🙈
integrity is applied by appending a Message Integrity Code (MIC) generated from blocks of encrypted message text. this makes sure a frame can't be modified by a receiver device that doesn't share a key with the sender 🛡️ and finally, sequential freshness uses a frame counter and a key sequence counter to check that the incoming frame is fresh and to guard against replay attacks ⭐
a cryptographic Message Authentication Code (or keyed MIC) is used to authenticate messages. longer MICs lead to improved resiliency of the code, but 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 ✨
7.3. 6LowPAN Options
AMI implementations based on IEEE 1901.2 and 802.15.4 (amendments g and e) can use all of the IPv6 Header Compression schemes specified in 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 🦋
7.4. Recommended Configuration Defaults and Ranges
7.4.1. Trickle Parameters
okay so [RFC6206] Trickle was designed to be density aware and to perform well in networks with a wide range of node densities 🌈 the mix of DIO packet suppression and adaptive timers for sending updates lets Trickle do well in both sparse and dense environments. node densities in AMI deployments can vary a LOT, from nodes with only one or a handful of neighbors to nodes with several hundred neighbors 😭 in high-density environments, relatively low values for Imin can cause a short burst of congestion when an inconsistency is detected and a large number of neighboring nodes send DIO updates at nearly the same time. the Trickle timer will exponentially back off, but some time may pass before the congestion clears. some link layers use contention mechanisms to avoid congestion, but relying only on the link layer to deal with congestion from a large number of DIO updates can increase communication latency for other control and data traffic in the network 🙃
to fix this kind of short-term congestion, this document recommends a more conservative set of values for the Trickle parameters than the ones in [RFC6206] 💖 in particular, DIOIntervalMin is set to a larger value to avoid congestion periods in dense environments, and DIORedundancyConstant is parameterized to match, as described below. these values work for timely distribution of DIO updates in both sparse and dense scenarios, while avoiding the short-term congestion that could show up in dense scenarios 🧚 because the actual link capacity depends on the particular link technology used in 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 to transmit one 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 the one 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 because of the larger chosen value for DIOIntervalMin and the proportional relationship between Imin and k suggested in [RFC6206]. this increase is meant to make up for the extra communication latency of DIO updates caused by the bigger DIOIntervalMin value, though the proportional relationship between Imin and k suggested in [RFC6206] is not kept. instead, DIORedundancyConstant is set to a lower value so there are fewer packet transmissions in dense environments 💅
7.4.2. Other Parameters
- AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 8 bits of resolution (e.g., for the ETX metric) 🎀
- to enable local repair, AMI deployments SHOULD set MaxRankIncrease to a value that lets a device move a small number of hops away from the root. with a MinHopRankIncrease of 256, a MaxRankIncrease of 1024 would let a device move up to 4 hops away 🦋
8. Manageability Considerations ✨
okay this part is giving infrastructure realness 🏗️ network manageability is a critical part of smart grid network deployment and operation. with millions of devices in the smart grid network, many of which need real-time reachability, automatic configuration, and lightweight network health monitoring and management, all of that is crucial for keeping the network available and running efficiently 💜 RPL enables automatic and consistent configuration of RPL routers through parameters specified by the DODAG root and disseminated through DIO packets. Trickle is used to schedule DIO transmissions, which keeps propagation of important network and parameter updates lightweight yet timely, and it lets network operators choose the trade-off point they're comfortable with between overhead and the reliability and timeliness of network updates 🧠
the metrics in use in the network, along with the Trickle Timer parameters that control how often and how redundantly network updates are sent, can be changed dynamically by the root during the lifetime of the network 👑 for that, 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 🫶
being able to dynamically update the metrics in use, and the frequency of network updates, means deployment characteristics (e.g., network density) can be discovered during network bring-up and used to tailor network parameters once the network is running, instead of relying on precise pre-configuration 🌈 this also lets the network parameters and the overall routing protocol behavior evolve during the lifetime of the network 🔥 RPL specifies a number of variables and events that can be tracked for 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 used in the field 🧚
9. Security Considerations 🔐
okay bestie, this section is SERIOUS, no cap 😭
smart grid networks are subject to stringent security requirements, since they're considered a critical infrastructure component. at the same time, they're made up of large numbers of resource-constrained devices connected by limited-throughput links 💀 so the choice of security mechanisms depends heavily on the device and network capabilities of a particular deployment.
unlike other types of LLNs, smart grid networks have both centralized administrative control and access to a permanent secure infrastructure 👑 as a result, smart grid networks are deployed with security mechanisms such as link-layer, transport-layer, and/or application-layer security mechanisms. while it's best practice to secure all layers, using RPL's secure mode may not be necessary 🦋 failing to protect any of these layers can result in various attacks: a lack of strong authentication of devices in the infrastructure can lead to uncontrolled and unauthorized access 🚨 similarly, failing to protect the communication layers can enable passive attacks (in wireless mediums) as well as man-in-the-middle and active attacks 😭
as this document describes the applicability of RPL non-storing mode, the security considerations defined in [RFC6550] also apply to this document and to AMI deployments 🫶
9.1. Security Considerations during Initial Deployment 🔐
okay so, during manufacturing, the meters get loaded up with their security credentials (keys and certificates) 🔑. The credentials configured at the factory are what the devices use to authenticate with the system. From there they negotiate their operational security credentials for both the network and application layers. It's giving secure onboarding arc ✨
9.2. Security Considerations during Incremental Deployment
if a device fails or is known to be compromised while the system is running, it gets replaced with a brand new device 🔄. The new device does not take over the security identity of the one it replaced. The security credentials tied to the failed or compromised device get removed from the security appliances. Bye bye, old identity 🫡
9.3. Security Considerations Based on RPL's Threat Analysis
[RFC7416] defines a set of security considerations for RPL security, and this document explains 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 relies on a mutual authentication and authorization process 🤝. To enable strong mutual authentication, all nodes, from smart meters to nodes in the infrastructure, need a credential. The credential may be bootstrapped at the time the node is manufactured, but it has to be properly managed and classified through the authorization process. The management and authorization process is what makes sure the nodes are properly authenticated and actually behaving or 'acting' in their assigned roles 👀.
Similarly, to make sure data hasn't been modified, confidentiality and integrity should be used at the suitable layers (e.g., the link layer, the application layer, or both) 🔐✨.
Now the big one. To provide the security mechanisms that address these threats, an AMI deployment MUST include the use of the security schemes defined by IEEE 1901.2 (and IEEE 802.15.4), with IEEE 802.15.4 defining the security mechanisms that afford mutual authentication, access control (e.g., authorization), and transport confidentiality and integrity. No skipping this one, periodt 💀
10. Privacy Considerations 🕵️♀️
Privacy of information flowing through smart grid networks is worth thinking about 🌸. A growing set of recommendations and requirements is being defined by different groups and consortiums. For example, the U.S. Department of Energy issued a document [DOEVCC] that defines a process and a set of recommendations to address privacy issues. Since this document describes the applicability of RPL, the privacy considerations defined in [PRIVACY] and [EUPR] apply to this document and to AMI deployments 💜.
11. References 📚
11.1. Normative References
[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.11.2. Informative references
[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>.Acknowledgements 🫶
Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden were contributors and noted as authors in earlier versions of this document 💖. The authors would also like to acknowledge the review, feedback, and comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP Vasseur 🙌.
Authors' Addresses 💌
Nancy Cam-Winget (editor)
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
United States of America
Email: ncamwing@cisco.com
Jonathan Hui
Nest
3400 Hillview Ave
Palo Alto, CA 94304
United States of America
Email: jonhui@nestlabs.com
Daniel Popa
Itron, Inc
52, rue Camille Desmoulins
Issy les Moulineaux 92130
France
Email: daniel.popa@itron.com📦 where this page comes from
- ietf: rfc8036 2017-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms