RFC 7548

Management of Networks with Constrained Devices: Use Cases

📅 published May 2015, from ietf

RFC 7548: Management of Networks with Constrained Devices: Use Cases 💖

Okay bestie, here's the title-block tea 🫖 It's an Informational doc (not Standards Track), published May 2015, with ISSN 2070-1721. The authors are M. Ersue, Ed. (Nokia Networks), D. Romascanu (Avaya), and J. Schoenwaelder and A. Sehgal (Jacobs University Bremen) 🌸 The block doesn't list anything it obsoletes or updates 🙈

Abstract ✨

This doc talks through use cases for managing networks that have constrained devices in them 🦋 The problem statement, deployment options, and requirements for those networks live in the companion doc "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547) 📚

Status of This Memo 🌷

This doc is not an Internet Standards Track spec. It's published for informational purposes 🧚

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🔍

For the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7548 💌

Copyright (c) 2015 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 in effect on the publication date. Please actually read these, because they spell out your rights and restrictions 🧾 Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅

Table of Contents 📖

   1. Introduction ....................................................3
   2. Access Technologies .............................................4
      2.1. Constrained Access Technologies ............................4
      2.2. Cellular Access Technologies ...............................5
   3. Device Life Cycle ...............................................6
      3.1. Manufacturing and Initial Testing ..........................6
      3.2. Installation and Configuration .............................6
      3.3. Operation and Maintenance ..................................7
      3.4. Recommissioning and Decommissioning ........................7
   4. Use Cases .......................................................8
      4.1. Environmental Monitoring ...................................8
      4.2. Infrastructure Monitoring ..................................9
      4.3. Industrial Applications ...................................10
      4.4. Energy Management .........................................12
      4.5. Medical Applications ......................................14
      4.6. Building Automation .......................................15
      4.7. Home Automation ...........................................17
      4.8. Transport Applications ....................................18
      4.9. Community Network Applications ............................20
      4.10. Field Operations .........................................22
   5. Security Considerations ........................................23
   6. Informative References .........................................24
   Acknowledgments ...................................................25
   Contributors ......................................................26
   Authors' Addresses ................................................26

1. Introduction ✨

Okay so picture this: constrained devices (aka sensors, smart objects, or smart devices) with limited CPU, memory, and power 🔋 can get connected to a network. That network of constrained devices can be constrained or challenged itself, like with unreliable or lossy channels, wireless tech with limited bandwidth and a dynamic topology, or the need for a gateway or proxy to reach the Internet 🫶 In other scenarios, the constrained devices can join an unconstrained network using off-the-shelf protocol stacks. These little guys might be gathering info in all kinds of settings, like natural ecosystems, buildings, and factories, and then sending it to one or more server stations 🌿

Network management is all about monitoring network status, detecting faults (and figuring out what caused them), setting network parameters, and doing stuff to remove faults, keep things running normally, and make the network and apps work better 📈 The traditional network management app periodically collects info from a set of managed network elements, processes the data, and shows the results to the network management users 📊 But constrained devices are lowkey a whole different vibe: they often have limited power, low transmission range, and might be unreliable 🥺 That unreliability can come from the device itself (like a battery that's totally exhausted 🪫) or from a constrained channel (low-capacity and high-latency). They might also need to work in hostile environments with serious security requirements, or run in harsh places for a long time with nobody checking on them 💀 So managing a network with constrained devices comes with different challenges than managing a traditional IP network 🙈

This doc is all about understanding use cases for managing a network with constrained devices involved 🦋 It lists and discusses a bunch of use cases from both the network point of view and the application point of view. The list isn't exhaustive, since other scenarios (ones the authors don't even know about yet) are possible 🌈 The application scenarios aim to show where networks of constrained devices are expected to be deployed. For each one, we first briefly describe the characteristics, then talk about how network management can be provided, who's likely responsible for it, and which time-scale management operations are likely to happen 🗓️

The problem statement, deployment and management topology options, and requirements for networks with constrained devices can be found in the companion doc [RFC7547] 📚

This document builds on the terminology in [RFC7228] and [RFC7547]. [RFC7228] is the base doc for terminology about constrained devices and constrained networks 🧠 Some use cases specific to IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are in [RFC6568] 🎀

2. Access Technologies 🔌

Besides the management requirements that come from the different use cases, the access technologies used by constrained devices can put restrictions and requirements on the Network Management System (NMS) and whichever protocol you choose 💅

Some networks of constrained devices might use traditional unconstrained access technologies, like local area networks with plenty of capacity 🌤️ In those cases, the constrainedness of the device creates the special management restrictions and requirements, not the access technology being used.

Other situations use constrained or cellular access technologies for network access, so the management restrictions and requirements come from those underlying access technologies 📶

This section discusses cellular and constrained access technologies because they impose some special requirements on managing constrained networks ✨ Fixed-line networks (like power-line communications) aren't covered here, since they tend to be quite static and don't usually impose any special management requirements 😴

2.1. Constrained Access Technologies 📡

Because of resource restrictions, embedded devices deployed as sensors and actuators in the various use cases use low-power, low-data-rate wireless access technologies for network connectivity, such as [IEEE802.15.4], Digital Enhanced Cordless Telecommunication (DECT) Ultra Low Energy (ULE), or Bluetooth Low-Energy (BT-LE) 🔋

In these scenarios, it's important for the NMS to know the restrictions these access technologies impose, so it can manage the constrained devices efficiently 🧠 Specifically, low-power, low-data-rate access technologies typically have small frame sizes. So it matters that the NMS and the management protocol craft packets in a way that avoids fragmentation and reassembly, since those can eat up valuable memory on constrained devices 🫠

Devices using these access technologies might operate through a gateway that translates between them and more traditional Internet protocols 🌉 A hierarchical approach to device management can be useful here: the gateway is in charge of the devices connected to it, while the NMS only conducts management operations toward the gateway 👑

2.2. Cellular Access Technologies 📶

okay so machine-to-machine (M2M) services are literally everywhere now 💖 mobile service providers are offering them because so many devices are getting connected with mobile broadband, like numerous devices, home appliances, utility meters, cars, video surveillance cameras, and health monitors 😭🫶 different applications, like a home appliance or an in-car network, use Bluetooth, Wi-Fi, or ZigBee locally, and then they connect to a cellular module that acts as a gateway between the constrained environment and the mobile cellular network. it's giving bridge energy 🌉✨

a gateway like that can offer different options for connecting mobile networks and constrained devices, and they're all so iconic:

  • a smartphone with 3G/4G and WLAN radio might use BT-LE to connect to the devices in a home area network 📱🏠
  • a femtocell might be combined with home gateway functionality, acting as a low-power cellular base station that connects smart devices to the application server of a mobile service provider 🗼💜
  • an embedded cellular module with LTE radio connecting the devices in the car network with the server running the telematics service 🚗🌈
  • an M2M gateway connected to the mobile operator network, supporting diverse Internet of Things (IoT) connectivity technologies including ZigBee and Constrained Application Protocol (CoAP) over 6LoWPAN over IEEE 802.15.4 🧚⭐

the thing all of these scenarios have in common is that they're embedded in a service and connected to a network provided by a mobile service provider 💅 usually there's a hierarchical deployment and management topology in place, where different parts of the network are managed by different management entities, and the count of devices to manage is high (like many thousands!!) 😳🍓 in general the network is made up of manifold types and sizes of devices matching different device classes, so the managing entity needs to be prepared to manage devices with diverse capabilities using different communication or management protocols. no pressure, right? 🙈

when the devices are directly connected to a gateway, they most likely get managed by a management entity integrated with the gateway, which itself is part of the NMS run by the mobile operator 🫶 smartphones or embedded modules connected to a gateway might be in charge of managing the devices on their own level too. and the initial and subsequent configuration of such a device is mainly based on self-configuration and is triggered by the device itself. the device handles its own glow-up, periodt 💖✨

last but not least, the gateway might be in charge of filtering and aggregating the data received from the device, since the information sent by the device might be mostly redundant 🧹💜

3. Device Life Cycle 🔄

okay so constrained devices deployed in a network might go through multiple phases in their lifetime, which means it's possible for different managers of networks and/or devices to exist during different parts of the device lifetimes 🦋 if you want the deep dive on the possible device life cycles, it's in [IOT-SEC] 📚🎀

3.1. Manufacturing and Initial Testing 🏭

typically, the life cycle of a device begins at the manufacturing stage 🌸 during this phase, the manufacturer of the device is responsible for the management and configuration of the devices. it's also possible that one use case uses multiple types of constrained devices (like temperature sensors, lighting controllers, etc.), and these could be manufactured by different entities. so during the manufacturing stage, different managers can exist for different devices 👑 same energy during the initial testing phase, where device quality-assurance tasks might be performed. the manufacturer remains responsible for managing those devices and the networks that might comprise them 💅

3.2. Installation and Configuration 🔧

the responsibility of managing the devices must be transferred to the installer during the installation phase 🎀 there must exist procedures for transferring management responsibility between the manufacturer and the installer. the installer may be the customer or an intermediary contracted to set up the devices and their networks. it's important that the NMS in use lets devices from different vendors be managed, so they can interoperate, and it also has to support configuring trust relationships between them 🫶🔐

it's possible that the installation and configuration responsibilities lie with different entities too. like, the installer of a device might only be responsible for cabling a network, physically installing the devices, and making sure they have initial network connectivity (for example, configuring IP addresses) 🧵 after that, the customer or a subcontractor might actually configure how the device operates. so during installation and configuration, multiple parties might be responsible for managing one device, and appropriate methods must be available to make sure that management responsibility gets handed off properly 🤝✨

3.3. Operation and Maintenance 🛠️

at the start of the operation phase, operational responsibility for a device and network should be passed on to the customer 💜 the customer might, however, contract the maintenance of the devices and network out to a subcontractor. if that happens, the NMS and management protocol should allow for configuring different levels of access to the devices. and since different maintenance vendors might be used for devices that do different jobs (like HVAC, lighting, etc.), it should also be possible to restrict management access to devices based on whoever is currently responsible as the manager 🔒🌈

3.4. Recommissioning and Decommissioning ♻️

the owner of a device might choose to replace it, repurpose it, or even decommission it 🦋 in each of these cases, either the customer or the contracted maintenance agency must make sure appropriate steps are taken to meet the end goal ✨

if the device needs to be replaced, the manager of the network (the customer or the responsible contractor) must detach the device from the network, remove all the appropriate configuration, and discard the device 🗑️ then a new device must be configured to take its place. the NMS should allow for transferring the configuration and replacing an existing device 💖 the management responsibility of the operation/maintenance manager ends once the device is removed from the network. and during the installation of the new replacement device, the same responsibilities apply as during the Installation and Configuration phases 🔁

the device being replaced may not have reached end-of-life yet, so instead of being discarded, it may be installed in a new location 🌍 in this case, the management responsibilities are once again in the hands of the entities responsible for the Installation and Configuration phases at the new location 🫶

if a device is repurposed, the management responsibility for that device might change too 🎀 for example, a device might be moved from one building to another. in this case, the managers responsible for devices and networks in each building could be different. so the NMS must not only allow for changing configuration, but also for transferring management responsibilities 🚨💅

and in case a device is decommissioned, the management responsibility typically ends at that point 🕊️

4. Use Cases 🌍

4.1. Environmental Monitoring 🌿

environmental monitoring apps are all about deploying a bunch of sensors to monitor emissions, water quality, or even the movements and habits of wildlife 🐻🦋 other apps in this category include earthquake or tsunami early-warning systems 🌊 these sensors often span a large geographic area, they can be mobile, and they're often difficult to replace. and honestly? the sensors are usually not protected against tampering, which is a whole vibe 😳

management of environmental-monitoring apps is mostly about checking whether the system is still functional, and about rolling out new constrained devices in case the system loses too much of its structure 🧚 the constrained devices themselves need to be able to establish connectivity (autoconfiguration), and they need to be able to handle events like losing neighbors or being moved to other locations. resilient bestie behavior 💪✨

management responsibility typically rests with the organization running the environmental-monitoring application 👑 since these monitoring apps must be designed to tolerate a number of failures, the time scale for detecting and recording failures is, for some of these apps, likely measured in hours, and repairs might easily take days 🕰️ in fact, in some scenarios it might be more cost- and time-effective not to repair such devices at all 🤷‍♀️ however, for certain environmental monitoring apps, much tighter time scales may exist, and they might be enforced by regulations (for example, monitoring of nuclear radiation) ☢️⚠️

since a lot of environmental-monitoring sensors are likely to be in areas that matter for safety (flood monitoring, nuclear radiation monitoring, etc.), it is important for management protocols and NMSs to ensure appropriate security protections 🚨🔐 these protections include not only access control, integrity, and availability of data, but also mechanisms that can deal with situations that might be categorized as emergencies, or when tampering with sensors/data might be detected. this part is seriously not optional, bestie 💀💜

4.2. Infrastructure Monitoring ✨

Okay so infrastructure monitoring is all about keeping an eye on things like bridges, railway tracks, and (offshore) windmills 🌉🚂💖 The main goal is usually to catch any events or changes in the structural conditions that could mess with the risk and safety of whatever's being watched. Another secondary goal is to schedule repairs and maintenance in a cost-effective way, bestie, because nobody wants to overspend 💅

The infrastructure might be sitting in a factory, or spread out over a wider area that's kinda hard to get to 🗺️ So the network could be a mix of fixed and wireless tech, using sturdy networking gear and supporting reliable communication through application-layer transactions. Literally so reliable 🫶 Constrained devices in a setup like this are most likely C2 devices [RFC7228] and they have to be controlled centrally by an application running on a server, no cap 👑

If the distributed network is spread really wide, the wireless devices might use long-distance wireless techs like Worldwide Interoperability for Microwave Access (WiMAX) or 3G/LTE 📡 When there's an in-building network involved, it can be built on Ethernet or wireless techs that work well indoors 🏢 Iconic.

Managing infrastructure monitoring apps is mainly about making sure the system is functioning properly 🔍 The devices usually get rolled out and installed by dedicated experts, and updates are rare because the infrastructure itself doesn't change much 🦋 BUT, and this is a big but 🙈, monitoring devices are often deployed in unsupervised environments, so special attention MUST be given to protecting the devices from being modified. Not me being dramatic, but this is literally a must-have 😭

Management responsibility typically sits with the organization that owns the infrastructure or is responsible for running it 💼 The time scale for detecting and recording failures is likely measured in hours, and repairs might easily take days 🍓 However, certain events (like natural disasters) may require status information to be obtained much more quickly, and replacements of failed sensors may need to be rolled out fast (or redundant sensors activated quickly) 🚨 If the devices are hard to access, a self-healing feature on the device might become necessary 🩹 And since infrastructure monitoring is closely tied to safety, management protocols and systems MUST provide appropriate security protections to ensure confidentiality, integrity, and availability of data. Main character energy for security, periodt 🔐💜

4.3. Industrial Applications 🏭

Industrial applications and smart manufacturing are all about tasks like networked control and monitoring of manufacturing equipment, asset and situation management, or manufacturing process control ⚙️ Honestly, factories NEED smart capabilities now 💅 From an engineering standpoint, industrial apps are intelligent systems that enable rapid manufacturing of new products, dynamic response to product demand, and real-time optimization of manufacturing production and supply-chain networks 🔥 Some potential industrial applications (for smart factories and smart manufacturing) are:

  • Digital control systems with embedded, automated process controls, operator tools, and service information systems that optimize plant operations and safety 🎀
  • Asset management using predictive maintenance tools, statistical evaluation, and measurements that maximize plant reliability 🧚
  • Smart sensors that detect anomalies to avoid abnormal or catastrophic events 🌈
  • Smart systems integrated within the industrial energy-management system and externally with the smart grid, enabling real-time energy optimization ⭐

Management of industrial apps and smart manufacturing may, in some situations, involve Building Automation tasks like controlling energy, HVAC, lighting, or access control 💡 Interacting with management systems from other application areas can be super important in some cases (for example, environmental monitoring for electric energy production, energy management for dynamically scaling manufacturing, or vehicular networks for mobile asset tracking) 🚗 Managing constrained devices and networks isn't just about their network connectivity, bestie 🫣 Since constrained devices have limited capabilities, a management system might even need to configure, monitor, and operate the primary functions the constrained device is used for, on top of managing its network connectivity 🧠

Sensor networks are an essential tech for smart manufacturing 📶 Measurements, automated controls, plant optimization, health and safety management, and other functions are provided by a large number of networked sectors. Data interoperability and seamless exchange of product, process, and project data are enabled through interoperable data systems used by collaborating divisions or business systems 🤝 Intelligent automation and learning systems are vital to smart manufacturing, but they MUST be effectively integrated with the decision environment 🧩 The NMS being used MUST ensure timely delivery of sensor data to the control unit so it can make appropriate decisions 📬 Similarly, relaying commands MUST also be monitored and managed to ensure optimal functioning 👀 Wireless sensor networks (WSNs) have been developed for machinery Condition-based Maintenance (CBM) because they offer significant cost savings and enable new functionalities 💰 Inaccessible locations, rotating machinery, hazardous areas, and mobile assets can all be reached with wireless sensors 🛰️ Today, WSNs can provide wireless link reliability, real-time capabilities, and quality of service, and they can enable industrial and related wireless sense-and-control applications ✨

Management of industrial and factory applications is largely focused on monitoring whether the system is still functional, real-time continuous performance monitoring, and optimization as needed 📊 The factory network might be part of a campus network or connected to the Internet 🌐 Constrained devices in such a network need to be able to establish configuration themselves (autoconfiguration) and might need to handle error conditions as much as possible locally 🛠️ Access control has to be provided with multi-level administrative access and security 🔑 Support and diagnostics can be provided through remote monitoring access centralized outside of the factory 📞

Factory-automation tasks require continuous monitoring to optimize production 🏗️ Groups of manufacturing and monitoring devices could be defined to establish relationships between them 🧵 To ensure timely optimization of processes, commands from the NMS MUST arrive at all destinations within an appropriate duration ⏱️ This duration could change based on the manufacturing task being performed 🔄 Installation and operation of factory networks have different requirements 📋 During the installation phase, many networks (usually distributed along different parts of the factory or assembly line) coexist without a connection to a common backbone 🧱 A specialized installation tool is typically used to configure the functions of different types of devices, in different factory locations, in a secure manner 🔧 At the end of the installation phase, interoperability between these stand-alone networks and devices MUST be enabled 🔗 During the operation phase, these stand-alone networks are connected to a common backbone so they can retrieve control information from and send commands to appropriate devices 📡

Management responsibility is typically owned by the organization running the industrial application 🏢 Since monitoring applications must handle a potentially large number of failures, the time scale for detecting and recording failures is, for some of these applications, likely measured in minutes ⏰ However, for certain industrial applications, much tighter time scales may exist (for example, real time), which might be enforced by the manufacturing process or the use of critical material 🚦 Management protocols and NMSs MUST ensure appropriate access control, since different users of industrial control systems will have varying levels of permissions 🪪 For example, while supervisors might be allowed to change production parameters, they SHOULD NOT be allowed to modify the functional configuration of devices the way a technician should 🙅‍♀️ It is also important to ensure integrity and availability of data, since malfunctions can potentially become safety issues 🦺 This also implies that management systems MUST be able to react to situations that may pose dangers to worker safety 🚑 Stay safe out there, bestie 💜

4.4. Energy Management ⚡

Okay bestie, so the EMAN working group came up with an energy-management framework [RFC7326] for devices and device components that are inside or connected to communication networks 💡. The big challenge here is that one network handles the power distribution (who gets the electricity), while a separate communication network is usually what monitors and controls that power distribution network 🔌. It's giving two-systems-that-need-to-talk-to-each-other energy 💀. Devices in energy management can be watched for things like power, energy, demand, and power quality 📊. If a device has batteries, those can be monitored and managed too 🔋.

Energy devices come in all kinds of complexity 🧚. You've got basic sensors or switches, specialized electrical meters, and power distribution units (PDU), plus subsystems inside network devices like routers and network switches, or inside home or industrial appliances 🏠. The operators of an energy-management system are either utility providers or customers who want to control and reduce energy consumption and the costs that come with it 💰. The topology changes depending on the deployment, and it can cover anything from small areas like individual homes to huge geographical areas 🗺️. The EMAN requirements document [RFC6988] goes into the requirements for energy management when it comes to monitoring and control functions 📝.

It's assumed that energy management will apply to a wide range of devices, of all classes and network topologies 🌈. Specific resource monitoring, like battery utilization and availability, may be specific to devices with lower physical resources (device classes C0 or C1 [RFC7228]) 🔋✨.

Energy management is especially relevant to the Smart Grid 💜. A Smart Grid is an electrical grid that uses data networks to gather and act on energy and power-related information in an automated way 🤖. The goal is to improve the efficiency, reliability, economics, and sustainability of electricity production and distribution ⚡🌱.

Smart Metering is a great example of an energy-management application based on the Smart Grid 🎀. Lots of different, possibly wireless, small meters together produce a huge amount of data 📈. That data gets collected by a central entity and processed by an application server, which might live inside the customer's residence or off site in a data center 🏢. The communication infrastructure can be provided by a mobile network operator, because meters in urban areas will most likely have a cellular or WiMAX radio 📡. If the application server is inside the residence, though, those meters are more likely to use Wi-Fi protocols to connect with an existing network 🛜.

An Advanced Metering Infrastructure (AMI) network is another Smart Grid example 🦋. It lets an electric utility retrieve frequent electric usage data from each electric meter installed at a customer's home or business ⏱️. Smart Metering is different, because there the customer or their agents install appliance-level meters 🙋‍♀️. An AMI is typically managed by the utility providers, and it could also include other distribution automation devices like transformers and reclosers 🔧. Meters in AMI networks usually contain constrained devices that connect to mesh networks over a low-bandwidth radio 🕸️. Usage data and outage notifications can be sent from these meters to the utility's headend systems, through aggregation points on higher-end router devices. Those routers bridge the constrained network to a less constrained network via cellular, WiMAX, or Ethernet 🌉. Unlike the meters, these higher-end devices might be installed on utility poles owned and operated by a separate entity 😮‍💨.

So it becomes important for a management application to do more than just work with diverse types of devices 👑. It also has to work across multiple links that might be operated and managed by separate entities, each with their own divergent policies for their devices and network segments 🧩. During management operations, like firmware updates, the management systems need to perform robustly 🛠️. This is so they avoid accidental outages of critical power systems that could be part of AMI networks 🚨. Since AMI networks must also report on outages, the management system might have to manage the energy properties of the battery-operated AMI devices themselves as well 🔋😭.

A management system for home-based Smart Metering solutions will probably have devices laid out in a simple topology 🏡. AMI network installations, though, could have thousands of nodes per router (the higher-end device), and those nodes organize themselves in an ad hoc manner 🌀. That means a management system for AMI networks will need to discover and operate over complex topologies too 🧠. In some situations, the management system might also have to set up and manage the topology of the nodes, especially the critical routers 🏗️. Encryption-key management and sharing in both types of networks are also likely to be important for providing confidentiality for all data traffic 🔐. In AMI networks, a meter may only obtain the key after an end-to-end authentication process based on certificates 📜. The Smart Metering solution could take a similar approach, or the security may be implied because the meters become part of encrypted Wi-Fi networks 🫶.

Managing a network like this requires end-to-end management and information exchange across different types of networks 🌐. But as of today, there's no integrated energy-management approach and no common information model available 🙅‍♀️. Specific energy-management applications and network islands just use their own management mechanisms 🏝️. It's a whole mess, periodt 💅.

4.5. Medical Applications 🩺

Constrained devices can be an enabling technology for advanced, and possibly remote, health-monitoring and emergency-notification systems 💖. That ranges from monitors for blood pressure and heart rate all the way up to advanced devices that can monitor implanted technologies, like pacemakers or advanced hearing aids 🫀✨. Medical sensors don't just attach to human bodies, either. They can also live in the infrastructure people use, like bathrooms or kitchens 🛁🍓. Medical applications are also used to make sure treatments are being applied properly, and they might guide people who are losing orientation 🧭. Fitness and wellness apps, like connected scales or wearable heart monitors, encourage people to exercise and let them self-monitor their key fitness indicators 🏃‍♀️💪. Different applications use Bluetooth, Wi-Fi, or ZigBee connections to reach the patient's smartphone, or a home cellular connection, to get onto the Internet 📶.

Constrained devices in medical applications are managed either by the users of those devices, or by an organization that provides medical (monitoring) services for physicians 👩‍⚕️. In the first case, management has to be automatic and/or easy to install and set up by laypeople 🙈. In the second case, it can be expected that devices will be controlled by specially trained people 🎓. Either way, it's crucial to protect the safety and privacy of the people who use medical devices 🛡️💜. Security precautions to protect access to these devices (authentication, encryption, integrity protections, and so on) may be critical to safeguarding the individual 🔒. The level of access granted to different users may also need to be regulated 🚦. For example, an authorized surgeon or doctor must be allowed to configure all the necessary options on the devices. A nurse or technician, however, may only be allowed to retrieve data that can help with diagnosis 🩺📋. Even if the data a heart monitor collects is protected, the pure fact that someone carries such a device may still need protection 🫣. So certain medical appliances may not want to take part in discovery and self-configuration protocols, so they can stay invisible 🥷✨.

Lots of medical devices are likely to be used, and relied upon, to provide data to physicians in critical situations, where the patient might not be able to report that data themselves 🚑. Timely delivery of data can be super important in certain applications, like patient-mobility monitoring in nursing homes 🏥. Data must reach the physician and/or emergency services within specified time limits to be useful ⏰. That's why fault detection of the communication network or the constrained devices becomes a crucial function of the management system 🚨. It has to be carried out with high reliability and, depending on the medical appliance and its application, within seconds ⚡💯.

4.6. Building Automation 🏢✨

okay so building automation is basically the team of distributed systems that keeps a building running: monitoring and controlling the mechanical, electrical, and electronic stuff inside. 💖 It's used everywhere, from public and private spaces to industrial sites, institutions, and homes. Advanced Building Automation Systems (BASs) can bring together safety, environmental control, occupancy, and security all in one place. The big trend right now is that all these functional systems plug into the same communication infrastructure, which might be IP-based, and that network can be wired or wireless inside the building. It's giving unified 🫶

Building automation needs a lot of devices, anywhere from 10 to 100,000 sensors that watch the status of equipment and conditions inside the building, plus controllers with different specialized jobs for certain areas or the whole building. 🌸 Neighboring nodes can sit anywhere from 1 to 20 meters apart. Because of that, the NMS must be able to manage and monitor a huge number of devices, and they might be organized into multi-hop meshed networks. The distances between nodes, plus the use of constrained protocols, means networks of nodes might get segmented, and the management system should still be able to handle those segments and the nodes inside them. 🧚

Here's the part I'm obsessed with: unlike home automation, building devices are managed assets. They're known to a set of commissioning tools and a data store, so every connected device has a known origin. 🍓 That means the management system has to discover the devices on the network and make sure the expected list still matches what's actually there. Management covers checking that the expected devices are present and spotting any unwanted ones showing up. Literally the ultimate guest list energy 💅

Controllers in building automation handle things like the air quality, humidity, and temperature inside, plus the lighting. ✨ Other systems report on machinery like elevators, or on room equipment like projectors in meeting rooms. Security cameras and sensors can be deployed and operated on separate dedicated infrastructures that still connect to the common backbone. A BAS usually covers one building (or part of one), or a bunch of buildings grouped together on a campus. 🏫 A building network can be split into segments, and each segment might cover a floor, an area on a floor, or a particular function like security cameras. Some devices might even have their management tasks separated from the rest. For example, security cameras might run and be managed on a network separate from the HVAC in a building. 🦋

Some BAS sensors, like fire alarms and security systems, register, record, and transfer critical alarm information, so they must be resilient to events like power loss or security attacks. 😭 The management system must be able to deal with unintentional network segmentation caused by power loss or channel unavailability, and it must also be able to detect security events. Certain devices operate under specific conditions, so there might be a need to certify components and subsystems that work in those constrained environments based on specific requirements. In some places, if a control system like temperature control malfunctions, that has to be reported in the shortest possible time. 🔥 Complex control systems can misbehave, so their critical status reporting and safety algorithms need to be basic and robust, and they need to keep working even in critical conditions. Providing this monitoring, configuration, and notification service is a major job for the management system used in building automation. 👑

Building automation can be deployed in newly designed buildings, or over existing infrastructure. 🎀 With new buildings there's a wider range of options, since the solution can be planned into the building's infrastructure from the start. With existing buildings, the solution has to fit into what's already there, which means dealing with existing wiring, distance limits, and radio signals getting blocked by walls and floors, and that can make deployment pretty tricky. Because of that, some existing WLAN solutions (like [IEEE802.11] or [IEEE802.15]) may be deployed. 💜 In mission-critical or security-sensitive environments, or anywhere links fail often, topologies that can reconfigure the network and keep connections continuous may be required. Some of the simple sensors in building automation may be very constrained devices for which C0 or C1 [RFC7228] may be assumed. 🌈

For lighting, groups of lights must be defined and managed, and commands sent to a group of lights must arrive within 200 ms at all destinations. ⭐ Installation and operation of a building network have different requirements. During installation, lots of stand-alone networks of a few to 100 nodes can coexist without being connected to the backbone. In this phase, each node is identified with a network identifier tied to its physical location, and devices are accessed from an installation tool so they can join the network securely. Setting common parameter values to enable interoperability may be required during installation. 🧁 During operation, the networks connect to the backbone, and the relationship between the network identifier and the physical location is kept. Network parameters like address and name are stored in the DNS, and those names can help figure out where a device physically is. 🗺️

A building automation NMS also has to take safety and security seriously. 🔐 Privacy and confidentiality of data is likely to be important, so unauthorized parties can't get access to it, since users' individual behaviors could potentially be figured out from their settings. Security considerations for authorization and access control to the NMS are also a big deal, because different users are likely to have different levels of operational permissions. For example, end users should be able to control lighting and HVAC systems, but only qualified technicians should be able to configure parameters that change how a device fundamentally operates. 🙈 Devices and the NMS also need to be able to detect and report any tampering, since tampering could lead to real user safety concerns. Imagine air quality sensors getting tampered with so carbon monoxide levels become life threatening. 💀 That means an NMS should also be able to deal with, and appropriately prioritize, situations that could potentially lead to safety concerns.

4.7. Home Automation 🏡🌸

Home automation covers controlling lighting, heating, ventilation, air conditioning, appliances, entertainment, and home security devices, all to boost convenience, comfort, energy efficiency, and safety. ✨ You can think of it as the residential version of building automation. The difference is that the infrastructure in a home is run in a way that's way more ad hoc. In some setups there's no centralized management system like a BAS, but in others, outsourced and cloud-based systems might be used to manage the devices in the home. ☁️

Home-automation networks need some configuration, like associating switches or sensors with actuators. 💅 That setup might be done by electricians deploying the solution, by third-party home-automation service providers (like small specialized companies or home-automation device manufacturers), or by residents using the application user interface on the devices to configure parts of the solution. Failures might be reported to residents through suitable interfaces, or they might get recorded and made available to the service providers in charge of maintaining the home-automation infrastructure. 🫶

Management responsibility either sits with the residents, or it's outsourced to electricians and/or third parties offering management of home-automation solutions as a service. 🦋 A mix of electricians, service providers, and residents may be responsible for different parts of managing the infrastructure. Time scales for failure detection and resolution are, in many cases, likely counted in hours to days. ⏳ So it's a whole team effort, bestie 🎀

4.8. Transport Applications ✨

okay bestie, so "transport application" is basically the umbrella term for smashing communications, control, and information processing together inside a transportation system 🚆 "Transport telematics" and "vehicle telematics" are both used to describe the whole family of tech that keeps transport systems running 💖 A transport application running on one of these systems covers every mode of transport and looks at every piece of the setup: the vehicle, the infrastructure, and the driver or user, all interacting with each other dynamically 🦋 Examples include inter- and intra-vehicular communication, smart traffic control, smart parking, electronic toll-collection systems, logistic and fleet management, vehicle control, and safety and roadside assistance 🎀

Now the distributed part is giving big "it's a whole network situation" energy 🌈 Transport applications need end-to-end management across different types of networks. It's likely that constrained devices in a network (like a moving in-car network) have to be controlled by an application running on an application server in a service provider's network 🧚 That kind of highly distributed setup, including cellular devices on vehicles, is assumed to include a wireless access network using a bunch of long-distance wireless technologies, such as WiMAX, 3G/LTE, or satellite communication, e.g., based on an embedded hardware module 📡 So the management of constrained devices in the transport system might be necessary to plan top-down, and it might need to use data models obliged from and defined on the application layer 💅 The assumed device classes in use are mainly C2 [RFC7228] devices. In some cases, where an in-vehicle network is involved, C1 devices [RFC7228] with limited capabilities and a short-distance constrained radio network, e.g., IEEE 802.15.4, might be used too 🫶

Every transport application will need an IT infrastructure to run on top of 🏗️ For example, in public-transport scenarios like trains, buses, or metro networks, the infrastructure might be provided, maintained, and operated by third parties like mobile-network or satellite-network operators. However, the management responsibility of the transport application typically rests with the organization running it (in the public-transport scenario, that would typically be the public-transport operator) 👑 Different parts of the infrastructure might also be managed by different entities. For example, the in-car devices are likely to be installed and managed by the manufacturer, while the local government or transportation authority might be responsible for the on-road vehicular communication infrastructure those devices use 🚗 The backend infrastructure is also likely to be maintained by third-party operators. So the NMS must be able to deal with different network segments (each one operated and controlled by a separate entity) and enable appropriate access control and security 🔐

Depending on the type of application domain (vehicular or stationary) and the service being provided, it is important for the NMS to be able to function with different architectures. Different manufacturers might have their own proprietary systems that rely on a specific management topology option, as described in [RFC7547] 💀

Constituents of the network can be private, belong to individuals or private companies, or be owned by public institutions, which leads to different legal and organizational requirements 🍓 Across the entire infrastructure, a whole variety of constrained devices is likely to be used, and they must be individually managed 🌸 So the NMS must be able to either work directly with different types of devices or have the ability to interoperate with multiple different systems 🙈

The challenges of managing vehicles in a mobile-transport application are honestly so many 😭 First, the up-to-date position of each node in the network should be reported to the corresponding management entities, since nodes could be moving within or roaming between different networks 📍 Second, a variety of troubleshooting information, including sensitive location information, needs to be reported to the management system so it can provide accurate service to the customer 🔥 Management systems dealing with mobile nodes could possibly exploit specific patterns in node mobility. These patterns emerge from repetitive vehicle usage, like people commuting to work or supply vehicles moving shipments between warehouses, etc. 🚚 The NMS must also be able to handle partitioned networks, which would arise from the dynamic nature of traffic, resulting in large inter-vehicle gaps in sparsely populated areas 🏜️ And since mobile nodes might roam in remote networks, the NMS should be able to provide operating configuration updates regardless of node location 🗺️

The constrained devices in a moving transport network might be initially configured in a factory, and reconfiguration might only be needed rarely 🏭 New devices might be integrated in an ad hoc manner based on self-management and self-configuration capabilities ✨ Monitoring and data exchange might be necessary via a gateway entity connected to the backend transport infrastructure 🛰️ The devices and entities in the transport infrastructure need to be monitored more frequently, and they may be able to communicate at a higher data rate ⚡ The connectivity of these entities does not necessarily need to be wireless 🔌 The time scale for detecting and recording failures in a moving transport network is likely measured in hours, and repairs might easily take days 🫠 It's likely that a self-healing feature would be used locally 🩹 On the other hand, failures in fixed transport-application infrastructure (e.g., traffic lights, digital-signage displays) are likely to be measured in minutes, so as to avoid untoward traffic incidents 🚦 So the NMS must be able to deal with differing timeliness requirements based on the type of device 🎯

Transport applications of constrained devices and networks deal with automotive vehicles, so malfunctions and misuse can potentially lead to safety concerns too 🚨 Besides access control, privacy of user data, and timeliness, management systems should also be able to detect situations that are potentially hazardous to safety 🫣 Some of these situations could be automatically mitigated (e.g., traffic lights with incorrect timing), but others might require human intervention (e.g., failed traffic lights) 🛑 The management system should take appropriate actions in these situations 💜 And maintaining data confidentiality and integrity is an important security aspect of a management system, since tampering (or malfunction) can also lead to potentially dangerous situations 🔒😤

4.9. Community Network Applications 🏘️

Okay so community networks are literally giving "neighborhood wifi but make it a whole mesh" 🫶✨ They're made of constrained routers in a multi-hop mesh topology, chatting over lossy, and often wireless, channels 📡. The routers are mostly non-mobile, but the topology can still be super dynamic 🌊 because link quality keeps fluctuating on the wireless channel, thanks to obstacles or other nearby radio transmissions. Depending on which routers the community uses, their resources (memory, CPU) can be more or less constrained 💅. We're talking anywhere from a few kilobytes of RAM up to several megabytes or more, and the CPUs might be small and embedded or more powerful general-purpose processors 🤖.

Some iconic examples are the FunkFeuer network (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless (Seattle, USA), and AWMN (Athens, Greece) 🌈. These networks are public and non-regulated, so users can connect to each other and, through an uplink to an ISP, to the Internet too 🌸. The only thing you pay for is the initial purchase of a wireless router, and that's it, no fee 💖. The applications are super diverse, like location-based services, free Internet access, file sharing between users, distributed chat services, social networking, video sharing, etc. 🦋

As a real example, the FunkFeuer network has several hundred routers, and a lot of them have several radio interfaces (with omnidirectional and some directed antennas) 🔥. The routers are small-sized wireless routers, such as the Linksys WRT54GL, which was available in 2011 for less than 50 euros 🍓. Each router, with 16 MB of RAM and 264 MHz of CPU power, gets mounted on the rooftop of a user 🏠. When a new user wants in, they acquire a wireless router, install the appropriate firmware and routing protocol, and mount the router on the rooftop 🧚. IP addresses for the router are assigned manually from a list of addresses, because there's a lack of autoconfiguration standards for mesh networks in the IETF 🙈.

Even though the routers are non-mobile, those link quality fluctuations mean they need an ad hoc routing protocol that converges quickly to reflect the effective topology of the network 💜. Examples are the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing version 2 (OLSRv2) [RFC7181], which were developed in the MANET WG ⭐. Usually no human interaction is needed for these protocols, because all the variable parameters are either negotiated in the control traffic exchange or are only of local importance to each router (meaning they don't influence interoperability) 🫶. Still, external management and monitoring of an ad hoc routing protocol may be desirable so you can optimize its parameters 🔥. Optimizing can lead to a topology that's perceived to be more stable and to lower control traffic overhead, which then means a higher delivery success ratio of data packets, lower end-to-end delay, and less unnecessary bandwidth and energy use 👑✨

Different use cases for managing community networks are possible, and they're all kind of main character energy 💅:

  • A single NMS, for example a border gateway providing connectivity to the Internet, needs to manage or monitor the routers in the community network, either to investigate problems (monitoring) or to improve performance by changing parameters (managing) 🎀. Because the topology is dynamic, constant connectivity from each router to the management station can't be guaranteed 😭. Current network management protocols, such as SNMP and Network Configuration Protocol (NETCONF), may be used (for example, through interfaces such as the NHDP-MIB [RFC6779]) 🧚. But when the routers are constrained, existing protocols may require too many resources in terms of memory and CPU, and, more importantly, the bandwidth requirements may exceed the available channel capacity in wireless mesh networks 💀. On top of that, management and monitoring may be unfeasible if the connection between the NMS and the routers is frequently interrupted 🙈.
  • Distributed network monitoring, where more than one management station monitors or manages other routers 🌸. Since connectivity to a server can't be guaranteed at all times, a distributed approach may provide higher reliability, but at the cost of increased complexity 🧩. Right now, no IETF standard exists for distributed monitoring and management 😤.
  • Monitoring and management of a whole network or a group of routers 🦋. Monitoring the performance of a community network may require more information than what you can get from a single router using a network management protocol 💜. Stats like topology changes over time, data throughput along certain routing paths, congestion, etc. are of interest for a group of routers (or the routing domain) as a whole 🌈. As of 2014, no IETF standard allows for monitoring or managing whole networks instead of single routers 🥲

4.10. Field Operations 🚨

The challenges of configuring and monitoring networks operated in the field by rescue and security agencies can be really different from the other use cases, because the requirements and operating conditions of these networks are quite different 🧭.

With technology advancing, field networks today are getting big and can include a variety of equipment types that run different protocols and tools, which obviously makes these mission-critical networks more complex 😵‍💫. In a lot of scenarios, configurations are most likely performed manually 🛠️.

Some legacy and even modern devices don't even support IP networking 💀. Most of the protocols and tools vendors use are proprietary, which makes integration harder 😩.

The main reason for this disjoint operation scenario is that most equipment is developed with specific task requirements in mind, rather than with interoperability across varied equipment types 🧩. For example, the operating conditions for high altitude security equipment are very different from desert conditions 🏔️🏜️. Likewise, equipment used in fire rescue has different requirements than flood-relief equipment 🔥🌊. And interoperation with telecommunication equipment was not an expected outcome, or (in some scenarios) may not even be desirable 🙅‍♀️.

Right now, field networks run with a fixed Network Operations Center (NOC) that physically manages the configuration and evaluation of all field devices 🏢. Once configured, the devices might be deployed in fixed or mobile scenarios 🚙. Any configuration changes required would need to be appropriately encrypted and authenticated to prevent unauthorized access 🔐🔥

Hierarchical management of devices is a common requirement in these scenarios, since local managers or operators may need to respond to changing conditions within their purview 👑. The level of configuration management available at each hierarchy must also be closely governed 🫡.

Since many field operation devices are used in hostile environments, a high failure and disconnection rate should be tolerated by the NMS, which must also be able to deal with multiple gateways and disjoint management protocols 💪🌪️.

Multi-national field operations involving search, rescue, and security are becoming increasingly common, which means a diverse set of equipment designed with different operating conditions in mind needs to interoperate 🌍✨. On top of that, different intra- and inter-governmental agencies are likely to have different standards, best practices, rules and regulations, and implementation approaches that may contradict or conflict with each other 🙃. The NMS should be able to detect these and handle them in an acceptable manner, which may require human intervention 🧠🫶

5. Security Considerations 💀🔐

This document discusses use cases for management of networks with constrained devices. The security considerations described throughout the companion document [RFC7547] apply here as well. So yes, the security stuff from [RFC7547] is totally still in play here, bestie, don't skip it 🚨💜

6. Informative References 📚

Here are all the references, copied exactly so you can find every single one 🫶

[RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
           Network (MANET) Neighborhood Discovery Protocol (NHDP)",
           RFC 6130, DOI 10.17487/RFC6130, April 2011,
           <http://www.rfc-editor.org/info/rfc6130>.

[RFC6568]  Kim, E., Kaspar, D., and JP. Vasseur, "Design and
           Application Spaces for IPv6 over Low-Power Wireless
           Personal Area Networks (6LoWPANs)", RFC 6568,
           DOI 10.17487/RFC6568, April 2012,
           <http://www.rfc-editor.org/info/rfc6568>.

[RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
           Managed Objects for the Neighborhood Discovery Protocol",
           RFC 6779, DOI 10.17487/RFC6779, October 2012,
           <http://www.rfc-editor.org/info/rfc6779>.

[RFC6988]  Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T.,
           and B. Claise, "Requirements for Energy Management",
           RFC 6988, DOI 10.17487/RFC6988, September 2013,
           <http://www.rfc-editor.org/info/rfc6988>.

[RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
           "The Optimized Link State Routing Protocol Version 2",
           RFC 7181, DOI 10.17487/RFC7181, April 2014,
           <http://www.rfc-editor.org/info/rfc7181>.

[RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
           Constrained-Node Networks", RFC 7228,
           DOI 10.17487/RFC7228, May 2014,
           <http://www.rfc-editor.org/info/rfc7228>.

[RFC7326]  Parello, J., Claise, B., Schoening, B., and J. Quittek,
           "Energy Management Framework", RFC 7326,
           DOI 10.17487/RFC7326, September 2014,
           <http://www.rfc-editor.org/info/rfc7326>.

[RFC7547]  Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and U.
           Herberg, "Management of Networks with Constrained Devices:
           Problem Statement and Requirements", RFC 7547,
           DOI 10.17487/RFC7547, May 2015,
           <http://www.rfc-editor.org/info/rfc7547>.

[IOT-SEC]  Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
           R. Struik, "Security Considerations in the IP-based
           Internet of Things", Work in Progress, draft-garcia-core-
           security-06, September 2013.

[IEEE802.11]
           IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
           and Physical Layer (PHY) Specifications", IEEE Standard
           802.11, March 2012,
           <http://standards.ieee.org/about/get/802/802.11.html>.

[IEEE802.15]
           IEEE, "WIRELESS PERSONAL AREA NETWORKS (PANs)", IEEE
           Standard 802.15, 2003-2014,
           <https://standards.ieee.org/about/get/802/802.15.html>.

[IEEE802.15.4]
           IEEE, "Part 15.4: Low-Rate Wireless Personal Area Networks
           (LR-WPANs)", IEEE Standard 802.15.4, September 2011,
           <https://standards.ieee.org/about/get/802/802.15.html>.

Acknowledgments 🫶

okay so the authors wanted to give a shoutout to everyone who reviewed this doc and dropped valuable comments while it was being made 💖 bestie these are the legends:

Dominique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert Greevenbosch, Ulrich Herberg, Ted Lemon, Kathleen Moriarty, James Nguyen, Zach Shelby, Peter van der Stok, and Martin Thomson 👑

they also said thank you to the reviewers and the people on the Coman mailing list 🦋 their input was literally so important ✨

and Juergen Schoenwaelder and Anuj Sehgal got some funding help from Flamingo, which is a Network of Excellence project (ICT-318488) backed by the European Commission under its Seventh Framework Programme 🌈 iconic funding moment

Contributors 🎀

these folks made significant contributions to the doc and reviewed it too, so they get their own spotlight 🧚

  • Ulrich Herberg contributed Section 4.9, "Community Network Applications" 🌸
  • Peter van der Stok contributed to Section 4.6, "Building Automation" 🏠
  • Zhen Cao contributed to Section 2.2, "Cellular Access Technologies" 📡
  • Gilman Tolle contributed Section 4.4 "Energy Management" ⚡
  • James Nguyen and Ulrich Herberg contributed to Section 4.10 "Field Operations" 💅

the whole crew absolutely slayed this one 💜

Authors' Addresses 💌

here's where you can reach the authors. Mehmet Ersue is the editor, and he's at Nokia Networks 🍓 mehmet.ersue@nokia.com

Dan Romascanu is at Avaya 🦋 dromasca@avaya.com

Juergen Schoenwaelder is at Jacobs University Bremen 🌟 j.schoenwaelder@jacobs-university.de

Anuj Sehgal is also at Jacobs University Bremen 🎓 s.anuj@jacobs-university.de

that's the whole document, bestie 😭✨ the authors are literal icons and this RFC is a whole vibe 🔥💖

📦 where this page comes from