RFC 5867
Building Automation Routing Requirements in Low-Power and Lossy Networks
Abstract ✨
Okay bestie, so the ROLL (Routing Over Low-Power and Lossy) networks Working Group got chartered to work on routing for Low-Power and Lossy Networks (LLNs) across industrial, commercial (building), home, and urban markets 🏙️. This doc focuses on the building part and defines the IPv6 routing requirements for building automation 🏢💖
Status of This Memo 📋
This one is NOT an Internet Standards Track spec, it's just published for info, no cap 🫶
It's a product of the Internet Engineering Task Force (IETF) and 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). Not everything the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓
If you want the current status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc5867 🦋
Copyright Notice ©️
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 📜 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥
Some material in this doc may come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The folks who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents 🗂️
1. Introduction ....................................................4
2. Terminology .....................................................6
2.1. Requirements Language ......................................6
3. Overview of Building Automation Networks ........................6
3.1. Introduction ...............................................6
3.2. Building Systems Equipment .................................7
3.2.1. Sensors/Actuators ...................................7
3.2.2. Area Controllers ....................................7
3.2.3. Zone Controllers ....................................8
3.3. Equipment Installation Methods .............................8
3.4. Device Density .............................................9
3.4.1. HVAC Device Density .................................9
3.4.2. Fire Device Density .................................9
3.4.3. Lighting Device Density ............................10
3.4.4. Physical Security Device Density ...................10
4. Traffic Pattern ................................................10
5. Building Automation Routing Requirements .......................12
5.1. Device and Network Commissioning ..........................12
5.1.1. Zero-Configuration Installation ....................12
5.1.2. Local Testing ......................................12
5.1.3. Device Replacement .................................13
5.2. Scalability ...............................................13
5.2.1. Network Domain .....................................13
5.2.2. Peer-to-Peer Communication .........................13
5.3. Mobility ..................................................13
5.3.1. Mobile Device Requirements .........................14
5.4. Resource Constrained Devices ..............................15
5.4.1. Limited Memory Footprint on Host Devices ...........15
5.4.2. Limited Processing Power for Routers ...............15
5.4.3. Sleeping Devices ...................................15
5.5. Addressing ................................................16
5.6. Manageability .............................................16
5.6.1. Diagnostics ........................................17
5.6.2. Route Tracking .....................................17
5.7. Route Selection ...........................................17
5.7.1. Route Cost .........................................17
5.7.2. Route Adaptation ...................................18
5.7.3. Route Redundancy ...................................18
5.7.4. Route Discovery Time ...............................18
5.7.5. Route Preference ...................................18
5.7.6. Real-Time Performance Measures .....................18
5.7.7. Prioritized Routing ................................18
5.8. Security Requirements .....................................19
5.8.1. Building Security Use Case .........................19
5.8.2. Authentication .....................................20
5.8.3. Encryption .........................................20
5.8.4. Disparate Security Policies ........................21
5.8.5. Routing Security Policies to Sleeping Devices ......21
6. Security Considerations ........................................21
7. Acknowledgments ................................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Appendix A. Additional Building Requirements ......................23
A.1. Additional Commercial Product Requirements ................23
A.1.1. Wired and Wireless Implementations .................23
A.1.2. World-Wide Applicability ...........................23
A.2. Additional Installation and Commissioning Requirements ....23
A.2.1. Unavailability of an IP Network ....................23
A.3. Additional Network Requirements ...........................23
A.3.1. TCP/UDP ............................................23
A.3.2. Interference Mitigation ............................23
A.3.3. Packet Reliability .................................24
A.3.4. Merging Commissioned Islands .......................24
A.3.5. Adjustable Routing Table Sizes .....................24
A.3.6. Automatic Gain Control .............................24
A.3.7. Device and Network Integrity .......................24
A.4. Additional Performance Requirements .......................24
A.4.1. Data Rate Performance ..............................24
A.4.2. Firmware Upgrades ..................................25
A.4.3. Route Persistence ..................................251. Introduction 🌟
The ROLL (Routing Over Low-Power and Lossy) networks Working Group got chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in industrial, commercial (building), home, and urban markets. This doc narrows that down to the IPv6 routing requirements for building automation 🏢
Okay, the history is iconic. Commercial buildings have been running pneumatic communication routes connecting sensors to their controllers for over one hundred years, and then electronic ones took over 🕰️ Recent economic and technical advances in wireless communication mean facilities can swap wired solutions for wireless ones more and more. That cuts installation costs while still keeping communication highly reliable 💅
Cheap, easy-to-install wireless sensors let customers instrument their buildings with even more sensors. That gives tighter control and more energy savings, which is so good for the planet 🌍💚
Wireless versions of existing wired systems are coming for lots of building applications, including heating, ventilation, and air conditioning (HVAC), lighting, physical security, fire, and elevator/lift systems. The goal is lower installation costs, more flexibility when installing and retrofitting, and better sensing so buildings run more efficiently and deliver better service quality ✨
Sensing devices might be battery-less, battery-powered, or mains-powered. Actuators and area controllers are going to be mains-powered 🔌 Because of building codes and/or device density (like in an equipment room, for example), it's expected that a mix of wired and wireless sensors and actuators will show up in one building 🧚
Building management systems (BMSs) are deployed across a huge range of vertical markets: universities, hospitals, government facilities, kindergarten through high school (K-12), pharmaceutical manufacturing facilities, and single-tenant or multi-tenant office buildings 🎓🏥 Buildings range from 100K-sq.-ft. structures (5-story office buildings) to 1M-sq.-ft. skyscrapers (100-story skyscrapers), all the way up to complex government facilities like the Pentagon 🏛️ The topology described here is meant to be the model for all of these environments, but it clearly has to be tailored to the building class, building tenant, and vertical market being served 💼
Section 3 gives you the background you need to understand the context of building automation. That covers the sensor, actuator, area controller, and zone controller layers of the topology, typical device density, and installation practices 📚
Section 4 defines the traffic flow of those sensors, actuators, and controllers in commercial buildings 🚦
Section 5 defines the full set of IPv6 routing requirements for commercial buildings 💅
Appendix A covers important commercial building requirements that are out of scope for routing, but will be essential to the final acceptance of the protocols used within the building 🎀
Section 3 and Appendix A are mainly included for educational purposes 🧠
The aim of this doc is to provide the set of IPv6 routing requirements for LLNs in buildings, as described in Section 5. That's the main event, periodt 👑
2. Terminology 📖
For a description of the terminology used in this specification, check out [ROLL-TERM] 🦋
2.1. Requirements Language 📝
okay so bestie, 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]. no cap, these capitalised words are the ones that carry the real weight 💅
3. Overview of Building Automation Networks 🏢✨
3.1. Introduction 🧚
okay so this doc uses a framework to explain the network systems requirements of a building management system (BMS) in a commercial building 🎀. it's giving hierarchy: a BMS is a layered system of sensors, actuators, controllers, and user interface devices that work together to keep things safe and comfy while keeping energy costs in check 💖
a BMS is split up functionally across different but related building subsystems, like heating, ventilation, and air conditioning (HVAC); fire; security; lighting; shutters; and elevator/lift control systems. see Figure 1 below 👀
lowkey, a lot of a BMS is optional and only gets installed if the customer asks for it 🙈. sensors and actuators can't do anything on their own 😭. everything else can do some or all of its job standalone, and those devices can optionally be tethered together into a more cohesive system 🦋. the customer's requirements decide how much integration the facility gets 💅. honestly the design is iconic for fault tolerance, because each node is built to keep working on its own if the higher layers go down 🫶
+------+ +-----+ +------+ +------+ +------+ +------+
Bldg App'ns | | | | | | | | | | | |
| | | | | | | | | | | |
Building Cntl | | | | | S | | L | | S | | E |
| | | | | E | | I | | H | | L |
Area Control | H | | F | | C | | G | | U | | E |
| V | | I | | U | | H | | T | | V |
Zone Control | A | | R | | R | | T | | T | | A |
| C | | E | | I | | I | | E | | T |
Actuators | | | | | T | | N | | R | | O |
| | | | | Y | | G | | S | | R |
Sensors | | | | | | | | | | | |
+------+ +-----+ +------+ +------+ +------+ +------+
Figure 1: Building Systems and Devices3.2. Building Systems Equipment 🛠️
3.2.1. Sensors/Actuators 🌡️
okay so as Figure 1 shows, a BMS can be made of lots of functional stacks or silos that get interoperably woven together through building applications 🕸️. each silo has a bunch of sensors that watch the environment and actuators that change it, depending on what the upper layers of the BMS topology decide ✨. sensors are usually at the edge of the network, feeding environmental data into the system 📡. actuators are the sensors' counterparts 🫶: they change the characteristics of the system based on the sensor data and the applications that are deployed 💖
3.2.2. Area Controllers 🚪
an area is a small physical locale in a building, usually a room 🏠. HVAC (temperature and humidity) and lighting (room lighting, shades, solar loads) vendors oftentimes deploy area controllers 💅. area controllers get fed by sensor inputs that monitor the conditions inside the room. the sensors you'll usually find in lots of rooms are temperature, occupancy, lighting load, solar load, and relative humidity 🌸. specialised rooms (like chemistry labs) might have air flow, pressure, and CO2 and CO particle sensors too 🧪. room actuation covers temperature setpoint, lights, and blinds/curtains 🪟
3.2.3. Zone Controllers 🗺️
zone controllers have a similar set of characteristics to area controllers, just for a bigger space 🌈. a zone is normally a logical grouping or functional division of a commercial building. sometimes a zone also lines up with a physical locale, like a floor 🏢
zone controllers can have direct sensor inputs (smoke detectors for fire), controller inputs (room controllers for air handlers in HVAC), or both (door controllers and tamper sensors for security) 🔐. just like area/room controllers, zone controllers are standalone devices that run independently, or they can be attached to the larger network for more synergistic control 🤝
3.3. Equipment Installation Methods 🏗️
a BMS is installed very differently from most other IT networks, no cap 😤. IT networks are usually installed as an overlay onto the existing environment, from the inside out. so first the network wiring infrastructure goes in, then the switches, routers, and servers get connected and made operational, and finally the endpoints (e.g., PCs, VoIP phones) get added 💻
BMSs go the opposite way, from the outside in 🔄. the endpoints (thermostats, lights, smoke detectors) get installed in the spaces first, local control is set up in each room, and it gets tested for proper operation 🧯. then the individual rooms get lashed together into a subsystem (e.g., lighting) 💡. the individual subsystems (e.g., lighting, HVAC) then coalesce 🌀. later on, the whole system might get merged onto the enterprise network 🏬
the reason is partly that different construction trades get access to a building under construction at different times 🧱. a building is so big that even a single trade can have multiple independent teams working at once 👷♀️. also, the HVAC, lighting, and fire systems MUST be fully operational before the building can get its occupancy permit 🪪. so the BMS MUST be in place and configured well before any of the IT servers (DHCP; Authentication, Authorization, and Accounting (AAA); DNS; etc.) are operational 😭
this means the BMS cannot rely on the availability of the IT network infrastructure or application servers 🚨. instead, the BMS installation SHOULD be planned so it can dovetail into the IT system once the IT system is ready for an easy migration onto the IT network 🦋. front-end planning of available switch ports, cable runs, access point (AP) placement, firewalls, and security policies will make this adoption way easier 💖
3.4. Device Density 📊
device density changes depending on the application, and it's dictated by the local building code requirements 📐. the following subsections detail typical installation densities for different applications 🎀
3.4.1. HVAC Device Density 🌬️
HVAC room applications typically have sensors/actuators and controllers spaced about 50 ft. apart 📏. in most cases there's a 3:1 ratio of sensors/actuators to controllers. so for each room there's an installed temperature sensor, flow sensor, and damper actuator for the associated room controller 🌡️
HVAC equipment room applications are quite different 😳. an air handler system might have a single controller with up to 25 sensors and actuators within 50 ft. of the air handler. a chiller or boiler is also controlled with a single equipment controller instrumented with 25 sensors and actuators 🔥. each of these devices would be individually addressed, since the devices are mandated or optional as defined by the specified HVAC application 🧾. air handlers typically serve one or two floors of the building, and chillers and boilers may be installed per floor, but many times they service a wing, building, or the entire complex via a central plant 🏭
these numbers are typical 💁♀️. in special cases, like clean rooms, operating rooms, pharmaceutical facilities, and labs, the ratio of sensors to controllers can increase by a factor of three 🧪. tenant installations such as malls would opt for packaged units, where much of the sensing and actuation is integrated into the unit, so a single device address would serve the entire unit 🛍️
3.4.2. Fire Device Density 🔥
fire systems are way more uniformly installed, with smoke detectors installed about every 50 ft. 🚨 this is dictated by local building codes. fire pull boxes are installed uniformly about every 150 ft. a fire controller services a floor or wing, and the fireman's fire panel services the entire building and is typically installed in the atrium 🏛️
3.4.3. Lighting Device Density 💡
lighting is also very uniformly installed, with ballasts installed approximately every 10 ft. ✨ a lighting panel typically serves 48 to 64 zones. wired systems tether lots of lights together into a single zone, while wireless systems configure each fixture independently to increase flexibility and reduce installation costs 💜
3.4.4. Physical Security Device Density 🔐
security systems are non-uniformly oriented, with heavy density near doors and windows and lighter density in the building's interior space 🚪
the recent influx of interior and perimeter camera systems is increasing the security footprint 📹. these cameras are atypical endpoints that require up to 1 megabit/second (Mbit/s) data rates per camera, as contrasted with the few kbit/s needed by most other BMS sensing equipment 📈. previously, camera systems were deployed on proprietary wired high-speed networks. more recent implementations use wired or wireless IP cameras integrated into the enterprise LAN 🌐
4. Traffic Pattern ✨
Okay bestie, so the automation subsystems inside a building are super independent, and that totally changes what the network traffic looks like 🦋. Most of the real-time sensor data and actuator control just hangs out inside the local LLN, while alarms and other event data percolate up to the higher layers 💅.
Each sensor unicasts point to point (P2P) about 200 bytes of sensor data to its associated controller every minute, and it expects an application acknowledgment unicast back from the destination 🫶. Each controller unicasts messages at a nominal rate of 6 kbit/minute to peer or supervisory controllers 🎀. Thirty percent of each node's packets are destined for other nodes within the LLN, and seventy percent are destined for an aggregation device (multipoint to point (MP2P)) and routed off the LLN 👑. These messages also need a unicast acknowledgment from the destination. The numbers above assume direct node-to-node communication, and meshing and error retransmissions are not considered 🙈.
Multicasts (point to multipoint (P2MP)) go to all nodes in the LLN for node and object discovery when the network is first commissioned 🧚. This data is typically a one-time bind that is persisted from then on. Lighting systems will totally use multicasting during normal operations too, to turn banks of lights "on" and "off" all at once 💡.
BMSs may be either polled or event-based. Polled data systems generate a uniform and constant packet load on the network, but polled architectures have proven not to be scalable 😭. Today, most vendors have built event-based systems that pass data on event. These systems are highly scalable and generate low data on the network at quiescence, which is iconic ✨. The tea is that they'll generate a heavy load on startup, since all initial sensor data has to migrate to the controller level. They also generate a temporary but heavy load during firmware upgrades. This latter load can normally be mitigated by doing these downloads during off-peak hours 🌙.
Devices will also need to reference peers periodically for sensor data or to coordinate operation across systems. Normally, though, data migrates from the sensor level upwards through the local and area levels, and then to the supervisory level. Traffic bottlenecks typically form at the funnel point from the area controllers to the supervisory controllers 🚧.
Initial system startup after a controlled outage or an unexpected power failure puts tremendous stress on the network and on the routing algorithms 💀. A BMS is made up of a myriad of control algorithms at the room, area, zone, and enterprise layers. When these control algorithms are at quiescence, the real-time data rate is small and the network will not saturate 🌸. An overall network traffic load of 6 kbit/s is typical at quiescence. However, upon any power loss, the control loops and real-time data quickly atrophy 😩. A short power disruption of only 10 minutes may have a long-term deleterious impact on the building control systems, taking many hours to regain proper control. Control applications that cannot handle this level of disruption (e.g., hospital operating rooms) must be fitted with a secondary power source 🏥.
Power disruptions are unexpected and in most cases will immediately impact lines-powered devices. Power disruptions, however, are transparent to battery-powered devices, which keep trying to access the LLN during the outage 🔋. Battery-powered devices designed to buffer data that has not been delivered will further stress network operations when power returns.
Upon restart, lines-powered devices will naturally dither due to primary equipment delays or variance in the device self-tests. However, most lines-powered devices will be ready to access the LLN within 10 seconds of power-up ⚡. Empirical testing indicates that routes acquired during startup will tend to be very oblique, since the available neighbor lists are incomplete. This demands an adaptive routing protocol that allows for route optimization as the network stabilizes 🧭.
5. Building Automation Routing Requirements 👑
Okay, this is the part with the actual rules 🎀. Following are the building automation routing requirements for networks used to integrate building sensor, actuator, and control products. These requirements are written without presuming any preordained network topology, physical media (wired), or radio technology (wireless) 🌈.
5.1. Device and Network Commissioning
Building control systems are typically installed and tested by electricians who have little computer knowledge and no network communication knowledge whatsoever 🔧. These systems are often installed during the building construction phase, before the drywall and ceilings are in place 🏗️. For new construction projects, the building enterprise IP network is not in place during installation of the building control system. For retrofit applications, the installer still operates independently from the IP network so as not to affect network operations during the installation phase.
In traditional wired systems, correct operation of a light switch/ballast pair was as simple as flipping on the light switch 💡. In wireless applications, the tradesperson has to make sure the same operation happens, and also be sure the light switch is associated with the proper ballast. That's a lot, bestie 😅.
System-level commissioning will later be deployed using a more computer-savvy person with access to a commissioning device (e.g., a laptop computer) 💻. The completely installed and commissioned enterprise IP network may or may not be in place at this time. Following are the installation routing requirements.
5.1.1. Zero-Configuration Installation
It MUST be possible to fully commission network devices without requiring any additional commissioning device (e.g., a laptop). From the ROLL perspective, "zero configuration" means that a node can obtain an address and join the network on its own, without human intervention 🪄. No babysitting needed, periodt 💅.
5.1.2. Local Testing
During installation, the room sensors, actuators, and controllers SHOULD be able to route packets amongst themselves and to any other device within the LLN, without requiring any additional routing infrastructure or routing configuration 🧪.
5.1.3. Device Replacement
To eliminate the need to reconfigure the application when a failed device in the LLN is replaced, the replaced device must be able to advertise the old IP address of the failed device in addition to its new IP address 🔁. The routing protocols MUST support hosts and routers that advertise multiple IPv6 addresses. Iykyk 🫶.
5.2. Scalability
Building control systems are designed for facilities from 50,000 sq. ft. to 1M+ sq. ft. 🏢 The networks that support these systems must cost-effectively scale accordingly. In larger facilities, installation may happen at the same time on various wings or floors, yet the end system must seamlessly merge 🧩. Following are the scalability requirements.
5.2.1. Network Domain
The routing protocol MUST be able to support networks with at least 2,000 nodes, where 1,000 nodes act as routers and the other 1,000 nodes act as hosts 📈. Subnetworks (e.g., rooms, primary equipment) within the network must support up to 255 sensors and/or actuators.
5.2.2. Peer-to-Peer Communication
The data domain for commercial BMSs can sprawl across a vast portion of the physical domain 🌐. For example, a chiller may reside in the facility's basement because of its size, yet the associated cooling towers reside on the roof 🏔️. The cold-water supply and return pipes snake through all of the floors in between. The feedback control loops for these systems require data from across the facility, so the network has to be able to handle it.
A network device MUST be able to communicate in an end-to-end manner with any other device on the network. Thus, the routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain 🗺️.
5.3. Mobility
Most devices are affixed to walls or installed on ceilings within buildings, so the mobility requirements for commercial buildings are few 🧱. However, in wireless environments, location tracking of occupants and assets is gaining favor. Asset-tracking applications, such as tracking capital equipment (e.g., wheelchairs) in medical facilities, require monitoring movement with a granularity of a minute 🦽. Tracking babies in a pediatric ward, though, would require latencies of less than a few seconds 👶. Yikes, high stakes.
The following subsections document the mobility requirements in the routing layer for mobile devices. Note, however, that mobility can be implemented at various layers of the system, and the specific requirements depend on the chosen layer 🧠. For instance, some devices may not depend on a static IP address and are capable of re-establishing application-level communications when given a new IP address. Alternatively, mobile IP may be used, or the set of routers in a building may give the impression of a building-wide network and allow devices to keep their addresses no matter where they are, handling routing between the devices in the background 🪄.
5.3.1. Mobile Device Requirements
To minimize network dynamics, mobile devices while in motion should not be allowed to act as forwarding devices (routers) for other devices in the LLN 🚶♀️. Network configuration should allow devices to be configured as routers or hosts.
5.3.1.1. Device Mobility within the LLN
An LLN typically spans a single floor in a commercial building 🏬. Mobile devices may move within this LLN. For example, a wheelchair may be moved from one room on the floor to another room on the same floor 🛞.
A mobile LLN device that moves within the confines of the same LLN SHOULD re-establish end-to-end communication with a fixed device also in the LLN within 5 seconds after it ceases movement. The LLN network convergence time should be less than 10 seconds once the mobile device stops moving ⏱️.
5.3.1.2. Device Mobility across LLNs
A mobile device may move across LLNs, such as a wheelchair being moved to a different floor 🛗.
A mobile device that moves outside of its original LLN SHOULD re-establish end-to-end communication with a fixed device also in the new LLN within 10 seconds after the mobile device ceases movement. The network convergence time should be less than 20 seconds once the mobile device stops moving 🫠.
5.4. Resource Constrained Devices
Sensing and actuator devices may have processing power and memory that are 4 orders of magnitude less (i.e., 10,000x) than many more traditional client devices on an IP network 🐣. The routing mechanisms must therefore be tailored to fit these resource-constrained devices. Small but mighty, honestly 🦋.
5.4.1. Limited Memory Footprint on Host Devices
The software size requirement for non-routing devices (e.g., sleeping sensors and actuators) SHOULD be implementable in 8-bit devices with no more than 128 KB of memory 💜.
5.4.2. Limited Processing Power for Routers
The software size requirements for routing devices (e.g., room controllers) SHOULD be implementable in 8-bit devices with no more than 256 KB of flash memory 🌸.
5.4.3. Sleeping Devices 💤
Okay so sensing devices run on batteries or energy harvesting, and they spend most of their time snoozing so their power use stays in a modest budget 🔋✨. The routing protocol MUST take into account device characteristics such as power budget. Bestie, that's giving "plan your energy or get dropped" 💅
Here's the vibe check: a sensor battery (2,000 mAh) needs to last at least 5 years while it sends its data (200 octets) once per minute over a low-power transceiver (25 mA) and waits for an application acknowledgment 😭. The sending device has to keep its receiver in a high-powered state while it waits for the application ACK to come back. So to keep that wait short, we need a highly efficient routing protocol that minimizes hops, and hence end-to-end communication, is required 🏃♀️. The routing protocol MUST take into account node properties, such as "low-powered node", that produce efficient low-latency routes that minimize radio "on" time for these devices 🌸.
Sleeping devices MUST be able to receive inbound data 🧚. Messages sent to battery-powered nodes MUST be buffered by the last-hop router for a period of at least 20 seconds when the destination node is currently in its sleep cycle. The last-hop router holds the message so the sleepy device doesn't miss it 🫶.
5.5. Addressing 📬
Building management systems need different communication schemes to ask for or post network information 🏢. Multicasts or anycasts need to be used to figure out unresolved references within a device when the device first joins the network 🔍.
As with any network communication, multicasting should be minimized 🙈. This is especially a problem for small embedded devices with limited network bandwidth. Multicasts are typically used for network joins and application binding in embedded systems. Routing MUST support anycast, unicast, and multicast 💜.
5.6. Manageability 🛠️
As previously noted in Section 3.3, installing LLN devices within a BMS follows an "outside-in" workflow 🧩. Edge devices get installed first and tested for communication and application integrity. Then they get grouped into islands, then LLNs, and later attached to the enterprise network. Main character installation energy 👑
Diagnostics are most needed during the installation and commissioning phase, though sometimes diagnostic info gets requested during normal operation 🔧. Battery-powered wireless devices typically have a self-diagnostic mode that you can start with a button press. When you press the button, the device displays its link status and/or end-to-end connectivity 💡. Line-powered devices continuously show communication status with a bank of LEDs, possibly indicating signal strength and end-to-end application connectivity ✨.
The local diagnostics above are often good for room-level networks. But as these devices aggregate, system-level diagnostics may need to run to ease route vacillation, excessive hops, communication retries, and/or network bottlenecks 🚦.
In operational networks, the LLN devices are temporally monitored by the higher layers, because the application is mission-critical and communication integrity has to hold 🚨. If that communication fails, an alarm gets forwarded to the enterprise network from the monitoring node for analysis and remediation. Iykyk, this is serious business 😭.
Beyond the initial installation and commissioning, ongoing maintenance has to be simple and inexpensive too 💖. That means a straightforward device swap when a failed device is replaced, as noted in Section 5.1.3 🔁.
5.6.1. Diagnostics 🩺
To improve diagnostics, the routing protocol SHOULD be able to be placed in and out of "verbose" mode 📝. Verbose mode is a temporary debugging mode that gives extra communication info, including at least the total number of routed packets sent and received, the number of routing failures (no route available), neighbor table members, and routing table entries. The data in verbose mode should be enough to build and maintain a network connection graph at the monitoring node 🕸️.
Diagnostic data should be kept by the routers continuously and be available for solicitation at any time by any other node on the internetwork 📊. Verbose mode gets activated and deactivated via unicast, multicast, or other means. Devices with spare resources may choose to support verbose mode all the time 🌈.
5.6.2. Route Tracking 🗺️
Route diagnostics SHOULD be supported, giving info like route quality, number of hops, and available alternate active routes with their costs 💅. Route quality is the relative measure of "goodness" of the chosen source-to-destination route compared to alternate routes ⭐. This composite value may be measured as a function of hop count, signal strength, available power, existing active routes, or any other criteria that ROLL decides is the route cost differentiator 🎀.
5.7. Route Selection 🛣️
Route selection decides how reliable and high-quality the communication between devices is, by optimizing routes over time and sorting out any messiness from system startup, when nodes are joining the network at different times 🌀.
5.7.1. Route Cost 💸
The routing protocol MUST support a metric of route quality and optimize selection according to such metrics within constraints established for links along the routes 📈. These metrics SHOULD reflect things like signal strength, available bandwidth, hop count, energy availability, and communication error rates 🔋.
5.7.2. Route Adaptation 🦋
Communication routes MUST be adaptive and converge toward optimality of the chosen metric (e.g., signal quality, hop count) over time ✨.
5.7.3. Route Redundancy 🛟
The routing layer SHOULD be configurable so that secondary and tertiary routes can be set up and used if the primary route fails 🫶.
5.7.4. Route Discovery Time ⏱️
Mission-critical commercial applications (e.g., fire, security) need reliable communication and guaranteed end-to-end delivery of all messages in a timely way 🚒. Application-layer time-outs must be picked carefully, so they cover weird conditions like lost packets and/or route discoveries, but aren't set so large that they over-damp the network response 🙈. If route discovery happens during packet transmission time (reactive routing), it SHOULD NOT add more than 120 ms of latency to the packet delivery time ⚡.
5.7.5. Route Preference 🎯
The routing protocol SHOULD allow support for manually configured static preferred routes 🗝️.
5.7.6. Real-Time Performance Measures ⏰
A node sending a "request with expected reply" to another node must send the message to the destination and receive the response in not more than 120 ms. This response time should be achievable with 5 or fewer hops in each direction. This requirement assumes network quiescence and a negligible turnaround time at the destination node 🌙.
5.7.7. Prioritized Routing 👑
Network and application packet routing prioritization must be supported, so that mission-critical applications (e.g., fire detection) can't be deferred while less critical applications access the network 🚨. The routing protocol MUST be able to provide routes with different characteristics, also called Quality of Service (QoS) routing 💖.
5.8. Security Requirements 🔐
This section lays out specific requirements for any protocols developed or used in the ROLL building environment, so they get adequate security and keep suitable flexibility of use and function 🛡️.
Because there are so many kinds of buildings and tenants, BMSs must be completely configurable on-site 🏗️.
Because of the sheer number of BMS devices (thousands) and how hard they are to reach (often above ceilings), security configuration over the network is preferred over local configuration 🪜.
Wireless encryption and device authentication security policies need to be considered in commercial buildings. That has to be balanced against the limited processing capabilities and the extra latency on sensors, actuators, and controllers ⚖️.
BMSs are usually highly configurable in the field, so the security policy is mostly decided by the type of building the BMS goes into 🏠. Single-tenant owner-occupied office buildings installing lighting or HVAC control are candidates for a low level of security on the LLN, especially when the LLN isn't connected to an external network 💡. On the flip side, military or pharmaceutical facilities need strong security policies 🔒. As noted in the installation procedures in Sections 3.3 and 5.2, security policies MUST support dynamic configuration. That allows a low level of security during the installation phase (before building occupancy, when it may be fine to use only diagnostic levels of security), yet makes it possible to easily raise the security level network-wide during the commissioning phase of the system 📶.
5.8.1. Building Security Use Case 🏢
LLNs for commercial building applications should always implement and use encrypted packets 🔐. However, depending on the state of the LLN, the security keys may be:
- a key obtained from a trust center already operable on the LLN;
- a pre-shared static key as defined by the general contractor or its designee; or
- a well-known default static key.
Unless a node entering the network had previously received its credentials from the trust center, the entering node will try to ask the trust center for the network key. If the trust center is accessible, it will MAC-authenticate the entering node and return the security keys 🤝. If the trust center isn't available, the entering node checks whether it has been given a network key by an off-band means, and uses it to access the network 🕵️. If no network key has been configured in the device, it reverts to the default network key and enters the network. If neither of these keys is valid, the device signals via a fault LED 🚨.
This approach allows for simplified, independent commissioning with centralized authentication 🧁. The building owner or building type then decides when the trust center gets deployed. In many cases, the trust center doesn't need to be deployed until all of the local room commissioning is complete. But if the owner wants, the trust center can be deployed from the start, trading installation and commissioning flexibility for tighter security 💜.
5.8.2. Authentication 🪪
Authentication SHOULD be optional on the LLN 🫧. Authentication SHOULD be fully configurable on-site. Authentication policy and updates MUST be routable over-the-air 📡. Authentication SHOULD occur upon joining or rejoining a network. However, once authenticated, devices SHOULD NOT need to reauthenticate with any other devices in the LLN. Packets may need authentication at the source and destination nodes, but packets routed through intermediate hops should not need reauthentication at each hop 🔁.
These requirements mean that at least one LLN routing protocol solution specification MUST include support for authentication 💅.
5.8.3. Encryption 🔒
5.8.3.1. Encryption Types ✨
Okay bestie, data encryption of packets MUST be supported by all protocol solution specifications 🔐. Support can come from a network-wide key and/or an application key 🗝️. The network key would apply to all devices in the LLN, and the application key would apply to a subset of devices in the LLN 💖.
The network key and application key would be mutually exclusive 🌸. The routing protocol MUST allow routing a packet encrypted with an application key through forwarding devices without requiring each node in the route to have the application key 🦋. So the middle devices can pass the packet along without needing the key, and that's iconic 💅.
5.8.3.2. Packet Encryption 🎀
The encryption policy MUST support either encryption of the payload only or encryption of the entire packet 🧚. Payload-only encryption would eliminate the decryption/re-encryption overhead at every hop, which means more real-time performance ⚡. Literally the speed version 😭✨.
5.8.4. Disparate Security Policies 🌈
Okay, so LLNs are super limited on resources, right? 🥺 That means the security policy inside the LLN MUST be able to differ from the policy of the rest of the IP network in the facility 💜. BUT packets MUST still be able to route to or through the LLN from or to those networks 🛣️. Different rules inside, still connected outside. Main character energy 👑.
5.8.5. Routing Security Policies to Sleeping Devices 💤
The routing protocol MUST gracefully handle routing temporal security updates (e.g., dynamic keys) to sleeping devices on their "awake" cycle 🌙. This makes sure sleeping devices can readily and efficiently access the network, so they're not left out of the party 🎉.
6. Security Considerations 🛡️
The requirements placed on the LLN routing protocol in order to provide the correct level of security support are presented in Section 5.8 💅.
LLNs deployed in a building environment may be entirely isolated from other networks 🏢. They might also be attached to normal IP networks within the building yet physically disjoint from the wider Internet, or connected either directly or through other IP networks to the Internet 🌐. Even where no wired connectivity exists outside of the building, the use of wireless infrastructure within the building means that physical connectivity to the LLN is possible for an attacker 😭. Not me imagining an attacker just strolling up to the wireless 💀.
Therefore, it is important that any routing protocol solution designed to meet the requirements included in this document addresses the security features requirements described in Section 5.8 🔥. Implementations of these protocols will be required in the protocol specifications to provide the level of support indicated in Section 5.8 🎀. They will also be encouraged to make the support flexibly configurable, so an operator can make a judgment of the level of security they want to deploy at any time 🦋.
As noted in Section 5.8, use and deployment of the different security features is intended to be optional 🌸. This means that, although the protocols developed must conform to the requirements specified, the operator is free to determine the level of risk and the trade-offs against performance 💜. An implementation must not make those choices on behalf of the operator by avoiding implementing any mandatory-to-implement security features 🚫. Don't you dare take the decision away from the operator, bestie 😤.
This informational requirements specification introduces no new security concerns ✨.
7. Acknowledgments 🫶
Huge thanks to the authors, plus JP. Vasseur, David Culler, Ted Humpal, and Zach Shelby, who are gratefully acknowledged for their contributions to this document 💖.
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.8.2. Informative References
[ROLL-TERM] Vasseur, JP., "Terminology in Low power And Lossy
Networks", Work in Progress, March 2010.Appendix A. Additional Building Requirements 🏗️
Appendix A contains additional building requirements that were deemed out of scope for ROLL, yet provided ancillary substance for the reader 🧠. Extra tea, but make it useful 🍵.
A.1. Additional Commercial Product Requirements 🛍️
A.1.1. Wired and Wireless Implementations 🔌
Vendors will likely not develop a separate product line for both wired and wireless networks 🙄. Hence, the solutions set forth must support both wired and wireless implementations ✨. One product line, both vibes 💅.
A.1.2. World-Wide Applicability 🌍
Wireless devices must be supportable unlicensed bands 📻.
A.2. Additional Installation and Commissioning Requirements 🔧
A.2.1. Unavailability of an IP Network 🕳️
Product commissioning must be performed by an application engineer prior to the installation of the IP network (e.g., switches, routers, DHCP, DNS) 🛠️. So the engineer gets there first, then the network shows up 💅.
A.3. Additional Network Requirements 🕸️
A.3.1. TCP/UDP 🔁
Connection-based and connectionless services must be supported 🦋.
A.3.2. Interference Mitigation 📡
The network must automatically detect interference and seamlessly switch the channel to improve communication 🪄. Channel changes, and the nodes' responses to a given channel change, must occur within 60 seconds ⏱️. Quick, smooth, no drama 💖.
A.3.3. Packet Reliability 📦
In building automation, it is required that the network meet the following minimum criteria 💯:
<1% MAC-layer errors on all messages, after no more than three
retries;
<0.1% network-layer errors on all messages, after no more than three
additional retries;
<0.01% application-layer errors on all messages.Therefore, application-layer messages will fail no more than once every 100,000 messages 🥇. That's a very good track record, honestly iconic ✨.
A.3.4. Merging Commissioned Islands 🏝️
Subsystems are commissioned by various vendors at various times during building construction 🧱. These subnetworks must seamlessly merge into networks, and networks must seamlessly merge into internetworks, since the end user wants a holistic view of the system 🌸. Everything blending together like a perfect playlist 🎶.
A.3.5. Adjustable Routing Table Sizes 📒
The routing protocol must allow constrained nodes to hold an abbreviated set of routes 🤏. That is, the protocol should not mandate that the node routing tables be exhaustive 🙅♀️. Small tables are fine, bestie 💜.
A.3.6. Automatic Gain Control 📶
For wireless implementations, the device radios should incorporate automatic transmit power regulation to maximize packet transfer and minimize network interference, regardless of network size or density 🎚️. Balanced and efficient, no matter the crowd 🫧.
A.3.7. Device and Network Integrity 🩺
Commercial-building devices must all be periodically scanned to assure that each device is viable and can communicate data and alarm information as needed 🔍. Routers should maintain previous packet flow information temporally to minimize overall network overhead 🧾. Checking in on everyone, every single time 💖.
A.4. Additional Performance Requirements 🏎️
A.4.1. Data Rate Performance 📈
An effective data rate of 20 kbit/s is the lowest acceptable operational data rate on the network 📉. Anything slower is giving NO 🙅♀️.
A.4.2. Firmware Upgrades ⬆️
To support high-speed code downloads, routing should support transports that provide parallel downloads to targeted devices, yet guarantee packet delivery 🚀. In cases where the spatial position of the devices requires multiple hops, the algorithm should recurse through the network until all targeted devices have been serviced 🔁. Devices receiving a download may cease normal operation, but upon completion of the download must automatically resume normal operation 🔄. Back online, slay 💅.
A.4.3. Route Persistence 🧭
To eliminate high network traffic in power-fail or brown-out conditions, previously established routes should be remembered and invoked prior to establishing new routes for those devices re-entering the network 🌈. Remember where you were and go back there first, iykyk 🫶.
Authors' Addresses 💌
Jerry Martocci
Johnson Controls Inc.
507 E. Michigan Street
Milwaukee, WI 53202
USA
Phone: +1 414 524 4010
EMail: jerald.p.martocci@jci.com
Pieter De Mil
Ghent University - IBCN
G. Crommenlaan 8 bus 201
Ghent 9050
Belgium
Phone: +32 9331 4981
Fax: +32 9331 4899
EMail: pieter.demil@intec.ugent.be
Nicolas Riou
Schneider Electric
Technopole 38TEC T3
37 quai Paul Louis Merlin
38050 Grenoble Cedex 9
France
Phone: +33 4 76 57 66 15
EMail: nicolas.riou@fr.schneider-electric.com
Wouter Vermeylen
Arts Centre Vooruit
Ghent 9000
Belgium
EMail: wouter@vooruit.beThat's the whole thing, bestie 🌈🦋👑 RFC 5867 is officially served, and the requirements are all intact 💖✨
📦 where this page comes from
- ietf: rfc5867 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms