RFC 7733

Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control

📅 published February 2016, from ietf

RFC 7733: Applicability Statement for Using RPL in Home Automation and Building Control 🏠✨

Okay bestie, this one is a practical guide to using the RPL routing protocol suite in smart homes and buildings 🏡💖. It's a Standards Track document with ISSN 2070-1721, dated February 2016 🎀. The authors are A. Brandt from Sigma Designs, E. Baccelli from INRIA, R. Cragie from ARM Ltd., and P. van der Stok, who was a Consultant. Its title block doesn't list anything it obsoletes or updates, so it stands on its own 🌸. It's published by the Internet Engineering Task Force (IETF) as Request for Comments 7733 🦋.

Abstract

Okay, so the whole point is to help you pick and use the right protocols from the RPL suite so you can build the features needed to control buildings and homes 🧚✨.

Status of This Memo

This is an Internet Standards Track document 💅.

It's a product of the IETF and reflects the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. You can read more about Internet Standards in Section 2 of RFC 5741 📚.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7733 🔥.

Copyright (c) 2016 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 🌈.

Table of Contents

   1. Introduction ....................................................4
      1.1. Relationship to Other Documents ............................5
      1.2. Terminology ................................................6
      1.3. Required Reading ...........................................6
      1.4. Requirements That Are Out of Scope .........................6
   2. Deployment Scenario .............................................6
      2.1. Network Topologies .........................................7
      2.2. Traffic Characteristics ....................................8
           2.2.1. General .............................................9
           2.2.2. Source-Sink (SS) Communication Paradigm ............10
           2.2.3. Publish-Subscribe (PS, or Pub/Sub)
                  Communication Paradigm .............................10
           2.2.4. Peer-to-Peer (P2P) Communication Paradigm ..........10
           2.2.5. Peer-to-Multipeer (P2MP) Communication Paradigm ....11
           2.2.6. Additional Considerations: Duocast and N-Cast ......11
           2.2.7. RPL Applicability per Communication Paradigm .......11
      2.3. Layer 2 Applicability .....................................13
   3. Using RPL to Meet Functional Requirements ......................13
   4. RPL Profile ....................................................14
      4.1. RPL Features ..............................................14
           4.1.1. RPL Instances ......................................15
           4.1.2. Storing vs. Non-Storing Mode .......................15
           4.1.3. DAO Policy .........................................15
           4.1.4. Path Metrics .......................................15
           4.1.5. Objective Function .................................16
           4.1.6. DODAG Repair .......................................16
           4.1.7. Multicast ..........................................16
           4.1.8. Security ...........................................17
           4.1.9. P2P Communications .................................21
           4.1.10. IPv6 Address Configuration ........................21
      4.2. Layer 2 Features ..........................................21
           4.2.1. Specifics about Layer 2 ............................21
           4.2.2. Services Provided at Layer 2 .......................21
           4.2.3. IPv6 over Low-Power Wireless Personal Area
                  Network (6LoWPAN) Options Assumed ..................21
           4.2.4. Mesh Link Establishment (MLE) and Other Things .....21
      4.3. Recommended Configuration Defaults and Ranges .............21
           4.3.1. Trickle Parameters .................................22
           4.3.2. Other Parameters ...................................22
   5. MPL Profile ....................................................23
      5.1. Recommended Configuration Defaults and Ranges .............23
           5.1.1. Real-Time Optimizations ............................23
           5.1.2. Trickle Parameters .................................23
           5.1.3. Other Parameters ...................................24
   6. Manageability Considerations ...................................25
   7. Security Considerations ........................................25
      7.1. Security Considerations during Initial Deployment .........26
      7.2. Security Considerations during Incremental Deployment .....27
      7.3. Security Considerations for P2P Implementations ...........27
      7.4. MPL Routing ...............................................27
      7.5. RPL Security Features .....................................27
   8. Other Related Protocols ........................................28
   9. References .....................................................28
      9.1. Normative References ......................................28
      9.2. Informative References ....................................32
   Appendix A. RPL Shortcomings in Home and Building Deployments .....35
     A.1. Risk of Undesirable Long P2P Routes ........................35
       A.1.1. Traffic Concentration at the Root ......................35
       A.1.2. Excessive Battery Consumption in Source Nodes ..........35
     A.2. Risk of Delayed Route Repair ...............................35
       A.2.1. Broken Service .........................................36
   Appendix B. Communication Failures ................................36
   Acknowledgements ..................................................38
   Authors' Addresses ................................................38

1. Introduction ✨

The main goal of this doc is to guide how you use the Routing Protocol for Low-Power and Lossy Networks (RPL) suite in two application domains 🥰:

  • Home automation
  • Building automation

This guidance is built on the features that the requirements documents need. Those are "Home Automation Routing Requirements in Low-Power and Lossy Networks" [RFC5826] and "Building Automation Routing Requirements in Low-Power and Lossy Networks" [RFC5867], respectively 📋. Advanced Metering Infrastructure gets a look too, where it makes sense 💡. The two domains are different in how they're run, what performance they need, and what network shapes they usually have 🏗️. To frame everything, the doc uses an abstract set of distinct communication paradigms 🎀.

Home automation and building automation have a lot in common 🫶:

  • In both domains, the network can get cut off from the ISP and still has to keep giving control to the people living or working in the home or building. Routing needs to work even when there's no border router around 🚫.
  • Both domains deal with unreliable links but need instant, very reliable reactions 😭. That affects routing because of timeliness and multipath routing ⏱️.

The two domains mostly differ in commissioning, maintenance, and the user interface, and those usually don't touch routing 💅. So this doc focuses on reliability, timeliness, and local routing 🌸.

Heads up: following the guidance here doesn't automatically guarantee fully interoperable solutions in home automation and building control networks. Extra rigorous, managed programs will be needed to make sure interoperability happens 🙈.

1.1. Relationship to Other Documents

The Routing Over Low power and Lossy networks (ROLL) working group has specified a set of routing protocols for Low-Power and Lossy Networks (LLNs) [RFC6550] 🧚. This applicability text covers a subset of those protocols, plus the conditions where that subset fits, and it gives recommendations and requirements for the matching parameter value ranges 💜.

[RFC6997] was written as an extension to core RPL [RFC6550] and offers a solution for reactive discovery of point-to-point routes in LLNs 🦋. This document gives recommendations and requirements for the matching parameter value ranges too ✨.

[RFC7416] describes a common set of security threats 🔐. The applicability statements in Section 4.1.8.2.2 of this document complement [RFC7416] by describing preferred security settings and solutions within the applicability statement conditions 🛡️. This applicability statement recommends lighter-weight security solutions that suit home and building environments, and it explains why they fit 🍓.

1.2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖.

Also, this document uses terminology from [RFC6997], [RFC7731], [RFC7102], [IEEE802.15.4], and [RFC6550] 🤓.

1.3. Required Reading

The applicable requirements are described in [RFC5826] and [RFC5867] 📚. If you want a survey of the application field, check out [BC-Survey] 🔍.

1.4. Requirements That Are Out of Scope

The network diameter this doc considers is limited to a maximum diameter of 10 hops and a typical diameter of five hops 🌐. That covers the most common cases in home automation and building control networks 🏠.

This document doesn't consider the applicability of RPL-related specifications for urban and industrial applications [RFC5548] [RFC5673], which may have much larger network diameters 🏙️💀.

2. Deployment Scenario ✨

okay so buildings literally need communications networks to hit energy-saving regulations 💅 The environment can be adjusted to match how comfy the people inside are, and when nobody's there, energy use can drop. Cost is the biggest reason wireless networking gets deployed in buildings, especially when they're retrofitting, because going wireless skips the cabling and building modifications that would otherwise cost a fortune 💸 It's giving money-saver era.

A typical home automation network has less than 100 nodes 🏠 Large building deployments can reach 10,000 nodes, but to keep light and air conditioning running without interruption in each zone of the building, nodes are usually organized into subnetworks 🧚 Each building automation subnetwork typically has tens to hundreds of nodes, and for critical operations it may run independently from the other subnetworks. Very main character behavior for a critical system, honestly 👑

The whole point of a home or building automation network is controlling light and heating/cooling 🌸 People use wall controllers to step in, and that gets combined with movement, light, and temperature sensors so things can adjust on their own, like closing window blinds or dropping the room temperature. Generally, the sensors and actuators in a home or building have fixed physical locations and stay in the same automation network 🦋

People expect an immediate and reliable response to their presence or actions 😭 Like, if a light doesn't switch on the second you walk into a room, you'll be confused and honestly pretty dissatisfied with the lighting product. Reliable is not optional.

Monitoring whether everything is working correctly matters just as much as responding quickly 🫶 Devices usually report their status regularly and send alarm messages to tell users or implementers when controlled equipment or a controlled network has malfunctioned. Bestie, we need those alerts to be reliable too.

In building control, the building management network's infrastructure can be shared with security/access, Internet Protocol (IP) telephony, and fire/alarm networks 🔥 This is a real win for the operation and cost of the network! However, care should be taken to make sure the availability of the building management network doesn't get compromised beyond the point where critical functions can still perform adequately. Sharing is caring, but not to the point of breaking the important stuff 💀

In homes, the entertainment network for audio/video streaming and gaming has different needs 🎀 Its biggest requirement is high bandwidth, which home or building control typically doesn't need. So the home's entertainment network will mostly stay separate from the control network, which also means it has less impact on the control network's availability. Separate lanes, no drama 🌈

2.1. Network Topologies

Generally, the home automation network or building control network is made of wired and wireless subnetworks 🕸️ In large buildings especially, the wireless subnetworks can connect to an IP backbone network where all the infrastructure services live, like the Domain Name System (DNS) and automation servers.

The wireless subnetwork can be set up using any of the following topologies:

  • A stand-alone network of 10-100 nodes without a border router. This usually happens in the home with a stand-alone control network, in low-cost buildings, and while high-end control systems are being installed in buildings 🍓
  • A connected network with one border router. This setup happens in homes where appliances get controlled from outside the home, maybe through a smartphone, and in lots of building control scenarios 📱
  • A connected network with multiple border routers. This typically happens in installations of large buildings 🏢

Lots of the nodes are battery powered and may be sleeping nodes that wake up based on clock signals or external events 🔋 💤

In a building control network with a large installation and multiple border routers, subnetworks often overlap, both geographically and in terms of wireless coverage 🌈 Because the network has two purposes, (i) direct control and (ii) monitoring, a given subnetwork may have two kinds of routing topologies: (i) a tree-shaped collection of routes that starts at a central building controller, goes through the border router, and lands on destination nodes in the subnetwork, and (ii) a flat, undirected collection of intra-network routes between functionally related nodes in the subnetwork. Two routing vibes, one network 🦋

Most nodes in home and building automation networks are typically Class 0 devices [RFC7228], like individual wall switches 🧚 Only a few nodes, like multi-purpose remote controls, are more expensive Class 1 devices, since they can afford more memory capacity 💜

2.2. Traffic Characteristics

Traffic can come into the network from a central controller, or it can start at a node inside the network 🌸 Most of it is lightweight point-to-point control, like Put-Ack or Get-Response. There are exceptions, though 👀 Bulk data transfer is used for firmware updates and logging, where firmware updates come into the network and logs go out of it. Group communication is used for service discovery or for controlling groups of nodes, like light fixtures 💡

Often there's a direct physical relationship between a controlling sensor and the equipment it controls 🫶 For example, the temperature sensor and room controller are in the same room, sharing the same climate conditions. That means most senders and receivers are close enough to talk one hop directly ✨ If you graphed the communication, you'd see several fully connected subsets of nodes. But interference, multipath fading, reflection, and other transmission effects can temporarily break that one-hop direct path 😭 For reliability, it's essential that alternative n-hop communication routes exist so errors can be recovered quickly. (See Appendix B for motivation.)

Over a whole day, the networks are very lightly loaded 😴 But bursts of traffic can happen, like someone repeatedly mashing the button on a remote control, a defect occurring, or other unforeseen events 🚨 Even then, timeliness still has to be maintained, so measures are necessary to remove any unnecessary traffic. Short routes are preferred, and long multi-hop routes via the border router should be avoided whenever possible 🛣️

Group communication is essential for lighting control 💡 For example, once a person's presence is detected in a room, lighting control only applies to that room, and no other lights should be dimmed or switched on/off. Lowkey, a multicast message with a one-hop and two-hop radius would usually be enough to control the lights that need it. The same goes for Heating, Ventilating, and Air Conditioning (HVAC) and other climate-control devices 🌡️ To cut down on network load, it's advisable that messages to the lights in a room aren't distributed any further across the mesh than necessary, based on the intended receivers. Only send it where it's needed, bestie 💅

[Office-Light] shows an example of an office space, and [OccuSwitch] describes how wireless lighting control products are used today 🎀

2.2.1. General

Air conditioning and other environmental-control applications can accept response delays of tens of seconds or longer 🥶 Alarm and light control applications, though, may be treated as soft real-time systems. A slight delay is fine, but the perceived quality of service drops significantly if response times go over 250 ms 😤 If the light doesn't turn on right away, a user will probably hit the controls again, which creates a chain of commands like Light{on,off,on,off,...} or Volume{up,up,up,up,up,...}. On top of that, repeatedly sending commands adds unnecessary load to the network, which then makes the network even less responsive. It's a whole cycle, and it's giving chaos 🌀

2.2.2. Source-Sink (SS) Communication Paradigm

This paradigm means lots of sources send messages to the same sink, which is sometimes reachable through the border router 🪣 So Source-Sink (SS) traffic can show up in home and building networks. The traffic might come from environmental sensors (often in a wireless subnetwork) that push periodic readings to a central server. The readings might be used just for logging or, more often, processed to adjust light, heating, and ventilation 📊 Alarm sensors can also generate SS-style traffic 🚨 In a home automation network, the central server will mostly connect to a wired segment of the home network, though cloud services will likely be used too ☁️ In a building automation network, the central server may connect to a backbone or be placed outside the building.

When it comes to message latency, most SS transmissions can tolerate worst-case delays measured in tens of seconds ⏳ Fire detectors are the exception here 🔥 Special provisions about where the fire detectors and smoke dampers are located need to be put in place to meet stringent delay requirements, which are measured in seconds. Serious, serious business, no cap.

2.2.3. Publish-Subscribe (PS, or Pub/Sub) Communication Paradigm

This paradigm is when a bunch of devices show interest in a service provided by a server device 📣 For example, a server device can be a sensor delivering temperature readings based on delivery criteria, like changes in the acquired value or the age of the latest acquisition. In building automation networks, this paradigm may be closely tied to the SS paradigm, since servers connected to the backbone or outside the building can subscribe to data collectors placed at strategic spots in the building automation network 🏗️ How PS gets used will probably vary a lot from installation to installation, so no one-size-fits-all here 🙈

2.2.4. Peer-to-Peer (P2P) Communication Paradigm

This paradigm is when one device transfers data to another device, often one connected to the same subnetwork 🤝 Peer-to-Peer (P2P) traffic is super common in home automation networks 🏠 Most building automation networks rely on P2P traffic too, as described in the next paragraph. Other building automation networks rely on P2P control traffic between controls and a local controller box for advanced group control 🎛️ A local controller box can also connect to service control boxes, which generates more SS or PS traffic.

P2P traffic is usually generated by remote controls and wall controllers that push Control Messages straight to light or heat sources 💡 P2P traffic has a stringent requirement for low latency, because it often carries application messages that humans trigger, and we are NOT waiting around 😤 As mentioned in Section 2.2.1, application messages should be delivered within a few hundred milliseconds, even when connections fail momentarily. Fast or it didn't happen ⚡

2.2.5. Peer-to-Multipeer (P2MP) Communication Paradigm 🦋

Okay bestie, so this paradigm is basically a device sending the same message once for every single destination device 📨✨. P2MP traffic is super common in home and building automation networks. Like, a thermostat in the living room notices a temperature change and sends temperature acquisitions to several fans and valves, one after another 🌡️💨. This paradigm is also closely related to the PS paradigm when one server device has multiple subscribers 🫶.

2.2.6. Additional Considerations: Duocast and N-Cast 🌈

This one is the paradigm where a device sends a message to many destinations in one network transfer invocation 📣. Multicast is giving perfect for lighting 💡, like when a presence sensor sends a presence message to a whole set of lighting devices. It also increases the probability that the message gets delivered within strict time constraints ⏰. The recommended multicast algorithm (e.g., [RFC7731]) gives you a mechanism for delivering messages to all the intended destinations 🎀.

2.2.7. RPL Applicability per Communication Paradigm 👑

Okay so, for the SS paradigm applied to a wireless subnetwork, with a server reachable through a border router, using RPL [RFC6550] in non-storing mode is the move 🙌. The devices are low on resources, so source routing gets used from the border router to the destination in the wireless subnetwork, for messages generated outside the mesh network. SS-type messages have no specific timing constraints, so network repair does not violate the operational constraints (no cap) 💅. When no SS traffic is happening, it is good practice to only load RPL code that enables the P2P mode of operation [RFC6997]. That keeps the code size down and helps satisfy memory requirements 🧠.

To assure responsiveness, P2P-RPL [RFC6997] is required for all P2P and P2MP traffic taking place between nodes within a wireless subnetwork (excluding the border router) 🦋. Source and destination devices are typically physically close, based on room layout, so most P2P and P2MP traffic is one-hop or two-hop traffic 🏠. Appendix A identifies the shortcomings of using RPL for this type of communication, and P2P-RPL is how those shortcomings get counteracted 💪. Appendix B explains why reliability measures such as multipath routing are still necessary even when one-hop communication dominates 🙈.

Here are some more perks of P2P-RPL for home and building automation networks, bestie 🎀:

  • Individual wall switches are typically inexpensive Class 0 devices [RFC7228] with extremely low memory capacities. Multi-purpose remote controls for use in a home environment typically have more memory, but these devices are asleep when there is no user activity. P2P-RPL reactive discovery allows a node to wake up and find new routes within a few seconds, while memory-constrained nodes only have to keep routes to relevant targets 😴.
  • The reactive discovery features of P2P-RPL ensure that commands are normally delivered within the 250 ms time window ⚡. When connectivity needs to be restored, discovery is typically completed within seconds. In most cases, an alternative route (a route that was discovered earlier) will work, and route rediscovery is not necessary 🙌.
  • Broadcast storms typically associated with route discovery for the Ad hoc On-Demand Distance Vector (AODV) [RFC3561] are less disruptive for P2P-RPL. P2P-RPL has a Stop bit, which is set by the target of a route discovery to notify all other nodes that no more Destination-Oriented Directed Acyclic Graph (DODAG) Information Object (DIO) messages should be forwarded for this temporary DAG. Something that looks like a broadcast storm may happen when no target is responding. However, in this case, the Trickle suppression mechanism kicks in, limiting the number of DIO forwards in dense networks 🌊.

Due to the limited memory of the majority of devices, P2P-RPL SHOULD be deployed with source routing in non-storing mode, as explained in Section 4.1.2 🫶.

Multicast with the Multicast Protocol for Low-Power and Lossy Networks (MPL) [RFC7731] is preferably deployed for N-cast over the wireless network. Configuration constraints that are necessary to meet reliability and timeliness with MPL are discussed in Section 4.1.7 ✨.

2.3. Layer 2 Applicability 🧩

This document applies to [IEEE802.15.4] and [G.9959], which are adapted to IPv6 by the adaptation layers [RFC4944] and [RFC7428]. Other Layer 2 technologies, accompanied by an "IP-over-Foo" specification, are also relevant, provided there is no frame size issue and there are link-layer acknowledgements 💜.

The adaptation layers above leverage the compression capabilities of [RFC6554] and [RFC6282]. Header compression allows small IP packets to fit into a single Layer 2 frame, even when source routing is used. A network diameter limited to five hops helps to achieve this, even while using source routing 📦.

Dropped packets are often experienced in these targeted environments 😭. Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and even Transmission Control Protocol (TCP) flows may benefit from link-layer unicast acknowledgements and retransmissions. Link-layer unicast acknowledgements SHOULD be enabled when [IEEE802.15.4] or [G.9959] is used with RPL and P2P-RPL 🔥.

3. Using RPL to Meet Functional Requirements 🧚

Several features required by [RFC5826] and [RFC5867] challenge the P2P paths provided by RPL. Appendix A reviews these challenges. In some cases, a node may need to spontaneously initiate the discovery of a path towards a desired destination that is neither the root of a DAG nor a destination originating Destination Advertisement Object (DAO) signaling. Furthermore, P2P paths provided by RPL are not satisfactory in all cases, because they involve too many intermediate nodes before reaching the destination 😤.

P2P-RPL [RFC6997] SHOULD be used in home automation and building control networks, as traffic of a point-to-point style is substantial and route repair needs to be completed within seconds ⏱️. P2P-RPL provides a reactive mechanism for quick, efficient, and root-independent route discovery/repair 🦋. The use of P2P-RPL furthermore allows data traffic to avoid having to go through a central region around the root of the tree, and it drastically reduces path length [SOFT11] [INTEROP12]. These characteristics are desirable in home and building automation networks, because they substantially decrease unnecessary network congestion around the root of the tree 🌸.

When more reliability is required, P2P-RPL enables the establishment of multiple independent paths. For one-hop destinations, this means that one one-hop communication and a second two-hop communication take place via a neighboring node. Such a pair of redundant communication paths can be achieved by using MPL, where the source is an MPL Forwarder while a second MPL Forwarder is one hop away from both the source and the destination node. When the source multicasts the message, it may be received by both the destination and the second MPL Forwarder. The second MPL Forwarder forwards the message to the destination, thus providing two routes from sender to destination 👯‍♀️.

To provide more reliability with multiple paths, P2P-RPL can maintain two independent P2P source routes per destination, at the source. Good practice is to use the paths alternately to assess their existence. When one P2P path has failed (possibly only temporarily), as described in Appendix B, the alternative P2P path can be used without discarding the failed path. The failed P2P path, unless proven to work again, can be safely discarded after a timeout (typically 15 minutes) ⏳. A new route discovery is done when the number of P2P paths is exhausted due to persistent link failures 🔁.

4. RPL Profile 💖

P2P-RPL SHOULD be used in home automation and building control networks. Its reactive discovery allows for low application response times, even when on-the-fly route repair is needed ⚡. Non-storing mode SHOULD be used to reduce memory consumption in repeaters with constrained memory when source routing is used 🧸.

4.1. RPL Features 🎀

An important constraint on the application of RPL is the presence of sleeping nodes 😴.

For example, in a stand-alone network, the master node (or coordinator) providing the logical Layer 2 identifier and unique node identifiers to connected nodes may be a remote control that returns to sleep once new nodes have been added. Due to the absence of the border router, there may be no global routable prefixes at all. Likewise, there may be no authoritative always-on root node, since there is no border router to host this function 🏝️.

In a network with a border router and many sleeping nodes, there may be battery-powered sensors and wall controllers configured to contact other nodes in response to events and then return to sleep. Such nodes may never detect the announcement of new prefixes via multicast 📡.

In each of the above-mentioned constrained deployments, a link-layer node (e.g., coordinator or master) SHOULD assume the role of an authoritative root node, transmitting unicast Router Advertisement (RA) messages with a Unique Local Address (ULA) prefix information option to nodes during the joining process. This prepares the nodes for a later operational phase, where a border router is added 🌈.

A border router SHOULD be designed to be aware of sleeping nodes, in order to support the distribution of updated global prefixes to such sleeping nodes 💌.

4.1.1. RPL Instances 🦋

When operating P2P-RPL on a stand-alone basis, there is no authoritative root node maintaining a permanent RPL DODAG. A node MUST be able to join at least one RPL Instance, as a new, temporary instance is created during each P2P-RPL route discovery operation. A node MAY be designed to join multiple RPL Instances 🌸.

4.1.2. Storing vs. Non-Storing Mode 🧠

Non-storing mode MUST be used to cope with the extremely constrained memory of a majority of nodes in the network (such as individual light switches) 💡.

4.1.3. DAO Policy 📨

Nodes send DAO messages to establish downward paths from the root to themselves. In order to minimize the power consumption overhead associated with path discovery, DAO messages are not acknowledged in networks composed of battery-operated field devices. The DAO messages build up a source route because the nodes MUST be in non-storing mode 🔋.

If devices in LLNs participate in multiple RPL Instances and DODAGs, both the RPLInstance ID and the DODAGID SHOULD be included in the DAO 🫶.

4.1.4. Path Metrics 📊

Expected Transmission Count (ETX) is the RECOMMENDED metric. [RFC6551] provides other options ✨.

Packets from asymmetric and/or unstable links SHOULD be deleted at Layer 2 🗑️.

4.1.5. Objective Function 🎯

Objective Function Zero (OF0) [RFC6552] MUST be the Objective Function. Other Objective Functions MAY be used when dictated by circumstances 👑.

4.1.6. DODAG Repair 🛠️

Since P2P-RPL only creates DODAGs on a temporary basis during route repair or route discovery, there is no need to repair DODAGs 🙌.

For SS traffic, local repair is sufficient. The accompanying process is known as "poisoning" and is described in Section 8.2.2.5 of [RFC6550]. Given that the majority of nodes in the building do not physically move around, creating new DODAGs should not happen frequently 🏢💕.

4.1.7. Multicast 📢

Okay bestie, commercial lighting setups sometimes need multicast so one command can hit a whole group of lights at once ⏰. There are a few ways to pull that off, and [RFC7731] is the RECOMMENDED protocol for home and building setups 🏠. This section leans super hard on the findings in [RT-MPL] 🤓.

So here's how it goes. When a packet shows up, the MPL Forwarder kicks off a run of back-to-back Trickle timer intervals, and the first one starts at a minimum size of Imin. Every interval after that is double the one before it, with a maximum value of Imax 📈. There's a cap on how many intervals you get, given by max_expiration. For each interval of length I, a time t is randomly picked in the range [I/2, I]. For a given packet p, MPL counts how many copies it receives during [0, t] and keeps that tally in a counter c. At time t, MPL rebroadcasts p when c < k, where k is a predefined constant with k > 0 💅

Now the vibe check on timeliness ✨. Density of forwarders and how often messages get generated both matter a lot for control operations. A high message rate is totally expected when someone is mashing a remote-control button or when alarms go off 🚨

Timeliness is basically tied to how dense the MPL routers are 🌐. In the ideal case, the message travels through the network as one single wave, so the max delay is about the number of hops times the smallest repetition interval of MPL. Every forwarder that gets the message passes it along to the next hop by repeating it. If a copy shows up at a forwarder that already has the message, that copy doesn't need to be repeated 🙈. A small value of k can inhibit repetition. To keep things timely, k should be high enough that messages get repeated on the very first arrival at the forwarder. BUT a network that's too dense will saturate the medium, and the only fix for that is a low k 😭. So the move is a relatively high k plus a low enough forwarder density to avoid medium saturation. Depending on how reliable the links are, it's advisable to set up the density so that at least two forwarders per hop repeat messages to the same set of destinations 🫶

There are no rules for selecting forwarders for MPL 🤷‍♀️. In buildings with central management tools, the forwarders can be selected, but at the time of this writing it's not possible to automatically configure the forwarder topology in the home 🏡

4.1.8. Security 🔐

Real talk, RPL MAY use unsecured RPL messages to keep message size small 📦. If even one node is using unsecured RPL messages, then link-layer security MUST be used on all nodes. So all RPL messages MUST be secured using:

  • RPL message security, or
  • Link-layer security, or
  • Both RPL message security and link-layer security

A symmetric key is used to secure an RPL message, whether through RPL message security or link-layer security 🔑. The symmetric key MUST be distributed or established in a secure fashion. Any node can have more than one symmetric key in use at any one time. The same symmetric key MUST NOT be used for both RPL message security and link-layer security between two peer nodes 🚫

4.1.8.1. Symmetric Key Distribution 🗝️

The scope of symmetric key distribution MUST be no greater than the network itself, i.e., a group key. This document describes what needs to be implemented to meet this requirement 🎯. The scope of symmetric key distribution MAY be smaller than the network, for example:

  • A pairwise symmetric key between two peers.
  • A group key shared between a subset of nodes in the network.

4.1.8.2. Symmetric Key Distribution Mechanism 🛡️

The authentication mechanism described in Section 6.9 of [ZigBeeIP] SHALL be used to securely distribute a network-wide symmetric key 💖

The whole point of the authentication procedure is mutual authentication, and that gives you two things 👑:

  • It stops untrusted nodes without appropriate credentials from joining the trusted network.
  • It stops trusted nodes with appropriate credentials from joining an untrusted network.

There's an Authentication Server in charge of authenticating the nodes on the network 🧑‍💻. If authentication works out, the Authentication Server sends the network security material to the joining node through the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] [RFC6345]. Then the joining node becomes a full participating node in the network and can apply Layer 2 security to RPL messages using the distributed network key 🎉

Here's the tricky bit 🙃. The joining node doesn't have the network security material yet, so it can't apply Layer 2 security to the packets it exchanges during authentication. The enforcement point rules at the edge of the network make sure the PANA authentication packets still get processed, even though they're unsecured at the Medium Access Control (MAC) layer. Those same rules make sure any other incoming traffic that isn't secured at the MAC layer gets discarded and never forwarded 🚧

4.1.8.2.1. Authentication Stack 🥞

Think of authentication as a protocol stack, where each layer encapsulates the layers above it 🧁

  • Transport Layer Security (TLS) [RFC5246] MUST be used at the highest layer of the authentication stack, and it carries the authentication exchange. There is one cipher suite based on a Pre-Shared Key (PSK) [RFC6655] and one cipher suite based on Elliptic Curve Cryptography (ECC) [RFC7251].
  • Extensible Authentication Protocol-TLS (EAP-TLS) [RFC5216] MUST be used at the next layer to carry the TLS records for the authentication protocol.
  • EAP [RFC3748] MUST be used to provide the mechanisms for mutual authentication. EAP needs a way to transport EAP packets between the joining node and the node where the Authentication Server lives. Those nodes aren't necessarily in radio range of each other, so the EAP transport method needs multi-hop support. PANA [RFC5191] [RFC6345], which operates over UDP, MUST be used for this purpose. [RFC3748] specifies how to derive a session key using the EAP key hierarchy, but only the EAP Master Session Key shall be derived, since [RFC5191] says it's used to set up keys for PANA authentication and encryption 🔐
  • PANA [RFC5191] and a PANA relay [RFC6345] MUST be used at the next layer:
    • The joining node MUST act as the PANA Client (PaC).
    • The parent edge router node MUST act as a PANA Relay Element (PRE) according to [RFC6345], unless it is also the Authentication Server. All routers at the edge of the network MUST be capable of functioning in the PRE role.
    • The Authentication Server node MUST act as the PANA Authentication Agent (PAA). The Authentication Server MUST be able to handle packets relayed according to [RFC6345].

This network authentication process uses link-local IPv6 addresses for transport between the new node and its parent 🌿. If the parent isn't the Authentication Server, it MUST then relay packets from the joining node to the Authentication Server and vice versa, using the PANA relay mechanism [RFC6345]. The joining node MUST use a link-local address based on its EUI-64 as the source address for the initial PANA authentication message exchanges 📍

4.1.8.2.2. Applicability Statements 📚

Okay, so these applicability statements explain how all the specs connect to each other 🧩

4.1.8.2.2.1. Applicability Statement for PSK TLS 🔑

[RFC6655] has Authenticated Encryption with Associated Data (AEAD) TLS cipher suites that are super similar to [RFC5487], whose AEAD part is detailed in [RFC5116]. [RFC5487] references both [RFC5288] and the original PSK cipher suite document [RFC4279], which references RFC 2246. RFC 2246 was eventually replaced by [RFC5246], which defines the TLS 1.2 messages 💜

4.1.8.2.2.2. Applicability Statement for ECC TLS 🌊

[RFC7251] has AEAD TLS cipher suites that are very similar to [RFC5289], whose AEAD part is detailed in [RFC5116]. [RFC5289] references the original ECC cipher suite document [RFC4492], which references RFC 2246. Again, RFC 2246 was eventually replaced by [RFC5246], which defines the TLS 1.2 messages 🫧

4.1.8.2.2.3. Applicability Statement for EAP-TLS and PANA 🦋

[RFC5216] specifies how [RFC3748] is used to package [RFC5246] TLS records into EAP packets. [RFC5191] provides transportation for the EAP packets and for the network-wide key, which is carried in an encrypted Attribute-Value Pair (AVP) as specified in [RFC6786]. The proposed Pseudorandom Function (PRF) and authentication (AUTH) hashes based on SHA-256 are represented as specified in [RFC7296] and detailed in [RFC4868] 🧠

4.1.8.2.3. Security Using RPL Message Security 🎀

If RPL is used with secured messages [RFC6550], the following RPL security parameter values SHOULD be used:

  • Counter is Time (T) flag = 0: Don't use the timestamp in the Counter field. Counters based on timestamps are more applicable to industrial networks, where strict timing synchronization between nodes is often implemented. Home and building networks typically don't do that kind of strict timing sync, so a monotonically increasing counter is more appropriate ⏳
  • Algorithm = 0: Use Counter with the Cipher Block Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with AES-128. This is the only assigned mode at present 🔒
  • Key Identifier Mode (KIM) = 10: Use a group key, Key Source present, and Key Index present. Since a home or building network has a relatively confined perimeter, a group key is usually enough to protect RPL messages sent between nodes. The Key Source field lets multiple group keys be used within the network 🗂️
  • Security Level (LVL) = 0: Use MAC-32. This is recommended, because integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary, given how relatively non-confidential RPL message payloads are 🫶

4.1.9. P2P Communications 🤝

[RFC6997] MUST be used to accommodate P2P traffic, which is typically substantial in home and building automation networks 💞

4.1.10. IPv6 Address Configuration 🌐

Assigned IP addresses MUST be routable and unique within the routing domain [RFC5889] 🏷️

4.2. Layer 2 Features 🧃

No particular requirements exist for Layer 2, except for those cited in the "IP-over-Foo" RFCs (see Section 2.3) 💭

4.2.1. Specifics about Layer 2

Not applicable

4.2.2. Services Provided at Layer 2

Not applicable

4.2.3. IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Options Assumed

Not applicable

Not applicable

The following sections describe the recommended parameter values for P2P-RPL and Trickle 🌸

4.3.1. Trickle Parameters

Okay so Trickle is the thing that spreads network parameter values to every node, and it's totally chill about timing 💅 The recommended Trickle parameter values are:

  • DIOIntervalMin 4, which translates to 16 ms 🌸
  • DIOIntervalDoublings 14 🎀
  • DIORedundancyConstant 1 💖

When a node sends a changed DIO, that counts as an inconsistency and forces the receiving node to respond within Imin. So when something happens that changes the DIO, ideally the node that's n hops away hears about it within n times Imin ⏱️ But depending on node density, packets can get lost or never get sent at all, so the delays can get bigger. Not me waiting forever 💀

In general, we can expect DIO changes to propagate within 1 to 3 seconds in the networks this is meant for ✨ When nothing is happening, the DIO sending interval grows to 4.37 minutes, which drastically cuts down the network load 🦋 And if a node doesn't receive DIO messages for more than 10 minutes, it can safely conclude that its connection with other nodes has been lost 😭

4.3.2. Other Parameters

This section is about the P2P-RPL parameters 🧚

P2P-RPL [RFC6997] provides the features requested by [RFC5826] and [RFC5867]. It uses a subset of the frame formats and features defined for RPL [RFC6550], but it may be combined with RPL frame flows in advanced deployments. Iconic multitasking 👑

The recommended parameter values for P2P-RPL are:

  • MinHopRankIncrease 1
  • MaxRankIncrease 0
  • MaxRank 6
  • Objective Function: OF0 🍓

5. MPL Profile ✨

MPL is used to distribute values to groups of devices 🫶 Because it's based on the Trickle algorithm, timeliness should also be guaranteed. A deadline of 200 ms needs to be met when a human action is followed by an immediately observable action, like switching on the lights 💡 The deadline needs to be met in a building where the number of hops from seed to destination varies between 1 and 10. Main character energy, literally 🌈

5.1.1. Real-Time Optimizations

When the network is heavily loaded, MAC delays contribute significantly to end-to-end delays when MPL intervals between 10 and 100 ms are used to meet the 200 ms deadline 😩 It's possible to set the number of buffers in the MAC to 1 and set the number of back-off repetitions to 1. The number of MPL repetitions makes up for the reduced probability of transmission per MAC invocation [RT-MPL] 🔥

Also, end-to-end delays and message losses get reduced by adding a real-time layer between MPL and MAC. That layer throws away the earliest messages (using the MPL message numbering) and favors the most recent ones 🦋

5.1.2. Trickle Parameters

This section proposes values for the Trickle parameters that MPL uses to distribute packets that need to meet a 200 ms deadline 💜 The probability of meeting the deadline goes up when you (1) choose a small Imin value, (2) reduce the number of MPL intervals so the load drops, and (3) reduce the number of MPL Forwarders, which also lightens the load ✨

The consequence is that the value of k can be larger than 1, because network load reduction is already guaranteed by the network configuration 🎀

If the density of MPL repeaters can be limited, it's possible to choose low MPL repeat intervals (Imin) with k values such that k > 1. The minimum value of k is related to:

  • The value of Imin. The length of Imin determines the number of packets that can be received within the listening period of Imin.
  • The number of repeaters receiving the broadcast message from the same forwarder or seed. These repeaters repeat within the same Imin interval, which increases the c counter.

Within the first MPL interval, a limited number, q, of messages can be transmitted. Assuming a 3 ms transmission interval, q = Imin / 3. Assuming that at most q message copies can reach a given forwarder within the first repeat interval of length Imin, the related MPL parameter values are suggested in the following sections 🧮

5.1.2.1. Imin

The recommended value is Imin = 10 to 50 ms 🌸

When the chosen Imin value is much smaller, the interference between the copies leads to significant losses, since q is much smaller than the number of repeated packets 😭 With much larger intervals, the probability that the deadline will be met goes down as the hop count goes up.

5.1.2.2. Imax

The recommended value is Imax = 100 to 400 ms 🍓

The value of Imax is less important than the value of max_expiration. Given an Imin value of 10 ms, the third MPL interval has a value of 10 * 2 * 2 = 40 ms. When Imin has a value of 40 ms, the third interval has a value of 160 ms. Since more than three intervals are unnecessary, Imax doesn't contribute much to performance 🙈

5.1.3. Other Parameters

The other parameters are the k parameter and the max_expiration parameter 🧚

k > q (see condition above). Under this condition, and for a small Imin value, a value of k = 2 or k = 3 is usually sufficient to minimize packet losses in the first repeat interval 💅

max_expiration = 2 - 4. Higher values lead to more network load while generating copies that will probably not meet their deadline 💀

6. Manageability Considerations

At this time, it is not clear how homenets will be managed 🤷‍♀️ Consequently, it is not clear which tools will be used and which parameters must be visible for management.

In building control, management is mandatory 🏢 It is expected that installations will be managed using the set of currently available tools (including IETF tools like Management Information Base (MIB) modules, Network Configuration Protocol (NETCONF) modules, Dynamic Host Configuration Protocol (DHCP), and others), with large differences between the ways an installation is managed 🌈

7. Security Considerations 🔐

This section refers to the security considerations of [RFC6997], [RFC6550], and [RFC7731], as well as some attacks and countermeasures discussed in Sections 6 and 7, respectively, of [RFC7416] 🫶

Communications network security is based on providing integrity protection and encryption to messages. This can be applied at various layers of the network protocol stack, using various credentials and a network identity 🔒

The credentials that matter for RPL are (i) the credential used at the link layer when link-layer security is applied (see Section 7.1), or (ii) the credential used for securing RPL messages. In both cases, the assumption is that the credential is a shared key. Therefore, there MUST be a mechanism in place that allows secure distribution of a shared key and configuration of a network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) secure delivery when a device is introduced into the network, or (iii) secure delivery by a trusted neighboring device, as described in Section 4.1.8.1. The shared key MUST be stored in a secure fashion that makes it difficult for an unauthorized party to read it 🗝️

This document mandates that a Layer 2 mechanism be used during initial and incremental deployment. Please see the following sections. Not optional, bestie 🚨

7.1. Security Considerations during Initial Deployment

Wireless mesh networks are typically secured at the link layer so that unauthorized parties can't access the information exchanged over the links 🕸️ It's a basic practice to create a network of nodes that share the same keys for link-layer security and exclude nodes sending unsecured messages. With per-message data origin authentication, it's possible to stop unauthorized nodes from joining the mesh ✨

At initial deployment, the network is secured by consecutively securing nodes at the link layer, which builds a network of secured nodes. Section 4.1.8.2 describes a mechanism for building a network of secured nodes 🧱

This document does not specify a multicast security solution. Networks deployed with this specification will depend on Layer 2 security to keep outsiders from sending multicast traffic. It's recognized that this does not protect this control traffic from impersonation by already-trusted devices. That's an area for a future specification 👀

For building control, an installer will use an installation tool that establishes a secure communication path with the joining node. It's recognized that the recommendations for initial deployment discussed in this section don't cover all building requirements, such as selecting (independent of network topology) the node to be secured 🛠️

It's expected that a set of protocol combinations will evolve within existing alliances of building control manufacturers. Each set satisfies the installation requirements of installers, operators, and manufacturers of building control networks in a given installation context, e.g., lighting deployment in offices, HVAC installation, incremental addition of equipment in homes, and others 🏠

In the home, the home owner can visually inspect the nodes. Also, a simple procedure, e.g., pressing buttons simultaneously on an already-secured device and an unsecured joining device, is usually enough to make sure the unsecured joining device is authenticated securely, configured securely, and paired appropriately 🔘

This recommendation is in line with the countermeasures described in Section 7.1 of [RFC7416] 💜

7.2. Security Considerations during Incremental Deployment

Once a network is operational, new nodes need to be added, or nodes fail and need to be replaced 🔄 When a new node needs to be added, it joins the network via an assisting node in the manner described in Section 7.1.

On detection of a compromised node, all trusted nodes need to have their symmetric keys that are known to be shared with the compromised node rekeyed, and the trusted network is built back up as described in Section 7.1 🚨😭

7.3. Security Considerations for P2P Implementations

Refer to the security considerations of [RFC6997] 🧚

7.4. MPL Routing

The routing of MPL is determined by enabling the interfaces for specified multicast addresses 🗺️ Those addresses can be specified via a Constrained Application Protocol (CoAP) application, as specified in [RFC7390]. An alternative is creating an MPL MIB and using the Simple Network Management Protocol (SNMPv3) [RFC3411] or equivalent techniques to specify the multicast addresses in the MIB. For secure dissemination of MPL packets, Layer 2 security SHOULD be used, and the configuration of multicast addresses as described in this section MUST be secure 🔐💅

7.5. RPL Security Features

okay so this bit is basically a bestie-level recap of the RPL security stuff from [RFC7416] 🔐✨ this section follows the same structure as Section 8 ("RPL Security Features") of [RFC7416], and [RFC7416] is the deep-dive threat analysis with all the countermeasures, so if you want the full tea, go read that 💅

okay so the confidentiality part: RPL message security does payload protection, same as Section 7 of this document, which matches Section 8.1 ("Confidentiality Features") of [RFC7416] 🫶 the key length and key lifetime depend on operational conditions, maintenance, and installation procedures, so it's not one-size-fits-all bestie 🌸

Sections 7.1 and 7.2 of this document recommend link-layer security to assure integrity, lining up with Section 8.2 ("Integrity Features") of [RFC7416] 🔥 that's the integrity glow-up 🦋

the multiple paths thing is giving reliability ✨ the provision of multiple paths recommended in Section 8.3 ("Availability Features") of [RFC7416] is also recommended from a reliability point of view 💖 and randomly choosing paths MAY be supported 🎀 (so it's optional, not a must, babe 🙈)

last one: the key management stuff, discussed in Section 8.4 ("Key Management") of [RFC7416], is provided in Section 4.1.8.2 of this document 🗝️💜 iykyk that's where the keys get sorted out 👑

  1. Other Related Protocols

okay so the other protocols bit is lowkey simple 🧚 application and transport protocols used in home and building automation are expected to mostly consist of CoAP over UDP, or equivalents 🌈 UDP is typically used for IP transport to keep the application response time and bandwidth overhead down 💨 and CoAP is used at the application layer to reduce memory footprint and bandwidth requirements 🍓 literally the efficiency queen era 👸💅

  1. References

9.1. Normative References

ngl the reference list is long, so here it comes, every single one, all the details intact 📚💖

[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>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.

[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.

[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.

[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <http://www.rfc-editor.org/info/rfc5191>.

[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.

[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.

[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.

[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>.

[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2009, <http://www.rfc-editor.org/info/rfc5673>.

[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, <http://www.rfc-editor.org/info/rfc5826>.

[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 2010, <http://www.rfc-editor.org/info/rfc5867>.

[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>.

[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011, <http://www.rfc-editor.org/info/rfc6345>.

[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>.

[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>.

[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <http://www.rfc-editor.org/info/rfc6554>.

[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <http://www.rfc-editor.org/info/rfc6655>.

[RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, November 2012, <http://www.rfc-editor.org/info/rfc6786>.

[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, DOI 10.17487/RFC6997, August 2013, <http://www.rfc-editor.org/info/rfc6997>.

[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, "A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network", RFC 6998, DOI 10.17487/RFC6998, August 2013, <http://www.rfc-editor.org/info/rfc6998>.

[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>.

[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, <http://www.rfc-editor.org/info/rfc7251>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.

[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>.

[IEEE802.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, DOI 10.1109/ieeestd.2011.6012487, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>.

[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.

9.2. Informative References 🦋

okay bestie, these are the extra-reading refs. The doc points to them for context, but you don't need them to implement anything 📚 Here's the lineup:

Appendix A. RPL Shortcomings in Home and Building Deployments ✨

A.1. Risk of Undesirable Long P2P Routes 🌳

okay so the DAG is a tree, which means it grows out from a single root. If nodes sitting on different branches need to talk to each other, the DAG mechanisms in RPL [RFC6550] push the traffic up toward the root, potentially all the way up, and then back down another branch [RFC6998]. in the best case two nodes can reach each other through just two router nodes, but in some unfortunate cases RPL sends traffic three hops up and then three hops back down again 😭 that causes a bunch of messy stuff, which we'll go through in the sections below 💀

A.1.1. Traffic Concentration at the Root 🚦

the closer a P2P data flow gets to the root, the more it has to squeeze in on the way up, so the congestion risk goes up with it. radio is broadcast by nature, so any child of the root isn't just beaming RF power down its own sub-tree, it's beaming it up toward the root too 📡 that can jam other MP2P traffic trying to leave the tree, or stop the root from sending P2MP traffic into the DAG because the listen-before-talk link-layer protection kicks in 🙈

A.1.2. Excessive Battery Consumption in Source Nodes 🔋

battery-powered nodes that start P2P traffic depend on the route length. longer routes mean source nodes have to stay awake for longer before going back to sleep, so a longer route roughly translates into higher battery consumption ⚡

A.2. Risk of Delayed Route Repair 💔

the RPL DAG mechanism uses DIO and DAO messages to keep an eye on the health of the DAG 👀 every so often, changed radio conditions can make a route unusable right after a destination has sent a DAO saying it's reachable. the next Trickle timer-controlled DIO/DAO update will eventually fix the broken routes, sure, but not necessarily in a timely way for the app. in an apparently stable DAG, Trickle timer dynamics can slow the update rate down to a few times every hour 🐌 so if a user sends an actuator command, like light on, in the gap between the destination module's last DAO and one of the parents sending the next DIO, the destination just can't be reached. RPL has no mechanism to start restoring connectivity in a reactive way, and the result is a broken service in home and building applications 😤

A.2.1. Broken Service 📞

telecom people know that once voice delay goes over 250 ms, users start getting confused, frustrated, and/or annoyed. same vibe with lights: if the light doesn't turn on in that same window, the home control user just hits the button again, which causes a sequence like Light{on,off,off,on,off,...} or Volume{up,up,up,up,up,...} 🎛️ whether the result is nothing or some unintended response, it's unacceptable. a controlling system must be able to restore connectivity to recover from the error situation. waiting an unknown amount of time is not an option 🚫 although this issue was identified during the P2P analysis, it applies just as well to application scenarios where an IP application outside the LLN controls actuators, lights, etc. 💡

Appendix B. Communication Failures 🌸

measurements of connectivity between neighboring nodes are discussed in [RTN2011] and [MEAS] 📊

the work is motivated by measurements in the literature showing that the range of an antenna is not circle symmetric. the signal strength at a given level follows an intricate pattern around the antenna, and there may be holes inside the area a polar plot outlines 🕳️ communication isn't symmetric either: node B receiving messages from node A doesn't mean node A receives messages from node B. the signal quality also fluctuates over time, and the height of the antenna inside a room can change the range too. as you move away from the source, three regions are generally recognized: (1) a clear region with excellent signal quality, (2) a region with fluctuating signal quality, and (3) a region without reception. just installing meshes with neighbors in the clear region isn't enough, as described below 🙅

[RTN2011] extends existing work by:

  • Observations over periods of at least a week,
  • Testing links that are in the clear region,
  • Observation in an office building during working hours, and
  • Concentrating on one-hop and two-hop routes.

eight nodes were spread over a surface of 30 square meters. all nodes are one hop away from each other, and all of them sit in each other's clear region. each node sends messages to each of its neighbors and repeats the message until it arrives. the latency was measured over periods of at least a week, and latencies longer than a second kept showing up for no apparent reason, but only on working days and never on weekends 📅 bad periods could last for minutes ⏳ by sending messages over two paths, (1) a one-hop path directly and (2) a two-hop path via a randomly chosen neighbor, the probability of delays larger than 100 ms dropped significantly 📉

the conclusion: even for one-hop communication between not-too-distant "line of sight" nodes, there are periods of low reception where communication deadlines of 200 ms get blown past 😩 it pays to send a second message over a two-hop path to make timely delivery more reliable 🫶

[MEAS] confirms that temporary bad reception by close neighbors can happen in other kinds of areas too. nodes were installed on the ceiling in a grid with 30-50 cm between them, and two hundred nodes were spread over an area of 10 m x 5 m 🏢 it clearly showed that the probability of reception drops as distance goes up. at the same time, a few nodes furthest from the sender had a high probability of receiving messages, while some close neighbors of the sender didn't receive anything at all 🤯 the patterns of which nodes had good reception changed over time 🔄

the conclusion here: even direct neighbors can have temporarily bad reception for periods of several minutes. for reliable and timely communication, it is imperative to have at least two communication paths available (e.g., two-hop paths next to the one-hop path for direct neighbors) 👑

Acknowledgements 🎀

this document reflects discussions and remarks from several individuals, including (in alphabetical order) Stephen Farrell, Mukul Goyal, Sandeep Kumar, Jerry Martocci, Catherine Meadows, Yoshihiro Ohba, Charles Perkins, Yvonne-Anne Pignolet, Michael Richardson, Ines Robles, Zach Shelby, and Meral Sherazipour 💜

Authors' Addresses 🧚

Anders Brandt
Sigma Designs

Email: anders_Brandt@sigmadesigns.com


Emmanuel Baccelli
INRIA

Email: Emmanuel.Baccelli@inria.fr


Robert Cragie
ARM Ltd.
110 Fulbourn Road
Cambridge  CB1 9NJ
United Kingdom

Email: robert.cragie@arm.com


Peter van der Stok
Consultant

Email: consultancy@vanderstok.org
📦 where this page comes from